News

IBM i Support in 2026: The Skills Cliff, Not Uptime

Ask an IT director about IBM i support risk, and the discussion usually starts with uptime, aging hardware, and disaster recovery. Those risks are easy to define. They have owners, budgets, and action plans. The risk that often gets overlooked is harder to quantify. It has a name, and in many cases, a leaving date. 

The platform’s reliability is part of the reason this risk has grown. When a system runs for years without a serious incident, there is little pressure to document how it works or share responsibility for running it. There may be no second person who has handled a recovery. Over time, critical knowledge ends up with one administrator because nothing required the organization to spread it. 

The Test That Reveals Your Real iSeries Support Position 

Four questions can tell you more about your actual position than a risk register: 

  1. If tonight’s save fails, who investigates it? Has that person handled one before? 
  1. If a user loses access to a critical library, who can diagnose the authority problem? 
  1. When the next release upgrade is due, who will plan it? Has that person managed an upgrade before? 
  1. If your primary administrator resigned tomorrow, how long would it take to restore your confidence in the system? 

In many organizations, the same person answers all four questions. In some cases, nobody can answer the third. The last upgrade may have been handled by a contractor, with the notes never making it into the organization’s documentation. 

That is not an uptime problem. More hardware redundancy will not solve it. It is also not something most IBM AS400 support agreements are designed to address. 

Why the Skills Cliff Is Steeper Than the Hiring Market Suggests 

IBM i administrators can still be hired. The harder part is finding someone who understands the details of your particular environment. 

That person may know which nightly jobs have to run first, why a subsystem has an unusual configuration, how to work around an interface that fails twice a year, or which alerts can safely be ignored. Those details rarely appear in a job description, and they are not something a new hire can learn simply by knowing IBM i. 

The good news is that much of this knowledge is procedural rather than architectural. An operational runbook can be rebuilt in weeks if someone shadows the current administrator and documents the work as it happens. The challenge is getting that work started. The person with the knowledge is usually busy keeping the system running, so documentation keeps getting pushed down the list. 

The One IBM AS400 Maintenance Risk with a Date on It 

Release currency is where the skills problem becomes more urgent. IBM has set 30 September 2026 as the end of standard support for IBM i 7.4. After that, coverage continues through a paid Service Extension with a narrower scope and no enhancements. IBM i 7.3 reached the same milestone in September 2023. Check your position against IBM’s lifecycle page, since support dates and available options can change. 

For someone who has performed the work before, an upgrade is routine IBM AS400 maintenance. The problem is that upgrades do not happen often enough for every administrator to have recent experience with them. If nobody is confident about planning the move, the organization can reach the support deadline without a clear path forward. 

That is one way companies end up paying for a Service Extension. It may not be the option they wanted. It becomes the option they can execute because nobody is ready to manage the upgrade safely in time. 

There is also an opportunity to address other gaps during the upgrade. IBM i 7.6, generally available since April 2025 on Power10 and Power11, includes multifactor authentication built into the operating system, according to IBM’s enhancement notes. For organizations dealing with authentication and control concerns, that can be worth factoring into the upgrade discussion. 

What Should Be in Scope for IBM AS400 Maintenance 

IBM iSeries support is often compared by response times. Response time matters, but it does not tell you how exposed the environment is. Coverage depth and documentation give you a better view of that risk. 

An IBM AS400 maintenance arrangement should include: 

  • An operational runbook that documents the job schedule, dependencies, save and recovery procedures, and known workarounds. 
  • Named coverage with a designated second person who can step in when the primary resource is unavailable. 
  • Release and PTF currency management, with a defined plan and target date rather than a yearly reminder. 
  • Security and authority reviews covering dormant user profiles and excessive authorities. 
  • Save and recovery verification through a tested restore, not just confirmation that a backup job completed. 
  • Capacity and hardware lifecycle tracking, since the hardware can limit which releases you can run. 
  • A documented escalation path to IBM, with entitlement details stored somewhere other than one person’s inbox. 

The runbook deserves particular attention. If an IBM iSeries support proposal does not include documentation as a deliverable, you may simply be replacing one single point of failure with another. The provider becomes the only party that knows how the environment works. 

A Ninety-Day Plan If You Have Someone Retiring 

You do not necessarily need a large transformation program to address the knowledge gap. A focused 90-day effort can cover the most important areas while the current administrator is still available. 

  • Weeks 1 to 3: Shadow the daily and monthly operational routines. Document the steps, including the ones that seem obvious to the incumbent. 
  • Weeks 4 to 6: Perform a real restore in a test environment using the documented procedure. The incumbent should observe the process rather than carry it out. 
  • Weeks 7 to 9: Review user profiles, authorities, and dormant accounts. Document why unusual configurations exist instead of recording only what they are. 
  • Weeks 10 to 12: Plan the next release upgrade with the incumbent involved. The actual upgrade can happen later, but the plan should be documented while the person who knows the environment can still review and correct it. 

The restore in weeks four to six is especially important. It is often skipped, yet it is where undocumented gaps become visible. A recovery procedure that nobody has actually followed is still only a hypothesis. 

Frequently Asked Questions 

Our System Has Not Failed in Years. Is This Really Urgent? 

The absence of failure is what created the exposure, because it removed every prompt to document, rotate or rehearse. The urgency comes from the retirement date of the person who holds the knowledge and from the 2026 release support deadline, neither of which is affected by how stable the platform has been. 

Should We Hire or Use a Managed Service? 

Either works. For IBM AS400 support, the deciding factor is usually whether you have enough continuous work to keep a specialist engaged and current. Where the estate is stable, a hire can end up underutilized and hard to retain. Where you do hire, still contract for documentation, because a single internal specialist is the same concentration risk with a different name on it. 

What Does IBM System i Support Cost? 

IBM System i support pricing varies with estate size, coverage hours and whether development capacity is included, so treat any figure quoted before an assessment as indicative. The more useful comparison is what you are buying: hours of availability, or coverage plus documentation and release currency. Those are different products at similar prices. 

Can We Delay the Release Upgrade Past September 2026? 

Yes, through Service Extension, at additional cost and with a narrower scope that excludes enhancements. It is a reasonable bridge if you are mid-project or waiting on a software vendor to certify a release. It is an expensive default if the reason is that nobody feels able to plan the upgrade. 

How Do We Convince the Board This Matters? 

Present the four-question test with real names in the answers. A risk register entry about legacy technology invites debate; a slide showing that one named individual is the sole answer to every operational question, and that they retire in eighteen months, does not. 

The platform will keep running. Whether anyone knows how to run it is a separate question, and it is the one worth budgeting for this year.  

Share this