Modernizzare un gestionale AS/400 (IBM i) senza riscriverlo

Molte aziende italiane mandano avanti produzione, magazzino, ordini e fatturazione su un gestionale che gira da vent'anni o più su un sistema AS/400. Oggi quella piattaforma si chiama IBM i (è passata da AS/400 a iSeries, System i e infine IBM i), ma il nome che quasi tutti usano è ancora il primo. Davanti a un sistema così datato la reazione istintiva è pensare che vada buttato e rifatto. Quasi sempre è la conclusione sbagliata. Il problema raramente è la macchina, che resta affidabile e veloce. Il problema è che quel gestionale vive isolato dal resto del mondo, dipende da una competenza sempre più rara, e spesso non è mai stato pensato per essere esposto verso l'esterno in sicurezza. Sono tre problemi diversi, e nessuno dei tre si risolve riscrivendo tutto da capo.

Il gestionale AS/400 funziona: il problema è un altro

Un sistema AS/400 in produzione da anni ha un pregio che si sottovaluta: contiene la logica di business dell'azienda, affinata da decenni di casi reali, eccezioni e correzioni. Riscriverla da zero significa buttare via quel patrimonio e rischiare di reintrodurre errori già risolti. Ecco perché i rischi veri sono altri tre. Il primo è l'isolamento: il gestionale non parla con il sito, con l'app, con i portali di clienti e fornitori, con gli altri applicativi. Il secondo è la competenza: il linguaggio con cui è scritto, l'RPG, è padroneggiato da sempre meno persone, molte vicine alla pensione. Il terzo è la sicurezza: nato in un'epoca in cui il sistema stava chiuso in sala macchine, non è detto che sia pronto a essere raggiunto da una rete moderna.

Perché conviene modernizzare l'AS/400 invece di riscriverlo

La proposta più frequente è anche la più rischiosa: rifare tutto su una piattaforma nuova, in un colpo solo. Sulla carta è seducente, nella pratica è il tipo di progetto che più spesso sfora tempi e budget, o fallisce. Un gestionale che regge l'azienda non si può spegnere per mesi in attesa del sostituto, e ricostruire anni di regole in un'unica migrazione significa scoprire troppo tardi tutti i dettagli che nessuno ricordava più.

L'alternativa matura non è sostituire, è collegare: lasciare l'AS/400 a fare ciò che fa bene e costruirgli intorno, per gradi, lo strato moderno che gli manca. Ogni passo porta un valore concreto da subito e si può fermare o correggere senza aver messo a rischio il cuore del sistema.

Come integrare l'AS/400 con delle API su RPG e DB2

Il primo mattone è dare al gestionale una porta di comunicazione moderna. I programmi RPG e il database DB2 for i che vivono sull'AS/400 possono essere esposti, senza modificarli, dietro delle API: interfacce che parlano il linguaggio di oggi (richieste web, formato JSON) e che gli altri sistemi sanno già usare. Il database del sistema è pienamente interrogabile in SQL, e la piattaforma esegue Java come runtime di prima classe, pienamente supportato: questo permette di costruire uno strato di servizi che legge e scrive sul gestionale attraverso canali stabili, senza riscrivere la logica che c'è dentro. Sono gli stessi strumenti standard di qualsiasi applicazione moderna: ad esempio un framework Java come Spring Boot per lo strato di servizi, che dialoga con DB2 in modo naturale. Da fuori il sistema diventa un servizio come un altro; dentro, resta esattamente com'era.

È il pattern che in letteratura si chiama "strangler fig": invece di sostituire il sistema in un colpo, gli si costruisce intorno un guscio moderno che intercetta le richieste e ne assorbe una funzione alla volta. Il vecchio e il nuovo convivono, e il passaggio avviene per gradi, quando ogni singolo pezzo è pronto e verificato.

Dal green-screen 5250 a un'interfaccia web moderna

Con quelle API in piedi, il passo successivo è l'interfaccia. Le classiche schermate a caratteri verdi (il terminale 5250) funzionano, ma allontanano gli utenti più giovani, rendono lenta la formazione e non esistono su un telefono. Sopra lo strato di servizi si può costruire un'interfaccia web, e all'occorrenza un'app, con librerie a componenti diffuse (ad esempio React) che consumano il JSON prodotto dalle API, e con l'esperienza d'uso che le persone si aspettano oggi. L'operatore lavora su una schermata moderna; dietro, ogni azione arriva al gestionale di sempre. Una precisazione onesta: rifare l'interfaccia non vuol dire fotografare le vecchie schermate e incollarle su una pagina web, una scorciatoia fragile che si rompe al primo cambiamento. Vuol dire ricostruire l'interazione sopra le API, dove dati e regole passano da canali stabili.

Integrare i dati dell'AS/400 con gli altri sistemi

Un gestionale isolato tiene i dati chiusi dentro di sé. Spesso servono altrove: per alimentare un altro applicativo, per scambiarli con un portale di fornitori o clienti, per estrarne stampe aggiornate. Poiché il database DB2 for i è interrogabile in SQL, quei dati possono essere resi disponibili ad altri sistemi in modo controllato, oppure copiati con continuità verso un'altra base dati quando serve tenerli allineati. Il punto delicato non è tecnico, è di metodo: si espone solo ciò che serve, con letture dedicate, senza consegnare a chi sta fuori le chiavi dell'intero sistema.

Mettere in sicurezza l'IBM i durante la modernizzazione

Qui sta il punto che troppi progetti di modernizzazione trascurano, e che invece è decisivo. Aprire verso una rete moderna un sistema nato per stare chiuso in sala macchine ne moltiplica la superficie d'attacco. Non è un rischio teorico: anche su IBM i vengono scoperte vulnerabilità reali, e una configurazione degli accessi ereditata da vent'anni fa spesso concede più poteri del necessario. Modernizzare senza mettere in sicurezza vuol dire costruire una casa nuova su una serratura vecchia.

La modernizzazione fatta bene tratta la sicurezza come parte del progetto, non come un ritocco finale. Lo strato di API non è solo una comodità tecnica, è anche il punto di controllo: è lì che si decide chi può fare cosa, si validano le richieste, si tiene traccia degli accessi e si evita di esporre il sistema in modo diretto.

Sul gestionale stesso vale il principio del privilegio minimo: ogni utenza tecnica riceve solo i poteri che le servono, e le autorità più ampie (quelle equivalenti all'amministratore assoluto del sistema, storicamente il profilo QSECOFR) restano riservate e sorvegliate. Le versioni recenti di IBM i aggiungono strumenti moderni, come l'autenticazione a più fattori, che vanno sfruttati. La regola è semplice: ogni porta che si apre verso l'esterno va progettata per reggere chi la userà male, non solo chi la userà bene.

Ridurre la dipendenza dagli sviluppatori RPG

Il terzo problema, la competenza, si affronta senza drammi ma senza rimandarlo. Trovare e trattenere chi conosce l'RPG è sempre più difficile e costoso, e legare la sopravvivenza dell'azienda a poche persone è un rischio in sé. Lo stesso approccio graduale offre una via d'uscita: man mano che si costruisce lo strato di servizi, si può spostare, un pezzo alla volta, la logica che cambia più spesso verso tecnologie diffuse, per cui è facile trovare competenze. Non è una corsa a smantellare il gestionale, è una riduzione controllata della dipendenza: il cuore stabile resta dov'è, le parti che evolvono migrano dove il mercato del lavoro è più ampio.

Modernizzare l'AS/400 un passo alla volta, con rischio controllato

Il filo che lega tutto è il metodo: nessuna migrazione totale, ma una sequenza di passi delimitati, ognuno con uno scopo chiaro e un risultato verificabile. Si parte quasi sempre da un'analisi iniziale: capire com'è fatto il sistema, quali dati e programmi contano davvero, dove sono i rischi di sicurezza e da quale integrazione conviene cominciare. Da lì si sceglie il primo blocco che porta valore subito (spesso una singola integrazione, o una schermata critica rifatta), lo si realizza a scopo e prezzo definiti, e solo dopo si decide il passo seguente. Così l'investimento resta sotto controllo, il gestionale non si ferma mai, e a ogni tappa c'è qualcosa che funziona, non una promessa.

In sintesi

• Il sistema AS/400 (IBM i) di solito non è il problema: è affidabile e custodisce la logica di business dell'azienda.
• I rischi veri sono tre: isolamento dagli altri sistemi, competenze RPG sempre più rare, sicurezza pensata per un mondo chiuso.
• Riscrivere tutto in un colpo solo è la strada più costosa e più esposta al fallimento.
• La via matura è collegare, non sostituire: API sopra programmi e database, senza toccarne il cuore.
• Sopra le API: interfaccia web moderna al posto del green-screen, e dati integrati con gli altri sistemi.
• La sicurezza si progetta insieme al resto, non si aggiunge alla fine: privilegio minimo, un punto di controllo unico, autenticazione forte.
• Un passo alla volta, ognuno con valore concreto e rischio delimitato, a partire da un'analisi iniziale.

Domande frequenti sulla modernizzazione dell'AS/400

Quanto costa modernizzare un gestionale AS/400?

Non esiste un prezzo unico: dipende da quali integrazioni e interfacce servono davvero. Proprio per questo conviene partire da un'analisi iniziale a costo contenuto, che definisce ambito e priorità del primo blocco. L'approccio a fasi rende costi e tempi prevedibili, perché ogni passo ha uno scopo e un prezzo definiti prima di cominciare.

Bisogna spegnere l'AS400 durante la migrazione?

No. La logica è costruire lo strato moderno accanto al sistema, che resta in produzione. Il vecchio e il nuovo convivono e le funzioni passano una alla volta, quando ognuna è pronta e verificata. Non c'è un fermo dell'azienda in attesa del sostituto.

Si può integrare l'AS/400 con e-commerce e fatturazione elettronica?

Sì. Una volta esposto il gestionale dietro delle API, i suoi dati e le sue funzioni diventano disponibili verso altri sistemi: un negozio online, un portale di fornitori o clienti, lo scambio di documenti (EDI) o l'invio della fatturazione elettronica. Si espone solo ciò che serve, in modo controllato.

Come si affronta la carenza di sviluppatori RPG?

Con la stessa modernizzazione graduale: man mano che si costruisce lo strato di servizi, la logica che cambia più spesso può migrare verso tecnologie diffuse, per cui è facile trovare competenze. Il cuore stabile resta sull'AS/400, e la dipendenza da una competenza rara si riduce nel tempo.

Conviene modernizzare o riscrivere tutto da capo?

Nella grande maggioranza dei casi conviene modernizzare. Riscrivere tutto in un colpo solo significa buttare via decenni di logica di business e affrontare il progetto più a rischio di fallimento. Collegare e sostituire per gradi porta valore da subito e tiene il rischio sotto controllo.

Collegare il passato al presente, in sicurezza

Modernizzare un gestionale AS/400 non vuol dire rinnegare ciò che funziona da vent'anni. Vuol dire collegarlo al presente, in sicurezza, senza fermare l'azienda e senza scommettere tutto su una riscrittura. Il primo passo non è un grande progetto, è una domanda: da dove conviene cominciare, e con quale rischio.

Il modo più semplice per rispondere è partire da un'analisi iniziale: capire quali dati e programmi contano davvero, dove sono i rischi di sicurezza e da quale integrazione conviene cominciare. È un primo passo a scopo e prezzo definiti, non un impegno sull'intero progetto.

Per i servizi con cui questi interventi vengono realizzati:

Integrazione e modernizzazione di sistemi legacy