Reblaze to Cloudflare: a 300-domain iGaming estate, rebuilt as an operating model.

DNS was included in the migration scope from the beginning. For 300 domains, leaving DNS behind on a separate legacy operating model would have preserved unnecessary complexity after the edge migration. Moving DNS to Cloudflare gave the customer one place to manage authoritative DNS and the Cloudflare security and delivery controls that depended on it.

The migration work included reviewing the existing records, validating required dependencies and moving the zones into the target Cloudflare structure. The important point was not merely that records existed after the move — the team needed confidence that the new DNS state still represented the applications correctly. That is why DNS validation was tied directly to the ingress and zone mapping work.

With hundreds of domains, origin and ingress addresses cannot be treated as isolated infrastructure objects. Nanosek built a mapping between ingress IPs and Cloudflare zones — a practical application map rather than a collection of disconnected DNS records.

The mapping also made future troubleshooting safer. When an ingress issue occurred, the operational team could identify the affected zones deliberately instead of searching through hundreds of configurations during an incident.

Rate limiting was a core security requirement for the new environment. Nanosek implemented Cloudflare Advanced Rate Limiting rather than relying only on simple global request thresholds.

For an iGaming estate, a single “requests per IP” rule is rarely enough. Different endpoints can have very different traffic profiles, and abusive behavior may target authentication flows, APIs or other sensitive application functions while staying below broad volumetric thresholds.

The rate-limiting design therefore focused on the behavior being protected and the scope of the rule, rather than using one threshold across all 300 domains. That gave the customer a stronger control plane for responding to abuse while reducing the risk of overly broad limits affecting legitimate traffic.

The new Cloudflare environment also included Cloudflare for SaaS. That meant the migration needed to account for more than the directly managed primary zones — SaaS hostnames had to fit into the same certificate, security and operational model as the rest of the estate.

Nanosek incorporated Cloudflare for SaaS into the platform design instead of treating it as a separate project after the main migration. This was particularly important in a large domain environment, where manually handling every hostname as a one-off configuration would not scale operationally.

Large migrations can become inconsistent very quickly. The first group of zones receives careful engineering, while later zones are sometimes onboarded under deadline pressure with exceptions and temporary settings that eventually become permanent.

Nanosek used the migration to establish and apply a Cloudflare best-practice baseline across the estate — reviewing how controls should be structured, where policies should be reusable and where application-specific exceptions were genuinely required.

A mature 300-domain environment should be able to explain why one zone is configured differently from another.

A migration is incomplete if the only way to know that something is wrong is for an end user to report it. Nanosek configured the operational layer alongside the Cloudflare migration, including notifications, alerts and monitoring for events that required attention.

This gave the customer visibility into the new platform and provided a basis for continuous operational support after the initial migration work was complete. The goal was to make important changes and abnormal conditions observable, while avoiding an alerting model so noisy that operators would learn to ignore it.