Three clocks run under the phrase "AS/400 end of life." Most migration quotes price one of them and call it the project.
The first clock sits under the machine. IBM publishes a support date for the Power model in your rack. The second clock sits in the operating system. Every IBM i release carries a published end of support date, and yours is on that list. The third clock has no publisher. It runs on the retirement date of the developer who is the only person left who can read your billing programs.
Each clock buys a different project at a different price. Read the three as one date and you approve a budget for the cheapest of them.
What AS400 end of life means on your system
IBM has never announced an end of life for the platform. The AS/400 became the iSeries and then the System i. The operating system now carries the name IBM i and runs on Power hardware. Your programs came through every one of those renames intact. That continuity is the reason a program written in 1994 still compiles today.
So when a search for AS400 end of life returns a date, ask what the date belongs to. Two answers cover most of them. The date belongs to a hardware model, or it belongs to an operating system release. A third case arrives by letter, when a software vendor drops support for older IBM i releases of its own product.
IBM publishes the first two dates, and the tables below carry what IBM published as of 23 August 2026. Your team still reads the machine type and the release level off your own system to use them. Nobody publishes the third date at all.
The words IBM uses, and why a quote can hide behind them
IBM runs more than one lifecycle term at once, and a quote built on the wrong term prices the wrong project. The wording below is IBM's own, taken from IBM's product lifecycle page for the Power S924 and from IBM's Service Extension document for IBM i, both read on 23 August 2026.
| IBM's term | IBM's own wording | Where it applies |
|---|---|---|
| End of marketing (EOM) | "The date upon which the IBM offering will no longer be actively sold (no new sales or orders)." | Power hardware and IBM i releases |
| End of support (EOS) | "The last date on which IBM will deliver standard support services for the offering." | Power hardware and IBM i releases |
| End of support, on hardware | "technical and field (parts) support are no longer provided, and all expert remote support for the system is withdrawn" | Power servers |
| End of support, on software | "service or support for a specific release or version of the offering is no longer provided" | IBM i releases |
| Service Extension | "Basic usage and problem rediscovery support for specified out-of-service IBM i product releases" | IBM i releases only |
IBM's own material carries second names for the same events. Announcement letters say withdrawal from marketing where the lifecycle pages say end of marketing. IBM's POWER8 article says end of service where the lifecycle pages say end of support. Each pair names one event, and a third variant, End of Standard Service, turns up in IBM's POWER9 notice.
One phrase in circulation is not IBM's at all. Vendors write withdrawal from service, and that wording appears in none of IBM's withdrawal announcement letters. IBM titles those letters Services withdrawal and heads the column EoS effective date, or End of Standard Service on letters from 2025 onward. A quote leaning on withdrawal from service is quoting nobody, so ask which IBM date it means before you sign.
Keep Service Extension in its own box. It covers IBM i software only. Power hardware carries no equivalent offering, and an extended maintenance contract covers that side.
Clock one: the Power hardware under the partition
Every Power model carries two IBM dates. The first one ends new orders for that model. The second one ends IBM hardware support, and that is the date that reaches your operations team, because it ends the agreement that puts a replacement part on a truck when a disk fails.
The table below lists the models an AS/400 shop is most likely to still be running. Every row comes off IBM's product lifecycle pages, read on 23 August 2026, where IBM heads the column "Transition to End of Support Services".
| Power generation | Model and machine type | IBM's term | Date IBM publishes |
|---|---|---|---|
| POWER7 | 720 (8202-E4B), 740 (8205-E6B), 770 (9117-MMB), 780 (9179-MHB) | End of support | 30 September 2019 |
| POWER7+ | 710 (8231-E1D), 720 (8202-E4D), 770 (9117-MMD), 780 (9179-MHD) | End of support | 31 December 2020 |
| POWER7 | 795 (9119-FHB) | End of support | 31 December 2020 |
| POWER8 | S822 (8284-22A), S824 (8286-42A) | End of support | 31 March 2024 |
| POWER8 | S814 (8286-41A) | End of support | 31 May 2024 |
| POWER8 | E870 (9119-MME), E880 (9119-MHE) | End of support | 31 October 2024 |
| POWER9 | S914 (9009-41A), S922 (9009-22A), S924 (9009-42A) | End of support | 31 January 2026 |
| POWER9 | E980 (9080-M9S) | End of support | 31 December 2027 |
| POWER10 | S1022 (9105-22A), S1024 (9105-42A), E1080 (9080-HEX), E1050 (9043-MRX) | End of support | No date published |
The POWER9 row is the one that bites this year. IBM set that date in a notice of its own, Upcoming Changes to Power9 Maintenance Services, dated 12 September 2024, and wrote that afterward IBM "no longer provides preventive service, new updates or fixes." That date passed on 31 January 2026. A shop still running an S914 or an S924 sits outside IBM hardware support today.
IBM published the POWER8 dates in an article of its own, IBM Power8 end of service. IBM wrote there that the affected servers "will no longer receive full IBM maintenance services." An unsupported box keeps running. It stops receiving the patches an auditor asks about.
POWER10 has no published end of support date. IBM's lifecycle page for the Power E1050 shows a general availability date of 22 July 2022 and nothing after it. The POWER11 pages IBM opened in July 2025 read the same way.
Find the machine type and model on the system before you trust any row above. IBM keys every date to a machine type, and a model number that looks close belongs to a different machine. Read your maintenance agreement next and write down the date the coverage stops. A third-party maintainer can carry a box well past IBM's date, and that arrangement has an end date of its own.
This clock prices the smallest of the three projects. Your team moves the partition onto newer hardware in your own room, or onto a hosted partition somewhere else. The RPG source arrives unchanged on either path. Nobody has to read a single program to price the work.
Clock two: the IBM i release running on that partition
IBM supports each IBM i release for a published period and then stops. Your team can read the current release straight off the system in a few seconds. IBM prints the rest on one page.
The table below comes off IBM's Release life cycle page. IBM last modified that page on 3 March 2026, and these rows read as of 23 August 2026. IBM heads the support column "Change in Service Level" and defines that heading in a footnote as the date of change from the standard support period to extended support.
| IBM i release | IBM's term | Date IBM publishes | Service Extension |
|---|---|---|---|
| 7.1 | End of support | 30 April 2018 | Ended 30 April 2024 |
| 7.2 | End of support | 30 April 2021 | Ended 30 April 2026 |
| 7.3 | End of support | 30 September 2023 | Through 30 September 2028 |
| 7.4 | End of support | 30 September 2026 | 1 October 2026 through 30 September 2029 |
| 7.5 | End of support | Not announced | Not announced |
| 7.6 | End of support | Not announced | Not announced |
Two rows carry a deadline inside this budget year. IBM stopped selling 7.4 on 30 April 2026 and ends support for it on 30 September 2026. The 7.2 Service Extension ended on 30 April 2026, and a 7.2 partition now runs with nothing behind it from IBM.
IBM has announced no end of support date for 7.5 or 7.6. IBM's footnote promises that the date "will be announced with at least 12 months' notice prior to the effective termination date." A shop on either release has a year of warning coming.
What actually changes on the support date is narrower than most quotes claim. IBM's own support roadmap says a shop with active software maintenance can still download existing program temporary fixes from Fix Central after the date passes. New defects are the gap. Report a fresh problem on an out-of-service release without a Service Extension and IBM does not take the case. A vulnerability found next year gets no fix.
Your software vendors certify their products against supported releases, and their support desks begin declining tickets from shops that have fallen behind. An auditor who asks whether your operating system is supported gets an answer nobody wants to put in writing.
IBM sells Service Extension on some releases past the standard date. Price that option before you assume it. Service Extension keeps defect support flowing for a defined window, and it does nothing about the software vendors who have already moved on.
An upgrade is real work with real testing. Programs compiled decades ago usually survive a release change without a source edit. The risk sits in the products around them. Your ISV licenses and your custom exit programs both need a pass on the new release before anybody schedules a cutover.
The hardware clock and the software clock couple here, and IBM states the coupling in the same roadmap. IBM i 7.4 is the last release that supports POWER8 systems. IBM i 7.3 is the last release that supports POWER7 and POWER7+ systems. Both of those releases sit at or past their end of support date, so a POWER8 shop cannot answer clock two without also answering clock one. That is one project with two invoices.
Clock three: the developer who can still read the code
No vendor publishes this date. It sits in your HR system, and it is the retirement date of the person who wrote the order entry suite.
The pattern in an RPG shop is consistent enough to describe from the outside. One or two developers hold the working model of how the whole system fits together. They built that model by maintaining the system for twenty years. Nothing in the source names them. Nothing in the documentation replaces them. We covered the hiring side of this problem in IBM i modernization in 2026.
When that person leaves, the code stays and the map goes with them. A new developer can learn to read RPG after training. Reading RPG and knowing why the nightly job runs in that exact order are two different skills, and only one of them comes from a class.
Ask the question directly and the date usually surprises the room. Most senior RPG developers have a year in mind and have never been asked for it. The answer converts an anxiety into a planning input, and it costs one conversation.
This clock prices the largest of the three projects, and it is the only one with no deadline printed anywhere. Your team sets the date by asking the person.
Why one quote for all three clocks costs you twice
A hosting vendor prices clock one. Read the questionnaire and the shape gives it away. It asks for processor cores, disk capacity, user counts and the current release. Every answer comes off a system value or an invoice.
An upgrade partner prices clock two. That team wants your release level and your ISV inventory, and the estimate turns on testing effort.
Nobody prices clock three from a questionnaire, because pricing it starts with reading the source. That is the work most quotes leave out, and it is the work that produces change orders after the contract is signed. Our page on IBM i modernization cost walks through the drivers that actually move the number.
The cost of the code work never comes from a program count alone. Four thousand programs where nothing calls half of them is a smaller job than eight hundred programs wired together through copy members nobody has resolved since the last upgrade.
Put your three dates on one page before you call anybody
Five lines produce a real budget conversation. Your team can finish this list today.
- Record the machine type and model, then read its end of support date off the hardware table above or off IBM's product lifecycle search.
- Record the current IBM i release, then read its end of support date off the release table above.
- Read the maintenance agreement and write down the date the coverage stops.
- Ask each developer who can read RPG on your system when they plan to retire.
- Count the programs in your production libraries from the library listing itself.
The first four lines take a morning now that two of the dates are printed here. The fifth line is where most teams discover that the number in everyone's head has been wrong for years. A library listing counts objects. It does not tell you which of those objects anything still calls, and that gap is the whole reason budgets slip.
What the source has to tell you before a budget becomes real
Two of your three dates now sit in the tables above. The third comes off your own code, and no team reads four thousand programs by opening them one at a time. The practical method ingests the whole source library in one pass and builds the map from what the source says.
AS/Forward does that pass. It reads six RPG dialects through a proprietary ingestion layer, then builds an interconnection graph across every program, file, copy member and display file it finds. From that structure it generates a plain-English description of each program. Because the description comes from the ingested source, a developer can open the member and check it.
The pass also reports what it could not read. Unresolved copy members and missing dependencies land on the program page as warnings. A readiness status shows how confident the ingestion layer is in each program it read. Clean programs move forward, and your developers spend their hours on the exceptions.
Two of the outputs change a budget directly. The graph names every program that nothing calls, and nobody should pay to convert dead code. The migration view scopes one change at a time: pick a field or an object, and the view lists what else moves with it.
Where your source sits during that pass is the next question a regulated shop asks. The preferred deployment runs air-gapped inside your own infrastructure, and nothing leaves your network. AS/Forward carries one US patent pending. Golden Path Digital tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories.
Which clock should set your budget year
Take the earliest of the three and work backward from it.
Most teams find the hardware date first, and hardware carries the loudest failure. A disk fails on an unsupported model and the business waits on a parts search that nobody can put a time on.
The release date usually lands second. An upgrade is a project your team can schedule and test on a calendar, and that makes it the easiest of the three to defend in a budget meeting.
The developer date is the quiet one. It arrives on a Friday with a cake, and by Monday the map is gone. Nothing breaks that day. Every estimate after it gets softer, and every change request takes a week longer than the last one.
IBM revises these pages, so check both tables against IBM's own listing before you commit money to a date. An AS/Forward assessment then reads your production libraries and hands your team the program count, the dependency graph, the plain-English descriptions and the list of what nothing calls. Put that beside your two IBM dates and the budget stops being an argument about assumptions. Call Golden Path Digital at 501-232-7188 and tell us which of your three clocks runs out first.