What it costs to keep an AS/400 ERP running, and what the fee covers

The question almost always arrives in the same shape: “what does the AS/400 cost us per year?”. And the answer circulating inside the company is almost always a single figure, the one on the invoice from the supplier who looks after the ERP.

That figure is true and incomplete. On a production IBM i the cost lines are five, they come from three different suppliers with different renewal dates, and the two heaviest appear on no invoice at all. Comparing the cost of keeping against the cost of replacing using only the application fee compares one fifth of the spend against the whole of the alternative, and the conclusion comes out wrong by construction.

This article lists the five lines, explains what an application maintenance contract does and does not cover, and puts the comparison in the form where a decision can be made.

TL;DR

• The annual spend of an AS/400 ERP has five lines: IBM software maintenance, hardware maintenance, application maintenance, third-party licences, in-house skills.
• The application fee is the one everyone knows, and it is rarely the largest. Third-party licences accumulated over twenty years, and the cost of skills, weigh more, and nobody ever adds them up.
• Software maintenance and hardware maintenance are two separate contracts, with two separate expiry dates. On a Power9 machine the second has been out of standard support since 31 January 2026, whatever state the first is in.
• An application maintenance contract normally covers correction, not evolution. The boundary sits in the contract and needs reading before renewal, because it is the line that decides what the next two years will cost.
• The cost grows even while standing still: the hourly rate for specialist work on an out-of-support release is higher than on a supported one, and the gap widens every year for a demographic reason before a technical one.
• The correct comparison against a migration takes total cost across the company planning horizon, usually five years, with all five lines inside it. Not annual fee against project price.

In AS/400 maintenance work handled by Obsidian Technologies, the time spent reconstructing what is attached to the system regularly exceeds the time spent changing the program that was actually requested, because a written inventory of the integrations almost never exists.

The five lines, and who invoices them

The first four are visible. The fifth becomes visible on the day the person who knew how it worked stops answering the phone.

1. IBM software maintenance

It covers the right to download PTFs and to open tickets against the release. IBM publishes no list price: the figure depends on the machine model, the number of activated cores and the contract in place, so only the reseller can give the real number.

Two things matter more than the price. The first is that this contract is tied to the release, not to the machine: when a release leaves standard support, ordinary maintenance no longer covers it and a separate, more expensive extension contract is required. That is what happens to IBM i 7.4 from 30 September 2026, and we set out the full matrix in the article on IBM i 7.4 leaving support.

The second is that this line is almost always underestimated in internal reasoning, because it is paid once a year and lands in a budget chapter nobody reopens.

2. Hardware maintenance

A different contract, a different expiry date, potentially a different supplier. It covers spare parts and on-site intervention within contracted times.

The recurring mistake here is having looked at only one of the two dates. A Power9 scale-out machine left standard hardware support on 31 January 2026: a company that upgraded the operating system believing it had put itself in order has the software supported and the iron not. Two boxes, ticked separately.

3. Application maintenance

This is the fee everyone knows, and the one that gets negotiated. In Italian practice it takes two shapes.

Fixed fee with an included hours allowance. A monthly amount covering a number of intervention hours, with anything beyond charged at a rate. It is the most common shape and the most legible: you know what you are buying.

Fee as a percentage of the original project value. A convention borrowed from standard licensed software, where 18-22% per year is settled practice. On a custom ERP written twenty years ago that percentage has no basis: the original project value is a historical number that no longer describes either the size or the fragility of the current code.

What you need to know before renewing is not the price, it is the scope. See the section below.

4. Third-party licences

This is the line that surprises, because under a single label sits a collection that has been accumulating for twenty years.

On an IBM i in production for two decades you will almost always find a backup product, something that generates and archives PDFs from spool, a terminal emulator licensed per seat, often a reporting tool, sometimes a high availability or replication product, and the connectors facing outward (EDI, electronic invoicing, document management).

Each has its own renewal, its own supplier and its own date. Added together they regularly exceed the application fee, and almost no company holds the complete list in one place. Building it takes half a day and changes the arithmetic of the total.

5. Skills

This one appears on no invoice, and it is the line that weighs most. The correct way to put it in the budget is to ask what replacing it would cost.

The Italian market of people who administer IBM i and write RPG is not widening, and the age bracket of those who have done it for twenty years is the one approaching retirement. The practical consequence is already visible in rates: specialist work on an out-of-support release costs more than the same work on a supported one, for the plain reason that fewer people will take it on.

This line behaves differently from all the others. The first four grow with inflation. This one grows with scarcity, so faster, and it cannot be renegotiated.

What an application maintenance contract actually covers

This is the clause that decides the next two years of spend, and it is the one that gets read least.

Normally inside:

• Correction of malfunctions in existing functions
• Telephone support within defined hours
• Regulatory adjustments, but only if the contract names them and only for the formats it names
• An allowance of hours for small work, with unused hours almost never carrying into the following year

Normally outside:

• Any evolutionary development, meaning any function that did not exist before
• New integrations towards external systems
• Operating system release upgrades and the corrections arising from them
• Data recovery after an incident
• Performance tuning work when volumes grow

The useful question to put to the supplier before signing is a single one, and it is worth putting in writing: “is an adjustment to a new tax authority specification correction or evolution?”. The answer tells you more than the price, because over five years regulatory adjustments arrive regardless, and how the contract classifies them moves figures the fee gives no hint of.

The comparison people get wrong

The wrong way to frame it is annual fee on one side, migration price on the other. These are different quantities: one is a flow, the other a stock. Comparing them directly always makes the fee win, whatever the real situation.

The correct way is to fix the company planning horizon, usually five years, and total all five lines across that horizon under both scenarios.

Under stay, the five lines have to be projected upward: software maintenance becomes an extension contract once the release leaves support, hardware needs its own extension or replacement, third-party licences rise at renewal, and the skills line grows faster than the rest.

Under move, the project cost has to be added to the fact that maintenance lines do not go to zero, they change nature: the new system has its own fee, its own licences and its own skills. Anyone presenting a migration as the end of running costs is selling, and anyone evaluating it that way is disappointed at eighteen months.

The timelines for each strategy, which are the other half of the arithmetic, are set out in how long an AS/400 migration takes, and the five available strategies in the AS/400 migration guide.

Mistakes we see

1. Comparing the fee against the project price. The framing error described above, and the one that keeps systems running longer than the company would have chosen had it seen the complete figures.

2. Having no list of third-party licences. Without that list the total of line 4 is unknown, and in plenty of cases it is the second largest line. It gets built by looking at the last twenty-four months of renewals in the accounts, not by asking IT.

3. Confusing software maintenance with hardware maintenance. Two contracts, two dates. The confusion is particularly expensive on Power9, where the two dates sit seven months apart.

4. Treating the skills line as unquantifiable. It is quantifiable: estimate what it would cost to run a handover transferring the knowledge to a second person. That number, which usually nobody has ever written down, is the exposure the company carries every day.

5. Renewing without rereading the scope. The fee renews tacitly and the scope stays as it was negotiated years ago, when the system had fewer integrations and fewer regulatory constraints. Rereading it costs an hour.

FAQ

Which is the largest line in the annual spend of an AS/400?

It depends on the installation, and in most cases we see it is not the application fee. On systems in production for more than fifteen years the sum of third-party licences often exceeds the fee, and the skills line, once quantified, exceeds both.

Does the maintenance fee cover release upgrades?

Almost never. An operating system upgrade is a project in its own right, with assessment, testing on a separate partition and a cutover window. Contracts that include it say so explicitly, and they are a minority.

Is it better to bring application maintenance in-house?

Only if more than one person in-house already knows the system. With a single person you move the cost from the fee to the risk, and the risk is worse because it has no contractual ceiling.

What does IBM software maintenance cost?

There is no public list price. It depends on the model, the activated cores and the contract in place, and the reseller gives the figure. It is worth asking for it alongside the cost of any extension contract, because comparing those two numbers is what makes the options comparable.

Does an out-of-support system cost more to maintain?

Yes, in two ways. The extension contract costs more than ordinary maintenance, and the hourly rate for specialist work on unsupported releases is higher because fewer suppliers will take it on. The second effect is the one that compounds.

How do you inventory the integrations?

Starting from scheduled jobs and output queues, not from what people remember. Anything that sends files, receives files, prints or calls something outside the system shows up there. It is the same activity needed before a release upgrade, so it is worth doing once and keeping current.

The three figures to have before renewing

The spend of an AS/400 ERP does not become visible from the invoice you know best. It becomes visible by assembling five lines that arrive from different suppliers in different months, two of which never arrive at all.

Three numbers make the decision possible, and all three can be recovered in a week: the annual software maintenance cost asked of the reseller, the total of third-party renewals read from the accounts over the last twenty-four months, and the estimated cost of running a handover to a second person on that system. With those three, the choice between staying and moving takes one meeting. Without them it gets postponed, which is what has been happening for years.

If you run an IBM i in production and want the complete arithmetic for your case rather than an estimate, let’s talk. The assessment produces the five lines with your own numbers, and it is needed regardless of what gets decided afterwards.

Further reading: the AS/400 cloud migration page for the cost model comparison, and the legacy systems modernization pillar.

Sources: IBM documentation on planning an upgrade to IBM i 7.5 for release requirements, and IT Jungle for the 7.4 withdrawal. Support dates verified on 21 August 2026 and worth reverifying before spending decisions.