Migrare un sito da cPanel a Plesk

Migrare un sito da cPanel a Plesk

Migrare un sito da cPanel a Plesk e una operazione comune quando si cambia provider o si consolida l'infrastruttura. Plesk offre un Migration Manager integrato che semplifica la maggior parte dei casi, ma una pianificazione attenta riduce errori e downtime.

Strumenti disponibili

Plesk Obsidian include il Plesk Migrator: una estensione che si connette via SSH al server cPanel di origine, scarica account, database, email, configurazioni DNS e ricostruisce tutto su Plesk. Funziona via API cPanel + WHM e gestisce trasferimenti incrementali. In alternativa, per pochi siti, si puo procedere manualmente con backup cPanel (.tar.gz) e import in Plesk.

Pre-requisiti

Sul server cPanel: accesso WHM e SSH come root. Sul server Plesk: estensione Migrator installata, spazio disco sufficiente, DNS gestito esternamente o pronto a essere aggiornato. Verifica versioni PHP supportate: cPanel e Plesk potrebbero avere versioni leggermente diverse, abilita quella necessaria su Plesk prima della migrazione.

Procedura passo-passo

  1. Installa Plesk Migrator su Plesk: Estensioni > Migration & Transfer Manager.
  2. Su Plesk avvia New Migration e inserisci IP/SSH credentials di cPanel.
  3. Plesk scansiona gli account; seleziona quelli da migrare.
  4. Avvia il trasferimento iniziale (puo richiedere ore).
  5. Verifica la copia: file, database, email, alias.
  6. Riduci TTL DNS a 300 secondi 24h prima del cutover.
  7. Esegui sync incrementale finale per recuperare eventuali differenze.
  8. Aggiorna i record DNS verso il nuovo IP Plesk.
  9. Rigenera certificati SSL (Let s Encrypt via WP Toolkit o pulsante SSL It!).
  10. Monitora i log per 48-72 ore.

Cosa migra automaticamente

  • File di siti web e relativi permessi.
  • Database MySQL/MariaDB con utenti e grants.
  • Caselle email IMAP/POP con messaggi e cartelle.
  • DNS zones (per riferimento, da applicare manualmente al nameserver).
  • Cron job e configurazioni PHP per dominio.
  • Subdomain e add-on domain.

Cosa verificare a mano

  • Configurazioni specifiche: .htaccess complessi, regole Apache custom.
  • Permessi file di CMS (WordPress, Joomla, Prestashop).
  • Certificati SSL: rigenerali con Let s Encrypt o reimporta i custom.
  • Mail filter, autoresponder, mailing list che usano sintassi cPanel specifica.
  • Cron expression che potrebbero richiedere adeguamento PATH.

Errori comuni e come risolverli

  • Versione PHP errata: imposta la versione corretta nel pool PHP-FPM di Plesk.
  • Email duplicate: se il sync gira durante traffico email, rischio doppioni.
  • DNS non aggiornati: controlla TTL e propagazione.
  • Permission denied dopo migrazione: esegui plesk repair fs.

Domande frequenti

D: Quanto dura una migrazione tipica?
R: Da poche ore a 1-2 giorni per server con molti account o GB.

D: Ho downtime?
R: Minimo, se TTL DNS basso e sync incrementale. Tipicamente 5-15 minuti.

D: Posso rollback se qualcosa va male?
R: Si, il server cPanel resta attivo finché non lo dismetti.

Approfondimento tecnico: differenze nei filesystem layout

cPanel e Plesk organizzano i file in modo diverso, e il Migrator gestisce automaticamente le traduzioni. cPanel mette i siti in /home/USER/public_html/, Plesk in /var/www/vhosts/DOMAIN/httpdocs/. Anche i percorsi log differiscono: cPanel /usr/local/apache/logs/, Plesk /var/www/vhosts/system/DOMAIN/logs/. Eventuali path hard-coded negli script o nel codice applicativo vanno aggiornati post-migrazione.

I web server differiscono: cPanel storicamente Apache + LiteSpeed opzionale; Plesk Apache + Nginx in reverse proxy di default. Configurazioni Apache custom (mod_rewrite, mod_security) si trasferiscono per .htaccess; configurazioni Nginx eventuali vanno riscritte.

Scenari d'uso reali

Un provider migra 200 account in un weekend con Plesk Migrator, sync incrementale notturno e cutover programmato.

Un singolo cliente WordPress migra manualmente con WP All-in-One Migration + reimport database: 30 minuti, zero rischio.

Un e-commerce Magento migra con più attenzione: media, cron, queue, configurazione cache; tipicamente 2-3 settimane di pianificazione.

Checklist operativa migrazione

  • Plesk Migrator installato e configurato.
  • Accesso SSH root su entrambi i server.
  • Versioni PHP allineate.
  • TTL DNS ridotto 48h prima.
  • Sync incrementale finale prima del cutover.
  • Rigenerazione SSL su Plesk.
  • Test funzionale post-migrazione.

Risorse e riferimenti

Plesk Migration Manager docs: docs.plesk.com/en-US/obsidian/migration-guide. Articoli ufficiali su transfer Tool. Per scenari complessi (e-commerce, multi-server), considera supporto Plesk Premium o partner certificati. Backup di sicurezza pre-migrazione sempre prima del cutover.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su migrare un sito da cpanel a plesk richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.

Hai trovato utile quest'articolo?