Migrazione cloud: fasi, strategie e obblighi da pianificare

La migrazione cloud è lo spostamento di applicazioni, dati e infrastruttura da un data center proprio, da un hosting privato o da un altro provider verso un cloud pubblico. Secondo la documentazione di Google Cloud si fa in quattro fasi (valutazione, pianificazione, spostamento, messa a punto) e per ogni carico si sceglie una strategia, dal trasferimento così com'è alla riscrittura. Prima dei server si decidono identità, rete, piano di ritorno e obblighi normativi.

Questa guida segue il metodo del Google Cloud Architecture Center e aggiunge quello che GDPR, NIS2, DORA e Data Act chiedono a un'azienda italiana che migra.

Cos'è la migrazione cloud, in concreto

Migrare non vuol dire copiare macchine virtuali. Vuol dire decidere, carico per carico, se spostarlo com'è, adattarlo, riscriverlo, sostituirlo con un servizio in abbonamento o lasciarlo dov'è. Che si parta da un data center di proprietà, da una colocation o da un altro cloud, il metodo resta lo stesso.

Il cloud è già entrato in tre imprese italiane su quattro tra quelle con almeno 10 addetti. Secondo Eurostat, nel 2025 il 75,6% di queste imprese (settore finanziario escluso) usava servizi cloud a pagamento via internet, contro il 52,7% della media UE (dataset isoc_cicce_use). Il dato conta qualsiasi servizio a pagamento e non dice quanti carichi restano in sala server: la migrazione riguarda quelli.

Le quattro fasi della migrazione cloud

Google descrive la migrazione come un percorso dal punto A, l'infrastruttura di oggi, al punto B, l'ambiente cloud, diviso in quattro fasi: Assess, Plan, Deploy e Optimize (Migrate to Google Cloud: Get started).

1. Valutazione: sapere cosa hai

Si costruisce l'inventario dei carichi e delle loro dipendenze (database, code di messaggi, sistemi di configurazione), si calcola il costo totale di possesso dell'ambiente di arrivo e si misurano le prestazioni di partenza.

Nell'inventario vanno anche le informazioni non tecniche:

• Licenze. Alcune consentono l'uso in cloud, altre lo vietano esplicitamente; quelle calcolate su CPU o socket possono non avere più senso su un'infrastruttura cloud.
• Vincoli sui dati. Alcuni dati possono avere restrizioni sulla regione geografica in cui vengono conservati.
• Carichi sensibili che possono richiedere server dedicati a un solo cliente (sole tenancy).

Poi si classifica ogni carico. Google propone una matrice con criticità per il business, dipendenze, fermo massimo tollerabile e difficoltà di migrazione, che nella forma più semplice ha tre valori: facile, difficile, non migrabile.

La valutazione si chiude con il piano: carichi e dati raggruppati in lotti, l'ordine dei lotti e quello dei carichi dentro ogni lotto, e tre documenti, cioè il design tecnico, la matrice RACI e una timeline a ritroso (T-minus plan). Prima di impegnarsi su tutto il parco conviene un proof of concept: secondo le best practice di Google serve a misurare il fermo reale, provare gli scenari di ritorno indietro e verificare che ruoli IAM, policy di sicurezza e requisiti di compliance corrispondano alle esigenze dell'azienda.

2. Pianificazione: costruire le fondamenta

Prima di spostare un solo carico si costruisce l'infrastruttura di base: gestione delle identità, struttura di organizzazione e progetti, rete. Nella stessa fase si fissano le priorità della migrazione.

Poi si sceglie il primo carico. Google consiglia di non partire da un sistema critico, perché ogni errore commesso mentre la squadra impara ricade sull'attività principale, ma nemmeno da un sistema usato poche volte l'anno o da un caso limite: il primo carico serve a imparare schemi che si ripetono. Nel loro esempio, meglio il database di staging che la logica delle transazioni dell'e-commerce.

3. Spostamento: muovere i carichi

Si progetta e si esegue il processo con cui i carichi passano su Google Cloud. Per ogni tipo di oggetto esiste uno strumento dedicato:

• Migrate to Virtual Machines per server fisici e macchine virtuali, da ambienti on-premise o da altri cloud;
• Database Migration Service per i database;
• Storage Transfer Service per i dati verso Cloud Storage;
• Transfer Appliance, un dispositivo fisico per volumi da centinaia di terabyte fino a 1 petabyte.

Il rischio di questa fase si governa con due regole delle best practice di Google: una strategia di ritorno indietro (rollback) per ogni passo del piano, provata periodicamente, e un tempo massimo per ogni passo, scaduto il quale la squadra torna indietro invece di insistere. I passi che possono causare perdita di dati anche con il rollback vanno individuati prima.

Sul fermo Google è esplicito: migrare a zero o quasi zero downtime è più difficile, perché richiede ridondanza per ogni carico da spostare. Dove possibile si evita di imporlo: per i carichi che tollerano un fermo si sceglie una finestra, per esempio la sera tardi o il fine settimana.

4. Messa a punto: usare davvero il cloud

Nell'ultima fase si comincia a sfruttare le capacità del cloud su prestazioni, scalabilità, disaster recovery e costi. Alla via di ritorno verso l'ambiente di origine si rinuncia solo quando i carichi hanno girato senza problemi per un periodo stabilito e il monitoraggio non vede più verso la sorgente traffico che dovrebbe andare al cloud. A migrazione chiusa vanno aggiornati runbook, documentazione di supporto e dashboard di monitoraggio.

Le sei strategie di migrazione, dal rehost al repurchase

Per ogni carico si sceglie una strategia. La documentazione di Google ne definisce sei:

1. Rehost (lift and shift): il carico si sposta con modifiche minime o nulle. È la strada più semplice e di solito la più rapida, ma il carico non sfrutta appieno le caratteristiche del cloud.
2. Replatform (lift and optimize): si sposta il carico e poi lo si adatta al nuovo ambiente, per esempio portandolo su container. Richiede più lavoro del rehost e più cicli di test.
3. Refactor (move and improve): si modifica il carico per usare funzioni come scalabilità e alta disponibilità. Richiede più tempo del rehost e competenze nuove.
4. Re-architect: cambia il modo in cui il codice funziona, per esempio scomponendo un'applicazione monolitica in microservizi. È più complesso del refactor e richiede più cicli di test, perché può introdurre bug o problemi di sicurezza.
5. Rebuild (remove and replace): si dismette l'applicazione e la si riprogetta e riscrive da zero per il cloud. Elimina il debito tecnico, ma può richiedere più tempo di rehost e refactor e non si applica al software acquistato già pronto.
6. Repurchase: si passa da un software acquistato on-premise al suo equivalente SaaS, per esempio dalla collaborazione e dall'archivio locali a Google Workspace. Può richiedere molto meno lavoro di un refactor, di un rebuild o di un re-architect, ma costare di più e lasciare meno controllo sull'ambiente.

La regola generale della stessa guida: le migrazioni che riescono cambiano il carico il meno possibile durante lo spostamento.

La sicurezza non si sposta da sola

In cloud la sicurezza si divide: l'infrastruttura fisica è del provider, mentre identità, permessi, configurazioni e dati restano a te. È il modello di responsabilità condivisa, e va letto prima di scegliere la strategia: secondo Google, in cloud puoi costruire la tua infrastruttura virtualizzata oppure comprare servizi completamente gestiti, in cui ti occupi solo dei carichi e lasci al provider la gestione degli ambienti di esecuzione. Se il tema è nuovo, il punto di partenza è la guida su cos'è la cloud security.

Due punti da fissare nel piano:

• Dove finiscono backup e log. La regione si sceglie servizio per servizio. Google Cloud ha due regioni in Italia, Milano (europe-west8) e Torino (europe-west12), con tre zone ciascuna: va verificato che anche copie, log e disaster recovery stiano dove hai deciso.
• Una verifica a carichi spostati. Dopo il passaggio serve una fotografia della sicurezza del cloud sull'ambiente reale: cosa è esposto su internet, con quali permessi, vicino a quali dati.

Cosa chiedono GDPR, NIS2, DORA e Data Act

GDPR

Se nei carichi ci sono dati personali, il provider diventa responsabile del trattamento. L'art. 28 del Regolamento (UE) 2016/679 chiede di ricorrere solo a responsabili che presentino garanzie sufficienti e regola il ricorso ad altri responsabili, mentre il Capo V (art. 44 e seguenti) disciplina i trasferimenti verso paesi terzi. Contratto di trattamento, sub-responsabili e paesi da cui opera il supporto vanno verificati in valutazione.

NIS2

Per un soggetto essenziale o importante, il D.Lgs. 138/2024 inserisce tra le misure minime la continuità operativa, con gestione dei backup e ripristino in caso di disastro (art. 24, comma 2, lett. c), e la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori di servizi (lett. d). Il provider cloud è uno di questi fornitori: il comma 3 chiede di tenere conto delle sue vulnerabilità specifiche e della qualità complessiva delle sue pratiche di sicurezza.

DORA

Per le entità finanziarie, come banche, istituti di pagamento, imprese di investimento e assicurazioni, il Regolamento (UE) 2022/2554 contiene una regola che tocca i tempi del progetto: «Le entità finanziarie informano tempestivamente l’autorità competente in merito a eventuali accordi contrattuali previsti per l’utilizzo di servizi TIC a supporto di funzioni essenziali o importanti, nonché del momento in cui una funzione diventa essenziale o importante.» (art. 28, par. 3). Se la migrazione porta in cloud una funzione essenziale o importante, la comunicazione va messa in calendario quando l'accordo è ancora in progetto. Per gli stessi servizi l'entità predispone strategie di uscita (art. 28, par. 8), e ogni accordo entra nel registro delle informazioni (art. 28, par. 3).

Data Act

Se parti da un altro cloud, o vuoi sapere da subito come uscirai, vale il Regolamento (UE) 2023/2854, applicabile dal 12 settembre 2025. Il contratto con il provider deve consentire il passaggio a un altro fornitore o a un'infrastruttura locale con un preavviso massimo di due mesi e un periodo transitorio massimo di 30 giorni, salvo le proroghe previste dallo stesso articolo. In quel periodo il provider assiste il cliente e mantiene un elevato livello di sicurezza, in particolare sui dati in trasferimento (art. 25). Dal 12 gennaio 2027 il provider non può più applicare tariffe di passaggio; fino ad allora può applicarne di ridotte, non superiori ai costi direttamente connessi al passaggio (art. 29). I criteri per scegliere il provider, uscita compresa, sono nella guida su come scegliere un cloud provider.

Gli errori che fanno slittare una migrazione

• Spostare tutto in un colpo, invece di imparare sui primi lotti e allargarli man mano che la squadra fa esperienza.
• Scoprire le licenze a metà, quando andavano lette nell'inventario.
• Chiedere zero fermo ovunque, anche sui carichi che tollerano una finestra.
• Lasciare sicurezza e compliance a dopo: identità, rete e regioni stanno nelle fondamenta, gli obblighi normativi nella valutazione.

In sintesi

Una migrazione cloud riesce quando si sa cosa si sposta prima di spostarlo: inventario con dipendenze e licenze, una strategia per ogni carico, fondamenta costruite per prime, un rollback per ogni passo e gli obblighi normativi in piano dall'inizio.

AmagisTech è partner Google Cloud: partiamo da un assessment di architettura, carichi, costi e rischi, e da lì definiamo il target e il piano di migrazione. Se stai valutando di portare i tuoi carichi in cloud, inizia da qui: cloud e infrastruttura su Google Cloud.