Hai 4 modi per modernizzare un sistema legacy: spostarlo così com'è nel cloud, convertirne il codice verso una piattaforma moderna, ricostruirlo attorno alle regole di business che hai estratto, oppure sostituirlo con un prodotto pronto e conservare solo i dati. Decidono 4 domande: le tue regole sono specifiche della tua azienda? Il problema sta in dove gira il sistema o nel sistema stesso? Chi ne capisce ancora il codice? Quanto cambiamento può assorbire il tuo personale? Amazon raggruppa queste strade in 7 strategie e Microsoft in 8, entrambe decise sistema per sistema.

Nella parte 4 hai estratto le regole di business del tuo sistema e le hai fatte confermare dai responsabili dei processi. Sono queste regole a rendere possibile il confronto che segue: senza di esse non sai quale comportamento perderesti con ogni strada.

Le quattro strade in parole semplici

I nomi tecnici sono tanti, ma si riducono a 4 decisioni che qualsiasi manager può seguire. Questa tabella le confronta; i nomi tra parentesi sono quelli che sentirai dai fornitori:

StradaQuando convieneCosa conservaCosa rischiaChi deve essere coinvolto
Spostare così com'è (Rehost)Il sistema è stabile e fa il suo lavoro; il problema sono i server o il data centerTutto: codice, regole e modo di lavorareTi porti i vecchi problemi in un posto nuovoL'IT e chi è responsabile di sicurezza e dati
Convertire il codice (Replatform o Refactor)Le regole sono valide, ma il linguaggio o la piattaforma non è più supportato o le licenze sono diventate un pesoLe regole e il comportamento del sistema, su un linguaggio o una piattaforma modernaErrori di conversione nascosti che emergono solo nei casi rariGli sviluppatori, più i responsabili dei processi per testare i risultati
Ricostruire attorno alle regole (Rebuild)Le regole sono specifiche della tua azienda e ti distinguono, e il vecchio sistema non riesce più a contenere ciò che ti serveLe regole confermate e i dati; il codice viene riscritto da zeroLa strada più lunga e quella che richiede più decisioni della direzioneDirezione, responsabili dei processi e team di sviluppo insieme
Sostituire con un prodotto pronto (Replace)Il tuo lavoro in quest'area somiglia a quello degli altri, come le risorse umane o la contabilità generaleSolo i datiIl personale cambia modo di lavorare per adattarsi al prodotto, e perdi le regole che non supportaLa direzione e le persone che lo useranno ogni giorno

Il codice sorgente è il testo del programma con cui è stato scritto il sistema. Se non lo hai, o nessuno lo capisce più, la strada della conversione si complica; la guida alle strategie di Amazon cita un'applicazione che nessuno sa più mantenere, o il cui codice sorgente non è disponibile, tra i casi che spingono verso la riprogettazione.

Dove entrano gli strumenti di conversione con IA

Strumenti come AWS Transform lavorano soprattutto sulla seconda strada: leggono il vecchio codice e lo convertono verso una piattaforma moderna, per esempio portando vecchie applicazioni .NET Framework a una versione moderna che gira su Linux. Amazon afferma che lo strumento modernizza applicazioni Windows, mainframe e VMware fino a 5 volte più velocemente; è l'affermazione di Amazon sul proprio servizio, non un risultato garantito. Secondo la pagina dei prezzi, il servizio costa 0,035 dollari per minuto di agente e non addebita il tempo di inattività dell'utente.

Ma lo strumento non sceglie la strada al posto tuo. Accelera la conversione quando la conversione è la decisione giusta, e aiuta poco se la risposta migliore è sostituire il sistema con un prodotto pronto. Nota anche che la pagina delle regioni non elenca alcuna regione in Medio Oriente e avverte che i tuoi dati potrebbero essere elaborati in un'altra regione, mentre Amazon ha annunciato la sua regione cloud nel Regno per dicembre 2026, secondo la Saudi Press Agency. Se il tuo codice contiene dati dei clienti, verifica dove verranno elaborati prima di iniziare.

Cosa determina costi e tempi

Non ti daremo una cifra, perché qualsiasi cifra data senza conoscere il tuo sistema è un'ipotesi. Questi sono i fattori che fanno salire o scendere costi e tempi su ogni strada:

  • Dimensioni e intreccio: il numero di schermate, report e altri sistemi collegati, come ha mostrato il tuo inventario nella parte 3.
  • Chiarezza delle regole: ogni regola confermata fa risparmiare tempo, ogni regola sconosciuta significa una scoperta tardiva e costosa.
  • Qualità dei dati: dati duplicati o incompleti vanno ripuliti prima di qualsiasi trasferimento, qualunque sia la strada.
  • Quanto cambia per il personale: spostare così com'è non cambia nulla per l'utente; sostituire cambia quasi tutto e richiede formazione.
  • Chi capisce ancora il sistema: un dipendente che ne conosce la storia fa risparmiare settimane di congetture.

Sull'ordine dei passi, due fonti ufficiali danno un consiglio. La guida di Amazon descrive la riprogettazione come la strategia più complessa e costosa e, per le migrazioni grandi, consiglia di spostare prima e modernizzare a migrazione completata. Il Cloud Adoption Framework di Microsoft dice che spostare così com'è conviene solo se sei sicuro che il carico di lavoro resterà nello stato attuale per almeno due anni; altrimenti è meglio modernizzare subito ed evitare di fare il lavoro due volte. Abbiamo trattato il trasferimento vero e proprio nella nostra guida pratica alla migrazione nel cloud.

Due opzioni che tutti dimenticano: mantenere e dismettere

Non tutti i sistemi legacy vanno modernizzati adesso. Sia l'elenco di Amazon sia quello di Microsoft iniziano con due opzioni che non costano un progetto intero:

  • Dismettere: alcuni sistemi non sono più davvero usati. Amazon fa l'esempio delle applicazioni senza alcuna connessione in entrata negli ultimi 90 giorni, o con un uso di processore e memoria inferiore al 5 per cento. Dismetterle dopo averne archiviato i dati riduce manutenzione e rischio di sicurezza.
  • Mantenere: un sistema stabile che fa il suo lavoro senza un motivo vicino per cambiare, o uno legato a una macchina di fabbrica senza equivalente. Qui la decisione è tenerlo, sorvegliarlo e tornarci più avanti.

Se propendi per sostituirlo con un ERP pronto, confronta prima standard e su misura con i criteri di come scegliere un ERP, e parti dal tuo elenco di regole confermate: ogni regola che il prodotto non supporta diventerà una personalizzazione costosa o lavoro manuale.

Il punto di vista di Origami

Non partiamo dalla tecnologia ma dalle regole: quali regole di business di questo sistema distinguono la tua azienda e quali sono comuni a tutti? Ciò che ti distingue merita di essere costruito o convertito con cura; ciò che è comune può essere ben servito da un prodotto pronto ben integrato con gli altri tuoi sistemi. Per questo la decisione è spesso un mix: un sistema sostituito, un altro convertito, un terzo mantenuto così com'è.

Usiamo gli strumenti di IA dove fanno davvero risparmiare tempo, nel leggere, convertire e testare il codice, ma la scelta della strada resta alla direzione, una volta che vede cosa conserva e cosa perde ogni opzione. Se vuoi vedere come lavoriamo, dai un'occhiata ai nostri servizi.

L'esercizio di questa settimana: una decisione per sistema

Torna all'inventario dei tuoi sistemi e aggiungi due colonne per ciascuno: le sue regole sono specifiche della tua azienda o comuni? E dov'è il problema: nel luogo in cui gira o nel sistema stesso? Poi annota la strada provvisoria:

SistemaRegole specifiche o comuni?Problema nel luogo o nel sistema?Strada provvisoria
Esempio: sistema prezziSpecificheIl sistemaConvertire o ricostruire
Esempio: gestione ferieComuniIl sistemaSostituire con un prodotto pronto
Esempio: vecchio archivioNon usatoNon importaDismettere dopo aver archiviato i dati

Sono esempi illustrativi; la tua tabella sarà diversa. Ciò che conta è che ogni sistema abbia un motivo scritto per la sua strada, rivisto dai responsabili dei processi prima di chiedere preventivi.

Prossimamente

Hai scelto una strada per ogni sistema. Resta il giorno più rischioso del progetto: il giorno del passaggio. Nella parte 6 spieghiamo come testare il codice scritto o convertito dall'IA confrontando i risultati dei due sistemi sulle stesse transazioni reali, come farli girare in parallelo per un periodo definito e quando serve un piano di ritorno.

Fonti