Come migrare un sito web con cPanel passo dopo passo

La migrazione di un sito web con cPanel si risolve bene quando la tratti come un cambio controllato, non come una copia frettolosa di file. Il punto non è solo spostare dati: devi preservare vhost, database, account mail, cron, versioni PHP, permessi e soprattutto il comportamento osservabile del sito dopo il cutover. Se salti uno di questi pezzi, il problema emerge quasi sempre in produzione e quasi mai nel momento in cui hai ancora tutto sotto mano.

Il flusso corretto è semplice nella logica: inventario, backup, trasferimento, ripristino, verifica, cambio DNS, osservazione. La differenza tra una migrazione pulita e una migrazione che ti consuma la giornata sta nella qualità dei controlli intermedi. In cPanel hai già diversi strumenti utili, ma vanno usati con un criterio preciso: backup consistenti, esportazione database, verifica delle versioni PHP, e un piano di rollback che non dipenda dalla fortuna.

Prima di toccare il server: inventario e punto di ritorno

Prima di copiare qualunque cosa, fotografa lo stato del sito. Devi sapere dove sono i documenti web, quali database usa l’applicazione, quali cron job sono attivi, quali account mail dipendono dal dominio e quale versione PHP sta servendo il sito. In molti casi il sito “funziona” solo perché il vecchio ambiente ha una combinazione precisa di runtime e configurazioni. Se la replichi male, il problema non è la migrazione: è l’aver ignorato il baseline.

In cPanel, i punti da controllare sono questi: File Manager per la root del sito, phpMyAdmin per i database, Cron Jobs per le attività pianificate, Email Accounts se il dominio gestisce posta, e MultiPHP Manager o Select PHP Version per la versione dell’interprete. Se il sito usa un pannello separato per DNS o se il DNS è gestito altrove, annota anche TTL, record A/AAAA, MX, CNAME e eventuali record TXT per SPF, DKIM e verifiche esterne.

Il punto di ritorno è il backup verificabile. Non basta dire “ho fatto una copia”: devi poter dimostrare che esiste un archivio ripristinabile e che contiene sia file sia database. Se usi gli strumenti di cPanel, conserva anche l’orario di creazione del backup e il nome esatto del file generato. Se fai backup manuali, salva anche il comando usato e l’hash del file compresso.

Backup coerente: file, database, configurazioni e posta

Per una migrazione standard hai quattro blocchi: document root, database MySQL/MariaDB, configurazioni applicative e dati di posta se il dominio li usa. L’errore tipico è copiare solo la directory pubblica e poi scoprire che il sito dipende da file fuori dalla webroot, da un database non esportato o da un cron che rigenera contenuti. Per questo conviene fare il backup con un ordine stabile e documentato.

Se hai accesso SSH e il provider lo consente, un backup manuale è spesso più trasparente di un clic nel pannello. Esempio per i file:

cd /home/UTENTE
find public_html -maxdepth 2 -type f | wc -l

tar -czf backup-files-$(date +%F).tar.gz public_html

Prima controlla la dimensione della webroot e il numero di file, così hai un riferimento per capire se il trasferimento è completo. Dopo la compressione, verifica che l’archivio sia leggibile:

tar -tzf backup-files-$(date +%F).tar.gz | head

Per il database, esporta in formato SQL con opzione compatibile. Se il sito è in produzione e il database è attivo, l’ideale è una finestra di manutenzione breve oppure un freeze delle scritture prima dell’export. In alternativa, se l’app consente una modalità maintenance, attivala per ridurre il rischio di inconsistenze.

mysqldump --single-transaction --routines --triggers --events \
  -u DBUSER -p DBNAME | gzip > backup-db-$(date +%F).sql.gz

La verifica minima non è opzionale:

gzip -t backup-db-$(date +%F).sql.gz
zcat backup-db-$(date +%F).sql.gz | head

Se usi solo il pannello, esporta il database da phpMyAdmin con formato SQL e conserva il file sul tuo workstation prima di caricarlo sul nuovo server. Per la posta, se il dominio ospita caselle che vuoi migrare, controlla la sezione Email Accounts e, se necessario, esporta i messaggi con lo strumento supportato dal provider o pianifica una migrazione separata. Non dare per scontato che “il sito” e “la mail” siano lo stesso problema: spesso hanno requisiti diversi e finestre diverse.

Preparare il nuovo cPanel: account, PHP, estensioni e limiti

Prima di caricare i dati, prepara il nuovo ambiente con la stessa logica del vecchio. Crea l’account o il dominio nel nuovo cPanel, verifica che la document root sia quella attesa e imposta la stessa versione PHP, o una compatibile, prima ancora di importare i file. Se l’app richiede estensioni specifiche, installale o abilita quelle necessarie dal gestore PHP del pannello.

Molti siti falliscono dopo la migrazione per differenze banali: memory_limit troppo basso, upload_max_filesize insufficiente, max_execution_time stretto, moduli PHP mancanti, oppure permessi errati sul filesystem. Meglio allineare prima queste impostazioni, così la prima apertura del sito non diventa una sessione di debug sotto pressione.

Se devi intervenire su PHP da cPanel, il percorso tipico è MultiPHP Manager per la versione e MultiPHP INI Editor per i parametri. Se l’app richiede configurazioni custom, tieni un diff chiaro del file o dello snippet modificato. Un esempio prudente:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120

Non alzare i limiti “a sentimento”: servono per il test e per il traffico reale, ma vanno rapportati alla RAM e al profilo dell’app. Se il sito è WordPress con plugin pesanti o un CMS che genera immagini al volo, la soglia giusta la trovi osservando error log e tempi di risposta, non con la superstizione.

Trasferire i file: rsync, archivio o File Manager

Per pochi megabyte puoi usare il File Manager di cPanel, ma per migrazioni serie è meglio un trasferimento via SSH o SFTP. Il vantaggio non è solo la velocità: hai ripetibilità, puoi riprendere il trasferimento e puoi verificare i permessi. Se hai accesso root o shell con privilegi adeguati, rsync è la scelta più pulita.

rsync -avz --progress /home/UTENTE/public_html/ user@nuovo-server:/home/UTENTE/public_html/

Se non hai shell sul server sorgente, crea un archivio compresso, trasferiscilo e poi estrailo sul nuovo ambiente. In questo caso, verifica sempre che il proprietario dei file sia quello corretto dopo l’estrazione. Un sito con owner sbagliato può sembrare presente ma restare inaccessibile o generare 403/500.

tar -xzf backup-files-2026-04-21.tar.gz -C /home/UTENTE/
chown -R UTENTE:UTENTE /home/UTENTE/public_html

Se il sito usa directory fuori da public_html, come storage per upload, cache, log applicativi o backup interni, includile nell’inventario e nel trasferimento. È un dettaglio che spesso salta fuori solo dopo il go-live, quando l’app cerca file che non esistono più.

Ripristinare il database senza rompere i riferimenti

Il database si importa dopo aver creato utente e schema sul nuovo server. In cPanel questo passa di solito da MySQL Databases: crea il database, crea l’utente, assegna i privilegi completi sul solo database richiesto, poi importa il dump. Se il database è grande, usa SSH per evitare limiti di timeout del browser.

gunzip -c backup-db-2026-04-21.sql.gz | mysql -u NEWDBUSER -p NEWDBNAME

Dopo l’import, controlla il numero di tabelle e, se l’app lo consente, confronta un paio di record chiave con il server sorgente. Non serve validare tutto a mano, ma serve una prova che l’import non sia stato tronco o corrotto.

mysql -u NEWDBUSER -p -e "USE NEWDBNAME; SHOW TABLES;"

Se il sito usa un file di configurazione con credenziali database, aggiorna subito host, nome database, utente e password. Nei framework più comuni questi dati stanno in file come .env, wp-config.php, configuration.php o simili. Non lasciare mai credenziali vecchie in giro: oltre al rischio di errore, tieni aperta una superficie d’attacco inutile.

Quando il database viene spostato tra server con versioni diverse di MySQL o MariaDB, testa compatibilità di charset e collation. Un salto tra default diversi può produrre ordinamenti strani, errori su indici lunghi o caratteri corrotti nei contenuti. Se hai dubbi, verifica almeno questo:

mysql -u NEWDBUSER -p -e "SHOW VARIABLES LIKE 'version%';"
mysql -u NEWDBUSER -p -e "SHOW VARIABLES LIKE 'collation_server';"

Configurare il dominio: document root, SSL e DNS

Una migrazione fatta bene non si limita al contenuto. Devi garantire che il dominio punti al nuovo origin e che il certificato TLS sia valido prima del traffico reale. In cPanel, dopo aver aggiunto il dominio o il sottodominio, verifica la document root e poi attiva il certificato con SSL/TLS Status o AutoSSL, se disponibile. Se il certificato è gestito esternamente, preparalo prima del cambio DNS.

Per il DNS, abbassa il TTL con anticipo se hai controllo sulla zona. Così il cutover si propaga più rapidamente. Il giorno della migrazione, aggiorna il record A o AAAA verso il nuovo IP, senza toccare record che non c’entrano con il sito. Se usi CDN o proxy, considera anche la cache edge: puoi dover fare purge o mettere il sito in modalità bypass per evitare di servire contenuti vecchi.

Un controllo rapido del DNS è questo:

dig +short example.com A
curl -I https://example.com

Se il sito risponde con il certificato sbagliato, o con redirect loop, il problema può stare nel virtual host, nella configurazione HTTPS o nel fatto che il dominio punta ancora al vecchio server. Qui la prova minima è sempre doppia: lookup DNS e risposta HTTP. Una sola delle due non basta.

Verifiche applicative: permessi, rewrite, cache e cron

Quando file e database sono al loro posto, la parte più delicata è l’applicazione. Molti CMS dipendono da regole di rewrite in .htaccess, da permessi precisi e da task pianificati. Se il sito genera errori 500 o mostra una pagina bianca, il primo controllo è il log errori del dominio e del motore PHP. In ambiente cPanel i percorsi variano, ma spesso trovi i log in aree come ~/logs, /usr/local/apache/logs/error_log oppure nel pannello stesso tramite Errors.

Una sequenza pratica è questa:

Per esempio, una regola di rewrite mancante può far sembrare il sito “rotto” anche se i file sono corretti. Se il CMS usa permalinks, prova a rigenerarli dal pannello dell’app o a confrontare il contenuto di .htaccess con quello del server precedente. Non copiare ciecamente: verifica che non ci siano direttive obsolete o riferimenti a percorsi vecchi.

I cron job vanno trattati con la stessa attenzione del database. Un backup, un feed, una sincronizzazione o una pulizia cache programmata possono essere la differenza tra un sito stabile e uno che si comporta in modo intermittente. In cPanel, la sezione Cron Jobs mostra tempi e comandi: controlla che gli script puntino ai nuovi percorsi e che il PHP invocato sia quello giusto.

Cutover: quando cambiare DNS e come ridurre il rischio

Il cutover va fatto solo quando il nuovo ambiente risponde bene in locale o tramite hosts file. Se il sito è ancora sotto test, non anticipare il DNS: ogni minuto in più speso a verificare è un minuto guadagnato dopo. Il cambio record deve essere l’ultimo atto, non il primo gesto con cui speri di “vedere se funziona”.

La strategia più sicura è questa: metti il sito in maintenance se l’app lo richiede, sincronizza gli ultimi dati se il contenuto cambia spesso, aggiorna il DNS, tieni vivo il vecchio server per un periodo di transizione e osserva i log. Se il sito è statico o poco dinamico, la finestra può essere breve. Se invece gestisce ordini, utenti o contenuti editoriali, la transizione richiede più disciplina.

Durante il cutover misura almeno tre cose: TTFB, tasso di errore e assenza di redirect anomali. Se hai un monitor esterno, meglio ancora. Un semplice controllo ripetuto può bastare per capire se il nuovo origin è stabile:

for i in 1 2 3 4 5; do curl -o /dev/null -s -w '%{http_code} %{time_starttransfer}\n' https://example.com; done

Se vedi 200 costanti e tempi ragionevoli, hai una prima conferma. Se compaiono 500, 502, 403 o tempi che oscillano troppo, fermati e guarda i log prima di fare altro. La migrazione non si “aggiusta” a colpi di refresh del browser.

Rollback: come tornare indietro senza improvvisare

Il rollback deve essere definito prima del cambio DNS. Il piano minimo è: ripristino del vecchio record DNS, riattivazione del vecchio server, eventuale disattivazione del maintenance mode sul vecchio ambiente e, se hai scritto dati sul nuovo server, valutazione di un re-sync selettivo. Non tutte le migrazioni sono reversibili in modo perfetto, ma tutte devono avere una via di ritorno documentata.

Conserva per almeno qualche giorno il backup del vecchio sito e il dump del database precedente al cutover. Se qualcosa va storto, ti serve sapere esattamente quale versione stavi servendo e in quale momento. In una migrazione pulita, il rollback è un’operazione tecnica, non una discussione sul perché “sembrava tutto a posto”.

Controlli finali utili dopo il go-live:

Assunzione: il sito è ospitato su un ambiente Linux con cPanel, accesso almeno parziale a file e database, e il provider non impone vincoli aggiuntivi non documentati.

Se vuoi ridurre davvero gli incidenti, il trucco non è fare la migrazione più in fretta: è fare meno cose in contemporanea. Un sito copiato bene, un database importato bene e un DNS cambiato al momento giusto valgono più di cento tentativi di “vediamo se si sistema”.