Migrate Between CDN Providers Without Downtime (2026)

Migrating CDN providers without downtime is less about flipping a switch and more about orchestrating a gradual handoff where traffic seamlessly shifts from the old to the new.

Let’s watch this happen with a hypothetical example.com that’s moving from "OldCDN" to "NewCDN."

The Setup: DNS is King

The core of any CDN is how it’s fronted by DNS. When a user requests static.example.com, their DNS resolver queries authoritative DNS servers. These servers, in turn, point to the CDN’s edge servers. For a migration, we’re going to manipulate these DNS records.

OldCDN Configuration (Pre-Migration)

DNS Record: static.example.com IN CNAME oldcdn.edge.provider.com
Origin Server: your-origin-server.com
Cache Rules: Standard image/JS/CSS caching, TTLs set to 1 hour (3600 seconds).

NewCDN Configuration (Pre-Migration)

DNS Record (Staged): static.example.com IN CNAME newcdn.edge.provider.com
Origin Server: your-origin-server.com
Cache Rules: Similar to OldCDN, but maybe with slightly more aggressive compression enabled.

The Migration Strategy: The Slow Roll

The key is to leverage DNS TTLs and a phased approach.

Lower TTLs on Existing Records (The "Warm-up"): Before making any changes, we need to reduce the Time-To-Live (TTL) on the existing CNAME record for static.example.com. This tells DNS resolvers worldwide to ask for the record more frequently.
- Action: In your DNS provider’s control panel (e.g., Route 53, Cloudflare, GoDaddy), change the TTL for static.example.com from 3600 seconds (1 hour) to 60 seconds (1 minute).
- Why it works: This ensures that when we make the actual switch, DNS resolvers will pick up the change much faster, minimizing the window where users might still be hitting the old CDN. You’ll need to wait for the current TTL to expire globally before this new, lower TTL is fully effective.
Populate the New CDN Cache (The "Pre-warming"): This is crucial. If the new CDN doesn’t have the assets cached, the first requests hitting it will be origin fetches, potentially overwhelming your origin server and causing slow loads or errors.
- Action: Use a tool like curl with a loop, or a dedicated CDN pre-warming service, to hit static.example.com (while it’s still pointing to OldCDN) with URLs that will be served by the new CDN. This sounds like a paradox, but you’re essentially telling the new CDN’s edge servers to go fetch the content from your origin and cache it. You’ll need to configure the NewCDN to point to your origin server and potentially set up a temporary, internal DNS record or hosts file entry on the machine running the pre-warming script to ensure it hits the new CDN’s CNAME during this phase.
```
# Example pre-warming script (conceptual)
for url in $(cat urls.txt); do
  # Ensure your local DNS or hosts file is set up to resolve static.example.com to NewCDN's IPs
  curl -I "https://static.example.com/${url}"
  sleep 0.1 # Small delay to avoid overwhelming the origin
done
```
- Why it works: By fetching assets through the new CDN’s infrastructure before directing live traffic to it, you ensure that the cache is warm. When traffic does shift, the new CDN can serve most requests from its edge cache, just like the old one.
The DNS Cutover (The "Switch"): This is the moment of truth. You’ll change the CNAME record to point to the new provider.
- Action: Update the CNAME record for static.example.com in your DNS provider to newcdn.edge.provider.com.
- Why it works: DNS resolvers around the world will now start receiving the new IP addresses associated with newcdn.edge.provider.com. Because we lowered the TTL earlier, this change propagates relatively quickly. Users whose DNS resolvers have updated will start hitting the NewCDN.
Monitor and Verify (The "Watchful Eye"): Immediately after the DNS change, closely monitor both CDNs and your origin server.
- Action:
  - New CDN Dashboard: Watch cache hit rates, error rates, and traffic volume.
  - Old CDN Dashboard: Traffic should be rapidly decreasing.
  - Origin Server: Monitor load, response times, and error logs. Look for any unexpected spikes.
  - Real User Monitoring (RUM): If you have RUM tools, observe performance metrics from actual users.
  - Synthetic Monitoring: Use tools like Pingdom or Uptrends to continuously check static.example.com from various locations.
- Why it works: This allows you to catch any issues immediately. If the cache wasn’t fully warmed, or if there’s a misconfiguration, you can see it and react.
Gradually Increase TTL (The "Settling"): Once you’re confident the NewCDN is handling traffic smoothly and your origin is stable, you can increase the TTL back to a more standard value.
- Action: Change the TTL for static.example.com back to 3600 seconds (or whatever your optimal caching duration is).
- Why it works: Longer TTLs reduce the load on DNS infrastructure and improve performance for end-users by decreasing the number of DNS lookups required.
Decommission Old CDN: After a period of successful operation (e.g., 24-48 hours), you can safely remove the CNAME record pointing to the old CDN from your DNS settings.
- Action: Delete the static.example.com DNS record.
- Why it works: This formally removes the old CDN from your infrastructure and prevents any accidental or lingering traffic from being directed to it.

The Next Hurdle: SSL Certificates

Once you’ve successfully migrated your primary static assets, the next logical step is to ensure your SSL certificates are correctly configured and managed on the new CDN, as this is critical for secure delivery and can introduce its own set of transition challenges if not handled proactively.