Migrare un sito cPanel a un VPS senza downtime

Pubblicato il 10 settembre 2026

Per migrare un sito cPanel a un VPS senza un'interruzione imprevista, tratta il DNS come lo switch finale, non come il primo compito. Prepara il server di destinazione, copia l'account, testalo sul nuovo indirizzo IP, riduci il DNS TTL, poi modifica i record solo dopo che i controlli dell'applicazione, della posta e di SSL sono andati a buon fine. Il sito resta disponibile mentre il lavoro avviene in background.

Per il sito di una piccola impresa, un account agenzia o un negozio con ordini attivi, la migrazione riguarda meno lo spostamento dei file e più la conservazione del comportamento del servizio. Versioni di PHP, permessi del database, cron job, instradamento della posta elettronica, reindirizzamenti e regole del firewall devono tutti arrivare in uno stato certamente funzionante. I file di solito sono la parte facile. Le piccole impostazioni nascoste intorno a loro sono dove le migrazioni si guadagnano i capelli grigi.

Prima di migrare un sito cPanel a un VPS

Inizia con un inventario dell'account esistente. Registra i nomi di dominio e i sottodomini, l'utilizzo dello spazio disco dell'account, la versione di PHP e le estensioni, le dimensioni dei database, i cron job, gli account email, gli inoltri, gli autorisponditori, i record DNS, i certificati SSL e tutti i servizi esterni che dipendono dall'indirizzo IP del server. Per i carichi di lavoro e-commerce e SaaS, identifica anche callback di pagamento, allowlist API, provider di email transazionali e worker in background.

Verifica che il VPS di destinazione abbia margine sufficiente. Lo spazio disco dovrebbe coprire l'account di origine, l'archivio temporaneo della migrazione, i database, i backup e la crescita normale. I requisiti di RAM e CPU dipendono dal traffico e dallo stack software. Un sito vetrina può funzionare comodamente su un VPS modesto; WooCommerce, Magento, un grande WordPress multisite o un'applicazione con molto traffico normalmente richiedono più memoria e capacità del database.

La destinazione dovrebbe essere preparata prima che venga copiato qualsiasi dato di produzione. Imposta l'hostname del server, installa e aggiorna cPanel e WHM se quello è il pannello di controllo scelto, configura i nameserver se il VPS ospiterà il DNS e abilita un firewall con aperte solo le porte necessarie. Conferma che i backup siano configurati in modo indipendente dal server di origine. Un backup archiviato solo sul VPS è utile, ma non è un piano di ripristino completo se il VPS stesso ha un problema.

Se stai passando da un hosting cPanel condiviso a un VPS, verifica cosa veniva gestito in precedenza per te. Il vecchio host potrebbe aver gestito il filtro della posta, il DNS, il rinnovo automatico di SSL, la scansione malware o i backup esterni al server. Su un VPS gestito, questi elementi possono essere verificati e mantenuti insieme a te. Su un server non gestito, diventano una tua responsabilità operativa. Nessuno dei due approcci è sbagliato, ma le supposizioni costano care.

Riduci il DNS TTL prima del cutover

Circa 24-48 ore prima della modifica pianificata, riduci il TTL dei record DNS rilevanti a 300 secondi, se pratico. Questo consente ai record A, AAAA e MX aggiornati di propagarsi più velocemente quando arriva il momento del cutover. Non abbassarlo cinque minuti prima dello spostamento aspettandoti che internet diventi filosofico al riguardo. I resolver ricorsivi potrebbero avere già in cache il vecchio valore.

Conserva una copia della zona DNS attuale prima di modificarla. Se dopo lo switch compare qualcosa di imprevisto, ripristinare record noti è più rapido che ricostruirli a memoria.

Scegli il metodo di trasferimento giusto

Transfer Tool di WHM è di solito il metodo più pulito per spostare account cPanel completi tra server compatibili. Trasferisce dati dell'account, database, email, informazioni sulla zona DNS e molte impostazioni a livello di account in un unico processo controllato. Usa l'accesso root o a livello reseller dove possibile e verifica che il server di origine consenta la connessione SSH richiesta.

Anche un backup completo di cPanel può funzionare bene quando il trasferimento diretto da server a server non è disponibile. Genera il backup, spostalo in modo sicuro sul nuovo VPS e ripristinalo tramite WHM. Questo approccio è più manuale e il backup potrebbe rappresentare un momento nel tempo anziché le modifiche più recenti, quindi pianifica con attenzione la sincronizzazione finale.

Per applicazioni con configurazioni insolite, una migrazione manuale può essere più sicura. Copia i file del sito web con rsync o un altro metodo di trasferimento sicuro, esporta e importa i database, ricrea utenti e permessi, quindi ricostruisci la configurazione esterna all'account. Questo richiede più tempo, ma offre maggiore controllo quando il sistema di origine ha regole Nginx personalizzate, percorsi non standard, storage esterno o worker dell'applicazione.

Evita di copiare solo la directory public_html a meno che tu non abbia confermato che non c'è altro da preservare. Email, database, file nascosti, definizioni cron, materiali SSL e file di configurazione spesso si trovano fuori da quella cartella.

Testa il VPS prima delle modifiche al DNS pubblico

Una volta ripristinato l'account, convalida il sito rispetto all'IP di destinazione senza modificare il DNS pubblico. Una voce locale nel file hosts consente al tuo computer di risolvere il dominio verso il nuovo VPS mentre tutti gli altri continuano a raggiungere il vecchio server. Questo è il momento giusto per individuare un'estensione PHP mancante, una regola di rewrite non funzionante o un utente del database che non è stato trasferito.

Testa le pagine principali, il flusso di login, i moduli di contatto, il checkout, l'area amministrativa, i caricamenti di immagini e le attività pianificate. Mentre lo fai, controlla i log dell'applicazione e il log degli errori del web server. Verifica che il sito stia utilizzando la versione di PHP prevista e che la proprietà dei file sia corretta. Una pagina che si carica una volta non è l'intero test. Dovrebbe anche scrivere nel database, inviare i messaggi richiesti e gestire normalmente le sessioni autenticate.

Verifica anche SSL prima del cutover. Se il certificato viene riemesso dopo che il DNS punta al VPS, conferma che il virtual host del web server sia corretto e che le porte 80 e 443 siano raggiungibili. Se stai portando un certificato esistente, installa in modo sicuro la sua catena di certificazione e la chiave. I browser sono piuttosto onesti riguardo agli errori dei certificati, a volte con più dramma del necessario.

Gestisci l'email separatamente dal traffico web

L'email è la parte più comunemente trascurata di una migrazione a VPS. Se il dominio usa un servizio email esterno come Google Workspace o Microsoft 365, preserva i record MX, SPF, DKIM e DMARC esistenti. Non sostituirli accidentalmente con record di posta locale di cPanel.

Se l'email è ospitata in cPanel, sposta le caselle di posta e testa invio e ricezione sul VPS. Durante la transizione DNS, i nuovi messaggi possono arrivare su uno dei due server. Mantieni attivo il vecchio account di hosting per almeno 48-72 ore dopo lo switch ed esegui una sincronizzazione finale di posta e file se l'origine resta attiva. Per volumi elevati di posta o caselle critiche per l'attività, pianifica un cutover della posta più deliberato invece di trattarlo come un ripensamento.

Esegui il cutover con attenzione e mantieni disponibile il vecchio server

Quando i test sono puliti, metti le parti dinamiche del sito in una breve modalità di manutenzione se l'applicazione lo consente. Esegui un'esportazione finale del database o una sincronizzazione dell'account per acquisire ordini, invii dei moduli, modifiche degli utenti e aggiornamenti dei contenuti effettuati dal trasferimento iniziale. Ripristina o sincronizza questi dati finali sul VPS, quindi rimuovi la modalità di manutenzione dopo che il nuovo ambiente è pronto.

Aggiorna il record A con il nuovo indirizzo IPv4 e il record AAAA solo se IPv6 è configurato e testato. Se anche i nameserver stanno cambiando, apporta la modifica in modo deliberato e conferma che la nuova zona contenga tutti i record richiesti. Cambiare i nameserver e ricostruire il DNS nello stesso momento aggiunge variabili in movimento. A volte è necessario, ma non è la situazione DNS più elegante.

Tieni d'occhio il nuovo server durante le prime ore. Controlla i log di accesso web, gli errori PHP e dell'applicazione, il carico della CPU, la pressione sulla memoria, l'utilizzo del disco, lo stato della coda di posta e l'attività del database. Conferma che i backup automatici vengano eseguiti correttamente e che il monitoraggio possa raggiungere il nuovo VPS. Su kodu.cloud, è qui che le operazioni gestite e il monitoraggio FASTCARE sono utili: il servizio torna tranquillo perché qualcuno sta osservando il comportamento reale del server, non solo la homepage.

Non annullare immediatamente il vecchio servizio. Lascialo online finché la propagazione DNS non si è stabilizzata, il flusso della posta non è confermato, i backup non sono verificati e gli utenti chiave non hanno testato il sito live. Per la maggior parte dei siti standard, 72 ore sono una finestra di sicurezza ragionevole. Mantieni un piano di rollback durante quel periodo: conserva i vecchi valori DNS, evita modifiche distruttive alla sorgente e sappi chi prenderà la decisione se sarà necessario tornare indietro.

Controlli post-migrazione che prevengono problemi futuri

Dopo lo spostamento, rivedi backup pianificati, periodi di conservazione, test di ripristino, aggiornamenti di sicurezza, comportamento del firewall e trend delle risorse. Rimuovi le vecchie voci di test dal tuo file hosts locale. Aggiorna tutte le allowlist esterne, le destinazioni di monitoraggio, gli endpoint webhook e la documentazione che fanno riferimento al vecchio indirizzo IP.

Un VPS ti offre anche l'opportunità di ripulire il disordine accumulato da tempo nell'hosting. Rimuovi account email inattivi, vecchie copie di staging, database abbandonati e plugin o estensioni che non sono più necessari. Fallo dopo che la migrazione è stabile, non durante la finestra critica di trasferimento. Le modifiche fatte con calma sono più facili da annullare.

Una buona migrazione lascia più di un sito che casualmente si carica. Lascia un server che puoi monitorare, ripristinare, aggiornare e di cui puoi fidarti quando il traffico arriva in un'ora scomoda. Integra questo margine operativo nello spostamento e il prossimo intervento di manutenzione sembrerà molto meno un'operazione di salvataggio.

Andres Saar Customer Care Engineer