Modernizzazione AS/400 con business attivo: scenario manifatturiero

Nota editoriale: lo scenario descritto è un pattern industry-typical costruito su elementi comuni a progetti reali di modernizzazione AS/400 nel manifatturiero italiano. Non è un caso specifico di un cliente Obsidian.

Una manifatturiera marchigiana, 120 dipendenti, due stabilimenti produttivi, AS/400 in produzione dal 1998. Tre linee di produzione che lavorano in turni 24/7. Il sistema gestisce ordini, MRP, magazzino, fatturazione, controllo qualità. Spegnerlo non è un’opzione: ogni ora di fermo significa 8.000-12.000 euro di perdita produttiva. Vediamo come si imposta una modernizzazione strangler fig in questo contesto, perché è il pattern più replicabile nel manifatturiero italiano.

Il contesto dello scenario

Azienda manifatturiera del settore meccanico-precision in provincia di Pesaro:

• 120 dipendenti complessivi: 90 in produzione su tre turni, 30 in uffici (amministrativi, commerciali, qualità, IT)
• Due stabilimenti, sede principale + filiale produttiva
• Fatturato circa 25-35 milioni euro/anno
• AS/400 IBM Power7 (hardware del 2010, già in extended support IBM)
• ~1.400 programmi RPG attivi sviluppati internamente fra 1998 e 2018
• 8 integrazioni esterne: e-commerce B2B, MES di linea, sistema CRM cloud, fatturazione elettronica via SDI, sistema logistico per spedizioni, controllo qualità (con bilance e strumenti di misura), sistema di firme digitali, gestione documentale
• Database storico: ~80 milioni record produzione, 12 milioni record ordini, 4 milioni record anagrafica (clienti + articoli + componenti BOM)
• Personale RPG interno: 1 senior 58 anni (in pensione nel 2027), 1 junior 41 anni con competenze RPG limitate

Il dolore concreto: hardware fuori manutenzione IBM, costo crescente di gestione, integrazioni nuove sempre più costose ($30-50k a integrazione per CRM cloud), assenza di pipeline per integrare AI/automazione che il consiglio di amministrazione vorrebbe testare, prospettiva del senior che va in pensione con knowledge non documentata.

Cosa è a disposizione (vincoli del progetto)

• Budget: 280-400k euro complessivi, distribuibili su 24-30 mesi
• Timeline: nessuna scadenza esterna, ma il senior RPG va in pensione a fine 2027 (vincolo dolce)
• Team interno: 1 senior RPG part-time sul progetto (50%), 1 junior full-time (per il handover), 1 IT manager (10%)
• Vincolo non negoziabile: zero fermo produzione. Le tre linee 24/7 non possono fermarsi per migrazione, mai
• Vincolo non negoziabile: i dati storici di produzione (utili per certificazioni qualità, garanzie cliente, recall potenziali) vanno mantenuti accessibili in query per minimo 10 anni
• Vincolo non negoziabile: ogni cambio del MES di linea (linea-AS/400 protocol) richiede coordinazione con linea-stop di max 2 ore in fascia notturna

L’approccio scelto: strangler fig modulare

Tre decisioni di scope nelle prime 4 settimane.

Decisione 1: strangler fig modulare invece di big-bang o replacement. Le alternative valutate:

• Big-bang replacement con SAP Business One o TeamSystem Enterprise: scartato per rischio operativo (1-2 weekend di fermo minimo in fase cut-over, non sostenibile per 24/7).
• Refactoring monolitico: scartato per la dipendenza dal senior RPG che va in pensione.
• Replatforming puro (lift-and-shift su IBM Cloud): considerato come fase intermedia, ma non risolve la dipendenza RPG.
• Strangler fig: scelto perché permette di mantenere produzione attiva, distribuisce il rischio modulo per modulo, e libera il senior RPG progressivamente.

Decisione 2: ordine di migrazione driven by risk + opportunità. Si parte dai moduli a basso rischio operativo + alto valore di modernizzazione:

1. Modulo anagrafica clienti (basso rischio, alto valore: permette integrazioni CRM cloud più semplici)
2. Modulo anagrafica articoli/BOM (medio rischio, alto valore)
3. Modulo ordini (alto rischio ma core, da fare con cura)
4. Modulo fatturazione (medio rischio, valore standard)
5. Modulo magazzino (alto rischio, valore alto)
6. Modulo MRP + produzione (rischio altissimo, ultimo modulo migrato)

I dati storici di produzione restano sull’AS/400 in read-only mode dopo dismissione del modulo MRP.

Decisione 3: stack target deliberato.

• Backend: Node.js + TypeScript (talent pool ampio, AI tooling eccellente, fit con i microservizi che il team junior può manutenere)
• Database: PostgreSQL su istanza cloud (Hetzner Helsinki, GDPR-friendly)
• Layer di compatibilità: un servizio “AS/400 facade” che traduce richieste REST in chiamate al gestionale legacy (via IBM i Access Client Solutions API)
• Observability: Grafana + Loki + Tempo, self-hosted

L’esecuzione: i primi 24 mesi

Mesi 1-3: foundation

• Audit completo del codice RPG con assistenza AI per accelerare reverse-engineering
• Mappatura delle ~340 regole business nascoste nei programmi RPG core
• Setup infrastruttura target (cloud, CI/CD, monitoring)
• Costruzione del facade AS/400-to-REST iniziale

Mesi 4-6: primo modulo (anagrafica clienti)

• Riscrittura del modulo anagrafica clienti in Node.js + PostgreSQL
• Sviluppo shadow mode: il nuovo modulo riceve le richieste in parallelo all’AS/400, output confrontati
• Settimana 24: cut-over modulo anagrafica clienti, legacy come fallback per 4 settimane
• Settimana 28: dismissione modulo anagrafica RPG, l’AS/400 ora chiama il nuovo servizio via facade

Mesi 7-10: secondo modulo (anagrafica articoli/BOM)

• Stesso pattern, complessità maggiore per la struttura BOM ricorsiva
• Settimane 36-40: cut-over con periodo shadow più lungo (BOM è critico)

Mesi 11-14: terzo modulo (ordini)

• Modulo core, la riscrittura richiede attenzione massima
• 8 sotto-moduli: ordini cliente, conferme, modifiche, evasioni, annullamenti, RMA, back-orders, anomalie
• Shadow mode prolungato (6 settimane) prima del cut-over

Mesi 15-18: quarto modulo (fatturazione)

• Compresa migrazione delle integrazioni SDI dal sistema RPG al nuovo sistema
• Cut-over con particolare attenzione alla riconciliazione fiscale

Mesi 19-22: quinto modulo (magazzino)

• Integrazione con barcode reader e bilance industriali (i protocolli proprietari sono il cost driver nascosto qui)
• Cut-over in finestra notturna concordata con i magazzinieri di turno

Mesi 23-30: sesto modulo (MRP + produzione)

• Il modulo più critico, gestisce le tre linee 24/7
• Shadow mode prolungato (12 settimane) con confronto bit-per-bit degli output
• Cut-over graduale: prima una linea, poi la seconda, poi la terza, ognuna in fasce di stop di 2 ore notturne

Mesi 31-32: dismissione legacy + freeze dati storici

• AS/400 in modalità sola lettura
• Tutti i dati storici accessibili via query, ma scrittura disabilitata
• Spegnimento parziale (riduzione costi extended support IBM)

I risultati dopo 24 mesi (modulo 5 completato)

(numeri illustrativi di pattern industry-typical):

• Zero fermi di produzione attribuiti alla migrazione (zero downtime)
• 5 moduli su 6 migrati, 64 KLOC su ~95 rimosse dall’AS/400
• Cost-saving già misurabile: -35k euro/anno di costi infrastruttura AS/400 + -25k/anno di consulenze esterne sui moduli ora moderni
• 3 nuove integrazioni abilitate dal nuovo stack (impossibili sul legacy puro): dashboard direzione real-time, agente AI per customer service, integrazione con sistema di scheduling produzione moderno
• Senior RPG: andato in pensione a fine 2027 come previsto, il junior ora maneggia l’80% dei moduli legacy rimasti (solo MRP)
• Tempo di onboarding nuovo sviluppatore: da 8-12 mesi (per imparare RPG) a 4-6 settimane (per essere produttivo su Node.js + PostgreSQL)

Cosa farebbe la differenza in progetti simili

1. Più tempo sul facade AS/400 nelle prime settimane. Il layer di compatibilità iniziale viene tipicamente sottostimato di 4-5 settimane. Investirci più tempo all’inizio paga, invece di patcharlo durante i primi due moduli.

2. Shadow mode automatizzato dal primo modulo. Il confronto output legacy vs nuovo manuale (sviluppatore a campione) non scala. Serve fin da subito un servizio di diff automation che logga tutte le divergenze. Introdurlo solo dal modulo 3 in poi è troppo tardi.

3. Coinvolgere il MES vendor prima. Il MES di linea tipicamente ha API proprietarie che si capiscono davvero solo arrivati al modulo 5 (magazzino). Una technical deep-dive call con il vendor MES al mese 1-2 evita 3-4 settimane di reverse-engineering più avanti.

Lessons learned trasferibili

1. Strangler fig richiede 50% di tempo in più di un refactoring “puro”, ma elimina il rischio operativo. Per business 24/7 questo è il vantaggio decisivo. Il costo aggiuntivo è quasi sempre minore del costo di un outage da big-bang fallito.

2. L’ordine dei moduli conta più della velocità. Sbagliato partire dal modulo “più importante” (MRP) per voglia di mostrare risultati. Si parte dai moduli meno rischiosi ma di alto valore abilitante (anagrafica), si costruisce muscle memory del team, si attacca il core solo quando il team è esperto.

3. AI come copilota di analisi RPG è game-changer. Senza assistenza AI, il reverse-engineering di 1.400 programmi RPG sarebbe stato 6-9 mesi. Con AI come copilota di lettura (Claude / GPT in modalità code), si è ridotto a 3-4 mesi. Per scrivere il nuovo codice l’AI ha contribuito meno (codice business specifico, l’AI non lo conosce), ma per comprendere il legacy è stato decisivo.

4. Il facade ben fatto è il singolo investimento più redditizio. Il layer di compatibilità fra AS/400 legacy e nuovi servizi è quello che consente al sistema di funzionare durante tutta la transizione. Sottoinvestirci porta a fragilità che costa carissimo recuperare.

5. Junior backfill del senior in pensione: 18 mesi non bastano. Il senior RPG part-time + junior full-time per i 24 mesi di progetto è stata la formula minima. Iniziare prima (3 anni prima del retirement) sarebbe stato meglio: il junior avrebbe assimilato più domain knowledge.

FAQ

Quanto costa una migrazione strangler fig per un’azienda di queste dimensioni?

Per scenari simili (100-200 dipendenti, fatturato 20-50M, AS/400 di 1.000-2.000 programmi attivi): 250-450k euro complessivi in 24-36 mesi. È più caro di replacement (200-350k) ma elimina il rischio operativo che per business 24/7 è il vincolo dominante.

Si può fare con un team più piccolo lato fornitore?

In progetti di questa scala il setup tipico è 2-3 sviluppatori dedicati al progetto + 1 architect + 1 project manager. Con meno persone i tempi salgono linearmente. Con più persone non si scala bene oltre i 4-5: il coordinamento sulle parti complesse del legacy richiede pochi senior che hanno il quadro completo, non molte mani.

Cosa succede se il senior RPG va in pensione prima della fine del progetto?

Scenario di rischio reale e mitigato come segue: (a) coinvolgimento del senior in tutte le decisioni di mappatura domain knowledge nei primi 12 mesi, (b) handover documentale serio (60-80 pagine di documentazione strutturata sui moduli core), (c) accordo contrattuale per consulenza post-pensione 30-50 ore/anno se serve. Costo del consulente esterno: 80-150 euro/ora. Si gestisce, ma è meglio prevenire.

Quanto costa mantenere l’AS/400 in read-only dopo la dismissione?

Tipicamente 4-8k euro/anno se mantenuto in cloud (Skytap, IBM Cloud) con minimum config. Si valuta caso per caso quanto a lungo tenerlo: spesso 2-3 anni dopo cut-over completo, poi i dati storici vengono migrati in data lake moderno con interfaccia di consultazione.

L’AI può prendere il posto del senior RPG?

No. L’AI è acceleratore di analisi, non sostituto di expertise. Il senior RPG conosce la storia operativa del codice (chi ha scritto cosa, perché, cosa è ancora valido, cosa no). L’AI può leggere il codice ma non conosce le decisioni implicite. Le aziende che provano a sostituire il senior con AI puro scoprono dopo 6-9 mesi di aver perso pezzi importanti del know-how operativo.

Si può applicare lo stesso pattern a sistemi diversi da AS/400 (es. ERP custom in .NET 2.0)?

Sì, perfettamente. Lo strangler fig è agnostico rispetto alla tecnologia di partenza. Il pattern funziona per qualunque sistema monolitico che si vuole modernizzare senza fermo operativo: AS/400, ERP custom in .NET/Java/Delphi, sistemi mainframe IBM z/OS. Cambiano i dettagli tecnici del facade e del reverse-engineering, ma la struttura del progetto è la stessa.

Conclusione

Modernizzare un AS/400 con business attivo 24/7 non è semplice ma è fattibile con strategia strangler fig, ordine modulare guidato da rischio e opportunità, team senior con la pazienza necessaria. Le aziende che lo affrontano con calma nei 24-36 mesi ottengono un sistema moderno senza un’ora di downtime. Quelle che cercano di farlo in 12 mesi con big-bang quasi sempre falliscono, e i costi del fallimento superano largamente i risparmi cercati.

Se gestite un’azienda manifatturiera con un AS/400 critico e volete confrontarvi sul pattern di modernizzazione applicabile al vostro caso, parliamone. Il primo confronto è gratuito.

Per approfondire: la pagina pilastro modernizzazione legacy, la pagina dedicata alla migrazione AS/400 cloud, la pagina settore manifatturiero, e gli articoli correlati guida alla migrazione AS/400 e 5 trappole delle migrazioni legacy.