Migrazione zero-downtime: runbook operativo per spostare siti senza drammi

Hai un cliente su shared hosting che cade ogni due settimane, TTFB pessimo, backup opachi e supporto inesistente. Decidi di migrare. Il problema è che “spostare il sito” non basta: devi spostare file, database, email, DNS, cron, SSL e soprattutto la fiducia del cliente.

Questo runbook serve a fare una migrazione con downtime visibile vicino allo zero. Non perfetta in assoluto, ma controllata, reversibile e difendibile.

Se sei ancora in fase di valutazione, parti dalla pagina Migrazioni. Se invece il problema è un server già in crisi, prima leggi Server down: cosa fare nei primi 60 minuti.

TL;DR

Una migrazione zero-downtime funziona se rispetti cinque regole:

1. Riduci il TTL con anticipo.
2. Prepara il target prima di toccare il sorgente.
3. Sincronizza i dati almeno due volte.
4. Definisci un cutover con checklist e criteri di successo.
5. Tieni un rollback pronto, scritto, testato.

Se una di queste cinque manca, non stai facendo una migrazione. Stai sperando.

Quando ha senso migrare

I segnali tipici sono questi:

• uptime mediocre o incident frequenti
• performance instabili senza causa chiara
• provider che non ti lascia accesso reale a log, backup e configurazioni
• email che finiscono in spam o non hanno autenticazione corretta
• costi cloud fuori scala rispetto al carico reale
• stack legacy ereditato che nessuno vuole più toccare

Se il problema è sicurezza o compromissione, la migrazione non sostituisce l'hardening. In quel caso abbina questo runbook a Hardening SSH: checklist operativa in 15 step e alla pagina Security Hardening.

Fase 1: discovery vera, non call da venditore

Prima di scrivere un comando, raccogli tutto.

Inventario minimo

Per ogni sito o applicazione devi sapere:

• dominio e sottodomini coinvolti
• DNS attuali e nameserver
• stack web: Nginx, Apache, LiteSpeed, cPanel, Plesk
• versione PHP e moduli necessari
• motore database e dimensione dati
• cron job attivi
• certificati SSL e modalità di rinnovo
• servizi mail collegati
• task applicativi o webhook esterni
• directory reali di file e upload

Comandi che uso sempre

# DNS corrente
whois dominio.it | grep -Ei "Name Server|nserver"
dig +short A dominio.it
dig +short MX dominio.it

# Peso dei dati
cd /var/www && du -sh .
mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024,2) AS size_mb FROM information_schema.tables GROUP BY table_schema ORDER BY size_mb DESC;"

# Versioni stack
php -v
nginx -v
apache2 -v
mysql --version
crontab -l

Output atteso della discovery

Alla fine devi avere un documento con:

• origine
• destinazione
• dipendenze
• finestra di cutover
• rischio residuo
• piano rollback

Se non riesci a spiegare la migrazione in una pagina, non sei pronto a farla.

Fase 2: prepara il target come se dovesse restare per anni

Errore comune: usare il target solo come “posto dove spostare i file”. Sbagliato. Il target è la nuova produzione. Quindi va preparato bene:

• sistema operativo supportato
• utenti e permessi corretti
• hardening base
• backup già attivi
• monitoring già attivo
• versioni PHP/MySQL coerenti con l'applicazione
• certificati e mail pianificati

Checklist minima target

# utenti applicativi
adduser deploy
adduser backup

# cartelle applicative
mkdir -p /var/www/dominio.it
chown -R www-data:www-data /var/www/dominio.it

# backup e monitoring già presenti
systemctl enable --now nginx
systemctl enable --now mysql
systemctl enable --now node-exporter

Se il target nasce già male, la migrazione sarà tecnicamente riuscita ma commercialmente fallita.

Fase 3: abbassa il TTL prima del cutover

Il TTL non si abbassa cinque minuti prima. Idealmente:

• 24-48 ore prima per domini critici
• 12-24 ore prima per contesti più semplici

Valori pratici:

• A/AAAA: 300 secondi
• CNAME: 300 secondi
• MX: solo se stai migrando anche la posta

dig dominio.it

Controlla che il nuovo TTL sia effettivamente propagato prima del giorno di migrazione.

Fase 4: prima replica dati

L'obiettivo della prima replica è copiare la maggior parte dei dati mentre il sorgente è ancora online.

File

rsync -avz --delete \
  --exclude='cache/' \
  --exclude='tmp/' \
  /var/www/dominio.it/ root@target:/var/www/dominio.it/

Database

mysqldump --single-transaction --routines --triggers --events dbname > /tmp/dbname.sql
scp /tmp/dbname.sql root@target:/tmp/
ssh root@target 'mysql dbname < /tmp/dbname.sql'

Perché non basta una replica sola

Perché nel frattempo arrivano:

• nuovi ordini
• commenti
• upload
• email
• scritture applicative

Quindi la prima replica non serve a chiudere la migrazione. Serve a ridurre il delta finale.

Fase 5: definisci la checklist di cutover

La checklist di cutover deve essere sequenziale e con owner chiaro. Un esempio minimo:

1. Conferma backup sorgente e target.
2. Metti il sito in maintenance o read-only se necessario.
3. Esegui seconda replica file.
4. Esegui dump finale database.
5. Importa sul target.
6. Aggiorna config applicativa.
7. Testa localmente con /etc/hosts.
8. Cambia DNS.
9. Verifica HTTP, HTTPS, login, ordini, form, email.
10. Tieni osservazione attiva per 60-120 minuti.

Test locale prima dello switch

# /etc/hosts sul tuo pc
203.0.113.10 dominio.it www.dominio.it

curl -I https://dominio.it
curl -s https://dominio.it | head

Se non testi il target prima del DNS, non stai facendo cutover. Stai facendo roulette.

Fase 6: email e DNS, il punto dove si rompe tutto

Molte migrazioni “senza downtime” falliscono non sul sito, ma sulla posta.

Devi verificare:

• record MX
• SPF
• DKIM
• DMARC
• eventuali relay esterni
• webmail o IMAP locali

Se stai lasciando la posta sul provider vecchio, documentalo. Se la stai migrando, serve un runbook a parte.

Per problemi di deliverability, questa è una delle guide che pubblicheremo nella fase successiva. Nel frattempo non improvvisare: la reputazione mail si rompe più facilmente di quanto si ricostruisca.

Fase 7: rollback vero

Un rollback vero risponde a tre domande:

• in quanto tempo torni indietro?
• quali dati perdi nel ritorno?
• chi decide che si torna indietro?

Regola pratica

Definisci prima i trigger di rollback. Per esempio:

• login non funzionante oltre 15 minuti
• checkout o form non funzionanti
• errori applicativi critici senza fix rapido
• perdita connettività mail o DNS non prevista

Se uno di questi trigger si verifica e non hai fix rapido, torni indietro. Punto.

Errori che vediamo più spesso

1. Migrare e hardenizzare insieme

Troppi cambiamenti nello stesso cutover. Prima replica il comportamento, poi ottimizza.

2. Cambiare versione PHP a sorpresa

Se passi da PHP 7.4 a 8.3 durante la migrazione, hai aggiunto una variabile enorme.

3. Dimenticare i cron

Il sito apre, ma backup, import, cache warmup o sync non girano più.

4. Ignorare la mail

Il sito è online ma le email di form, ordine o reset password non partono.

5. Non monitorare dopo lo switch

Il fatto che la home risponda non significa che tutto sia sano.

Quando questa guida non basta

Questa guida basta per migrazioni lineari: WordPress, WooCommerce, applicazioni PHP classiche, stack Linux standard.

Non basta se hai:

• multi-server con load balancer
• replica database complessa
• applicazioni con code e worker multipli
• e-commerce con ordini elevati durante il cutover
• provider sorgente con accesso limitato o opaco

In questi casi serve un progetto dedicato. Parti da Migrazioni o da un audit gratuito se vuoi mappare rischio, effort e finestra operativa.

Checklist finale riusabile

Prima del cutover:

• TTL ridotto
• target pronto
• backup verificato
• prima replica completata
• checklist scritta
• rollback approvato

Durante il cutover:

• maintenance o freeze scritture
• seconda replica file
• dump finale database
• import target
• test locale
• switch DNS

Dopo il cutover:

• verifica login
• verifica form
• verifica ordini o eventi critici
• verifica email
• monitoraggio 60-120 minuti
• chiusura con report

La migrazione fatta bene non si nota. Il cliente non ti deve dire “bravi, che migrazione elegante”. Deve dirti: “non ci siamo accorti di niente”.