Quanto costa mantenere un gestionale AS/400 e cosa copre il canone

La domanda arriva quasi sempre nella stessa forma: “quanto ci costa all’anno tenere l’AS/400?”. E quasi sempre la risposta che circola in azienda è una cifra sola, quella del canone del fornitore che segue il gestionale.

Quella cifra è vera e incompleta. In un sistema IBM i in produzione le voci sono cinque, arrivano da tre fornitori diversi con scadenze diverse, e le due più pesanti non stanno su nessuna fattura. Chi confronta il costo di mantenere con il costo di sostituire usando solo il canone applicativo confronta un quinto della spesa con la totalità dell’alternativa, e la conclusione esce sbagliata di default.

Questo articolo elenca le cinque voci, spiega cosa copre e cosa non copre un canone di manutenzione applicativa, e mette il confronto nella forma in cui si può decidere.

TL;DR

• La spesa annua di un gestionale AS/400 ha cinque voci: manutenzione software IBM, manutenzione hardware, manutenzione applicativa, licenze di terze parti, competenze interne.
• Il canone applicativo è quello che si conosce, ed è raramente la voce più grossa. Le licenze di terze parti accumulate in vent’anni e il costo delle competenze pesano di più, e nessuno le somma mai.
• Manutenzione software e manutenzione hardware sono due contratti distinti, con due date di scadenza distinte. Su una macchina Power9 il secondo è già fuori supporto standard dal 31 gennaio 2026, indipendentemente da come sta il primo.
• Un canone di manutenzione applicativa copre di norma la correzione, non l’evoluzione. La riga di confine sta nel contratto e va letta prima del rinnovo, perché è la riga che decide quanto costeranno i prossimi due anni.
• Il costo cresce anche stando fermi: la tariffa oraria per un intervento specialistico su una release fuori supporto è più alta di quella su una supportata, e la differenza aumenta ogni anno per una ragione demografica prima che tecnica.
• Il confronto corretto con una migrazione mette il costo totale sull’orizzonte di piano dell’azienda, di solito cinque anni, con dentro tutte e cinque le voci. Non il canone annuo contro il prezzo del progetto.

Negli interventi di manutenzione su gestionali AS/400 seguiti da Obsidian Technologies la parte di tempo che si spende a ricostruire cosa è agganciato al sistema supera regolarmente quella che si spende a modificare il programma richiesto, perché il censimento delle integrazioni non esiste quasi mai in forma scritta.

Le cinque voci, e chi le fattura

Le prime quattro si vedono. La quinta si vede il giorno in cui la persona che sapeva come funziona non risponde più al telefono.

1. Manutenzione software IBM

Copre il diritto a scaricare le PTF e ad aprire ticket sulla release. IBM non pubblica un listino: il prezzo dipende dal modello di macchina, dal numero di core attivati e dal contratto in essere, quindi la cifra vera la dà solo il rivenditore.

Due cose contano più del prezzo. La prima è che questo contratto è legato alla release, non alla macchina: quando una release esce dal supporto standard, la manutenzione ordinaria non la copre più e serve un contratto di estensione separato e più caro. È quello che succede a IBM i 7.4 dal 30 settembre 2026, e ne abbiamo scritto la matrice completa nell’articolo su IBM i 7.4 fuori supporto.

La seconda è che la voce è quasi sempre sottostimata nei ragionamenti interni, perché viene pagata una volta all’anno e finisce in un capitolo di bilancio che nessuno riapre.

2. Manutenzione hardware

È un contratto diverso, con una scadenza diversa, potenzialmente con un fornitore diverso. Copre i ricambi e l’intervento on-site entro tempi contrattuali.

Qui l’errore ricorrente è di aver guardato una sola delle due date. Una macchina Power9 scale-out è uscita dal supporto standard hardware il 31 gennaio 2026: chi ha aggiornato il sistema operativo pensando di essersi messo in regola ha il software supportato e il ferro no. Sono due caselle e vanno spuntate separatamente.

3. Manutenzione applicativa

È il canone che tutti conoscono, e la voce su cui si negozia. Nella pratica italiana prende due forme.

Canone fisso con monte ore incluso. Un importo mensile che comprende un numero di ore di intervento, con le ore eccedenti a tariffa. È la forma più diffusa e la più leggibile: si sa cosa si compra.

Canone a percentuale sul valore del progetto originario. Convenzione presa dal software di licenza standard, dove il 18-22% annuo è prassi consolidata. Su un gestionale custom scritto vent’anni fa quella percentuale non ha una base: il valore del progetto originario è un numero storico che non descrive più né la dimensione né la fragilità del codice attuale.

Quello che serve sapere prima di rinnovare non è il prezzo, è il perimetro. Vedi la sezione seguente.

4. Licenze di terze parti

È la voce che sorprende, perché sotto un’etichetta sola si nasconde una collezione stratificata in vent’anni.

Su un IBM i in produzione da vent’anni si trovano quasi sempre un prodotto di backup, uno di generazione e archiviazione PDF dello spool, un emulatore di terminale con licenze per postazione, spesso un tool di reportistica, a volte un prodotto di alta affidabilità o replica, e i connettori verso l’esterno (EDI, fatturazione elettronica, gestione documentale).

Ognuno ha il suo rinnovo, il suo fornitore e la sua data. Sommati arrivano regolarmente a superare il canone applicativo, e quasi nessuna azienda ha l’elenco completo in un unico foglio. Costruirlo richiede mezza giornata e cambia il ragionamento sul totale.

5. Le competenze

Non compare su nessuna fattura, ed è la voce che pesa di più. Il modo corretto di metterla a bilancio è chiedersi quanto costerebbe sostituirla.

Il mercato italiano di chi amministra IBM i e scrive RPG non si sta allargando, e la fascia anagrafica di chi lo fa da vent’anni è quella che si avvicina alla pensione. La conseguenza pratica si vede già oggi nelle tariffe: un intervento specialistico su una release fuori supporto costa più di uno su una release supportata, per la ragione banale che meno persone accettano di prenderlo in carico.

Questa voce si comporta diversamente da tutte le altre. Le prime quattro crescono con l’inflazione. Questa cresce con la scarsità, quindi più in fretta, e non si può rinegoziare.

Cosa copre davvero un canone di manutenzione applicativa

È la riga che decide la spesa dei prossimi due anni, ed è quella che si legge meno.

Di norma è dentro:

• La correzione di malfunzionamenti su funzioni esistenti
• Il supporto telefonico entro orari definiti
• Gli adeguamenti normativi, ma solo se il contratto li nomina e solo per i tracciati che nomina
• Un monte ore di piccoli interventi, con il residuo che quasi mai si accumula sull’anno successivo

Di norma è fuori:

• Ogni sviluppo evolutivo, cioè qualsiasi funzione che prima non c’era
• Le integrazioni nuove verso sistemi esterni
• L’aggiornamento di release del sistema operativo e le correzioni che ne derivano
• Il recupero dati dopo un incidente
• Il lavoro di performance tuning quando i volumi crescono

La domanda utile da fare al fornitore prima di firmare è una sola, e conviene farla per iscritto: “un adeguamento a una nuova specifica dell’Agenzia delle Entrate è correzione o evoluzione?”. La risposta dice più del prezzo, perché in cinque anni gli adeguamenti normativi arrivano comunque e la loro classificazione contrattuale sposta cifre che il canone non lascia intuire.

Il confronto che si fa male

Il modo sbagliato di impostarlo è mettere il canone annuo da una parte e il prezzo di una migrazione dall’altra. Sono due grandezze diverse: una è un flusso, l’altra è uno stock. Confrontarle direttamente fa sempre vincere il canone, qualunque sia la situazione reale.

Il modo corretto è fissare l’orizzonte di piano dell’azienda, di solito cinque anni, e sommare su quell’orizzonte tutte e cinque le voci nei due scenari.

Nello scenario si resta, le cinque voci vanno proiettate crescenti: la manutenzione software diventa contratto di estensione quando la release esce dal supporto, l’hardware richiede la sua estensione o la sostituzione, le licenze terze aumentano con i rinnovi, e la voce competenze cresce più delle altre.

Nello scenario si migra, il costo del progetto va sommato al fatto che le voci di manutenzione non si azzerano, cambiano natura: il sistema nuovo ha il suo canone, le sue licenze e le sue competenze. Chi presenta una migrazione come la fine dei costi di mantenimento sta vendendo, e chi la valuta così resta deluso a diciotto mesi.

I tempi di ciascuna strategia, che sono l’altra metà del conto, li abbiamo messi in fila in quanto tempo serve per migrare un AS/400, e le cinque strategie possibili nella guida alla migrazione AS/400.

Errori che vediamo fare

1. Confrontare il canone con il prezzo del progetto. È l’errore di impostazione descritto sopra, ed è quello che tiene fermi i sistemi più a lungo di quanto l’azienda avrebbe deciso guardando i numeri completi.

2. Non avere l’elenco delle licenze di terze parti. Senza quell’elenco il totale della voce 4 è sconosciuto, e in parecchi casi è la seconda voce per dimensione. Si costruisce guardando i rinnovi degli ultimi ventiquattro mesi in contabilità, non chiedendo all’IT.

3. Confondere manutenzione software e manutenzione hardware. Due contratti, due date. La confusione è particolarmente cara su Power9, dove le due date distano sette mesi.

4. Trattare la voce competenze come non quantificabile. È quantificabile: si stima quanto costerebbe l’affiancamento per trasferire la conoscenza a una seconda persona, e quel numero, che di solito nessuno ha mai messo per iscritto, è il costo che l’azienda sta correndo scoperta ogni giorno.

5. Rinnovare senza rileggere il perimetro. Il canone si rinnova tacito e il perimetro resta quello negoziato anni fa, quando il sistema aveva meno integrazioni e meno vincoli normativi. La rilettura costa un’ora.

FAQ

Qual è la voce più grossa nella spesa annua di un AS/400?

Dipende dall’installazione, e nella maggior parte dei casi che vediamo non è il canone applicativo. Su sistemi in produzione da oltre quindici anni la somma delle licenze di terze parti supera spesso il canone, e la voce competenze, se la si quantifica, supera entrambe.

Il canone di manutenzione copre l’aggiornamento di release?

Quasi mai. L’aggiornamento del sistema operativo è un progetto a sé, con assessment, test su partizione separata e finestra di fermo. I contratti che lo includono lo dicono esplicitamente, e sono una minoranza.

Conviene portare la manutenzione applicativa in casa?

Solo se in casa c’è già più di una persona che conosce il sistema. Con una persona sola si sposta il costo dal canone al rischio, e il rischio è peggiore perché non ha un tetto contrattuale.

Quanto costa la manutenzione software IBM?

Non c’è un listino pubblico. Dipende dal modello, dai core attivati e dal contratto in essere, e la cifra la dà il rivenditore IBM. Conviene chiederla insieme al costo dell’eventuale contratto di estensione, perché è il confronto fra i due numeri a rendere confrontabili le opzioni.

Un sistema fuori supporto costa di più da mantenere?

Sì, e in due modi. Il contratto di estensione costa più della manutenzione ordinaria, e la tariffa oraria degli interventi specialistici su release non supportate è più alta perché meno fornitori le prendono in carico. Il secondo effetto è quello che cresce nel tempo.

Come si fa il censimento delle integrazioni?

Partendo dai job schedulati e dalle code di uscita, non dalla memoria delle persone. Quello che manda file, riceve file, stampa o chiama qualcosa fuori dal sistema compare lì. È la stessa attività che serve prima di un aggiornamento di release, quindi vale la pena farla una volta e tenerla aggiornata.

Le tre cifre da avere prima di rinnovare

La spesa di un gestionale AS/400 non si conosce guardando la fattura che si conosce meglio. Si conosce mettendo insieme cinque voci che arrivano da fornitori diversi in mesi diversi dell’anno, e due delle cinque non arrivano affatto.

Tre numeri rendono la decisione possibile, e si recuperano tutti e tre in una settimana: il costo annuo della manutenzione software chiesto al rivenditore, il totale dei rinnovi di terze parti letto in contabilità sugli ultimi ventiquattro mesi, e il costo stimato di affiancare una seconda persona su quel sistema. Con questi tre, il confronto fra restare e muoversi si fa in una riunione. Senza, si rimanda, ed è quello che succede da anni.

Se avete un IBM i in produzione e volete il conto completo del vostro caso invece di una stima, parliamone. L’assessment produce le cinque voci con i numeri vostri, e serve comunque, qualunque sia poi la decisione.

Per approfondire: la pagina migrazione AS/400 verso il cloud per il confronto sul modello di costo, e il pilastro modernizzazione dei sistemi legacy.

Fonti: la documentazione IBM su pianificazione dell’aggiornamento a IBM i 7.5 per i requisiti di release, e IT Jungle per il ritiro della 7.4. Le date di supporto sono verificate al 21 agosto 2026 e vanno riverificate prima di decisioni di spesa.