Democratizzare l’accesso ai dati tramite una Data Platform self-service utilizzando AWS LakeForma...
20 Maggio 2025 - 3 min. read

Matteo Goretti
DevOps Engineer
"Change is the law of life. And those who look only to the past or present are certain to miss the future."
John F. Kennedy
"The secret of change is to focus all of your energy not on fighting the old, but on building the new."
Dan Millman, Way of the Peaceful Warrior
Migrare i propri workload al Cloud può essere un processo complesso e richiedere molto tempo e focus da parte delle aziende.
Infatti, non si tratta semplicemente di individuare cosa migrare e spostarlo nel Cloud, ma richiede un’attenta pianificazione, oltre ad alcune attività preliminari fondamentali per evitare ritardi, costi imprevisti e rischi operativi.
Negli ultimi anni, AWS ha sviluppato e perfezionato il Migration Acceleration Program (MAP), un framework articolato in 3 macro-fasi - Assess, Mobilize, Migrate and Modernize - per supportare efficacemente, con l’aiuto della rete di partner, i propri clienti durante le attività.
Vediamole una per una:
Source: https://aws.amazon.com/migrate-modernize-build/cloud-migration/how-to-migrate/
Questa prima fase ha l’obiettivo di costruire un business case per valutare la prontezza dell’organizzazione alla migrazione sul Cloud, stimando esigenze di licensing, TCO (Total Cost of Ownership) e il dimensionamento corretto delle risorse computazionali.
La fase Mobilize prevede la creazione del piano di migrazione tenendo conto delle dipendenze tra workload e perfezionando il business case. In questa fase si definiscono aspetti come la Landing Zone, comprensiva del design della rete e la strategia di migrazione migliore secondo le "7R". Più tardi nell'articolo approfondiremo quest'ultimo aspetto.
La vera “magia”, infine, avviene nella fase Migrate and Modernize, in cui le macchine virtuali vengono trasformate in istanze EC2, container, database RDS e altri servizi gestiti.
Il MAP di AWS fornisce ottime linee guida per pianificare correttamente la migrazione, ma non è ancora sufficiente. Occorre anche individuare la strategia più adatta per ciascun workload.
AWS definisce sette differenti strategie, definite come le 7 “R” della migrazione.
Analizziamole nel dettaglio.
Una fase chiave per una migrazione di successo consiste nell’individuare la strategia giusta per spostare workload e applicazioni nel Cloud.
AWS ha definito sette strategie distinte, tutte con la lettera iniziale “R” (da cui il nome “7R”). Tutto ha origine nel 2010, quando Gartner introdusse la strategia delle "5R" per la migrazione.
In origine erano:
AWS ha inizialmente aggiunto una nuova “R” - Retire -, ma con la crescente adozione del Cloud si è presentata la necessità di un ulteriore approccio: Retain.
Tutto parte con un assessment e un processo di discovery dei workload, utilizzando strumenti che vedremo più avanti. Una serie di interviste con i responsabili applicativi e tecnici è di solito utile per scegliere la strategia di migrazione più adatta.
Dopo la valutazione iniziale, potrebbero risultare servizi o VM non più utilizzate, accese e lasciate lì (non è raro, fidatevi).
In questi casi, la strategia è la più semplice e richiede zero sforzo: spegnile!
La dismissione dei servizi obsoleti ha anche un impatto positivo sulla sicurezza, riducendo la superficie di attacco ed eliminando sistemi operativi, applicazioni e librerie vulnerabili.
Alcuni workload non possono essere migrati per varie ragioni: vincoli normativi sulla localizzazione dei dati, dipendenza da hardware fisico (come dongle di licenza), architetture non compatibili (ad es. CPU Sparc o PowerPC), oppure per concentrare l’effort su workload più critici dal punto di vista del valore aziendale.
Questi workload possono essere valutati in un secondo momento (e talvolta finiranno comunque nella categoria “Retire”).
Questa strategia è conosciuta anche come lift and shift. È un approccio infrastrutturale che sfrutta solo la componente IaaS del Cloud AWS.
Si tratta di migrare le VM verso istanze EC2 senza modifiche significative.
È utile per una migrazione rapida, ad esempio quando ci sono scadenze imposte da fattori esterni (rinnovi di licenze, obsolescenza hardware, scadenza di contratti di hosting o colocation).
Con questa strategia puoi anche sfruttare l’elasticità del Cloud, scalando automaticamente in base alla domanda (a patto che l’applicazione sia progettata per scalare).
Strumenti come AWS Application Migration Service (MGN) o VM Import/Export possono essere utilizzati. Questo articolo menziona anche un esempio risalente all’epoca in cui il servizio si chiamava ancora CloudEndure.
La strategia Relocate sposta server e piattaforme su una versione Cloud.
Viene spesso utilizzata per migrare database on-premise verso Amazon RDS usando AWS DMS (Database Migration Service), oppure per spostare interi ambienti VMware SDDC su VMware Cloud on AWS, o workload Kubernetes su Amazon EKS.
Nella maggior parte dei casi, la disponibilità o l’architettura applicativa non vengono impattate.
L’articolo di Mattia fornisce una panoramica eccellente e un caso d’uso aggiuntivo per DMS.
È l’approccio “drop and shop”: valutare un’alternativa SaaS dell’applicazione on-premise e verificare se soddisfa requisiti e bisogni aziendali.
È ideale per passare da una licenza tradizionale a un modello SaaS, aggiornare un’applicazione obsoleta o sostituirla del tutto.
Attenzione però a valutare con cura tempi ed effort per la migrazione dei dati, la formazione del team e l'integrazione con altri sistemi. In cambio, si ottengono riduzioni di costi di manutenzione, infrastruttura e sicurezza.
L’approccio “lift, tinker, and shift” introduce livelli di ottimizzazione durante il passaggio al Cloud.
Richiede alcune modifiche all’applicazione ma riduce l’effort per la gestione dell’infrastruttura, puntando sull’uso di servizi gestiti.
Il caso più comune è il passaggio da EC2 ai container, come è accaduto con WordPress in uno dei nostri progetti.
Occhio però agli errori comuni… o rischi di finire nel nostro speciale di Halloween!
Come suggerisce il nome, è l’approccio più ambizioso: modificare l’applicazione per renderla cloud-native e sfruttare i servizi nativi del Cloud.
Tuttavia, richiede un’attenta pianificazione e uno sforzo significativo: ci saranno modifiche importanti al codice.
È valido anche per i database: si può migrare il motore stesso (ad esempio, da Oracle a PostgreSQL, o usare Babelfish per ridurre i costi di licenza di SQL Server).
Alla fine avrai un’applicazione moderna, scalabile, a bassa manutenzione e perfettamente integrata nel Cloud.
Non è un percorso semplice, ma abbiamo una serie di articoli dedicati e un caso interessante che mostra come usare API Gateway per rifattorizzare gradualmente un’applicazione.
Dopo aver passato in rassegna questa lunga lista, si potrebbe pensare che la migrazione al Cloud sia un progetto in grado di impattare pesantemente su team e risorse, specialmente nelle grandi organizzazioni.
Effettivamente, quando si hanno centinaia o migliaia di server, scegliere la strategia giusta per ogni workload e valutare tutte le dipendenze può essere complesso e soggetto a errori.
Niente panico.
Una volta iniziato il percorso di analisi e comprensione della propria organizzazione, la strada verso la migrazione e modernizzazione diventerà chiara.
Hai già iniziato il tuo percorso di migrazione al Cloud? Quale strategia hai adottato per il tuo use case? Scrivilo nei commenti!
Proud2beCloud è il blog di beSharp, APN Premier Consulting Partner italiano esperto nella progettazione, implementazione e gestione di infrastrutture Cloud complesse e servizi AWS avanzati. Prima di essere scrittori, siamo Solutions Architect che, dal 2007, lavorano quotidianamente con i servizi AWS. Siamo innovatori alla costante ricerca della soluzione più all'avanguardia per noi e per i nostri clienti. Su Proud2beCloud condividiamo regolarmente i nostri migliori spunti con chi come noi, per lavoro o per passione, lavora con il Cloud di AWS. Partecipa alla discussione!