Shifting traffic from one CDN to another is a solved problem: change a weight, wait a TTL. Shifting it while a logged-in user keeps their cart, a player keeps its stream and an upload keeps its progress is the actual engineering — and it is done or not done long before the incident. “Seamless failover” is a property of how sessions, tokens and connections were designed, verified by a drill; the day itself only reveals the answer.
What “dropping a session” actually means
Be precise about the failure modes, because each has a different owner. A user can be logged out (session state was bound to the edge); shown errors (the new edge enforces different rules — a parity failure); served a certificate warning (the new edge lacks a valid cert); stuck on the dead platform (a resolver still answering old records — the DNS tail); or cut mid-operation (a long-lived connection that cannot survive any switch). The first two are design debts, the third is estate hygiene, the fourth is physics to accommodate, and the fifth is a class of traffic needing explicit handling. A failover plan is just these five, answered in advance — and the answers below are also why the steering guide insists both platforms stay fully valid during any drain.
Make sessions edge-independent
The rule: no session truth may live at the edge. Authentication rides signed cookies or tokens validated against your application, not any CDN’s session feature; carts and user state live in your backend keyed by that token; anything an edge worker stores in vendor-side state (KV stores, durable objects) must be reconstructible from the origin, or it is a session-dropper by design — one of the portability stakes catalogued in edge compute without lock-in. The test is beautifully simple and belongs in your suite: perform a real user journey (log in, add to cart, begin checkout) through platform A, switch resolution to platform B mid-journey, and continue. If step seven works on the other edge, sessions are edge-independent; if it doesn’t, you have found the debt on a Tuesday instead of during the outage.
Tokens, certificates and cache warmth
Three estate properties decide whether the receiving platform is actually ready. Tokens: signed URLs and cookies issued minutes ago on platform A must validate on platform B — same scheme, same keys, dual-key rotation windows coordinated across both, per the compatibility work in security parity; an incompatible token scheme converts failover into a mass 403. Certificates: every hostname, valid on both platforms, always — renewal automation monitored per platform, as the estate guide details, because a lapsed cert on the standby is failover’s most humiliating failure. Warmth: the receiving cache may be cold (fully, in active-passive; partially, in a lopsided split), so the switch lands a miss-storm on the origin exactly when nerves are already frayed — know the number in advance from your drill, protect the origin with shield and collapsing per origin-load reduction, and consider automated warming of the critical object set as part of the failover script itself.
The connection tail: websockets, uploads, streams
DNS-based switching never touches established connections — a websocket, a long upload or an open video session on platform A continues on platform A until it ends or breaks. That cuts both ways. It means failover is gentler than feared for ongoing work (nothing is actively severed by the weight change), and it means a genuinely dead platform hard-drops that tail with no remedy at the DNS layer — recovery must come from clients. So build reconnection as a first-class behaviour: websocket clients that re-resolve and re-establish with backoff (landing on the healthy platform automatically), uploads that resume by ranges rather than restart, and players that re-fetch manifests on segment failure — which for video graduates into per-segment client-side switching, the pattern that makes mid-stream platform failure a non-event and gets its own setup guide. Inventory your long-lived connection classes now; each needs exactly one sentence in the plan: how does it re-establish, and did we test it?
The failover drill, timed and scored
Everything above is a claim until drilled. Quarterly, in a low-traffic window, run the real thing: drain platform A by weight (or health-check trip), and measure — time to traffic majority on B, residual tail curve on A, error-rate delta during the window, origin load peak, and the session journeys from section two performed live across the switch, including one of each long-lived connection class. Score it, fix what failed, and record the timings, because those numbers are the difference between an incident commander saying “traffic completes moving in about four minutes, origin peaks at 2×, sessions hold” and saying “we think it should work.” Then wire the trigger: who or what decides to fail over, on what evidence, per the decision tree in the outage playbook — because the estates that fail over well are simply the ones where the incident-day action is a rerun of last quarter’s rehearsal.