CDN Migration Guide: Switching Providers Without Downtime

Migrating from one CDN provider to another is one of the most consequential infrastructure changes an organization can make. Every HTTP request your users make flows through the CDN layer, so a botched migration means downtime, broken SSL, stale content, and frustrated users. Yet migrations happen regularly—driven by cost optimization, feature needs, performance requirements, or contract renegotiation. For a comprehensive overview, see our guide on CDN Monitoring and Observability: Metrics That Matter — FlyFish NWA.

The good news: a methodical migration with parallel running and DNS-based cutover achieves zero downtime. This guide provides the step-by-step playbook, from pre-migration planning through post-cutover validation, with specific attention to the failure modes that catch teams off guard.

What Should the Pre-Migration Checklist Cover?

Migration planning starts weeks before the first DNS change. The pre-migration phase determines whether the cutover will be smooth or chaotic.

Feature inventory. Document every feature you use on the current CDN: caching rules, page rules, redirects, custom headers, edge functions, WAF rules, rate limiting, bot management, image optimization, and SSL configuration. Create a spreadsheet mapping each feature to its equivalent on the new provider. Identify any features without a direct equivalent—these are your migration risks.

Domain inventory. List every domain and subdomain that routes through the current CDN: apex domains, www, CDN-specific subdomains (cdn.example.com, static.example.com), API subdomains, and custom domains for SaaS tenants. Each domain needs a separate migration plan for DNS and SSL. See CDN for SaaS for multi-tenant domain migration considerations.

Performance baseline. Establish current performance metrics before migration: cache hit ratio by content type, TTFB by region (p50, p95, p99), error rates, and origin load. These become your success criteria—the new CDN must match or exceed these baselines. Use Real User Monitoring data for the most accurate baselines.

Timeline. Plan for 2–6 weeks end-to-end. Week 1: new CDN configuration and feature mapping. Weeks 2–3: parallel running and cache warming. Day X: DNS cutover. Weeks 4–5: post-migration validation. Do not rush—a migration under time pressure is a migration that fails.

How Do You Plan the DNS Cutover Strategy?

DNS is the control plane for CDN migration. The cutover strategy determines whether the transition is seamless or introduces downtime.

Lower TTL in advance. Two weeks before migration, reduce DNS TTL from its typical 3600 seconds (1 hour) to 300 seconds (5 minutes) or lower. This ensures that when you change the DNS record to point to the new CDN, the old record expires from resolver caches within minutes, not hours. After migration completes, raise TTL back to normal.

CNAME swap. If your domain uses a CNAME to the CDN endpoint (e.g., www CNAME old-cdn.example.net), the cutover is a single DNS record change: update the CNAME target to new-cdn.example.net. This is the simplest and safest cutover method.

Weighted DNS routing. For gradual cutover, use weighted DNS (supported by Route 53, NS1, and others) to send a percentage of traffic to the new CDN. Start at 5%, monitor for 24 hours, increase to 25%, then 50%, then 100%. This approach catches problems with minimal blast radius but extends the migration window. During the split, both CDNs must be fully configured and active.

Apex domain considerations. Apex domains (example.com without www) cannot use CNAME records per DNS standards. Options: use the new CDN provider's DNS with CNAME flattening (Cloudflare, NS1), use ALIAS/ANAME records if your DNS provider supports them, or migrate DNS hosting to the new CDN provider. This is often the most complex part of the migration for organizations with apex domain traffic.

How Do You Run Both CDNs in Parallel?

Parallel running is the safety net that makes zero-downtime migration possible. Both CDNs serve production traffic simultaneously, allowing you to validate the new CDN before committing.

Configuration replication. Replicate your entire CDN configuration on the new provider: caching rules, security rules, redirects, headers, and edge functions. Use infrastructure as code if possible—export the old configuration, transform it to the new provider's format, and apply via Terraform or API.

Origin configuration. Both CDNs must point to the same origin servers. Ensure your origin can handle the combined load of cache-miss traffic from two CDN providers during the parallel period. If your origin uses IP allowlisting, add the new CDN's edge IP ranges to the allowlist before starting parallel running.

Testing via host header. Before routing any real traffic, test the new CDN by sending requests with a custom host header or by overriding DNS locally (editing /etc/hosts). Verify: correct content is served, cache headers are correct, SSL terminates properly, redirects work, and WAF rules fire appropriately. Use the CDN Testing Strategies guide for a comprehensive test plan.

How Do You Warm the New CDN Cache Before Cutover?

A cold CDN cache means the first visitors after cutover experience cache misses—every request hits origin, resulting in higher latency and potentially overwhelming the origin server.

Extract popular URLs. Analyze your CDN logs from the current provider to identify the top 1,000–5,000 most-requested URLs. These account for the vast majority of traffic due to the power-law distribution of web content popularity.

Crawl from multiple regions. Send synthetic requests to the new CDN from edge locations in your key regions (US, EU, APAC at minimum). Each PoP caches independently, so you need to warm from each geographic region where you have significant traffic. Tools like curl with DoH (DNS over HTTPS) can target specific CDN PoPs.

Warm critical paths first. Prioritize: homepage, top landing pages, login/signup pages, API health endpoints, and your most popular content. These are the pages most likely to be hit immediately after cutover and most visible to users and monitoring systems.

Verify cache population. After warming, spot-check URLs by requesting them through the new CDN and inspecting response headers. Look for cache HIT status, correct Cache-Control headers, and expected content. A warm cache should show 90%+ hit ratio for the warmed URLs.

How Do You Migrate SSL Certificates?

SSL migration is the highest-risk step. Certificate errors are immediately visible to users and cannot be "retried"—browsers block the connection entirely.

Automatic certificate provisioning. Most CDN providers automatically provision SSL certificates (via Let's Encrypt) when you add a domain. Verify that certificates are issued and valid before cutover. Certificate provisioning requires DNS validation (a TXT or CNAME record proving domain ownership) or HTTP validation (a file served at a specific path). Complete validation before changing production DNS.

Custom certificates. If you use custom (purchased) certificates, upload them to the new CDN. Verify: the certificate chain is complete (leaf + intermediate + root), the private key matches the certificate, the certificate covers all required domains (including wildcards), and the expiration date is not imminent.

HSTS considerations. If your site uses HTTP Strict Transport Security with a long max-age, SSL downtime is catastrophic—browsers will refuse to connect over HTTP as a fallback. Double-check certificate validity on the new CDN before cutover, and ensure the new CDN serves the same HSTS header.

Certificate monitoring. Set up certificate expiration monitoring for all domains on the new CDN immediately after migration. Certificates that auto-renew usually work, but DNS or configuration changes during migration can silently break the renewal mechanism. A certificate that was valid at cutover may fail to renew 60–90 days later.

What Should You Monitor During Migration?

Monitoring during the migration window must be more granular and more frequent than normal operations. Set up these specific monitors before starting the cutover.

Real-time metrics. Watch: error rate (4xx and 5xx) compared to baseline, TTFB at p50 and p99 by region, cache hit ratio on the new CDN, origin request rate (should decrease as the new CDN cache warms), and SSL certificate validity for all domains.

Synthetic monitoring. Run synthetic checks from multiple geographic locations every 60 seconds against both the old and new CDN. Compare response times, content correctness (hash the response body), and header accuracy. Any divergence triggers an alert.

User-facing monitoring. Enable Real User Monitoring (if not already active) to detect client-side issues that synthetic monitoring misses: mixed content warnings, CORS failures, broken images, and JavaScript errors from CDN URL changes.

Communication. Notify your operations team, customer support, and key stakeholders before starting the cutover. Provide a timeline, expected impact (none, if the migration goes well), and the rollback trigger criteria. Document exactly which conditions will trigger a rollback decision.

How Do You Build and Test a Rollback Plan?

A migration without a tested rollback plan is reckless. The rollback must be faster than the forward migration and executable under pressure.

Rollback procedure. The rollback is conceptually simple: change DNS back to the old CDN. Because you lowered TTL before migration, DNS propagation should complete in 5–15 minutes. The old CDN's cache may be stale (it was not receiving traffic during the cutover period), so origin load will spike temporarily as the old CDN re-warms.

Keep the old CDN active. Do not cancel or deprovision the old CDN for at least 2 weeks after cutover. Keep the configuration intact and the domain registered. This is your safety net. The old CDN's cache will go cold during this period, but the configuration remains ready for rollback.

Rollback triggers. Define specific, measurable criteria that trigger a rollback: error rate exceeding 2x baseline for more than 5 minutes, TTFB exceeding 3x baseline at p99 for more than 10 minutes, SSL certificate errors on any production domain, or origin overload (CPU or memory exceeding 90% due to cache misses). Empower the on-call engineer to execute the rollback without executive approval—speed matters more than consensus during an incident.

Test the rollback. Before the real migration, rehearse the rollback in a staging environment or with a non-critical subdomain. Measure how long the DNS change takes to propagate and how the old CDN handles traffic resumption. A tested rollback plan is a confident rollback plan.

What Does Post-Migration Validation Look Like?

The cutover is not the end of the migration. Post-migration validation runs for 1–2 weeks and confirms that the new CDN meets all performance, reliability, and functionality requirements.

Performance comparison. Compare the pre-migration baseline metrics against post-migration actuals: cache hit ratio (should be within 5% of baseline within 48 hours), TTFB by region (should match or improve), error rate (should match baseline), and origin load (should be at or below baseline).

Feature verification. Walk through every feature from your pre-migration inventory and verify it works correctly on the new CDN: redirects resolve correctly, security headers are present, WAF rules block test attacks, edge functions execute correctly, and custom error pages display. Refer to the CDN Troubleshooting Guide for diagnostic techniques if issues arise.

SEO check. Verify that search engine crawlers can access your site through the new CDN. Check Google Search Console for crawl errors, verify that robots.txt is served correctly, confirm that canonical URLs and sitemaps resolve properly, and monitor for any ranking changes in the weeks following migration.

Decommission the old CDN. After 2 weeks of stable operation on the new CDN (and no rollback triggers), decommission the old provider. Cancel the contract (watch for auto-renewal terms), remove old CDN IP ranges from origin allowlists, restore DNS TTL to normal values (3600+ seconds), and update all documentation and runbooks to reference the new provider.

Document the entire migration: timeline, decisions made, issues encountered, and resolution steps. This becomes institutional knowledge for the next migration, which will likely happen in 2–3 years as the CDN landscape continues to evolve. For teams considering their next move, the Enterprise CDN guide covers vendor evaluation frameworks.