Guida alla migrazione AS/400 nel 2026: 5 strategie concrete

L’AS/400 (oggi IBM i) sta nei sistemi informativi di moltissime PMI italiane da 25-40 anni. Funziona. È stabile. Reggerà altri 10 anni se serve. Allora perché modernizzarlo? Non è una domanda retorica: ci sono molti casi in cui non vale la pena toccarlo. E ce ne sono altri, sempre più frequenti dal 2024 in qua, in cui rimandare la migrazione è il costo nascosto più alto che un’azienda paga sull’IT.

In questa guida proviamo a tracciare la linea tra i due, e a spiegare le 5 strategie concrete di migrazione disponibili nel 2026. Niente teorie da whitepaper. Solo quello che funziona davvero quando si tocca un sistema legacy con 30 anni di logica business stratificata.

TL;DR

• Esistono cinque strategie reali di migrazione AS/400 nel 2026: replatforming, refactoring, replacement, retirement e hybrid approach. Nessuna è universalmente migliore.
• Il vincolo dominante non è quasi mai tecnico: è la convivenza fra continuità operativa del business e disponibilità di personale che conosce la base codice esistente.
• Range di costo realistici per una media impresa italiana: 80.000-500.000 euro. I tempi vanno da 4 mesi (replatforming pulito) a 24-36 mesi (replacement con dati storici complessi).
• Lo strangler pattern (rimpiazzo modulo per modulo con sistema legacy ancora attivo) è la strategia con il rischio operativo più basso. Costa tempo: spesso 12-18 mesi. Vale quasi sempre la pena.
• L’AI tooling moderno aiuta nel reverse-engineering del codice RPG/COBOL ma non sostituisce il lavoro umano sul domain knowledge. Chi promette migrazioni automatiche AI-driven sta vendendo aria.

Perché si torna a parlare di AS/400 nel 2026?

Perché stanno scadendo contemporaneamente quattro cose che fino al 2022 sembravano gestibili separatamente.

Primo, i programmatori RPG e COBOL stanno andando in pensione. L’età media degli sviluppatori italiani specializzati su IBM i è oggi sopra i 55 anni. Non è una previsione: è il dato osservabile sui CV in circolazione e sui curricula universitari (nessun ITS italiano forma più RPG da circa 15 anni). Le stime di settore indicano una contrazione significativa del personale RPG attivo entro il 2030. Per un’azienda che dipende da quel personale per la manutenzione evolutiva del proprio gestionale, è un problema che si materializza in pratica già nel 2026-2027.

Secondo, le integrazioni con i sistemi moderni costano sempre di più. Un AS/400 isolato dal resto è gestibile. Un AS/400 che deve scambiare dati con un e-commerce, un CRM cloud, un WMS, un sistema di fatturazione elettronica, un BI moderno e ora anche piattaforme AI è un cantiere permanente. Ogni nuova integrazione richiede di costruire un ponte custom, e ogni ponte custom va manutenuto. Il debito tecnico delle integrazioni cresce più velocemente del valore che producono.

Terzo, le pressioni normative. La NIS2 (in Italia D.Lgs. 138/2024) impone requisiti specifici di gestione del rischio cyber, e un sistema legacy con accessi storici stratificati, log incompleti e patch policy degli anni 2000 è oggettivamente difficile da rendere conforme. Non è impossibile: è caro. La GDPR vintage del 2018 ha già richiesto interventi pesanti. NIS2, AgID, e in prospettiva l’AI Act (da agosto 2026) aggiungono livelli ulteriori. Su un AS/400 a 30 anni si finisce per spendere in compliance quanto si spenderebbe per una migrazione vera.

Quarto, l’AI integration impossibile su sistemi chiusi. Un’azienda che vuole usare LLM per automatizzare il customer service, per estrarre informazioni da contratti, per generare report dai propri dati, si ferma al confine dei propri silos AS/400. I dati ci sono ma non sono queryable in modo moderno: niente API REST native, niente streaming, niente SDK per servizi cloud. Si possono fare ponti, ma sono costosi e fragili. Il costo opportunità della AI mancata è invisibile sui bilanci, ma è già diventato uno dei primi driver di richieste di modernizzazione che si osservano nel mercato 2025-2026.

Quando questi quattro pesi si sommano sulla stessa azienda, la domanda smette di essere “se” modernizzare e diventa “come, quando, con quale ordine”.

Quando NON conviene modernizzare un AS/400?

Sezione contro-intuitiva, ma importante: ci sono casi reali in cui restare sul legacy è la scelta razionale.

Il primo caso è il sistema in fine vita. Se l’azienda ha già deciso di chiudere quella linea di business entro 3-5 anni, o se ha già pianificato la sostituzione completa dell’AS/400 con un altro sistema (ad esempio un nuovo ERP standard) entro il 2027, modernizzare l’AS/400 in vista del decommissioning è uno spreco. Si tiene operativo, si patcha quel minimo che serve per compliance, si spegne quando arriva il momento.

Il secondo caso è il sistema stabile, statico, perimetrato. Un AS/400 che gestisce un singolo flusso (es. gestione magazzino di uno stabilimento singolo), che non deve integrarsi con altro, che ha ancora 2-3 sviluppatori interni competenti e nessuno in pensione nei prossimi 5 anni, può tranquillamente rimanere così. La modernizzazione di un sistema che non sta creando problemi è un costo senza upside.

Il terzo caso è il business in fase di transizione. Se l’azienda sta vendendo, fondendosi, o ristrutturando profondamente, congelare l’IT è spesso la scelta giusta. Una migrazione fatta nel mezzo di una M&A diventa un cantiere che blocca altre cose. Meglio aspettare la stabilizzazione organizzativa e affrontare la migrazione con uno scope chiaro.

Il quarto caso è il valore unitario del legacy maggiore del valore della modernizzazione. Alcuni AS/400 contengono logica business così specifica, così affinata da decenni di iterazione, da rappresentare un vantaggio competitivo reale. Pensare di riscriverla è pericoloso: ogni riscrittura perde qualcosa, e quel qualcosa potrebbe essere proprio quello che fa funzionare l’azienda. In questi casi conviene incapsulare il legacy dietro un API layer moderno (vedi strangler pattern più avanti) invece di sostituirlo.

Quali sono i rischi di NON modernizzare un AS/400?

Quattro rischi principali, in ordine di probabilità: (1) impossibilità di trovare programmatori RPG/COBOL competenti entro 5 anni, con conseguente esplosione dei tariffari per gli ultimi rimasti; (2) crescita del debito tecnico nelle integrazioni con sistemi moderni, che a un certo punto diventa più costoso manutenere che riscrivere; (3) gap di compliance progressivo su NIS2, GDPR, accessibilità e prossimi requisiti normativi; (4) freno strutturale all’adozione di AI e automazione, che diventa un costo opportunità via via più caro.

Se nessuno di questi quattro rischi si applica al vostro caso, probabilmente siete nel quadrante “non modernizzare” e fate bene a rimanerci.

Quali sono le 5 strategie di migrazione AS/400?

Le strategie operative nel 2026 sono cinque. Non quattro, non sei. Cinque sono il punto giusto fra completezza e gestibilità decisionale.

1. Replatforming (lift-and-shift)

Si prende l’AS/400 così com’è e lo si sposta su infrastruttura cloud, mantenendo l’environment IBM i e il codice RPG/COBOL invariato. I principali provider sono IBM Cloud (Power Virtual Server), Skytap, Connectria, oppure setup ibridi su Azure/AWS.

Quando ha senso: quando il codice esistente funziona e il problema è infrastrutturale (hardware vecchio, contratti di manutenzione costosi, esigenza di disaster recovery moderna). Il valore aggiunto è quasi tutto operativo: si paga meno la manutenzione hardware, si guadagna in resilienza, si delega all’hyperscaler la gestione della macchina.

Cosa NON risolve: il problema dei programmatori RPG. Si continua a dipendere da quella skill, semplicemente su un’infrastruttura diversa. Anche il problema delle integrazioni rimane: l’AS/400 in cloud parla ancora con il suo dialetto.

Tempi e costi: 4-6 mesi, 80.000-150.000 euro per medie imprese. È la strategia più veloce e meno rischiosa, ma è anche quella con il valore di trasformazione più basso.

2. Refactoring (riscrittura modulare graduale)

Si riscrive progressivamente il software, modulo per modulo, in tecnologie moderne (tipicamente Java, .NET, Node.js o Python a seconda del team), mentre il sistema legacy continua a girare. Il pattern di riferimento si chiama strangler fig ed è documentato come pattern formale di software engineering: si “strozza” gradualmente il sistema vecchio sostituendone i pezzi.

Come funziona in pratica: si mette un layer di API in mezzo (un facade HTTP/REST che parla a entrambi i sistemi), si individua un modulo dell’AS/400 con interfaccia ragionevolmente isolata (es. gestione anagrafica clienti), lo si riscrive nella nuova tecnologia, si redirige il traffico verso il nuovo. Il modulo vecchio resta operativo come fallback per qualche settimana, poi si dismette. Si ripete per ogni modulo, in ordine di rischio crescente.

Quando ha senso: quando c’è dipendenza forte dal sistema (non si può fermare il business), quando il codice esistente contiene logica preziosa che va preservata, quando il team ha capacità ingegneristica interna per un progetto di lungo periodo.

Cosa NON risolve nel breve termine: non riduce immediatamente la dipendenza dai programmatori RPG, anzi nei primi mesi la aumenta (servono entrambe le competenze). Il vantaggio si raccoglie dopo 12-18 mesi.

Tempi e costi: 12-24 mesi, 150.000-300.000 euro per medie imprese. È la strategia con il rischio operativo più basso, perché ogni step è reversibile.

Posso fare la migrazione mantenendo il sistema attivo?

Sì, con il pattern strangler fig. Il sistema legacy continua a funzionare mentre i moduli vengono progressivamente rimpiazzati. È la strategia più sicura per business critici. Richiede più tempo (12-24 mesi tipici) ma elimina il rischio di un big-bang failure, cioè il caso in cui si spegne il vecchio sistema e il nuovo non regge il primo giorno di produzione.

3. Replacement (sostituzione completa)

Si abbandona il software custom dell’AS/400 e si adotta un ERP standard di mercato: SAP, Microsoft Dynamics, Odoo, oppure un verticale italiano (TeamSystem, Zucchetti, ESA, NTS). Il vecchio sistema si spegne quando il nuovo è in produzione, dopo data migration e training degli utenti.

Quando ha senso: quando il software AS/400 non è davvero un vantaggio competitivo ma una commodity diventata costosa da mantenere. Tipico nelle PMI manifatturiere e di distribuzione, dove l’AS/400 fa cose che fanno anche tutti gli ERP standard moderni, solo in modo proprio.

Cosa NON risolve: l’adattamento dei processi aziendali al nuovo sistema. Tutte le specificità che 30 anni fa avete deciso di codificare nel software custom ora dovete decidere se: (a) farle entrare nel sistema standard via customization (costoso), (b) cambiare i processi per adattarli allo standard (politicamente difficile), (c) tenere parte dei processi fuori dal sistema standard (proliferazione di Excel).

Tempi e costi: 18-36 mesi, 250.000-500.000+ euro per medie imprese, incluse licenze pluriennali e consulenza di implementazione. È spesso la migrazione più cara e quella con il rischio più alto di rigetto organizzativo.

4. Retirement (dismissione progressiva)

Si decide che alcune funzionalità dell’AS/400 non sono più strategiche e si rimuovono senza rimpiazzarle, oppure si rimpiazzano con strumenti distribuiti di nicchia (es. fatturazione con un servizio dedicato, magazzino con un WMS verticale, anagrafica clienti dentro un CRM moderno). Il monolite si scompone in più pezzi gestiti separatamente.

Quando ha senso: quando l’AS/400 è cresciuto negli anni accumulando funzioni che oggi sono coperte meglio da strumenti specifici. Spesso è la realtà nelle aziende che hanno fatto poca igiene IT negli ultimi 20 anni e si ritrovano il gestionale che fa anche cose che non dovrebbe.

Cosa NON risolve: il problema dell’integrazione fra tutti i pezzi nuovi. Si passa da un monolite a un insieme di sistemi che devono comunque parlare. È una semplificazione che porta complessità di un altro tipo.

Tempi e costi: 12-24 mesi a seconda di quanti pezzi si separano, 100.000-250.000 euro. Spesso si combina con un’altra strategia (es. retirement + replatforming del core).

5. Hybrid approach

Combinazione delle precedenti. Quasi sempre, quando si scende nel dettaglio di un caso reale, la strategia vera è ibrida: si fa replatforming del core, refactoring di 2-3 moduli critici, retirement di funzionalità ormai marginali, replacement di un pezzo con uno strumento di mercato.

Quando ha senso: praticamente sempre, dopo l’assessment serio. Le strategie “pure” sono utili come framework di ragionamento, ma le aziende reali stanno in mezzo.

Tempi e costi: dipendono dalla composizione, ma tipicamente 180.000-400.000 euro in 18-30 mesi.

Come scegliere la strategia di migrazione giusta?

Cinque criteri decisionali, in ordine di peso.

1. Continuità operativa richiesta. Se l’azienda non può fermarsi nemmeno per un weekend (es. distribuzione 24/7, sanità, produzione continua), lo strangler pattern (refactoring graduale) è quasi obbligatorio. Se invece c’è una finestra di stop ragionevole (es. settimana di Ferragosto per il manifatturiero stagionale), si aprono opzioni big-bang più aggressive.

2. Profondità della logica business custom. Se l’AS/400 contiene logica unica, accumulata da anni di iterazione (es. configuratore di prodotto custom, pricing algoritmico, regole di compliance specifiche del vostro settore), il replacement con SAP/Dynamics rischia di perderla. Refactoring o hybrid sono più sicuri.

3. Budget e timeline. Replatforming si compra con 100k in 6 mesi. Replacement richiede mezzo milione in 2-3 anni. La differenza non è solo finanziaria: è di assorbimento organizzativo. Quanto può sopportare l’azienda in termini di attenzione manageriale verso un progetto IT pluriennale?

4. Skill team interno. Avete un team IT interno capace di gestire un refactoring (richiede competenze ingegneristiche avanzate), o vi conviene un percorso che dipende meno dal team interno (replatforming, replacement)?

5. Maturità del mercato per il vostro settore. Per alcuni settori esistono ERP verticali italiani molto maturi (TeamSystem per studi professionali, Zucchetti per HR, ESA per manifatturiero su commessa). Per altri il mercato è frammentato e il custom resta la scelta più sana. Studiare cosa fanno realmente i vostri pari di settore aiuta a tarare la decisione.

Una matrice 2x2 utile per visualizzare:

                  Investimento BASSO         Investimento ALTO
                ┌──────────────────────┬──────────────────────┐
   Rischio      │                      │                      │
   operativo    │   REPLATFORMING      │     REPLACEMENT      │
   BASSO        │   (lift-and-shift)   │   (sostituzione)     │
                │                      │                      │
                ├──────────────────────┼──────────────────────┤
                │                      │                      │
   Rischio      │     RETIREMENT       │     REFACTORING      │
   operativo    │  (dismissione)       │  (strangler fig)     │
   ALTO         │                      │                      │
                └──────────────────────┴──────────────────────┘

La matrice ha un secondo significato che spesso si trascura: il rischio operativo “alto” non vuol dire pericoloso. Vuol dire che richiede vigilanza maggiore nel processo, perché si tocca direttamente la logica business. Il refactoring è in alto a destra non perché sia pericoloso, ma perché tocca il cuore del sistema mentre il sistema gira.

Quali sono gli errori più frequenti nelle migrazioni AS/400?

Sette pattern di fallimento che vediamo ripetersi.

1. Sottostimare il domain knowledge nascosto nel codice. Il codice RPG di vent’anni fa contiene non solo logica, ma decisioni: regole di sconto contrattate verbalmente con tre clienti storici, eccezioni per il magazzino di Brescia che fa solo lui, calcoli di provvigione che nessuno ricorda più perché funzionano così. Si stima sempre per linee di codice. Si dovrebbe stimare per regole business da disambiguare, che sono tipicamente 3-5 volte di più.

2. Trattare la migrazione come progetto IT invece che come progetto di business transformation. Le migrazioni che falliscono spesso falliscono perché l’azienda pensa che basti il CTO. In realtà serve il commitment del CEO, perché si toccano flussi che attraversano tutti i reparti. Senza sponsorship esecutiva continuativa, il primo conflitto fra IT e operations blocca il progetto.

3. Big-bang senza fallback. Spegnere il vecchio sistema il giorno in cui parte il nuovo, senza un piano di rollback testato, è la singola decisione più rischiosa. Anche le migrazioni meglio pianificate hanno bug il giorno del go-live. Senza fallback, un bug critico diventa una catastrofe operativa.

4. Ignorare la data quality legacy. I dati storici dell’AS/400 contengono errori, duplicati, codifiche obsolete, campi vuoti con significato implicito. Migrarli “così come sono” sul nuovo sistema porta gli stessi problemi nel mondo nuovo. Si dovrebbe fare data cleansing prima della migrazione, ma è un lavoro che nessuno vuole pagare.

5. Sottovalutare il training degli utenti finali. Il nuovo sistema è diverso, le schermate sono diverse, i tasti funzione spariscono. Gli utenti che usano il vecchio sistema da 25 anni hanno la memoria muscolare di sequenze di tasti che il nuovo sistema non riproduce. Senza un piano di training serio (40-80 ore per utente power), il rigetto utente affossa la migrazione anche se tecnicamente perfetta.

6. Affidarsi a fornitori che vendono pacchetti standard senza adattamento. Ci sono integratori che “migrano AS/400” vendendo lo stesso playbook a chiunque. Se il consulente non vi chiede prima cosa fa esattamente il vostro AS/400, sta vendendo qualcosa di precostituito che potrebbe non adattarsi alla vostra realtà.

7. Non prevedere il post-go-live. I primi 3-6 mesi dopo il go-live sono i più critici. Si trovano bug residui, si scoprono casi non gestiti, gli utenti chiedono adattamenti. Senza un budget e un team allocato per la fase post-go-live, il progetto si chiude formalmente ma lascia in eredità un sistema instabile.

Quanto tempo serve per migrare un AS/400?

La migrazione di un AS/400 richiede tipicamente 6-18 mesi, a seconda della complessità del codice e della strategia scelta. Il replatforming può essere completato in 4-6 mesi. Il refactoring graduale richiede 12-24 mesi ma con rischio operativo minore. Il replacement totale richiede 18-36 mesi.

I fattori che spostano i tempi sono: numero di programmi RPG (sopra i 1.500 programmi i tempi raddoppiano), numero di integrazioni esterne (ogni integrazione esterna aggiunge 4-8 settimane), volume di dati storici da migrare (sopra i 50 milioni di record si entra in tempi double-digit settimanali per il solo data transfer), personalizzazioni accumulate negli anni.

Un benchmark utile: per un AS/400 medio italiano (1.000-2.000 programmi RPG, 8-12 integrazioni esterne, 10-50 milioni di record storici) un refactoring serio richiede tipicamente 15-18 mesi. Se qualcuno propone meno di 9 mesi per questa fascia, o non ha capito il problema o sta vendendo male.

Quanto costa una migrazione AS/400 nel 2026?

Il range realistico per una media impresa italiana è 80.000-500.000 euro, ma è un range troppo ampio per essere utile. Suddividendolo per strategia: replatforming 80-150k, refactoring 150-300k, replacement 250-500k+, retirement 100-250k a seconda della profondità, hybrid tipicamente 180-400k.

I fattori principali che fanno variare il prezzo sono quattro: numero di programmi RPG (proxy della complessità funzionale), numero di integrazioni esterne (ogni ponte custom costa decine di migliaia di euro), volume dati storici (impatta sia transfer che cleansing), personalizzazioni accumulate (più sono, più assessment serve prima di stimare).

Una regola operativa che funziona: prendete il numero di programmi RPG attivi e moltiplicate per 100-150 euro per ottenere un ordine di grandezza minimo per il refactoring. Per replatforming dividetelo per 2-3. Per replacement aggiungete le licenze pluriennali del nuovo sistema (tipicamente 50-200k a seconda del prodotto e del numero utenti). Sono ordini di grandezza, non preventivi: ogni caso reale richiede assessment.

Quale ruolo ha l’AI tooling moderno nella modernizzazione AS/400?

Qui serve onestà, perché il marketing di settore sta gonfiando il tema da quasi tre anni.

Quello che l’AI fa davvero bene oggi: reverse-engineering del codice RPG legacy. I modelli moderni (Claude, GPT, Gemini in versione coding) leggono codice RPG di trent’anni fa e producono spiegazioni in italiano molto comprensibili. Per un team che eredita un codebase senza documentazione, questo accelera la fase di discovery in modo significativo: quello che richiedeva 4-6 settimane di reverse-engineering manuale ora si fa in 2-3 settimane con AI come copilota.

Quello che l’AI fa decentemente: tradurre RPG in linguaggi moderni a livello sintattico. Si dà al modello un programma RPG e si chiede di produrne l’equivalente in Java o Python. L’output è leggibile, ma quasi sempre non funziona in produzione senza editing pesante. Non perché l’AI sia incapace: perché il programma RPG vero contiene assunzioni sul contesto (file su nastro, journaling DB2 for i, accesso indicizzato) che il linguaggio target non replica nativamente.

Quello che l’AI NON fa: capire il business logic implicito. Il modello traduce quello che vede, non quello che dovrebbe essere. Se il codice RPG calcola sconto cliente con una formula che cambia in base al codice agente, e c’è un’eccezione documentata solo come commento in dialetto piemontese del 1998, l’AI non capisce che quella regola non si applica più dal 2015. Si limita a tradurla. Solo un essere umano che parla con chi gestisce il prodotto può decidere cosa preservare, cosa eliminare, cosa modificare.

Il warning più importante: chi propone migrazioni AS/400 “AI-driven” come fossero un click sta scaricando il rischio sul cliente. Il valore reale dell’AI nella modernizzazione è come acceleratore della fase di analisi e di prima stesura del codice nuovo, non come automa. La supervisione senior resta indispensabile, e i tempi totali si comprimono del 20-30% al massimo, non del 70-80% come a volte si sente promettere.

Per chi vuole sperimentare, l’approccio che funziona è: usare un modello LLM moderno come copilota di traduzione, non come motore. Si dà un programma RPG, si chiede traduzione + spiegazione + lista di assunzioni, e poi un developer senior decide cosa tenere. È il modo in cui usiamo l’AI nei progetti di modernizzazione che facciamo internamente.

FAQ

Si può migrare un AS/400 senza riscrivere RPG?

Sì, con replatforming. Il codice RPG resta invariato, cambia solo l’infrastruttura sottostante (cloud invece di hardware on-premise). È la strategia più veloce ma non risolve il problema della scarsità di sviluppatori RPG: continuate a dipenderne, solo su una macchina diversa.

Cosa succede ai dati storici quando si migra?

Si decide caso per caso. Le opzioni sono: (1) migrare tutto sul nuovo sistema (caro, lungo, ma “tutto in un posto”); (2) migrare solo i dati attivi e archiviare il resto su data lake o sistema di sola lettura (più rapido, ma due posti da consultare per le ricerche storiche); (3) tenere l’AS/400 in modalità sola-lettura per anni come fonte di consultazione storica, mentre il nuovo sistema gira (compromesso pragmatico spesso adottato).

Quanto costa mantenere un AS/400 oggi rispetto al cloud?

Per medie imprese, il TCO annuale di un AS/400 on-premise (hardware, manutenzione hardware IBM, licenze IBM i, personale RPG, energia, spazio fisico) è tipicamente 45.000-90.000 euro all’anno. Lo stesso carico in cloud (IBM Power Virtual Server, Skytap, Connectria) si attesta su 30.000-55.000 euro all’anno. Risparmio del 25-40% sul TCO, più resilienza superiore. Il replatforming si ripaga da solo in 3-5 anni.

È meglio un partner italiano o uno globale per la migrazione?

Dipende dallo scope. Per replatforming puro va bene un partner globale (IBM, Skytap, partner certificati IBM Cloud) perché il valore è infrastrutturale. Per refactoring e replacement il partner italiano ha vantaggi netti: parla la lingua del business locale, conosce i vincoli normativi italiani (GDPR, NIS2, fatturazione elettronica via SDI, conservazione digitale), e ha tariffe più allineate alle PMI italiane (di norma 50-65% del costo di un equivalente big global). Non è sempre vero, ma vale come ipotesi di partenza.

Cosa fare prima di iniziare l’assessment?

Tre cose, in ordine. (1) Documentare cosa fa concretamente l’AS/400 oggi: lista dei principali moduli, integrazioni esterne, utenti, volumi (anche solo approssimativi). (2) Mappare gli stakeholder interni: chi sono le tre persone senza il cui input qualunque migrazione fallirà? Coinvolgerli da subito. (3) Definire il budget orientativo a tre orizzonti: cosa siamo disposti a investire entro 6 mesi (pilot/replatforming), entro 18 mesi (refactoring parziale), entro 3 anni (modernizzazione completa). Senza queste tre informazioni qualunque preventivo che vi arriverà sarà generico.

Conclusione e prossimi passi

La migrazione di un AS/400 nel 2026 non è un progetto IT puro: è una decisione strategica che tocca continuità operativa, competenze interne, compliance e capacità futura di adottare AI. Le cinque strategie disponibili (replatforming, refactoring, replacement, retirement, hybrid) coprono tutti i casi sensati. Quale sia giusta per la vostra azienda dipende dal mix specifico dei vincoli, non da un framework universale.

Quello che emerge dalle conversazioni con CIO e direttori IT di PMI italiane: chi inizia ad affrontare la decisione nel 2026 ha tempo per farla bene. Chi aspetta il 2028, probabilmente non avrà più la disponibilità di programmatori RPG per gestire la transizione con calma. Il momento di iniziare l’assessment, anche solo per capire dove ci si trova, è adesso.

Se state valutando una migrazione AS/400 e volete una conversazione concreta, senza preventivi automatici e senza forfait inventati, parliamone. Il primo confronto è gratuito e dura il tempo di una telefonata.

Per approfondire altre dimensioni del tema, sono utili i seguenti riferimenti interni: la pagina pilastro modernizzazione legacy, la pagina dedicata alla migrazione AS/400 cloud, e la pagina settore manifatturiero, dove l’AS/400 è ancora oggi un protagonista nascosto della filiera produttiva italiana.