51 06/04/2026 07/04/2026 11 min

Migrazione da CyberPanel ad aaPanel: decisione operativa

Se vuoi spostare un server da CyberPanel ad aaPanel, la regola è semplice: non “converti” il pannello, migri i carichi. I due pannelli hanno approcci diversi su vhost, servizi, utenti, SSL, firewall e gestione dei siti. Tentare di sovrascrivere l’installazione esistente porta quasi sempre a conflitti su web server, PHP handler, permessi e regole firewall.

La strada corretta è questa: inventario, backup verificato, nuova installazione aaPanel, ripristino controllato, validazione, poi cutover DNS o switch IP. Se il server ospita produzione, tratta la migrazione come un change controllato con finestra di manutenzione e rollback chiaro.

Quando ha senso migrare

La migrazione ha senso se vuoi:

  • ridurre dipendenza da un pannello specifico;
  • standardizzare la gestione su aaPanel;
  • separare meglio siti, database e servizi;
  • ricostruire un’istanza pulita dopo anni di modifiche manuali.

Ha meno senso se l’obiettivo è solo “cambiare interfaccia”. In quel caso il costo operativo può superare il beneficio. Il punto critico non è il pannello in sé, ma come sono stati installati e personalizzati i servizi: Apache, Nginx, PHP, MariaDB/MySQL, Redis, firewall, mail stack e cron.

Prima di iniziare: cosa devi sapere

Non esiste una migrazione one-click affidabile tra CyberPanel e aaPanel per tutti gli scenari. La compatibilità dipende da:

  • web server usato: OpenLiteSpeed, LiteSpeed, Nginx, Apache;
  • modalità PHP: versioni multiple, FPM, LSAPI;
  • tipologia siti: WordPress, Laravel, statici, app custom;
  • database: MySQL/MariaDB locali o remoti;
  • posta: locale, relay SMTP, provider esterno;
  • servizi accessori: Redis, Memcached, cron, backup, firewall.

Se il server usa OpenLiteSpeed con configurazioni molto specifiche, la migrazione richiede più attenzione. Se invece ospita siti classici con database locali e poco tuning, il percorso è più lineare.

Strategia consigliata: migrazione parallela

La strategia più sicura è preparare un nuovo server con aaPanel e poi trasferire i contenuti dal vecchio server CyberPanel. Questo riduce il rischio di rompere l’istanza in uso e semplifica il rollback.

  1. Raccogli inventario completo del vecchio server.
  2. Fai backup di file, database, configurazioni e DNS.
  3. Installa aaPanel su una macchina pulita o su una VM nuova.
  4. Ricrea siti, database, utenti e versioni PHP.
  5. Ripristina i dati e testa con hosts file o dominio temporaneo.
  6. Taglia il traffico con cambio DNS o switch IP.
  7. Monitora log, errori 5xx, tempi di risposta e posta.

Inventario minimo da raccogliere

Prima di toccare qualsiasi cosa, annota questi elementi:

  • hostname e IP pubblico del server sorgente;
  • elenco domini e sottodomini;
  • document root di ogni sito;
  • versioni PHP in uso;
  • database associati a ciascun sito;
  • cron job;
  • regole firewall;
  • certificati SSL attivi e relativa scadenza;
  • eventuali mailbox o relay SMTP;
  • plugin di caching, WAF o CDN.

Se hai accesso SSH al server CyberPanel, una raccolta base può partire da questi comandi:

hostname -f
ip addr
ls -lah /home
crontab -l
php -v
mysql --version
ss -ltnp

Per i siti in genere CyberPanel usa percorsi sotto /home/DOMINIO/public_html, ma non dare per scontato che tutti i siti siano uguali: verifica il vhost reale e i symlink.

Backup: la parte che evita il disastro

Il backup va fatto prima della migrazione, non dopo. Minimo indispensabile:

  1. File dei siti: archivio per ogni document root.
  2. Database: dump separato per ogni DB.
  3. Configurazioni: vhost, cron, eventuali custom include.
  4. Certificati: solo se non intendi rilasciarli di nuovo via ACME.
  5. Lista utenti e permessi: utile per ricreare ownership corrette.

Esempio di backup file e database, da adattare ai tuoi path reali:

tar -czf /root/backup-siti-$(date +%F).tar.gz /home/DOMINIO/public_html
mysqldump --single-transaction --routines --triggers NOME_DB | gzip > /root/NOME_DB-$(date +%F).sql.gz

Verifica sempre che l’archivio sia leggibile:

tar -tzf /root/backup-siti-$(date +%F).tar.gz | head
gzip -t /root/NOME_DB-$(date +%F).sql.gz

Se il dump è corrotto o incompleto, fermati qui. Ripartire da un backup non verificato è il modo più veloce per perdere tempo e dati.

Installazione di aaPanel

aaPanel va installato su sistema pulito o comunque su una macchina dove non ci siano conflitti con stack già presenti. Se vuoi minimizzare i problemi, prepara una VM o un server nuovo con OS supportato e risorse adeguate.

Prima di installare, controlla che non ci siano web server o stack incompatibili già attivi:

systemctl status nginx apache2 httpd lsws mariadb mysql

Se il server nasce per aaPanel, installa il pannello seguendo la procedura ufficiale del progetto e poi scegli gli stack da gestire dal pannello. La scelta pratica è: web server, PHP, database, redis, firewall e scheduler. La migrazione funziona meglio se ricrei prima la piattaforma, poi i siti.

Durante l’installazione, prendi nota di:

  • porta del pannello;
  • credenziali iniziali;
  • directory di installazione;
  • servizi abilitati di default;
  • regole firewall da aprire solo se necessarie.

Ricreare i siti in aaPanel

In aaPanel crea prima i siti e solo dopo importa i dati. Per ogni dominio devi definire almeno:

  • nome dominio;
  • document root;
  • versione PHP;
  • tipo di web server;
  • opzione SSL;
  • eventuale redirect www/non-www;
  • log dedicati.

Il criterio corretto è quello del sito, non del pannello. Se un sito in CyberPanel era in PHP 8.1 con certe estensioni, in aaPanel devi ricreare lo stesso set, altrimenti il sito può andare in errore o degradare.

Se l’app è WordPress, verifica anche plugin di caching, object cache e permessi su upload. Se l’app è Laravel o Symfony, controlla il document root corretto, i permessi su storage e bootstrap/cache, e l’eventuale .env.

Ripristino file e database

Una volta creato il sito in aaPanel, ripristina i file nella nuova document root. Esempio:

rsync -aH --delete /backup/DOMINIO/public_html/ /www/wwwroot/DOMINIO/

Il path esatto può cambiare in base alla tua installazione di aaPanel, quindi verifica nella UI o con il file manager del pannello. Il punto importante è mantenere ownership e permessi coerenti con l’utente del web server.

Per il database, crea prima il DB e l’utente in aaPanel, poi importa il dump:

gunzip -c /root/NOME_DB-2026-04-05.sql.gz | mysql -u UTENTE_DB -p NOME_DB

Dopo l’import, controlla che le tabelle ci siano davvero:

mysql -u UTENTE_DB -p -e "USE NOME_DB; SHOW TABLES;"

Se il sito usa un file di configurazione con credenziali DB, aggiorna host, nome database, utente e password. Qui i punti tipici sono wp-config.php, .env, file custom di connessione o configurazioni CMS proprietarie.

Permessi, ownership e SELinux

Molti problemi post-migrazione non dipendono dal pannello ma dai permessi. Dopo il copia-incolla dei file, verifica che il web server possa leggere ciò che serve e scrivere solo dove è previsto.

Controlli base:

ls -lah /www/wwwroot/DOMINIO
find /www/wwwroot/DOMINIO -maxdepth 2 -type d | head

Se vedi errori 403 o upload che falliscono, il primo sospetto è ownership errata. Se la distribuzione usa SELinux, controlla anche i context. In quel caso la migrazione richiede una verifica aggiuntiva, perché i permessi Unix da soli non bastano.

SSL e certificati

Su aaPanel conviene spesso rilasciare nuovi certificati via Let’s Encrypt invece di portarsi dietro quelli vecchi, a meno che tu non abbia un motivo preciso per riusare la chiave privata. È più pulito, riduce problemi di path e ti evita di inseguire file sparsi.

Verifica per ogni dominio:

  • certificato valido;
  • chain completa;
  • redirect HTTP to HTTPS;
  • scadenza e rinnovo automatico.

Un test rapido lato shell:

curl -I https://dominio.tld
openssl s_client -connect dominio.tld:443 -servername dominio.tld < /dev/null | openssl x509 -noout -dates -subject

Se il browser mostra certificato errato o mismatch, il problema può essere il vhost, il SNI o il DNS che punta ancora al vecchio server.

DNS e cutover

Il cambio DNS è il momento in cui la migrazione diventa visibile agli utenti. Abbassa il TTL con anticipo se possibile, idealmente almeno 24 ore prima. Se non lo hai fatto, il cutover può comunque funzionare, ma il propagarsi sarà più lento e meno prevedibile.

Prima dello switch finale, testa il nuovo server con file hosts locale oppure con un dominio temporaneo. In questo modo puoi verificare il sito senza esporlo pubblicamente.

Controlli utili:

dig +short dominio.tld
curl -I http://IP_NUOVO
curl -I https://dominio.tld

Se il DNS è gestito da provider esterno, aggiorna solo record A/AAAA o CNAME necessari. Evita modifiche inutili durante il cutover. La regola è: meno cambi fai, meno punti di fallimento introduci.

Mail: il capitolo più delicato

Se il server gestisce anche la posta, la migrazione è più complessa. aaPanel può gestire componenti mail, ma non dare per scontato che il vecchio setup sia replicabile 1:1. Devi distinguere tra:

  • posta locale sul server;
  • relay SMTP esterno;
  • solo invio applicativo;
  • mailbox utenti finali.

Se il server invia solo mail applicative, spesso conviene mantenere un provider SMTP esterno e aggiornare le credenziali nell’app. Se invece ospita mailbox, devi migrare dati, utenti, record MX, SPF, DKIM e DMARC con molta attenzione.

Controlli minimi per l’email:

  • SPF corretto;
  • DKIM attivo;
  • DMARC presente;
  • PTR del server coerente;
  • porta 25/465/587 disponibile secondo policy del provider.

Qui il rollback va pensato prima: se la posta è critica, non cambiare MX finché il nuovo stack non ha superato test di invio e ricezione.

Controlli applicativi dopo il ripristino

Dopo aver copiato file e database, non limitarti a vedere la homepage. Fai un test funzionale per ogni sito:

  1. homepage;
  2. login admin;
  3. form contatto;
  4. upload file;
  5. checkout o funzioni core, se presenti;
  6. cron e job schedulati;
  7. invio email transazionali;
  8. cache e rigenerazione pagine.

Guarda anche i log del sito e del web server. I path variano, ma in genere trovi errori PHP, 403, 404, 500 o problemi di connessione DB. Un controllo rapido lato shell può essere:

tail -n 100 /www/wwwlogs/*.log
journalctl -u nginx -n 100 --no-pager
journalctl -u php-fpm -n 100 --no-pager

Se vedi pagine bianche, i sospetti principali sono: estensioni PHP mancanti, errori fatali, path sbagliato, permessi o DB non raggiungibile.

Rollback: come tornare indietro

Il rollback deve essere semplice e già deciso prima del cutover. La forma più pulita è mantenere attivo il vecchio server CyberPanel finché il nuovo non è validato. Se qualcosa va storto, puoi riportare il DNS al vecchio IP o riattivare il vecchio endpoint.

Rollback minimo:

  1. non toccare i dati sul vecchio server;
  2. ripristina DNS al vecchio IP;
  3. lascia TTL basso per accelerare il ritorno;
  4. conserva i dump e gli archivi della migrazione;
  5. annota la causa del fallimento prima di ritentare.

Se hai già spento il vecchio server, il rollback diventa più costoso. Per questo, durante la finestra di migrazione, tieni sempre una copia funzionante del sistema sorgente fino a validazione completa.

Errori tipici e come riconoscerli

Alcuni problemi ricorrono spesso:

  • 500 dopo la migrazione: PHP mismatch, estensioni mancanti, file .htaccess non compatibile, permessi errati;
  • 404 sulle route: document root sbagliato o rewrite non importate;
  • 403: ownership o policy di accesso;
  • DB error: credenziali, host o dump incompleto;
  • SSL warning: certificato non emesso, vhost errato, SNI mancante;
  • mail non parte: SPF/DKIM/relay/porta bloccata.

Quando il problema è ambiguo, isola il layer. Prima verifica DNS e risposta HTTP, poi web server, poi PHP, poi database. Non partire dal codice applicativo se non hai escluso i livelli sotto.

Checklist finale di migrazione

  1. Inventario completo fatto.
  2. Backup verificato con test di integrità.
  3. Nuovo server aaPanel installato e aggiornato.
  4. Siti ricreati con versioni PHP corrette.
  5. File ripristinati nella document root giusta.
  6. Database importati e testati.
  7. Permessi e ownership controllati.
  8. SSL attivo e valido.
  9. DNS aggiornato o testato via hosts file.
  10. Log monitorati per almeno un ciclo completo di accessi.

Se tutti i punti sopra sono verdi, la migrazione è sostanzialmente chiusa. Se uno solo è rosso, non considerarla finita: in hosting i problemi si presentano spesso dopo il primo traffico reale o il primo job schedulato.

Scelta pratica: migrare bene, non veloce

La migrazione da CyberPanel ad aaPanel non è un esercizio di velocità. È un esercizio di controllo. Il valore sta nel ricostruire un ambiente pulito, documentato e verificabile, non nel premere un pulsante e sperare che tutto resti uguale.

Se il sito è piccolo, il percorso più efficiente è quasi sempre: backup, nuovo server, ripristino, test, switch DNS, monitoraggio. Se il sito è complesso, aggiungi staging, test funzionali e un piano di rollback scritto. La parte difficile non è copiare i file: è evitare che il traffico reale trovi un dettaglio non verificato.

Assunzione operativa: questo articolo parte dallo scenario di migrazione tra due pannelli su server Linux con siti web, database locali e possibile uso di SSL e posta; se il tuo stack include cluster, storage esterno o mail server dedicato, il piano va adattato prima del cutover.

Riferimenti operativi utili

  • Documentazione ufficiale di aaPanel per installazione e gestione siti.
  • Documentazione del tuo web server e del tuo CMS.
  • Note sul provider DNS e sulla scadenza dei certificati SSL.
Se non hai un backup verificato e un rollback pronto, non è una migrazione: è un test in produzione.