10 errori da evitare migrando da cPanel a Plesk senza perdere email e DNS

Chi gestisce server per lavoro sa che una migrazione di pannello non è mai solo "copia e incolla". Tra cPanel e Plesk cambiano modello di licenza, strumenti e soprattutto l'ordine in cui vanno spostati DNS, email e database. Sbagliare sequenza significa email che rimbalzano o zone DNS che spariscono per ore. Ecco i punti dove si inciampa più spesso.

1. Non verificare il modello di licenza prima di preventivare

Plesk è una licenza per server, con opzioni di prezzo per server virtuali o fisici (VPS o dedicati), e secondo le FAQ ufficiali Plesk offre inoltre più edizioni, tutte licenziate in base al numero di domini per tale server. Chi arriva da cPanel deve sapere che cPanel ha recentemente aumentato i prezzi e ora offre la licenza in base al singolo account cPanel, per cui il costo dell'hosting di più account su cPanel sta salendo. Risultato pratico: su un server con decine di account a basso traffico, Plesk può costare meno perché il limite è sui domini gestiti, non sugli account attivi. Secondo il listino ufficiale consultato il 6 ottobre 2026 su plesk.com/pricing, la licenza Web Pro Edition VPS costa 18,29 €/mese (30 domini) e la Web Host Edition VPS 31,38 €/mese (domini illimitati); Plesk segnala inoltre che dal 1° gennaio 2026 entra in vigore una nuova struttura dei prezzi che riguarda i rinnovi successivi a quella data — verificare l'importo esatto sul listino al momento dell'acquisto.

2. Pensare che si possa migrare "per dominio"

Errore classico di chi è abituato a spostare account cPanel uno per uno. Con Plesk Migrator non è possibile scegliere di migrare singoli domini. Solo le sottoscrizioni possono essere scelte per la migrazione, e vengono migrate insieme a tutti i domini associati. Se un cliente ha 5 domini sotto lo stesso account cPanel, in Plesk arrivano tutti insieme o nessuno.

3. Ignorare cosa il tool NON trasferisce

Gli account reseller e cliente che non hanno domini non vengono trasferiti. Le impostazioni di servizio di Plesk — gestori PHP installati, impostazioni Fail2Ban, impostazioni ModSecurity, impostazioni firewall e altro — non vengono trasferite. Vanno ricostruite a mano sul server di destinazione prima di spostare il traffico, altrimenti il nuovo server parte senza protezioni minime.

4. Non controllare la versione di cPanel sorgente

Plesk Migrator supporta la migrazione dalle seguenti piattaforme sorgente: Plesk 8.6 e successivi (Linux e Windows), cPanel 11.5 e successivi, oltre a Confixx 3.3, Helm 3.2, Plesk Expand 2.3.2 e DirectAdmin 1.51 (solo migrazione custom da Ubuntu 10.x). Su versioni più vecchie il tool non è garantito.

5. Avviare la migrazione senza preparazione

La procedura va iniziata dal lato Plesk: si avvia la migrazione dal pannello di amministrazione Plesk sul server di destinazione in Tools & Settings > Migration & Transfer Manager > Start a New Migration. Da lì si passa a cPanel e si inserisce l'indirizzo IP del server sorgente, la porta SSH (22 di default), login e password root del server sorgente.

6. Non sapere che si può rifare il punto dove ci si è interrotti

Si può sempre tornare a questa pagina per continuare da dove si era interrotti o per avviare un nuovo processo di migrazione: utile se la prima prova fallisce per un timeout SSH o un disco pieno sul sorgente.

7. Dimenticare il TTL delle zone DNS

Nei file di configurazione per la migrazione via riga di comando esiste il parametro zones-ttl, che corrisponde al tempo in secondi che lo strumento di migrazione imposta come SOA minimum TTL e intervallo di refresh su un nuovo server DNS. Se non specificato, viene assunto il valore predefinito: 120 secondi. Un TTL troppo basso o troppo alto sul nuovo server, lasciato al default senza valutarlo, può allungare la propagazione o moltiplicare il traffico di query durante il passaggio.

8. Fare il cutover DNS prima di aver verificato posta e database sul nuovo server

La sequenza corretta è: migrare prima i dati (file, mail, database) con Plesk Migrator, verificare che la posta arrivi correttamente sul nuovo server con un dominio di test, e solo dopo abbassare il TTL e spostare i record DNS pubblici. Invertire l'ordine — puntare prima il DNS e poi scoprire che IMAP non risponde — significa email perse per il tempo di propagazione.

9. Non pianificare la finestra di migrazione

La documentazione ufficiale consiglia che se il server sorgente è sovraccarico o ha poche risorse, è meglio pianificare la migrazione fuori dall'orario di lavoro, quando possibile. Vale soprattutto per database di grandi dimensioni, dove il trasferimento può saturare I/O e CPU del sorgente.

10. Saltare i controlli pre-migrazione

Plesk Migrator include controlli pre e post migrazione, funzioni di segnalazione errori e permette di risincronizzare i dati tra vecchio e nuovo server dopo la migrazione. Ignorare gli avvisi mostrati in fase di "Prepare Migration" per fare prima è il modo più comune per ritrovarsi con sottoscrizioni a metà spostate.

---

In sintesi: prima di toccare un solo record DNS, verificare licenza e versione sorgente, lanciare la migrazione delle sottoscrizioni con Plesk Migrator, controllare a mano posta e database sul nuovo server, e solo alla fine abbassare il TTL e spostare il DNS pubblico. Il tool fa il lavoro pesante, ma l'ordine delle operazioni resta responsabilità di chi gestisce il server.