IBM i end-of-life announcements often create a predictable pause inside mid-market IT departments. ISV fees, upgrade costs, support options, and migration timelines can arrive at once.

That combination can make the IBM i end-of-life decision tree difficult to navigate. Once each cost and support option is clear, however, the path forward becomes much easier to evaluate.

IBM i End-of-Life and Its Effect on Your Environment

IBM typically describes this milestone as the end of standard support for a specific IBM i release. It changes the support model rather than causing the operating system itself to stop working.

IBM i 7.4 reaches the end of standard support on September 30, 2026. A Service Extension is available afterward for eligible 7.4 environments through September 30, 2029.

Service Extension can provide continued support beyond the standard lifecycle, although coverage and costs differ from regular Software Maintenance. That distinction matters when comparing an upgrade with another short-term support period.

IBM i environments running older software do not simply stop working when standard support ends. The operating system and business applications can continue running as they did before.

The practical question is how long that arrangement makes sense for your organization. Security maintenance, application support, IBM coverage, and long-term infrastructure plans all belong in that decision.

The Real Cost Behind an IBM i Upgrade Decision

Upgrading from one IBM i version to another involves more than the operating system itself. Every independent software vendor connected to the environment may have its own licensing requirements.

Some software vendors treat an operating system or infrastructure change as a licensing event. That can introduce transfer, upgrade, or support fees that materially change the project cost.

For a company planning to remain on IBM i for another decade, paying those fees to stay current may be a sound investment. The calculation can look different for an organization already planning to leave the platform.

Paying substantial transfer fees for another upgrade cycle may not make financial sense when a larger platform transition is already approaching. The practical answer is to get those figures in writing before choosing either path. Contact each ISV, document the costs, and then compare an on-premises upgrade with hosted IBM i.

In our experience, some software vendors may take one to three weeks to provide transfer fee information. In fact, I have seen some software vendors take months to respond. Starting early gives the team more time to compare both paths carefully.

We explored this issue in more depth in our post about how ISV transfer fees can impact IBM i cloud migrations.

Extended Support as a Short-Term Bridge

Between standard support and a full upgrade, IBM Service Extension can give organizations more time to complete their plans.

For eligible IBM i releases and products, a Service Extension can include support for new defects and general product usage. Exact coverage depends on the operating system release and installed products.

That additional period can be valuable when an organization needs more time for budgeting, software planning, or a larger infrastructure transition.

Service Extension still works best as part of a defined plan. Its value becomes easier to judge once the organization knows its expected timeline and upgrade costs.

Your team should determine how long additional support is needed and document the related Service Extension costs. The next step is confirming future ISV fees if an on-premises upgrade remains the preferred path. Finally, compare those costs with Cloud400 hosted IBM i over the same period.

Cloud Hosting Simplifies IBM i Version Management

One advantage of moving to hosted IBM i is the change in responsibility for hardware lifecycle, patch planning, and system administration.

Many mid-market organizations defer PTF updates because other IT concerns take priority when staff time is limited. Managed hosting gives those maintenance tasks a more structured process.

When Source Data hosts an IBM i environment on Cloud400, patching becomes a scheduled and collaborative activity with the client. Our team does not apply patches automatically without first confirming the update with the client. We confirm the schedule, review application compatibility, and apply approved updates during a controlled maintenance window.

That process keeps IBM i maintenance consistent while giving the client visibility into each planned update. It also provides a clearer record for future security and audit reviews.

Bob Losey has guided thousands of organizations through the version decisions created by IBM i support changes. His experience includes more than 45 years in IBM midrange systems, beginning with IBM before he founded Source Data Products in 1979. 

Bob has also worked with more than 4,000 organizations and has maintained a Premier IBM Business Partner relationship since 1992.

"There has been a security software patch to the IBM operating system practically every month since January 7, 2021. When end of life hits, your access to security patches may stop. The exposure is real." – Bob Losey, Founder and President, Source Data Products

Our post about PTF debt covers the longer-term effects of falling behind on PTF updates.

IBM i Cloud Migration With Limited Operational Disruption

Downtime is a main concern for IBM i shops considering a move to hosted infrastructure. Source Data clients often report that the final transition is quieter than expected.

Our team typically begins the cutover process with a system save at the end of business Friday. We move the save to Source Data's Cloud400 hosting environment and restore it to a logical partition sized around the actual workload.

With the preparation completed beforehand, we can have the hosted environment ready for testing and production by early Saturday afternoon, the next day.

ISV licensing still needs to be settled before the move, and network connectivity still requires careful coordination. However, the final migration can be one of the smoother parts of the project when the technical and licensing work is completed beforehand.

Common Questions About IBM i End-of-Life Upgrade

What happens to my IBM i system when a version reaches end-of-life?

The IBM i operating system does not stop running when standard support ends. Instead, the available IBM support and fix options change for that release. Eligible releases may continue receiving additional coverage through IBM Service Extension. Organizations should review current support terms before deciding whether to upgrade or use extended coverage.

Is it safe to keep running IBM i on an unsupported version?

An older IBM i release can keep running after standard support ends, but support and maintenance options become more limited. The practical risk depends on the operating system version, available Service Extension coverage, installed applications, security requirements, and the organization's own risk policies.

What is IBM i Extended Software Support and when does it make sense?

IBM Service Extension provides additional support for eligible IBM i releases after their standard support period has ended. Coverage may include known-defect and usage support, depending on the release and installed IBM products on a best-efforts basis. It can make sense as a temporary bridge while an organization completes an upgrade, hosting migration, or larger platform transition.

Why do ISV transfer fees complicate the IBM i upgrade decision?

Some independent software vendors charge transfer, upgrade, or licensing fees when applications move to another IBM i environment or release. For organizations uncertain about their long-term IBM i plans, those charges can materially affect the economics of another on-premises upgrade. Getting those figures in writing early gives the team real numbers for comparing an upgrade with hosted IBM i.

How does cloud hosting change ongoing IBM i version management?

Hosted IBM i shifts much of the infrastructure and system-management workload to a team that handles these responsibilities regularly. Source Data coordinates patching with each client, reviews software compatibility, and schedules approved updates within controlled maintenance windows. That structure helps organizations keep maintenance consistent without taking control of important application decisions away from the internal IT team.

What does a typical IBM i cloud migration weekend look like?

After a validation and testing period ranging from a few weeks to 60 days, a typical Source Data migration schedules a weekend to move our client’s production from their on-premises server to Cloud400. Their system has been right-sized based on the client’s actual workload to host their environment with Logical Partition (aka LPAR). Our client conducts a system save after business operations finish on Friday and overnights us the backup media. We restore our client’s system by early Saturday afternoon, the next day.

How do I calculate whether to upgrade on-premises or move to hosted cloud?

Start with three figures: ISV fees, hardware and support costs, and hosted IBM i costs over the same planning period. Then compare the total cost of each path over the next three to five years, not just the initial project costs. We covered these costs in a recent post comparing cloud hosting to buying new hardware.

Map Your IBM i Path Ahead of the Support Date

If your IBM i environment runs 7.4 or an older release, now is a useful time to review your support position. Start by gathering ISV transfer fee quotes and confirming the support options available for your current IBM i release. Use those numbers to compare another on-premises upgrade with hosted IBM i across the next three to five years.

The numbers often make the better path easier to see once you view hardware, software, support, and hosting costs together. IBM's official lifecycle documentation remains the primary reference for confirming standard support and Service Extension dates for each IBM i release.

The NIST National Vulnerability Database also provides a public reference for vulnerabilities affecting software components used across enterprise environments.

Connect with the Source Data Products team to review your IBM i environment and identify the path that best fits your technical and financial goals.