Qual è la vera differenza tra Re-Hosting, Refactoring e Rewriting?
Re-Hosting, Refactoring e Rewriting sono i tre approcci principali alla modernizzazione del mainframe. Si differenziano in modo sostanziale per costi, tempi, rischi e impatto nel lungo periodo.
- Il Re-Hosting sposta le applicazioni fuori da infrastrutture proprietarie senza modificare il codice
- Il Refactoring converte i linguaggi legacy in linguaggi moderni, preservando la logica applicativa
- Il Rewriting ricostruisce i sistemi per una nuova architettura di destinazione, utilizzando il reverse engineering assistito dall’AI
Ogni approccio ottimizza un risultato diverso: riduzione dei costi, manutenibilità o trasformazione architetturale. Considerarli intercambiabili è uno degli errori più comuni e costosi. Nei percorsi di large-scale modernization, sono approcci complementari che devono essere combinati, non scelti in modo isolato.
Quando il Re-Hosting è la scelta giusta?
Il Re-Hosting, spesso definito lift-and-shift, è il percorso più rapido per ridurre i costi dell’infrastruttura mainframe.
Consiste nello spostare le applicazioni mainframe verso ambienti enterprise basati su Linux, utilizzando piattaforme di emulazione. Il codice COBOL rimane invariato, preservando il comportamento funzionale delle applicazioni ed eliminando al tempo stesso l’hardware proprietario e i modelli di pricing basati su MSU/MIPS.
Questo approccio è particolarmente efficace quando le organizzazioni devono affrontare pressioni immediate sui costi, scadenze regolatorie stringenti o una limitata propensione al rischio a livello di codice. In genere, questi programmi consentono di ottenere una riduzione misurabile dell’OPEX entro 12-18 mesi e comportano un rischio di execution inferiore rispetto a iniziative di trasformazione più profonde.
Il compromesso è chiaro: il Re-Hosting riduce i costi, non la complessità. La developer experience, l’agilità dei sistemi e la readiness per l’AI rimangono sostanzialmente invariate. Il limite è strutturale: il Re-Hosting riduce i costi, ma non migliora l’architettura, la developer experience o l’agilità nel lungo periodo.
Quando il Refactoring ha più senso del Re-hosting?
Il Refactoring consente di ottenere benefici di modernizzazione senza la complessità di un Rewriting completo.
Come forma di Application Refactoring, il Refactoring automatizzato converte codice COBOL, RPG o PL/I in linguaggi moderni come Java, preservando la logica di business. L’applicazione mantiene lo stesso comportamento, ma runtime, strumenti e competenze necessarie per gestirla cambiano in modo sostanziale.
Questo approccio riduce il rischio legato alla disponibilità di competenze nel lungo periodo, abilita pipeline CI/CD moderne e crea una base che può supportare, in una fase successiva, microservizi e integrazioni basate su API. È particolarmente efficace quando la codebase è strutturalmente solida e ben compresa.
Il Refactoring modernizza il linguaggio, non l’architettura. Nell’ambito di iniziative più ampie di software modernization, rappresenta spesso la prima fase di un percorso di modernizzazione più lungo, non il punto di arrivo.
Quando il Rewriting guidato dall'AI è un'opzione?
Il Rewriting è necessario quando il problema è architetturale, non economico.
Le condizioni del technology stack e il livello di obsolescenza del codice sono fattori determinanti in questa scelta. I sistemi che si sono evoluti continuamente per decenni, senza cambiamenti strutturali rilevanti, spesso accumulano una complessità che limita l’innovazione. Nel tempo, questo può rendere sempre più difficile introdurre nuovi prodotti, generare insight di business dai dati transazionali, adattare le regole di business o implementare in modo efficiente anche piccole evolutive.
Il Rewriting potenziato dall’AI estrae la logica di business dai sistemi legacy e la reimplementa in un’architettura target progettata per operatività moderne, resilienza e adozione dell’AI. Il risultato non è codice convertito, ma un nuovo sistema con funzionalità equivalenti, costruito su fondamenta moderne.
Il Rewriting è indicato quando le codebase sono fortemente degradate, non documentate o incompatibili con l’architettura target. Offre il risultato più solido nel lungo periodo, ma richiede un impegno pluriennale, una governance forte e un investimento iniziale più elevato.
Come dovrebbero scegliere le organizzazioni tra Re-Hosting, Refactoring e Rewriting?
L’approccio più adatto nasce da una valutazione oggettiva, non da una preferenza.
Queste tre domande aiutano a orientare la scelta:
- Qual è l’obiettivo principale: riduzione dei costi, profondità della modernizzazione o AI readiness?
- Qual è la reale condizione della codebase?
- Quanto tempo ha a disposizione il programma?
