Chi gestisce infrastruttura enterprise in Italia conosce bene quel rack che nessuno vuole toccare: un IBM Power con AIX che gira da anni, regge il gestionale o il core bancario, e che tutti trattano come una reliquia intoccabile. Dismetterlo è un progetto che spaventa più per la percezione del rischio che per la reale complessità tecnica. Ma la percezione, sul campo, va smontata con i fatti.
L’ostacolo che salta fuori a metà progetto
Sulla carta i rischi tecnici di una dismissione AIX/Power sono noti e si possono censire: endianness big-endian di POWER contro il little-endian di x86, dipendenze applicative da runtime RPG/COBOL, il layer HMC/VIOS con il suo storage virtualizzato, il licensing DB2 o Oracle legato al conteggio dei core Power. Sono tutti temi veri, e ognuno può mordere la timeline se lo scopri in produzione anziché in analisi.
Ma nella nostra esperienza diretta l’ostacolo più insidioso non è stato un dettaglio di byte-order o una libreria compilata male. È stato disporre di un team abbastanza verticale ed esperto da eseguire davvero le strategie che avevamo pensato e validato in laboratorio. La differenza tra un progetto AIX che scivola di sei mesi e uno che chiude nei tempi non la fa l’endianness: la fanno le persone che sanno leggere un dump VIOS, ricompilare un runtime, ridisegnare il licensing DB2 senza esplodere i costi. Trovata quella competenza, e provato tutto prima in laboratorio, la migrazione è stata quasi indolore.
È un messaggio scomodo per chi cerca la scusa tecnica: nella maggioranza dei casi il legacy non è ingestibile, è orfano di competenze. E questo è un problema di pianificazione e di persone, non di architettura.
Le strategie: cosa ha funzionato e cosa ha generato debito
Su un carico mission-critical si può scegliere tra quattro approcci, ognuno con un profilo rischio/beneficio diverso. La nostra lettura, dopo averli visti all’opera, è questa:
- Rehost su x86/Linux — Il miglior rapporto rischio/beneficio quando l’applicazione è “portabile” e ben isolata dal sistema operativo. Ricompilare, ritestare, spostare i dati. È l’opzione meno affascinante ma la più prevedibile: perimetro chiaro, rollback possibile, nessuna riscrittura di logica di business. Se validato in laboratorio, si esegue in finestra.
- Replatform — Buon compromesso quando il rehost puro non basta: si tocca il database, si moderna il layer di persistenza, si containerizza dove ha senso. Richiede più test, ma ripaga in FinOps e in riduzione del lock-in.
- Riscrittura — Il beneficio potenziale è massimo, ma è anche la strada che più spesso genera debito tecnico peggiore del legacy stesso. Riscrivere da zero un applicativo RPG/COBOL che nessuno documenta più significa reinventare regole di business dimenticate, con il rischio concreto di consegnare un sistema nuovo e già fragile. Va riservata a casi in cui il valore strategico giustifica il progetto pluriennale, non usata come scorciatoia.
- Emulazione — Utile come ponte temporaneo, pericolosa come destinazione. Emulare Power su x86 ti toglie il problema hardware ma ti lascia intatta la dipendenza dal software legacy, spostando in avanti il debito senza estinguerlo. La usiamo solo come tappa, mai come traguardo.
Il filo conduttore: ciò che si prova prima in laboratorio si esegue in produzione senza sorprese. La riscrittura fallisce quando la si affronta come atto di fede; il rehost riesce perché è misurabile e reversibile.
“AIX funziona da 15 anni, perché toccarlo?”
È la frase che ogni CIO conservatore ci ripete. Non si risponde con la teoria, si risponde con i segnali operativi concreti:
- Fine supporto hardware Power: quando il modello esce dalla roadmap IBM e i ricambi diventano usato certificato, il rischio non è più tecnico ma di continuità operativa.
- Costi di manutenzione: contratti di supporto che salgono ogni anno, canoni DB2/Oracle legati a core Power sovradimensionati. La bolletta è già un caso business, basta metterla in tabella accanto alla TCO di un target x86.
- Competenze introvabili: se per un fix urgente devi richiamare un consulente in pensione, il tuo mission-critical dipende da una singola persona. È il segnale più forte di tutti — e coincide esattamente con l’ostacolo che ci ha impegnato di più sul campo.
- Incident specifici: un fermo non risolvibile in autonomia, un aggiornamento di sicurezza non più disponibile. Un solo incident del genere vale più di dieci slide sul rischio.
Il momento giusto per muoversi è quando hai ancora le competenze per farlo con calma, non quando l’hardware ti costringe in emergenza. Migrare sotto pressione, senza laboratorio e senza team verticale, è l’unico scenario in cui AIX diventa davvero un incubo.
Il verdetto
Muoversi: 1. La nostra esperienza diretta lo conferma senza ambiguità. Con un team esperto e una fase di laboratorio seria, la dismissione AIX è stata quasi indolore, eseguita senza fermare la produzione. Aspettare non riduce il rischio, lo concentra nel momento peggiore — quando l’hardware muore o l’ultimo specialista se ne va. Pianifica ora, prova in laboratorio, scegli il rehost dove puoi e riserva la riscrittura solo dove serve davvero. Il legacy non si abbandona con rimpianti: si abbandona quando hai ancora il controllo.