Migrare da Cloudflare a un'altro CDN: procedura sicura senza downtime

Migrare da Cloudflare a un'altro CDN (Akamai, Fastly, AWS CloudFront, BunnyCDN, KeyCDN) richiede pianificazione attenta per evitare downtime, perdita dati e degradazione utenti. Le ragioni per migrare possono essere economiche, performance specifiche, requisiti compliance, o preferenze stack interno. Vediamo una procedura sicura passo-passo che ho applicato su decine di migrazioni con G Tech Group.

Pre-migration checklist

Prima di iniziare verifica: 1) Inventario completo configurazione Cloudflare (Page Rules, WAF rules, Workers, custom certificates). 2) Lista record DNS con TTL attuali. 3) Eventuali servizi Cloudflare-specifici in uso (Pages, Workers, R2, Stream). 4) Identificazione feature paritarie sul nuovo CDN. 5) Test su staging del nuovo CDN. 6) Comunicazione team e stakeholder. Mai migrare nei picchi di traffico (lunedì mattino, Black Friday).

Procedura passo-passo

1. Riduci TTL DNS dei record A e CNAME importanti a 300 secondi (5 minuti) con 48h di anticipo.
2. Configura il nuovo CDN con tutti i comportamenti: cache rules, SSL, redirect.
3. Ottieni certificato SSL per il dominio sul nuovo CDN (Let's Encrypt o equivalente).
4. Testa il nuovo CDN puntando un sottodominio test (es. test.tuosito.it).
5. Verifica tutti i casi: pagine pubbliche, area admin, API, form submit, asset.
6. Esegui benchmark di performance per confronto.
7. Pianifica una maintenance window di 1 ora.
8. Aggiorna nameserver: spostali dal Cloudflare DNS a un DNS provider neutro o quello del nuovo CDN.
9. Attendi propagazione DNS: il TTL ridotto velocizza.
10. Monitora errori, latenze, error rate per 24-48h post migrazione.

Gestione del DNS durante migrazione

La parte critica è il DNS switch. Due strategie possibili. Strategia A (sicura): mantieni Cloudflare DNS, modifica i record A/CNAME per puntare al nuovo CDN. Permette rollback istantaneo cambiando IP. Strategia B (clean): cambia nameserver del registrar dal Cloudflare a un DNS provider (Route53, DigitalOcean DNS, ClouDNS). Più pulita ma rollback più lento. Per la maggior parte delle migrazioni Strategia A è preferibile.

Replicare le funzionalità Cloudflare

Non tutti i CDN hanno feature equivalenti. Workers → Fastly Compute@Edge, Akamai EdgeWorkers, AWS Lambda@Edge. Page Rules → equivalenti rule engine sul nuovo provider. WAF → AWS WAF, Akamai App Security. R2 → AWS S3, Backblaze B2. Stream → Mux, Vimeo. Pages → Vercel, Netlify, AWS Amplify. Access → Okta, Auth0. Documenta mappatura prima della migrazione.

SSL/TLS senza downtime

I certificati SSL richiedono attenzione. Sequenza corretta: 1) Sul nuovo CDN genera/installa certificato per il dominio (Let's Encrypt o paid). 2) Verifica certificato valido testando il sottodominio test. 3) Solo dopo cambio DNS. 4) Cloudflare Universal SSL si disattiva quando rimuovi il dominio dalla piattaforma. 5) Se hai HSTS preload, considera che il dominio resta vincolato a HTTPS valido per anni dopo migrazione. Mai disattivare HTTPS dopo HSTS preload.

Errori comuni e come risolverli

• Downtime di 30 minuti durante switch: TTL DNS troppo alto. Riduci a 60s 24h prima.
• Email rotte dopo migrazione DNS: record MX dimenticati. Esporta DNS completo prima.
• Certificato self-signed visibile: nuovo CDN non ha completato emissione. Verifica con SSL Labs.
• Funzioni Workers persi: codice non riportato. Esporta tutti i Workers script.
• Performance peggiori: nuovo CDN ha meno POP in regioni utenti. Verifica con WebPageTest pre-migration.

Rollback plan

Devi sempre avere un piano di rollback testato. Strategia A (DNS Cloudflare mantenuto): cambia record A indietro a IP origine, sito torna a passare da Cloudflare in minuti. Strategia B (NS cambiati): riporta nameserver a Cloudflare al registrar, propagazione 30-60 minuti. Documenta scripts pronti per rollback. Esegui dry-run del rollback prima di migrazione effettiva. Avere rollback pronto riduce stress e tempi di reazione a problemi.

Post-migration monitoring

Nelle 48 ore successive monitora attentamente: error rate (4xx, 5xx), latency p95, cache hit ratio, SSL handshake errors, traffic volume. Configura alert con Datadog, New Relic, o tools nativo del nuovo CDN. Confronta con baseline pre-migration. Se rilevi anomalie significative, valuta rollback fino a risoluzione. Solo dopo 7 giorni stabili considera migrazione "completata" e archivia configurazione Cloudflare backup.

Domande frequenti

D: Posso usare Cloudflare DNS senza Cloudflare CDN?
R: Sì, lascia record DNS con proxy off (nuvola grigia).

D: Devo cancellare l'account Cloudflare dopo migrazione?
R: No, conservalo come backup per il rollback per qualche mese.

D: I dati Stream/R2/Workers vengono persi?
R: Sì se cancelli l'account. Migra dati prima.

D: Tempo totale di una migrazione tipica?
R: 1-2 settimane di prep, 1 giorno di switch, 1 settimana di monitor.

Considerazioni operative finali

Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.

Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.

Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.

Hai bisogno di aiuto?

Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.