{"id":7880,"date":"2025-06-16T17:33:40","date_gmt":"2025-06-16T15:33:40","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7880"},"modified":"2025-07-02T16:22:51","modified_gmt":"2025-07-02T14:22:51","slug":"strategie-di-migrazione-al-cloud-come-scegliere-la-migliore","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/strategie-di-migrazione-al-cloud-come-scegliere-la-migliore\/","title":{"rendered":"Strategie di migrazione al Cloud: come scegliere la migliore"},"content":{"rendered":"\n
\n“Change is the law of life. And those who look only to the past or present are certain to miss the future.”<\/p>\n\n\n\n
John F. Kennedy<\/em><\/p>\n\n\n\n
\n“The secret of change is to focus all of your energy not on fighting the old, but on building the new.”\u00a0<\/p>\n\n\n\n
Dan Millman, Way of the Peaceful Warrior<\/em><\/p>\n<\/blockquote>\n<\/blockquote>\n\n\n\n
Migrare i propri workload al Cloud pu\u00f2 essere un processo complesso e richiedere molto tempo e focus da parte delle aziende.<\/p>\n\n\n\n
Infatti, non si tratta semplicemente di individuare cosa migrare e spostarlo nel Cloud, ma richiede un\u2019attenta pianificazione, oltre ad alcune attivit\u00e0 preliminari fondamentali per evitare ritardi, costi imprevisti e rischi operativi.<\/p>\n\n\n\n
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\u2019aiuto della rete di partner, i propri clienti durante le attivit\u00e0. <\/p>\n\n\n\n
Vediamole una per una:<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
Source: https:\/\/aws.amazon.com\/migrate-modernize-build\/cloud-migration\/how-to-migrate\/<\/em><\/p>\n\n\n\n
<\/p>\n\n\n\n
Assess<\/h4>\n\n\n\n
Questa prima fase ha l\u2019obiettivo di costruire un business case per valutare la prontezza dell\u2019organizzazione alla migrazione sul Cloud, stimando esigenze di licensing, TCO (Total Cost of Ownership<\/em>) e il dimensionamento corretto delle risorse computazionali.<\/p>\n\n\n\n
Mobilize<\/h4>\n\n\n\n
La fase Mobilize<\/em> 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<\/a><\/strong>, comprensiva del design della rete<\/a> e la strategia di migrazione migliore secondo le “7R<\/em>“. Pi\u00f9 tardi nell’articolo approfondiremo quest’ultimo aspetto.<\/p>\n\n\n\n
Migrate and Modernize<\/h4>\n\n\n\n
La vera \u201cmagia\u201d, infine, avviene nella fase Migrate and Modernize<\/em>, in cui le macchine virtuali vengono trasformate in istanze EC2<\/strong>, container<\/strong>, database RDS<\/strong> e altri servizi gestiti<\/strong>.<\/p>\n\n\n\n
Il MAP di AWS fornisce ottime linee guida per pianificare correttamente la migrazione, ma non \u00e8 ancora sufficiente. Occorre anche individuare la strategia pi\u00f9 adatta per ciascun workload.<\/strong><\/p>\n\n\n\n
AWS definisce sette differenti strategie, definite come le 7 \u201cR\u201d della migrazione.<\/p>\n\n\n\n
Analizziamole nel dettaglio.<\/p>\n\n\n\n
Le 7R della migrazione<\/h2>\n\n\n\n
Una fase chiave per una migrazione di successo consiste nell\u2019individuare la strategia giusta per spostare workload e applicazioni nel Cloud.<\/p>\n\n\n\n
AWS ha definito sette strategie distinte, tutte con la lettera iniziale \u201cR\u201d (da cui il nome \u201c7R\u201d). Tutto ha origine nel 2010, quando Gartner introdusse la strategia delle “5R<\/em>” per la migrazione. <\/p>\n\n\n\n
In origine erano:<\/p>\n\n\n\n
\n
- Relocate<\/li>\n\n\n\n
- Rehost<\/li>\n\n\n\n
- Replatform<\/li>\n\n\n\n
- Repurchase<\/li>\n\n\n\n
- Refactor<\/li>\n<\/ul>\n\n\n\n
AWS ha inizialmente aggiunto una nuova \u201cR\u201d – Retire<\/strong> -, ma con la crescente adozione del Cloud si \u00e8 presentata la necessit\u00e0 di un ulteriore approccio: Retain<\/strong>.<\/p>\n\n\n\n
Tutto parte con un assessment e un processo di discovery dei workload, utilizzando strumenti che vedremo pi\u00f9 avanti. Una serie di interviste con i responsabili applicativi e tecnici \u00e8 di solito utile per scegliere la strategia di migrazione pi\u00f9 adatta.<\/p>\n\n\n\n
Retire<\/h4>\n\n\n\n
Dopo la valutazione iniziale, potrebbero risultare servizi o VM non pi\u00f9 utilizzate, accese e lasciate l\u00ec (non \u00e8 raro, fidatevi).<\/p>\n\n\n\n
In questi casi, la strategia \u00e8 la pi\u00f9 semplice e richiede zero sforzo: spegnile!<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Retain<\/h4>\n\n\n\n
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\u2019effort su workload pi\u00f9 critici dal punto di vista del valore aziendale.<\/p>\n\n\n\n
Questi workload possono essere valutati in un secondo momento (e talvolta finiranno comunque nella categoria \u201cRetire\u201d).<\/p>\n\n\n\n
Rehost<\/h4>\n\n\n\n
Questa strategia \u00e8 conosciuta anche come lift and shift<\/strong>. \u00c8 un approccio infrastrutturale che sfrutta solo la componente IaaS del Cloud AWS.<\/p>\n\n\n\n
Si tratta di migrare le VM verso istanze EC2 senza modifiche significative.<\/p>\n\n\n\n
\u00c8 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).<\/p>\n\n\n\n
Con questa strategia puoi anche sfruttare l\u2019elasticit\u00e0 del Cloud, scalando automaticamente in base alla domanda (a patto che l\u2019applicazione sia progettata per scalare).<\/p>\n\n\n\n
Strumenti come AWS Application Migration Service (MGN) o VM Import\/Export possono essere utilizzati. Questo articolo<\/a> menziona anche un esempio risalente all\u2019epoca in cui il servizio si chiamava ancora CloudEndure<\/em>.<\/p>\n\n\n\n
Relocate<\/h4>\n\n\n\n
La strategia Relocate<\/em> sposta server e piattaforme su una versione Cloud.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Nella maggior parte dei casi, la disponibilit\u00e0 o l\u2019architettura applicativa non vengono impattate.<\/p>\n\n\n\n
L\u2019articolo di Mattia<\/a> fornisce una panoramica eccellente e un caso d\u2019uso aggiuntivo per DMS.<\/p>\n\n\n\n
Repurchase<\/h4>\n\n\n\n
\u00c8 l\u2019approccio \u201cdrop and shop\u201d: valutare un\u2019alternativa SaaS<\/strong> dell\u2019applicazione on-premise e verificare se soddisfa requisiti e bisogni aziendali.<\/p>\n\n\n\n
\u00c8 ideale per passare da una licenza tradizionale a un modello SaaS, aggiornare un\u2019applicazione obsoleta o sostituirla del tutto.<\/p>\n\n\n\n
Attenzione per\u00f2 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.<\/p>\n\n\n\n
Replatform<\/h4>\n\n\n\n
L\u2019approccio \u201clift, tinker, and shift<\/strong>\u201d introduce livelli di ottimizzazione durante il passaggio al Cloud.<\/p>\n\n\n\n
Richiede alcune modifiche all\u2019applicazione ma riduce l\u2019effort per la gestione dell\u2019infrastruttura, puntando sull\u2019uso di servizi gestiti.<\/p>\n\n\n\n
Il caso pi\u00f9 comune \u00e8 il passaggio da EC2 ai container, come \u00e8 accaduto con WordPress<\/strong> in uno dei nostri progetti<\/a>.<\/p>\n\n\n\n
Occhio per\u00f2 agli errori comuni\u2026 o rischi di finire nel nostro speciale di Halloween<\/a>!<\/p>\n\n\n\n
Refactor<\/h4>\n\n\n\n
Come suggerisce il nome, \u00e8 l\u2019approccio pi\u00f9 ambizioso: modificare l\u2019applicazione per renderla cloud-native e sfruttare i servizi nativi del Cloud.<\/p>\n\n\n\n
Tuttavia, richiede un\u2019attenta pianificazione e uno sforzo significativo: ci saranno modifiche importanti al codice.<\/p>\n\n\n\n
\u00c8 valido anche per i database: si pu\u00f2 migrare il motore stesso (ad esempio, da Oracle a PostgreSQL, o usare Babelfish per ridurre i costi di licenza di SQL Server).<\/p>\n\n\n\n
Alla fine avrai un\u2019applicazione moderna, scalabile, a bassa manutenzione e perfettamente integrata nel Cloud.<\/p>\n\n\n\n
Non \u00e8 un percorso semplice, ma abbiamo una serie<\/a> di articoli<\/a> dedicati e un caso interessante che mostra come usare API Gateway<\/strong> per rifattorizzare gradualmente un\u2019applicazione<\/a>.<\/p>\n\n\n\n
Migrare o non migrare?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Effettivamente, quando si hanno centinaia o migliaia di server, scegliere la strategia giusta per ogni workload e valutare tutte le dipendenze pu\u00f2 essere complesso e soggetto a errori.<\/p>\n\n\n\n
Niente panico. <\/p>\n\n\n\n
Una volta iniziato il percorso di analisi e comprensione della propria organizzazione, la strada verso la migrazione e modernizzazione<\/strong> diventer\u00e0 chiara.<\/p>\n\n\n\n
Hai gi\u00e0 iniziato il tuo percorso di migrazione al Cloud? Quale strategia hai adottato per il tuo use case? Scrivilo nei commenti!<\/p>\n\n\n\n
\n\n\n\nAbout Proud2beCloud<\/h4>\n\n\n\n