CDN Migration Guide: How to Change Providers Without an Outage

The safest CDN migration keeps the public URLs unchanged and treats the new provider as a parallel production path. Build and test the new configuration, lower DNS TTL in advance, switch traffic in controlled stages, monitor both providers and the origin, and retain a tested rollback. Google describes this as a hosting change without URL changes: prepare the new infrastructure, update DNS, monitor traffic, and shut down the old provider only after users and Googlebot are receiving the content correctly.

Before the migration: define the blast radius

Create an inventory of every hostname and traffic class. Include HTML, APIs, images, downloads, video, WebSockets, streaming, authentication, webhooks, robots.txt, XML sitemaps, redirects, and health endpoints. Record the current DNS records and TTLs, TLS certificates, origin addresses, firewall allowlists, host headers, compression, HTTP versions, cache rules, cookies, query handling, range requests, WAF rules, bot policies, purge workflows, and log exports.

Capture a baseline from the public edge and the origin:

• Status and redirect chain for representative URLs.
• Response headers, content type, body checksums, and cache status.
• DNS, TLS, connection, time-to-first-byte, and total response timing.
• RUM by page type, region, device, and release.
• Synthetic checks for important journeys and failure modes.
• Origin load, error rate, bandwidth, and request distribution.

The goal is not to make the new provider look good in isolation. It is to prove that the old and new paths behave the same where they should, and to identify intentional improvements separately from migration risk. The managed CDN overview covers the delivery concerns worth making explicit.

Prepare the new provider

1. Reproduce content and routing rules

Import the hostname and path model, then review every rule instead of assuming an export is complete. Verify origin selection, host header, SNI, HTTP method handling, query-string normalization, cookie pass-through, authentication, CORS, compression, and content negotiation. Confirm that dynamic responses are not cached and that static assets have the intended cache policy.

Keep the origin reachable by both providers during the migration. Update firewall allowlists and health checks before traffic moves. If the origin sees a provider-specific header or client IP format, test the application and security rules with both forms.

2. Configure TLS and DNS safely

Issue and validate certificates for every production hostname, including alternate hostnames and any API or asset domain. Test certificate chain, protocol support, redirects from HTTP to HTTPS, and origin certificate verification. A certificate that works on a temporary hostname does not prove that the production SNI and host mapping are correct.

Lower the relevant DNS TTL to a conservative value, ideally well before the change. Google recommends lowering it to a few hours at least a week before a hosting move so resolver caches refresh faster. TTL affects how quickly new answers propagate, but it does not force every resolver or existing connection to change immediately. Keep the old provider serving during that window.

3. Test through a controlled hostname

Use a temporary hostname or an internal routing mechanism to send test requests through the new edge. If the hostname is publicly reachable, prevent accidental indexing with an appropriate noindex control and keep it out of public links and sitemaps. Test real URLs and representative query strings, not only a static placeholder.

Compare old and new responses from several locations, with cold and warm cache states. Check HTML language and canonical tags, security headers, cookies, redirects, range responses, error pages, cache age, and purge behaviour. Test a controlled failure: make the origin slow or unavailable in a non-production environment and confirm that the new path times out, fails over, or serves a deliberately configured stale response without exposing sensitive content.

Cut over in stages

1. Freeze unrelated changes. Avoid combining a CDN migration with a redesign, domain change, application release, or large cache-policy rewrite.
2. Open the change window. Confirm owners, provider contacts, dashboards, test URLs, rollback commands, and the stop conditions.
3. Canary traffic. Use a capability that supports a controlled split, a low-risk hostname, or a limited region. DNS-only weighting can be imprecise because recursive resolvers cache answers, so measure actual traffic rather than assuming the percentage is exact.
4. Compare live signals. Watch status by path, TTFB, origin load, cache hit ratio, bandwidth, TLS errors, WAF actions, RUM, and synthetic journeys. Compare the new path with the baseline, segmented by geography and device.
5. Increase gradually. Move traffic in steps only when the previous step is stable for a meaningful observation window. Include a peak or representative workload before declaring success.
6. Keep the old provider active. Do not cancel the account, remove firewall access, or delete configuration while DNS caches and long-lived client connections still exist.

For resilience beyond a one-provider cutover, review Multi CDN. A multi-provider design still requires consistent cache, purge, security, and observability rules; adding a second provider does not remove operational complexity.

Rollback and post-migration validation

If the new path fails, restore the old DNS answer or routing weight, then confirm from multiple resolvers and regions that traffic is returning. Remember that DNS rollback is not instantaneous. Monitor both providers until old traffic rises and new traffic falls. Purge only when you know which provider holds the bad object; an indiscriminate purge can create an origin surge during an incident.

After the cutover, keep a migration dashboard for at least one normal traffic cycle and one peak period. Check Search Console crawl and index signals, server logs for Googlebot, status distributions, redirect rates, cache errors, and origin capacity. Google notes that a temporary Googlebot crawl-rate drop can occur after a hosting change, followed by a gradual recovery if the new infrastructure remains available and responsive.

When the evidence is stable, remove temporary test controls, update documentation and runbooks, verify DNS and certificate renewal ownership, and only then retire the old provider. If the migration also changes URLs, stop and follow a separate site-move plan: a provider change alone should not introduce redirects or canonical changes.

Common mistakes

• Treating DNS propagation as a precise, instant traffic switch.
• Migrating only the home page while APIs, assets, downloads, or WebSockets still use old rules.
• Forgetting origin firewall allowlists or changing the forwarded host and client IP semantics.
• Copying cache rules without reviewing cookies, query strings, authorization, and content negotiation.
• Testing the new provider only with a cold cache or from one region.
• Allowing a temporary test hostname to be indexed or linked publicly.
• Combining the migration with a URL change and then debugging SEO and infrastructure symptoms at once.
• Shutting down the old path before DNS caches, logs, and long-lived connections have settled.

Use the RUM versus synthetic monitoring guide to design the comparison dashboard, and the web performance budget guide to define performance stop conditions. For a migration review covering edge, SEO, and rollback, contact Optimi.

There are only two hard things in Computer Science: cache invalidation and naming things.