Partire dall'inventario, non dal fornitore
Prima di scegliere un provider o un'architettura di destinazione, elencate che cosa avete davvero in esercizio:
- Le applicazioni, con il responsabile di business, la criticità e gli utenti.
- L'infrastruttura: server, database, storage, apparati di rete, licenze.
- Le dipendenze: quale applicazione chiama quale, database condivisi, trasferimenti di file, job pianificati, indirizzi IP scritti nel codice.
- I dati: volumi, sensibilità, regole di conservazione, dove possono risiedere per legge.
- La gestione: come ogni sistema viene oggi salvato, monitorato, aggiornato e supportato.
La mappa delle dipendenze merita tempo. I dati sui flussi di rete e le interviste a chi gestisce i sistemi fanno emergere quasi sempre integrazioni che nessun documento cita: un export notturno verso la contabilità, una coda di stampa, l'account SFTP di un partner.
Una strategia per ogni applicazione
Non esiste un unico modo di migrare. La classificazione più diffusa, resa popolare da AWS, prevede sette opzioni:
| Strategia | In che cosa consiste | Quando ha senso |
|---|---|---|
| Retire | Dismettere | Nessuno la usa, o un altro sistema fa già lo stesso lavoro |
| Retain | Lasciarla dov'è, per ora | Aggiornata di recente, vincoli forti, o non conviene ancora spostarla |
| Rehost | Spostarla così com'è ("lift and shift") | Conta la velocità, l'applicazione è stabile, cambiarla è rischioso |
| Relocate | Spostare in blocco la piattaforma di virtualizzazione | Grandi ambienti VMware con una destinazione cloud compatibile |
| Replatform | Spostarla con modifiche mirate, ad esempio un database gestito | Vantaggi chiari con poche modifiche al codice |
| Repurchase | Sostituirla con un prodotto SaaS | Un pacchetto standard oggi copre l'esigenza |
| Refactor | Riprogettarla sui servizi cloud-native | L'applicazione è strategica e i suoi limiti frenano il business |
La risposta va data applicazione per applicazione e può cambiare nel tempo. Un percorso frequente è fare prima il rehost, per lasciare un data center nei tempi previsti, e poi il replatform o il refactor delle applicazioni che contano di più. Per i sistemi grandi e critici il refactor funziona meglio a piccoli passi: lo spieghiamo nell'articolo sul pattern strangler fig.
Prima la landing zone
La landing zone è la base su cui vivranno tutti i carichi migrati: struttura degli account o delle sottoscrizioni, rete, identità e accessi, log, cifratura, backup e controlli di sicurezza di base. Se è costruita una volta e descritta come codice, ogni nuova applicazione eredita gli stessi controlli invece di reinventarli.
È anche il momento in cui si decidono residenza dei dati e gestione delle chiavi, secondo le vostre regole di cloud sovrano. Cambiarle dopo che cinquanta carichi sono già arrivati costa caro.
Un pilota da cima a fondo
Scegliete una prima applicazione reale ma non critica e migratela completamente: infrastruttura, dati, monitoraggio, backup, procedure operative, passaggio al supporto. Il pilota mette alla prova landing zone, strumenti e team, e produce il modello (checklist, script, piani di test) che le migrazioni successive riutilizzano.
Le altre applicazioni si raggruppano poi in ondate, ordinate secondo le dipendenze e il calendario aziendale. Le applicazioni che comunicano di continuo tra loro di solito vanno spostate insieme, per evitare latenze e costi di trasferimento dati a cavallo dei due ambienti.
Migrazione dei dati e cutover
I dati sono di solito la parte più difficile. L'approccio dipende dai volumi e da quanto fermo il business può accettare:
- Copia offline: si bloccano le scritture, si copia, si verifica, si riparte in cloud. Semplice, ma il fermo cresce con i volumi.
- Replica continua: si copia in anticipo il grosso dei dati, si mantengono allineate origine e destinazione, poi si passa in una finestra breve.
In entrambi i casi il piano di cutover va scritto come una procedura con responsabili e tempi, criteri espliciti per decidere se procedere e un percorso di rollback. Va provato almeno una volta su una copia della produzione. Dopo la migrazione i dati si verificano con conteggi, checksum e controlli di business: totali che l'amministrazione riconosce convincono più dei log tecnici.
Gestione e costi dopo il trasloco
Un'applicazione migrata è finita solo quando è gestita bene nella sua nuova casa:
- Monitoraggio e allarmi collegati a chi è reperibile.
- Backup verificati con ripristini veri.
- Rilasci automatizzati, perché le modifiche non dipendano più da passaggi manuali su un server: ne parliamo nelle note su CI/CD e rilasci incrementali.
- Controllo dei costi: ogni risorsa etichettata per applicazione e responsabile, budget con avvisi, ridimensionamento dopo qualche settimana di uso reale, ambienti non produttivi spenti fuori orario.
In cloud i costi sono variabili per natura. Senza un responsabile e una revisione periodica tendono a crescere; con entrambi diventano una leva che l'azienda vede e governa.
Da dove partire
Completate l'inventario, scegliete la strategia per ogni applicazione, costruite la landing zone e migrate un pilota da cima a fondo. Il nostro servizio di cloud sovrano e cybersecurity segue questa sequenza, documentando ogni passo perché il vostro team possa gestire ciò che costruiamo.