Migrating a Live Casino to Private Anycast Without Downtime

Q: What does a zero-downtime Anycast cutover actually mean?

It means production traffic moves from your current provider to your new private Anycast edge in a controlled, reversible sequence — a small percentage first, validated, then progressively more — rather than a single DNS flip that sends 100% of traffic to an unproven network at once. 'Zero downtime' describes the goal of the sequence, not a guarantee that nothing can go wrong; the rollback path is what makes the goal achievable.

Q: How long does the cutover itself take, separate from building the network?

The cutover phase typically runs a few days to two weeks after the Anycast edge is built and validated — shorter for a single-jurisdiction operator on one primary domain, longer for a multi-brand or multi-license operator cutting over several domains and API endpoints in sequence. This is separate from and after the 2–4 week build described in building a private Anycast edge from scratch.

Q: What triggers a rollback during a live cutover?

Anything that moves a pre-agreed metric past its threshold during an observation window: elevated error rates on the new path, latency regression versus the old provider's baseline, failed health checks at a PoP, or a support/ops signal that something is visibly wrong for players. The rollback itself is a route withdrawal or a traffic-steering weight change back to the old provider — it should take minutes, not a war-room debate about whether to do it.

Q: Do we have to keep paying for the old provider during the migration?

Yes, for the duration of the cutover window. Running both paths in parallel — the old provider still fully live, the new Anycast edge taking a growing share of traffic — is what makes the migration reversible. Cancelling the old contract before the new edge has absorbed 100% of traffic for a full observation period removes your rollback option, which defeats the point of a phased cutover.

Q: Is this the same engagement as building the private Anycast network?

No. Building the network — ASN registration, IP-block allocation, PoP deployment, BGP peering — is covered in building a private Anycast edge from scratch and is what our Global Private Anycast Network Setup engagement delivers. This post is the operational runbook for the step after that: moving your live, revenue-generating traffic onto the network you just built without an outage.

The short answer

A zero-downtime cutover to a private Anycast network is a phased, reversible traffic shift, not a single DNS change. You run the old provider and the new Anycast edge in parallel, move a small percentage of traffic first, watch a fixed set of metrics against pre-agreed thresholds, and only increase the share once each step holds. Every step has a rollback that's a route withdrawal or a traffic-weight change, not a scramble — because the plan assumed from the start that some step might need to be reversed.

Who this is for

This is for the infrastructure or SOC lead at a casino or sportsbook operator who has already gone through the decision covered in building a private Anycast edge from scratch — the ASN is registered, the IP blocks are allocated, the PoPs are up, BGP is peering — and is now looking at the harder question: how do you move live, real-money traffic onto that network without a support ticket storm or a night of downtime.

It's not for the earlier decision of whether to build a private edge at all — that trade-off, including who the network makes financial and operational sense for, is the subject of the article linked above. This post assumes the network exists and is already validated for throughput and failover; it's about the traffic-move itself.

Multi-brand and multi-license operators have an extra wrinkle worth naming up front: if you hold licenses across several jurisdictions and run each on its own domain or sub-brand, the cutover isn't one event, it's a sequence of them — one brand at a time, in an order chosen by traffic volume and regulatory sensitivity, not alphabetically. Cutting your smallest, least-regulated brand over first and treating it as a live rehearsal for the higher-stakes ones is the pattern that shows up most often in practice.

Scope: what's actually moving

A casino's production surface usually isn't one thing to cut over — it's several, each with a different blast radius if it breaks:

The public site and static assets — lowest risk, most cacheable, the natural first candidate for the initial traffic slice.
The authenticated player surface — login, session cookies, account pages. Higher risk: a routing mistake here shows up as players getting logged out or seeing stale session state.
The cashier and payments API — deposit, withdrawal, balance calls. The highest-consequence surface; a dropped or misrouted request here is a support ticket and, at volume, a compliance question.
Live-odds and in-play websocket connections — long-lived connections that don't tolerate a mid-session route flap the way a stateless HTTP request does; these need their own cutover sequencing, usually last.

Treating these as one flat "the domain" migration is the most common planning mistake. Each surface gets its own slice of the phased rollout below, not necessarily on the same day.

The cutover, phase by phase

Phase	What happens	What you're watching
Dual-run setup	New Anycast edge goes fully live in parallel with the existing provider, serving zero real traffic — a shadow deployment	Health checks green at every PoP; synthetic monitoring from multiple regions matches expected latency
DNS TTL reduction	TTLs on the domains being migrated are lowered ahead of the cutover window, so a rollback DNS change actually propagates fast when you need it to	TTL confirmed low in resolver caches, not just in your zone file
Canary slice (1–5%)	A small, real percentage of traffic is steered onto the new edge — public site and static assets first, cashier/websocket last	Error rate, latency percentiles, and origin health on the canary slice versus the baseline on the old provider
Progressive ramp	Traffic share increases in fixed steps (for example 5% → 25% → 50% → 100%), with an observation window and an explicit go/no-go decision at each step	Same metrics as the canary, now at each new share level, plus support-ticket volume as a human-signal check
Old-provider decommission	Only after 100% of traffic has run clean on the new edge for a full observation period — a day, not an hour — is the old provider's routing actually removed	Sustained clean metrics at 100%; no lingering DNS records or health-check dependencies still pointing at the old path

The mechanism underneath the traffic-share steps is ordinary weighted traffic steering — the same primitive Cloudflare documents for its own load balancers, where "customers can also set Weights on pools via the API's random_steering object to determine the percentage of traffic sent to each pool." Whether the steering sits in DNS, in a load balancer in front of both paths, or in BGP path preference depends on what's being migrated; the principle — a percentage, not a binary switch — is the same at every layer.

The rollback path, and why it has to be built first

A cutover plan that doesn't specify the rollback in the same level of detail as the forward path isn't a plan — it's a hope. Two mechanisms cover most rollback scenarios:

At the traffic-steering layer: reversing a weighted-steering change is the same action as making it — set the new edge's weight back toward zero and the old provider's weight back up. This is fast because it's the same lever, not a different one.

At the BGP layer, if the migration involves announcing and withdrawing routes rather than just steering DNS or load-balancer weights, RFC 8326 standardizes exactly this situation — a planned, deliberate route withdrawal rather than an unplanned outage. The RFC's abstract describes "a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths," and the mechanism works by tagging the paths being withdrawn with a lowered LOCAL_PREF value so that alternate paths take over before the session actually closes — the opposite of an abrupt route pull that drops in-flight connections. It's designed for planned maintenance, but a controlled cutover rollback is exactly that: planned, not an emergency.

The rule that makes both of these usable under pressure: decide the rollback trigger conditions before the cutover window starts, in writing, not during it. If a step's error-rate or latency threshold is crossed, the rollback executes — it isn't a debate convened mid-incident about whether the numbers are "bad enough."

What to rehearse before the real cutover

The single highest-leverage thing a team can do before a live cutover is run the entire sequence — canary, ramp steps, and a deliberate rollback — against a non-production copy of the traffic first. This surfaces the problems a runbook document alone won't: a health check that's misconfigured to always report healthy, a monitoring dashboard that's actually looking at the wrong pool, an on-call engineer who doesn't actually have the access needed to execute the rollback step assigned to them.

Rehearsal also answers the question every stakeholder asks before signing off on a migration window: who owns each phase, and what's their explicit go/no-go authority. A phase without a named owner is a phase where the rollback decision gets made by committee at 2am, which is the outcome the whole plan exists to avoid.

The other output of a rehearsal is a communication plan, and it's easy to skip because it isn't a technical artifact. Support and community teams need to know the migration window in advance, what a player-visible symptom of a problem would actually look like (a stuck deposit, a dropped websocket mid-bet), and who to escalate to — not the general on-call rotation, but the specific engineer who owns the phase currently in flight. A cutover that's technically clean but catches your own support desk off guard still generates the tickets and social-media noise of an outage, even though the infrastructure never actually went down.

Limitations

This is the traffic-cutover runbook, not the network build — see building a private Anycast edge from scratch for ASN registration, IP-block allocation, PoP selection, and BGP peering setup, and the Global Private Anycast Network service page for what the build engagement delivers. It also doesn't cover DDoS mitigation tuning on the new edge — that's a separate hardening pass, ideally done before real traffic lands on it, covered under DDoS Protection. And it assumes the network you're cutting over to has already passed its own throughput and failover validation; cutting live traffic onto an edge that hasn't been stress-tested is a different, much larger risk than anything covered here.

Decision: plan the rollback before you plan the cutover

If you've built or are building a private Anycast edge and the open question now is how to move live traffic onto it without an incident, request a network design review and we'll scope the cutover sequence — phases, thresholds, and rollback triggers — against your actual traffic surfaces.

Frequently asked questions

What does a zero-downtime Anycast cutover actually mean? A controlled, reversible traffic shift — a small percentage moved first, validated, then progressively more — rather than a single DNS flip sending all traffic to an unproven network at once.

How long does the cutover itself take, separate from building the network? A few days to two weeks after the edge is built and validated, depending on how many domains and API surfaces are being moved.

What triggers a rollback during a live cutover? Any pre-agreed metric — error rate, latency, failed health checks — crossing its threshold during an observation window. The rollback is a route withdrawal or a traffic-weight change back to the old provider.

Do we have to keep paying for the old provider during the migration? Yes, for the cutover window — running both paths in parallel is what makes the migration reversible.

Is this the same engagement as building the private Anycast network? No — the build (ASN, IP blocks, PoPs, BGP peering) is a separate, earlier engagement. This is the runbook for moving live traffic onto a network that's already built.

Sources

RFC 8326 — Graceful BGP Session Shutdown, IETF, 2018 — the GRACEFUL_SHUTDOWN community mechanism underlying the BGP-layer rollback described above.
Cloudflare Load Balancing — Standard Steering Policies, Cloudflare Developer Docs — the weighted traffic-steering primitive referenced in the phase table.