Progetto cliente / Migrazione da Aruba

Cliente Laura / Rossano

Vuole uscire dalla vecchia agenzia. Sito su Aruba, email da gestire, migrazione WordPress da pianificare con calma.

Portato da Laura Hosting attuale: Aruba Fase: raccolta credenziali

Regola d'oro: Non toccare nulla all'inizio. Prima le credenziali, poi si pianifica. Senza accesso completo non fai niente — e rischi di fare danni senza poter riparare.

Situazione attuale

Il cliente (portato da Laura, referente diretto Rossano) vuole uscire dalla vecchia agenzia e passare la gestione del sito a Stefano. Il sito WordPress è attualmente su hosting Aruba, con dominio e caselle email sulla stessa infrastruttura.

Nessun accesso in mano a Stefano ancora. Il punto di partenza è raccogliere tutte le credenziali da Rossano, cambiare le password e centralizzarle nel brain. Solo dopo si pianifica qualsiasi migrazione.

Credenziali da raccogliere da Rossano
🖥️
Credenziali pannello Aruba (hosting)
Username + password account Aruba — accesso a cPanel o pannello dedicato
Mancante
🌐
Credenziali gestione dominio
Potrebbe essere lo stesso account Aruba o un registrar separato
Mancante
📁
Accesso FTP/SFTP ai file del sito
Host FTP, username, password — serve per il backup dei file WordPress
Mancante
🗄️
Accesso database MySQL (phpMyAdmin o credenziali dirette)
Host DB, nome DB, username DB, password DB
Mancante
🔑
Credenziali admin WordPress
URL wp-admin, username, password
Mancante
📧
Lista caselle email attive + info sullo storico
Quante caselle, chi le usa, quanto storico vogliono conservare — prima di toccare l'email
Da chiedere
Piano operativo in fasi
1
Raccogliere credenziali
Chiedi a Rossano tutte le credenziali elencate sopra. Non procedere senza. Appena le hai, cambiale e mettile nel brain (wiki/passwords/cliente-rossano/ oppure in .env).
2
Cambiare le password e centralizzare
Accedi ai pannelli con le credenziali di Rossano, cambia tutte le password e salvale nel brain. L'obiettivo è che Stefano (non la vecchia agenzia) abbia il controllo. Poi riconsegna l'accesso al cliente se necessario.
3
Audit del sito
Con accesso al sito, usa la skill Radar per fare un audit automatico: screenshot, problemi tecnici, plugin outdated, versione WordPress. Poi esamina il tema: è un child theme o CSS diretto sul tema principale? (Se è quest'ultimo, va risolto prima di migrare.)
4
Backup completo da Aruba
Prima di toccare qualsiasi cosa: backup. File via FTP (tutta la cartella WordPress) + export database (.sql tramite phpMyAdmin). Questo è il punto di ripristino se qualcosa va storto.
5
Decidere la destinazione
Dove va il sito? Sul server di Stefano (efesto), su Cloudways, su altro hosting? Dipende dal tipo di sito, traffico previsto, budget cliente. Pianifica con Giobi prima di procedere.
6
Migrazione WordPress
Upload file su nuovo hosting via FTP, import database, aggiornare wp-config.php con nuove credenziali DB, aggiornare URL in database. Testare su sottodominio temporaneo prima di cambiare DNS.
7
Migrazione email (operazione notturna)
La parte più rischiosa. Cambiare i record MX comporta un periodo di transizione dove le email possono andare su vecchio o nuovo server. Operazione notturna, con backup dello storico prima. Chiedere a Giobi le istruzioni dettagliate quando sei pronto.
8
Switch DNS e go-live
Cambiare i record DNS (A, MX) per puntare al nuovo hosting. Propagazione 1-48 ore. Monitorare che tutto funzioni. Il vecchio hosting va mantenuto attivo ancora qualche giorno come backup.
Migrazione WordPress — punti tecnici chiave
File
Backup via FTP
Scarica tutta la cartella WordPress: wp-content/ (temi, plugin, upload), wp-config.php, .htaccess. I file di sistema di WP si riscrivono.
Database
Export .sql
Da phpMyAdmin: Export → formato SQL → scarica il file. Contiene post, pagine, utenti, commenti, impostazioni.
URL rewrite
Aggiornare URL nel DB
Se il dominio cambia, va aggiornato nel database con WP-CLI o Search Replace DB. Attenzione ai dati serializzati — non fare un semplice sed/replace.
Child theme
CSS nel posto giusto
Il CSS personalizzato deve stare in un child theme, non sul tema principale. Altrimenti ogni aggiornamento del tema sovrascrive tutto. Giobi spiega allo sviluppatore.
Test
Sottodominio temporaneo
Crea un sottodominio tipo test.stevetech.it o preview.nomecliente.it e testa il sito lì prima di fare il switch DNS.
Email
Separare dal timing sito
Migra il sito prima, l'email dopo — in momenti separati. Meno cose che cambiano insieme = meno rischi di casino simultaneo.
Dove salvare le credenziali nel brain

Crea subito la struttura nel tuo brain per centralizzare le credenziali clienti. La cartella wiki/passwords/ deve essere organizzata per cliente.

Da fare
Creare wiki/passwords/ nel brain
Cartella principale per tutte le credenziali clienti
Da fare
Creare wiki/passwords/cliente-rossano/
Con un index.md che referenzia le credenziali in .env
Regola
Password vere solo in .env, mai nel wiki
Il wiki contiene il riferimento (es. "vedi ROSSANO_ARUBA_PASS in .env"), non il valore
Warning sull'email

Attenzione massima sulla migrazione email. Se si cambia il record MX e il vecchio server è ancora attivo, le email vanno in due posti diversi. Se si spegne il vecchio server troppo presto, si perdono email in transito. Il piano: backup di tutto lo storico prima, migrazione di notte quando il traffico è basso, monitoring attivo nelle ore successive. Non improvvisare — chiedi a Giobi le istruzioni dettagliate quando sei in quella fase.