Switch CDN providers
A CDN does more than cache: redirects, headers, firewall rules, certificates and edge code all live there. Rebuild them at the new provider, test, then switch DNS without surprises.
Official sources last reviewed · How we review
Build your personalized plan
A few questions, revealed as they become relevant. Your answers stay in this browser.
Start with the basics
We never ask for phone numbers, card numbers, passwords or codes. Names of providers or nicknames are enough.
Your plan so far
10things this change touches
- critical3
- high4
- moderate3
- low0
Updates as you answer. Every item will explain why it’s there.
What could break
In a typical cdn plan, these are the most serious things to get right.
Firewall, bot and rate-limiting rules
Critical · Website & DNS
Either attacks and bots get through, or real users, payment webhooks and monitoring are blocked by new default rules.
TLS certificates for each hostname
Critical · Website & DNS
Visitors see certificate errors at the switch until validation completes.
Origin protection for the new CDN
Critical · Website & DNS
The new CDN gets errors from your origin, or you open the origin to everyone and bypass the firewall.
Test through the new CDN before switching
Critical · Website & DNS
Differences in caching, redirects or firewall behaviour only show up once everyone has moved.
Point DNS at the new CDN
Critical · Website & DNS
Hostnames you forget stay on the old CDN until it's switched off, then fail.
Export the current CDN configuration
High · Website & DNS
Rules you didn't know existed disappear at the switch, from redirects to bot protection.
Recreate cache rules and cache keys
High · Website & DNS
Too little caching overloads your origin; too much can serve one visitor's personal page or cart to another.
Edge redirects and rewrites
High · Website & DNS
Old links, campaign URLs and QR codes return 404s after the switch.
Edge functions and workers
High · Integrations & APIs
Auth checks, A/B tests, header logic or whole routes stop working.
Security headers, CORS and HSTS at the edge
High · Website & DNS
Headers silently disappear, weakening security or breaking cross-origin requests from your apps.
Before and after the change
Before you change it
- Export the current CDN configuration
- Compare pricing, egress and contract terms
- Firewall, bot and rate-limiting rules
- Recreate cache rules and cache keys
- Edge redirects and rewrites
- Edge functions and workers
- Security headers, CORS and HSTS at the edge
- TLS certificates for each hostname
- Origin protection for the new CDN
- Root domain (apex) support
- Test through the new CDN before switching
After the change
- Point DNS at the new CDN
- Expect a cold cache and an origin spike
- Cache purges and API keys in CI/CD
- Watch errors, cache hit ratio and costs
- Remove the old CDN safely
Your own plan adds or removes items based on your answers, and explains why each one is there.
The safe order
Doing things in the right sequence is what keeps you from getting locked out halfway through.
Before the change
Step 1: Export the current configuration
Document every rule and setting, check contract terms, and move DNS first if the CDN hosts it.
- Export the current CDN configuration (high risk)
- Compare pricing, egress and contract terms (moderate risk)
Step 2: Rebuild rules and features at the new CDN
Recreate caching, redirects, headers, firewall rules and edge code.
- Firewall, bot and rate-limiting rules (critical risk)
- Recreate cache rules and cache keys (high risk)
- Edge redirects and rewrites (high risk)
- Edge functions and workers (high risk)
- and 1 more
Step 3: Set up certificates and origin access
Validate certificates and let the new CDN through your origin's defences.
- TLS certificates for each hostname (critical risk)
- Origin protection for the new CDN (critical risk)
- Root domain (apex) support (high risk)
Step 4: Test through the new CDN before switching
Compare responses from both CDNs using your real hostnames.
- Test through the new CDN before switching (critical risk)
During the change
Step 5: Switch traffic
Move hostnames to the new CDN, starting small, and watch origin load.
- Point DNS at the new CDN (critical risk)
- Expect a cold cache and an origin spike (moderate risk)
Step 6: Update purges and API keys in CI/CD
Point deploy pipelines at the new CDN.
- Cache purges and API keys in CI/CD (high risk)
Immediately after
Step 7: Watch the first week
Track errors, cache hit ratio and costs.
- Watch errors, cache hit ratio and costs (moderate risk)
Clean up
Step 8: Remove the old CDN safely
Revoke its access to your origin, delete hostnames, then cancel.
- Remove the old CDN safely (high risk)
Why this change needs a plan
A CDN sits between visitors and your servers and often does far more than caching: redirects, security headers, firewall and bot rules, certificates, image resizing and edge code. Switching means rebuilding all of that at the new provider before traffic moves.
What could break: a missing redirect or header, a firewall rule that blocks real users or webhooks, an origin that refuses the new CDN, private pages cached by mistake, and a deploy pipeline that still purges the old cache.
Why it matters
Your CDN is on the path of every request. Small configuration differences can expose private content, block customers or take the site down under load.
What makes it risky
Risk is highest when the CDN is also your DNS provider, when the origin only accepts the CDN's traffic, and when you rely on firewall rules, signed URLs or edge code.
Common mistakes
- Caching personalised pages because bypass rules for signed-in users weren't recreated.
- Forgetting edge redirects and security headers that only existed in the old CDN's settings.
- Leaving the origin firewall locked to the old CDN's IP ranges.
- Leaving CI/CD purging the old CDN's cache after deploys.
- Cancelling the old CDN while it's still your DNS provider.
Frequently asked questions
Will switching CDNs cause downtime?
Not if certificates are validated, the origin accepts the new CDN and you've tested with real hostnames before switching DNS. Lower TTLs a day ahead and move hostnames one at a time so any problem is small and quick to reverse.
Do I need to change DNS to switch CDNs?
Yes. With a CNAME setup you update each hostname's record to the new CDN. If the old CDN is also your DNS provider, you'll need to move DNS to another provider first.
Will my cache be empty after switching?
Yes, the new CDN starts cold, so your origin takes more load at first. Switch at a quiet time, scale the origin if needed, and use the new CDN's origin shield or tiered caching if it offers one.
What happens to my firewall and bot rules?
They don't transfer. Recreate custom rules, run new managed rules in log mode first, and allowlist monitoring, payment webhooks and partners before switching to block mode.
Can I run two CDNs at once?
During the move, yes: each hostname points at one CDN or the other. A long-term multi-CDN setup is possible with DNS-based traffic steering, but it means keeping two configurations in sync.