Leaving a CDN is your original migration run in reverse — except this time there is a live audience, a working incumbent to measure against, and usually a contract clock. The playbook that removes the drama: run the move as a temporary multi-CDN estate, prove the destination in shadow, shift traffic in observed percentage waves with the return path held open, and only decommission when the numbers — not the calendar — say done.
Migration is temporary multi-CDN
The reframe that makes everything easier: for the weeks of the move you are simply operating two CDNs, so every multi-CDN discipline on this site applies verbatim — certificates valid on both platforms throughout (the estate guide), configuration expressed once and generated per platform (config sync — and if the source config only exists as years of dashboard archaeology, the intent-extraction is honestly half the migration), tokens validating identically on both edges, and steering by weighted DNS (the steering setup). Timing note: start well before the renewal deadline the move is probably serving — the leverage of a demonstrated, partially-executed migration at the negotiating table is itself worth the early start, whichever way the negotiation ends.
Phase 1: build and prove the destination
Before a single user touches the new platform, build it to full parity and prove it in shadow. The proof stack, in rising order of confidence: the cross-edge test suite passing against the destination (every path class, cache behaviour, header, redirect, token check); shadow traffic replay and response diffing per shadow testing, which finds the semantic differences no checklist anticipates — query handling, Vary treatment, range quirks; and a synthetic performance baseline from the regions you care about, run fairly per the benchmarking method, so “is the new platform slower?” has a pre-answered baseline instead of a mid-migration panic. Exit criteria for the phase, written down: parity suite green N consecutive days, shadow diff rate below an agreed threshold with every residual diff explained, performance within tolerance. Teams that skip written exit criteria discover them retroactively, during the ramp, as incident titles.
Phase 2: the percentage ramp
Move traffic in waves, each held long enough to trust: an initial low-stakes slice (internal hostnames or a low-single-digit weight), then roughly 10 → 25 → 50 → 75 → 100, holding each step across at least one full daily traffic cycle — and across a weekend at one of the middle steps, because weekly patterns surface load shapes daily ones hide. At every step watch four families: error rates by path class on the new platform; cache hit ratio as its cache warms (expect the curve, know its shape from phase 1); origin load, which transiently rises while both platforms miss independently — the standard dilution effect, shield and collapsing verified in advance per origin-load reduction; and real-user metrics cut by platform, because RUM comparing the two live populations is the migration’s honest scoreboard. The rollback rule is pre-agreed and unheroic: any step that breaches thresholds gets its weight reverted first and diagnosed second — reverting a weight costs a minute; diagnosing under full load costs an evening.
Phase 3: the tail, the stragglers, the freeze
At 100% by weight, you are not done — you are at the start of the tail. Resolver stragglers keep arriving at the old platform for days (the TTL reality from the steering guide), long-lived references die slowly — hardcoded URLs in emails, apps pinned to old hostnames, partners who cached your integration docs — and every one of them still expects working responses. So the old platform stays fully configured and serving until its traffic decays to a measured floor: watch its request logs, chase the residual sources you control (app releases, partner notices), and keep certificates renewing on both platforms throughout — a cert lapsing on the “finished” side mid-tail is the classic migration face-plant, doubly cheap to avoid now that lifetimes are short. Meanwhile freeze scope: no new features, no config experiments on either platform until decommission — a migration is one variable; keep it that way.
Phase 4: decommission without burning bridges
Decommission is a checklist, executed deliberately once the tail is at the floor: export and archive the old platform’s final configuration and logs (you will want both — for the audit trail and for the occasional “how did we handle X before?”); remove the old platform’s ranges and credentials from origin allowlists and secret stores, per the hygiene habits of origin protection; update the estate documentation and the DNS to remove dead targets (a dangling CNAME to a released CDN hostname is a takeover invitation — the exact finding the quarterly audit hunts); and close the account cleanly against the contract’s notice terms. Then the last, easily-skipped step: the retrospective with numbers — planned versus actual timeline, what shadow testing caught versus what the ramp caught, what the old platform did better (there is always something; it belongs in the new platform’s backlog or the next selection’s criteria). Estates migrate more than once; the playbook that improves each time is the one that got written down.