IBM i 7.4 fuori supporto dal 30 settembre 2026: chi fa cosa

Il 30 settembre 2026 IBM cambia il livello di servizio di IBM i 7.4. Da quel giorno la release non riceve più correzioni nel regime di manutenzione ordinaria: continua a funzionare, continua a far girare la produzione, e smette di ricevere fix di sicurezza a meno che non si paghi un contratto separato.

La domanda che ci sentiamo fare più spesso è se il sistema si fermerà. No. Il 1° ottobre il gestionale si accende come tutti i giorni. La domanda giusta è un’altra, e riguarda meno l’informatica di quanto sembri: per quanto tempo si può tenere in produzione un sistema che gestisce ordini, magazzino e fatturazione e che non riceve più patch di sicurezza? Nel 2026, con la NIS2 che entra nei contratti di fornitura, quella è una domanda di conformità prima che tecnica.

Questo articolo mette in fila i fatti verificabili: le date, la matrice di compatibilità fra release e hardware, e le tre strade possibili con i loro costi. Nessuna delle tre è “migrare tutto adesso”.

TL;DR

• 30 settembre 2026: IBM i 7.4 esce dal supporto standard. La release era già stata ritirata dalla commercializzazione il 30 aprile 2026.
• Il sistema non smette di funzionare. Smette di ricevere PTF di sicurezza nel regime ordinario. È disponibile un contratto di estensione a pagamento, che secondo i comunicati dei partner IBM copre fino al 30 settembre 2029, a un costo che è un multiplo della manutenzione standard.
• La matrice comanda su tutto il resto: IBM i 7.5 gira su Power9, Power10 e Power11. IBM i 7.6 gira solo su Power10 (firmware minimo FW1060) e Power11. Chi è su Power8 ha in 7.4 l’ultima release possibile: per aggiornare il sistema operativo deve cambiare hardware.
• Chi è su Power9 ha un problema doppio e meno visibile: può salire a 7.5, ma la sua macchina è uscita dal supporto standard il 31 gennaio 2026. Il sistema operativo si aggiorna, il ferro sotto no.
• IBM i 7.5 e 7.6 non hanno una data di fine annunciata, e IBM si impegna a dare almeno 12 mesi di preavviso. Chi arriva a 7.5 compra tempo vero, non un rinvio di sei mesi.
• Un aggiornamento di release pulito, con assessment, test e finestra di cutover, richiede 90-180 giorni per un’installazione di media dimensione. Chi parte oggi arriva in tempo per il 30 settembre solo con uno scenario semplice. Per tutti gli altri la scadenza reale è già passata, e la scelta è fra estensione a pagamento e rischio scoperto.

Cosa significa davvero “fine del supporto standard”

IBM ha smesso di usare l’espressione end of support per queste transizioni e parla di change in service level. Non è cosmesi: descrive meglio cosa succede.

Dal 30 settembre 2026 su IBM i 7.4:

• Nessuna nuova PTF, incluse quelle di sicurezza. Le correzioni già pubblicate restano scaricabili, le nuove non arrivano.
• Nessun nuovo Technology Refresh. La 7.4 si ferma alla funzionalità che ha oggi.
• Supporto tecnico solo dentro un contratto di estensione, a pagamento e separato dalla manutenzione software ordinaria.
• Il software applicativo non viene toccato. Il vostro gestionale in RPG continua a girare identico.

La differenza fra “fine supporto” e “fine vita” conta perché determina l’urgenza. Non c’è nessuna data in cui la macchina si spegne. C’è una data oltre la quale ogni vulnerabilità scoperta nel sistema operativo resta aperta sul vostro sistema a tempo indeterminato, salvo pagare.

Perché nel 2026 questo è un tema di conformità

Fino a qualche anno fa un AS/400 senza patch era una scelta di rischio interna. Adesso è una scelta che qualcun altro valuta al posto vostro.

La NIS2 e il decreto italiano che la recepisce (D.Lgs. 138/2024) chiedono ai soggetti obbligati misure di gestione delle vulnerabilità e di aggiornamento, ed estendono la richiesta alla catena di fornitura. Se siete fornitori di un soggetto essenziale o importante, il questionario che vi arriva contiene una domanda su come gestite le patch dei sistemi che trattano i dati del cliente. “Il sistema è fuori supporto dal 2026 e non riceve correzioni” è una risposta che si può dare una volta, con un piano allegato. Due anni di fila no.

Lo stesso meccanismo vale per le certificazioni che i vostri clienti hanno e voi no: un audit ISO 27001 in casa di un cliente arriva a guardare i sistemi dei fornitori che stanno dentro il perimetro. Ne abbiamo scritto in dettaglio parlando di NIS2 per le software house italiane, e il meccanismo è identico quando il sistema in questione è un IBM i.

La matrice: quale release potete installare sulla vostra macchina

È la parte che decide tutto, e nel parco installato italiano è la meno conosciuta. IBM i non si aggiorna liberamente: ogni release ha un requisito minimo di generazione del processore.

Le due righe che contano sono quelle in grassetto.

IBM i 7.5 non è supportato su Power8. Chi ha una macchina Power8 ha in 7.4 la fine della strada dal lato software: nessun aggiornamento di release è possibile senza sostituire il server.

IBM i 7.6 non è supportato su Power9 né su nessuna generazione precedente. Chi ha Power9 può arrivare a 7.5, che è supportata e senza data di fine annunciata, ma non oltre.

E qui si aggiunge il pezzo che quasi nessuno mette nel conto: i server Power9 scale-out sono usciti dal supporto standard hardware il 31 gennaio 2026, cioè sette mesi prima della scadenza software di cui stiamo parlando. Chi ha un Power9 e aggiorna a 7.5 si ritrova con il sistema operativo supportato e la macchina no, il che significa nessuna manutenzione preventiva, nessun aggiornamento di machine code e nessuna garanzia sui ricambi salvo contratto di estensione.

Le tre situazioni reali, e cosa fare in ciascuna

Nel parco installato italiano che vediamo, tre configurazioni coprono la quasi totalità dei casi.

Siete su Power10 o Power11 con IBM i 7.4

È la situazione fortunata, ed è più comune di quanto si pensi: molte aziende hanno cambiato hardware negli ultimi tre anni senza toccare la release, perché l’aggiornamento del sistema operativo richiede una finestra di fermo e il ferro no.

Cosa fare: aggiornamento di release a 7.5 o direttamente a 7.6. È un progetto tecnico, non un progetto di trasformazione: nessuna riscrittura di codice, nessun cambio di logica applicativa. Le cose che si rompono sono quasi sempre le stesse tre: programmi che usano interfacce deprecate, integrazioni esterne con librerie legate alla versione, e job schedulati che dipendono da comportamenti non documentati.

Tempi realistici: 60-120 giorni fra assessment, test su partizione separata, correzione di quello che emerge e finestra di cutover. Con un ambiente di test già esistente si sta nella parte bassa.

Costo: è il caso meno caro, e resta comunque un progetto. La voce dominante è il tempo di test, non la licenza.

Siete su Power9

Cosa fare: la strada tecnica è 7.5, e va bene. Ma la decisione vera non è sul software: è sull’hardware, che è già fuori supporto standard da gennaio 2026.

Le due opzioni sono comprare l’estensione di manutenzione hardware e restare su 7.5 per qualche anno, oppure accorpare il cambio ferro e il cambio release in un unico progetto e arrivare a Power10 con 7.6. La seconda costa di più in un colpo solo e chiude la questione per un ciclo intero. La prima sposta la spesa avanti e va rifatta.

Il criterio che usiamo per scegliere: se il piano industriale dell’azienda prevede di tenere il sistema attuale oltre il 2029, l’accorpamento conviene quasi sempre. Se invece esiste già un progetto di sostituzione del gestionale nei prossimi 24-36 mesi, spendere su hardware nuovo per un sistema destinato a uscire è denaro che non torna: meglio l’estensione, e tenere il budget per il progetto vero.

Siete su Power8

È la situazione che richiede una decisione, e la scadenza del 30 settembre la mette in evidenza invece di crearla.

Dal lato software la strada è finita: 7.4 è l’ultima release installabile. Dal lato hardware, Power8 è fuori supporto da anni. Le opzioni sono tre e vanno guardate in faccia:

1. Contratto di estensione su 7.4 e sistema congelato. Costo alto e ricorrente, nessuna nuova funzionalità, e una data di fine comunque: secondo i comunicati dei partner IBM l’estensione arriva al 30 settembre 2029. Ha senso come ponte dichiarato di 12-24 mesi verso qualcosa, non come strategia.
2. Cambio hardware verso Power10 e salto a 7.5 o 7.6. Rimette il sistema in un ciclo supportato senza toccare le applicazioni. È la strada che tiene in piedi un AS/400 che funziona e che l’azienda non ha motivo di abbandonare.
3. Modernizzazione applicativa, cioè affrontare il problema a monte invece che a valle. È la strada più lunga e non si decide sulla base di una scadenza di supporto: si decide sulla base del costo di mantenere le competenze e della flessibilità che serve al business nei prossimi dieci anni.

Quello che non funziona è la quarta opzione non dichiarata, cioè restare su 7.4 senza estensione sperando che non succeda niente. Funziona finché non arriva il questionario di un cliente, un audit, o una vulnerabilità che finisce sui giornali.

Quanto costa non fare niente

È la domanda che manca sempre nei preventivi, e l’unica che rende decisorio il confronto.

Il costo del rinvio non è zero e non è nemmeno costante: cresce.

Anno 1: il contratto di estensione, che è un multiplo della manutenzione software ordinaria. È una voce di bilancio nuova che prima non c’era.

Anno 2: la stessa voce, più il costo crescente di trovare competenze. Il mercato delle persone che sanno amministrare IBM i in Italia non si sta allargando, e la fascia di età di chi lo fa da vent’anni è quella che si avvicina alla pensione. Il prezzo orario di un intervento specialistico su una release fuori supporto è già oggi più alto di quello su una supportata, per la ragione banale che meno persone accettano di toccarla.

Anno 3: si aggiunge il costo di opportunità. Ogni integrazione nuova (un portale clienti, un flusso EDI, un agente che legge i dati del gestionale) su un sistema fuori supporto richiede più lavoro, perché mancano funzionalità che nelle release recenti sono native e perché nessun fornitore terzo garantisce compatibilità con una release che IBM non supporta più.

Il costo che non si ammortizza: il giorno in cui una vulnerabilità nota e non correggibile diventa il motivo per cui si perde una gara o si esce da una fornitura. Non è un costo che si mette a budget, ed è quello che decide.

Cosa NON è cambiato, e va detto

C’è una quantità di comunicazione commerciale che usa questa scadenza per vendere migrazioni complete. Vale la pena mettere per iscritto quello che il 30 settembre 2026 non significa.

Non significa che l’AS/400 sia una tecnologia morta. IBM ha rilasciato 7.6 nel 2025 e Power11 nel 2025, e continua a investire sulla piattaforma. Una release nuova e una generazione di processori nuova non sono i segnali di un prodotto in uscita.

Non significa che dobbiate abbandonare RPG. Il codice applicativo non è toccato da un cambio di release. Chi vi propone una riscrittura come conseguenza necessaria del cambio di supporto sta unendo due discorsi che non hanno relazione tecnica.

Non significa che dobbiate andare in cloud. Portare un IBM i su infrastruttura di terzi è una decisione di modello di costo, con vantaggi e svantaggi propri, e va valutata per conto suo. Una nota di igiene informativa: parecchi contenuti in circolazione citano ancora Skytap come opzione su Azure. Skytap è stata acquisita da Kyndryl e il servizio oggi si chiama diversamente, quindi diffidate dei materiali che non lo sanno, perché probabilmente non sono aggiornati nemmeno sul resto.

Non significa che serva decidere entro settembre. Serve decidere entro settembre solo se l’obiettivo è non pagare l’estensione. Se il budget per l’estensione c’è, la scadenza vera diventa quella del vostro piano, non quella di IBM.

Errori che vediamo fare in questa fase

1. Scoprire la matrice hardware a metà progetto. È l’errore più costoso e il più frequente. Si avvia un aggiornamento a 7.6 e a due mesi dall’inizio si scopre che la macchina è Power9 e non lo supporta. La verifica della generazione del processore e del livello di firmware è la prima cosa da fare, prima di qualsiasi pianificazione, e richiede dieci minuti.

2. Confondere la scadenza software con quella hardware. Sono due contratti diversi, con due date diverse e due fornitori di servizio potenzialmente diversi. Molte aziende su Power9 stanno guardando settembre 2026 senza essersi accorte che il ferro è scoperto da gennaio.

3. Aggiornare la release senza un ambiente di test. Su un sistema che regge la fatturazione, il cutover senza prova è un rischio che non si giustifica per risparmiare la partizione di test. Se la macchina non ha risorse per una partizione separata, quella è già una risposta sulla domanda “serve hardware nuovo”.

4. Non censire le integrazioni. Il sistema operativo si aggiorna quasi sempre bene. Quello che si rompe sta ai bordi: il software di terze parti agganciato al sistema, i tool di backup, i driver di stampa, i connettori verso il gestionale documentale. Il censimento delle integrazioni è la parte dell’assessment che si tende a saltare ed è quella che genera le sorprese.

5. Trattarla come una decisione IT. La scelta fra estensione a pagamento, cambio hardware e modernizzazione dipende dal piano industriale dell’azienda a cinque anni, non dalla preferenza tecnica di chi amministra il sistema. Se la decisione resta dentro il reparto IT, si sceglie quasi sempre l’opzione che minimizza il fastidio immediato, che raramente è quella che minimizza il costo totale.

FAQ

Il 30 settembre 2026 il mio AS/400 smette di funzionare?

No. Non c’è nessun meccanismo di spegnimento e nessuna licenza che scade. Il sistema continua a girare esattamente come prima. Quello che cambia è che IBM non pubblica più correzioni per quella release nel regime ordinario, incluse le correzioni di sicurezza.

Quanto costa l’estensione di supporto?

IBM non pubblica un listino, e la cifra dipende dalla configurazione e dal contratto in essere. L’ordine di grandezza che circola nella comunità tecnica è di un multiplo consistente rispetto alla manutenzione software standard. La cifra vera per il vostro caso la dà solo il vostro rivenditore IBM, e vale la pena chiederla adesso e non a settembre, perché è il numero che rende confrontabili le tre opzioni.

Posso saltare da 7.4 direttamente a 7.6?

Dipende dall’hardware, non dalla release di partenza. Se siete su Power10 con firmware adeguato o su Power11, sì. Se siete su Power9, no: la strada è 7.5. Se siete su Power8, non potete andare né a 7.5 né a 7.6 senza cambiare macchina.

Quanto tempo serve per un aggiornamento di release?

Per un’installazione di media dimensione con un ambiente applicativo maturo, 90-180 giorni dall’avvio dell’assessment alla produzione. La distribuzione tipica è un terzo di analisi e censimento delle integrazioni, un terzo di test e correzione, un terzo di preparazione e finestra di cutover. Chi ha già una partizione di test e integrazioni documentate sta nella parte bassa. Chi non ha né l’una né le altre sta nella parte alta, e la ragione è che il tempo se ne va nel ricostruire cosa c’è agganciato al sistema.

E se stessimo comunque pensando di sostituire il gestionale?

Allora l’estensione a pagamento è quasi sempre la scelta giusta come ponte, e la scadenza di settembre diventa un dettaglio di budget invece che un evento. Sostituire un gestionale su AS/400 richiede tempi che si misurano in anni, non in mesi: abbiamo messo i numeri per ogni strategia nell’articolo su quanto tempo serve per migrare un AS/400. Spendere su hardware nuovo per un sistema che uscirà entro 24 mesi è la decisione che poi si rimpiange.

Il codice RPG va riscritto?

No, non per questo. Un cambio di release del sistema operativo non richiede modifiche al codice applicativo, salvo casi limitati di programmi che usano interfacce deprecate. Se qualcuno lega la riscrittura del codice alla scadenza di supporto, sta mettendo insieme due progetti che non hanno relazione tecnica, e il secondo costa uno o due ordini di grandezza più del primo.

Come faccio a sapere che generazione Power ho?

Il modello della macchina lo dice, e sta sull’etichetta o nelle informazioni di sistema. In caso di dubbio lo sa il vostro rivenditore, ed è la prima informazione da recuperare: senza quella, ogni ragionamento su cosa fare è aria.

Cosa fare nelle prossime sei settimane

Il 30 settembre 2026 non è una scadenza drammatica ed è una scadenza vera. Non ferma nessun sistema, ma chiude una porta: da quel giorno un IBM i 7.4 senza contratto di estensione è un sistema che non riceve più correzioni di sicurezza, dentro un contesto normativo che ha smesso di considerarlo un dettaglio interno.

La cosa utile da fare in queste sei settimane è molto più piccola del futuro del sistema informativo: recuperare la generazione Power della macchina, chiedere al rivenditore il costo dell’estensione, e censire cosa c’è agganciato al sistema. Con quelle tre informazioni la decisione si prende in una riunione. Senza, si rimanda per un altro anno, che è quello che è successo negli ultimi tre.

Se avete un IBM i in produzione e volete capire in quale delle tre situazioni siete, parliamone. Mezza giornata di assessment produce la matrice del vostro caso e il costo delle tre strade, e non impegna a nulla.

Per approfondire: la guida alla migrazione AS/400 per le cinque strategie possibili quando la decisione è di modernizzare, la pagina migrazione AS/400 verso il cloud, e il pilastro modernizzazione dei sistemi legacy.

Fonti: la documentazione IBM su pianificazione dell’aggiornamento a IBM i 7.6 e a IBM i 7.5 per i requisiti hardware, e IT Jungle per l’annuncio del ritiro della 7.4. Le date sono verificate al 15 agosto 2026: trattandosi di comunicazioni di prodotto, vale la pena riverificarle prima di prendere decisioni di spesa.