Le 7 R: il framework decisionale

Ogni migrazione enterprise parte dalla classificazione delle applicazioni secondo le 7 R. Retire elimina i workload obsoleti; Retain mantiene on-premises ciò che non conviene spostare (vincoli di compliance, hardware specializzato, ammortamenti in corso). Rehost (“lift-and-shift”) sposta la VM così com’è, minimizzando rischio e tempo. Relocate trasferisce interi cluster (es. VMware Cloud on AWS) senza riconfigurare i singoli host. Repurchase abbandona il software per una soluzione SaaS. Replatform (“lift-tinker-and-shift”) introduce ottimizzazioni contenute, tipicamente spostare un database self-managed su Amazon RDS o Aurora. Refactor riscrive l’applicazione per sfruttare servizi cloud-native.

Il criterio d’esame è il trade-off: rehost massimizza velocità e minimizza rischio ma non riduce il debito tecnico; refactor massimizza il valore a lungo termine ma richiede tempo, competenze e budget. In scenari con deadline di data-center exit stretta, la risposta corretta è quasi sempre rehost o relocate ora, refactor dopo.

Strumenti di migrazione

AWS Application Migration Service (MGN) è lo strumento primario per il rehost: replica a livello di blocco continua verso una staging area a basso costo, con cutover di pochi minuti e finestra di downtime ridotta. È la scelta corretta ogni volta che lo scenario chiede di spostare molti server con minimo re-engineering.

AWS Database Migration Service (DMS) migra database con downtime minimo grazie alla replica continua (CDC, change data capture). Per migrazioni omogenee (Oracle→Oracle) basta DMS; per quelle eterogenee (Oracle→Aurora PostgreSQL) serve prima AWS Schema Conversion Tool (SCT) per convertire schema, stored procedure e codice, poi DMS per i dati. SCT segnala anche le porzioni che richiedono conversione manuale.

Per lo spostamento di file e oggetti, AWS DataSync automatizza e accelera il trasferimento online da NFS/SMB/HDFS verso S3, EFS o FSx, con validazione dell’integrità: ideale quando esiste banda sufficiente e serve sincronizzazione ricorrente. Quando i volumi sono nell’ordine dei petabyte o la banda è insufficiente, la Snow Family (Snowball Edge) sposta i dati offline. AWS Transfer Family espone endpoint SFTP/FTPS/FTP gestiti su S3/EFS, utile per preservare workflow di partner esterni basati su protocolli legacy.

Modernizzazione verso container e serverless

Dopo il rehost, la modernizzazione riduce l’overhead operativo. La scelta del compute dipende dal controllo richiesto: Amazon ECS per container con orchestrazione AWS-native, Amazon EKS quando serve compatibilità Kubernetes o portabilità multi-cloud. AWS Fargate è il launch type serverless per entrambi: elimina la gestione delle EC2 sottostanti e si paga per task, ideale per workload variabili o team che non vogliono gestire il patching dei nodi. Si sceglie invece l’EC2 launch type quando servono GPU, istanze specifiche o maggiore densità di costo su carichi costanti e prevedibili.

Per le applicazioni event-driven o dai pattern di traffico irregolari, AWS Lambda porta la modernizzazione fino al serverless puro: nessun server da gestire, scaling automatico e costo a invocazione. È la destinazione tipica di un refactor di componenti stateless (API, elaborazione batch, integrazioni). La regola d’esame: Fargate per container esistenti che si vogliono liberare dalla gestione infrastrutturale, Lambda per logica riscritta a funzioni event-driven.

Trappole tipiche d’esame

  • Data-center exit tra pochi mesi + centinaia di server → MGN (rehost): il refactor immediato è la risposta sbagliata; si migra prima e si modernizza dopo, per rispettare la deadline riducendo il rischio.
  • Migrazione Oracle → Aurora PostgreSQL → SCT + DMS: DMS da solo copre solo i dati; senza Schema Conversion Tool lo schema eterogeneo non viene convertito.
  • Petabyte di dati con banda WAN limitata → Snow Family, non DataSync: DataSync è online e resta vincolato alla banda disponibile; l’offline vince sui grandi volumi con rete scarsa.
  • Downtime del database quasi nullo durante il taglio → DMS con CDC: la replica continua mantiene sincronizzati source e target fino al cutover, cosa che un dump-and-restore non garantisce.
  • Container esistenti da liberare dalla gestione dei nodi → Fargate: la trappola è proporre ECS/EKS su EC2 quando il requisito esplicito è azzerare l’overhead operativo del patching.
  • Partner esterni che usano SFTP verso storage → AWS Transfer Family: ricostruire il protocollo con Lambda o EC2 è più oneroso e non è la soluzione gestita attesa dallo scenario.