Quanto tempo serve per migrare un AS/400: tempi reali nel 2026

La risposta più onesta alla domanda “quanto tempo serve per migrare un AS/400” è: 6-18 mesi nella maggior parte dei casi, con picchi a 24-36 mesi per scenari complessi. Il range è ampio perché le strategie di migrazione hanno tempi molto diversi (4-6 mesi per replatforming, 18-36 per replacement), e ogni strategia ha modifier tipici che possono raddoppiare la timeline. Vediamo come si stima il vostro caso specifico.

Risposta in 3 righe

• Replatforming (lift-and-shift in cloud, codice RPG invariato): 4-6 mesi tipici.
• Refactoring graduale (strangler fig, riscrittura modulo per modulo): 12-24 mesi, con sistema legacy attivo per tutta la durata.
• Replacement (sostituzione con ERP standard): 18-36 mesi inclusi data migration e training utenti.

Quali fattori spostano davvero la timeline

Cinque fattori in ordine di impatto.

1. Numero di programmi RPG/COBOL attivi

Sopra i 1.500 programmi attivi i tempi raddoppiano rispetto alla baseline di 800-1.500 programmi. La ragione è semplice: il tempo di assessment, mappatura dipendenze, decisione su cosa migrare/scartare cresce in modo non-lineare con la dimensione del codice. Sotto i 500 programmi, invece, la migrazione è notevolmente più veloce.

2. Numero di integrazioni esterne

Ogni integrazione esterna attiva aggiunge tipicamente 4-8 settimane al progetto totale. Integrazioni con sistemi che hanno API REST moderne sono più veloci; integrazioni con vecchie API SOAP, FTP, file drop o database condivisi rallentano. Un AS/400 con 12 integrazioni esterne porta 3-6 mesi solo di lavoro su integrazioni.

3. Volume e qualità dei dati storici

Sotto i 10 milioni di record la migrazione dati è veloce (4-8 settimane). Tra 10 e 50 milioni è il caso medio (8-16 settimane). Oltre i 50 milioni si entra in dimensioni “industriali” che richiedono pianificazione batch dedicata, finestra di cut-over multi-weekend, possibili migrazioni incrementali (6-12 mesi solo sul data tier).

4. Disponibilità di personale chiave interno

I progetti dove c’è un referente tecnico interno (1-2 persone che conoscono bene il legacy e sono dedicate al progetto per metà del loro tempo) procedono del 30-50% più veloce. Quelli dove il personale interno è frammentato o saturato da altre attività vanno a rilento per accesso difficile alle informazioni chiave.

5. Continuità operativa richiesta

Se il business consente fermo di 1 weekend lungo (Ferragosto, Natale) per il cut-over, replacement diretto è veloce. Se il business non consente nessun fermo (24/7, sanità, distribuzione continua), va costruito un layer di compatibilità per il running parallelo: aggiunge tipicamente 2-4 mesi al progetto.

Tempi per ogni strategia

Replatforming (lift-and-shift): 4-6 mesi

Sposta l’AS/400 esistente su infrastruttura cloud (IBM Power Virtual Server, Skytap, Connectria) senza toccare codice RPG.

Fase 1 (settimane 1-3): Assessment infrastrutturale, scelta provider cloud, pianificazione network connectivity, valutazione SLA.

Fase 2 (settimane 4-10): Setup ambiente cloud, replicazione configurazione AS/400, test di compatibilità, backup completo.

Fase 3 (settimane 11-16): Dry run migrazione, cut-over finale in finestra di fermo concordata, go-live.

Fase 4 (settimane 17-24): Stabilization post-cut-over, ottimizzazione costi cloud, dismissione hardware on-premise.

Replatforming è la strategia più rapida ma copre solo il problema infrastrutturale: la dipendenza da programmatori RPG e i limiti di integrazione restano.

Refactoring graduale (strangler fig): 12-24 mesi

Riscrive il software modulo per modulo in tecnologia moderna mentre il sistema legacy continua a girare. Strategia con il rischio operativo più basso.

Fase 1, assessment e foundation (mesi 1-3):

• Audit completo del codebase legacy
• Mappatura processi business critici
• Design dell’architettura target (microservizi, API gateway, facade di transizione)
• Setup ambiente di sviluppo + CI/CD

Fase 2, strangler facade (mesi 4-5):

• Costruzione del facade HTTP/REST che intercetta le richieste
• Routing iniziale: tutte le richieste vanno ancora al legacy
• Setup observability (log, metriche, tracing)

Fase 3, primo modulo migrato (mesi 6-8):

• Scelta modulo a basso rischio (es. anagrafica clienti)
• Riscrittura in tecnologia moderna (Java, Node.js, .NET)
• Shadow mode: nuovo modulo riceve le richieste in parallelo al legacy, output confrontati
• Cut-over modulo singolo, legacy fallback per 4-8 settimane

Fase 4, moduli incrementali (mesi 9-22):

• Stesso pattern per ogni modulo successivo
• Ordine tipico: anagrafica → ordini → fatturazione → magazzino → contabilità
• Velocità che cresce con l’esperienza del team

Fase 5, dismissione legacy (mesi 22-24):

• Ultimi moduli e dati storici
• Spegnimento AS/400, conservazione dei dati storici in archivio query-only

Replacement (sostituzione totale): 18-36 mesi

Adottare un ERP standard al posto dell’AS/400 e migrare dati + processi.

Fase 1, selezione vendor (mesi 1-3):

• Vendor evaluation (SAP, Microsoft Dynamics, Odoo, TeamSystem Enterprise, NetSuite)
• Demo e POC con due-tre opzioni in parallelo
• Negoziazione commerciale e firma

Fase 2, discovery e blueprint (mesi 4-6):

• Mappatura processi attuali vs standard del nuovo ERP
• Definizione gap: cosa va in customization, cosa cambia nel processo aziendale, cosa si lascia perdere
• Design to-be

Fase 3, configurazione e customization (mesi 7-15):

• Configurazione moduli ERP standard
• Customization dei gap identificati
• Sviluppo integrazioni con sistemi esterni
• Migrazione dati storici (subprogetto a sé)

Fase 4, testing e training (mesi 16-22):

• UAT (User Acceptance Test) con utenti finali
• Training utenti chiave (40-80 ore per utente power)
• Dry run del go-live multipli
• Stabilizzazione parallel run

Fase 5, go-live + iperattenzione (mesi 22-30):

• Cut-over finale
• 3-6 mesi di iperattenzione post-go-live (bug, fix, fine-tuning utenti)
• Roll-out graduale per sedi/divisioni se applicabile

Fase 6, dismissione legacy (mesi 30-36):

• Spegnimento AS/400 in modalità sola lettura per 12-24 mesi (consultazione dati storici)
• Spegnimento totale con archiviazione long-term

Cosa rallenta sempre i progetti (più del previsto)

Cinque “categorie di stallo” che vediamo ripetersi.

1. Reverse-engineering del codice non documentato. L’AS/400 medio italiano ha documentazione interna ferma agli anni 2000, commenti in dialetto, autori in pensione. Il tempo per capire cosa fa effettivamente il codice è sempre 2-3x quello stimato a priori. Mitigazione: assessment serio in fase 1, AI come copilota di analisi RPG.

2. Data quality issues che emergono solo dopo migration test. Il 30-40% dei progetti scopre nei test di migrazione che i dati storici hanno problemi non noti: duplicati, codifiche miste, riferimenti incrociati rotti. Il data cleansing aggiunge tipicamente 8-16 settimane non preventivate. Mitigazione: campione pilota di dati migrati nelle prime 4-6 settimane di progetto.

3. Stakeholder approval delays. Decisioni di scope che richiedono CdA o sponsor esecutivo aspettano riunioni mensili. Ogni decisione importante può aggiungere 2-4 settimane se il governance non è snello. Mitigazione: steering committee settimanale dedicato al progetto, con autorità decisionale.

4. Integration with downstream systems. Gli AS/400 che hanno 8-15 integrazioni esterne attive scoprono in fase di test che alcune integrazioni “minori” sono in realtà critiche per processi che nessuno ricordava. Mitigazione: integration map completa documentata in fase 1, audit di tutte le interazioni batch notturne.

5. Resistance from end users. Utenti che usano l’AS/400 da 20-30 anni hanno muscle memory di sequenze di tasti, schermate, shortcut. Nuova interfaccia = rigetto iniziale, anche se oggettivamente più ergonomica. Senza piano di change management serio si rischia boycott operativo che blocca il go-live. Mitigazione: training presto, champion users coinvolti dal mese 4-6, non solo dal mese 18.

Come si fa una stima realistica per il vostro caso

Quattro domande per stimare in modo non-fantasioso:

1. Quanti programmi attivi RPG/COBOL avete? (Non quanti ne avete totali, ma quanti effettivamente eseguiti negli ultimi 12 mesi. Tipicamente è il 50-70% del totale, gli altri sono “abbandonati ma non rimossi”).

2. Quante integrazioni esterne attive? (Sistemi che scambiano dati col vostro AS/400, in batch o real-time).

3. Qual è la disponibilità di personale interno? (Le 1-2 persone che davvero conoscono il legacy sono dedicate parzialmente al progetto?).

4. Qual è la continuità operativa richiesta? (Si può fermare il sistema per uno o più weekend, oppure mai?).

Con queste 4 informazioni, una stima iniziale a banda di confidenza ±25% è fattibile. Stime sotto ±25% richiedono un assessment formale di 3-6 settimane sul codice e i dati.

Esempio: AS/400 con 1.200 programmi RPG attivi, 8 integrazioni, 1 persona interna dedicata al 50%, finestra di fermo solo Ferragosto.

• Replatforming: 5-6 mesi
• Refactoring strangler: 18-22 mesi (il fermo limitato impone strangler)
• Replacement: 24-28 mesi

FAQ

Si può fare la migrazione in meno di 6 mesi?

Solo per replatforming puro e AS/400 piccoli (sotto 500 programmi, poche integrazioni). Refactoring sotto 12 mesi è realistico solo se il codice legacy è già modulare bene e i dati sono puliti, situazione rara nei sistemi di 25-40 anni.

Quanto dura il parallel running?

Tipicamente 4-12 settimane per strategie replacement. Più breve per strategie strangler dove i moduli vengono migrati uno alla volta con fallback di 2-4 settimane ognuno. Più breve (1-2 settimane) per replatforming dove i sistemi non differiscono funzionalmente.

Cosa succede ai dati dopo la migrazione?

Tipicamente l’AS/400 resta acceso in modalità sola lettura per 12-24 mesi dopo il cut-over, come fonte di consultazione storica. Poi viene spento e i dati vengono archiviati in long-term storage (tipicamente con sistema di accesso query su dati storici a parte). Alcune aziende mantengono l’AS/400 in cold storage per 5-10 anni per ragioni di compliance fiscale e legale.

I tempi includono il change management organizzativo?

Solo parzialmente. I tempi tecnici includono training e roll-out, ma il change management profondo (cambio di processi aziendali, gestione resistenze, ridisegno organizzativo) è un progetto parallelo che spesso continua 6-12 mesi dopo il go-live tecnico. Sottovalutarlo è la singola causa più frequente di “progetto tecnico OK, ma azienda non ne beneficia”.

Quale fase costa di più in tempo?

In refactoring strangler: la fase 3 (primo modulo migrato) è la più dispendiosa in proporzione perché è dove il team apprende le specificità del legacy. Una volta superata, le velocità di migrazione raddoppiano. In replacement: la fase 3-4 (configurazione + UAT) sono le più lunghe in valore assoluto.

Si può comprimere la timeline assumendo più consulenti?

Solo entro certi limiti. Sopra una certa soglia (tipicamente 8-12 persone esterne sul progetto), l’aggiunta di consulenti rallenta invece di accelerare per problemi di coordinamento e di accesso alle informazioni chiave (che sono concentrate in poche persone interne). La curva non è lineare.

Conclusione

I tempi di migrazione di un AS/400 nel 2026 sono prevedibili a banda di confidenza ragionevole se l’assessment iniziale è serio. Sono imprevedibili se si parte direttamente dal vendor pitch senza assessment. La cosa peggiore che possiate fare è committarvi a una timeline aggressiva senza aver studiato il codice: ogni mese che si scopre essere “più lento del previsto” costa molto più di un mese in più preventivato a priori.

Se state valutando una migrazione AS/400 e volete una stima realistica della timeline per il vostro caso specifico, parliamone. Un assessment di 3-4 settimane dà una stima a ±15% che vale per progetti decennali.

Per approfondire: la pagina pilastro modernizzazione legacy, la pagina dedicata alla migrazione AS/400 cloud, e l’articolo correlato guida alla migrazione AS/400 nel 2026 per il quadro strategico completo.