5 IBM i Modernization Starting Points (And Why So Many Efforts Lose Steam)

5 IBM i Modernization Starting Points (And Why So Many Efforts Lose Steam)

IBM i modernization rarely fails because of technology. It fails because organizations underestimate what they’ve inherited: decades of embedded process, fragile dependencies, and operational risk hiding beneath “stable” systems.

Leaders don’t need another rewrite plan. They need clarity on where modernization actually breaks down — before millions are spent on the wrong starting point.

In this article we will reflect on five modernization starting points we have witnessed again and again, and the very human reasons so many programs stall along the way.

You’ll likely see your own story in one of them. Maybe in all of them.

Let’s take a look.

1. The “We Haven’t Really Started” Situation

Some organizations haven’t truly begun modernization yet. And that’s not as unusual as it sounds.

The IBM i system is still doing its job. It runs core operations. People trust it. At the same time, everyone knows it won’t carry the business forever. The topic comes up in leadership conversations. Vendors have been spoken to. Slides may have been shared. But there’s no funded program, no dedicated team, and no clear first move.

From the outside, it can look like hesitation. From the inside, it often feels like restraint.

Leaders in this position usually see both sides clearly. Doing nothing has risks. But so does starting something large, disruptive, and poorly defined when teams are already stretched. The system may be old, but it’s reliable. And reliability buys patience.

There’s also an upside that’s easy to miss. When you haven’t started, you’re not carrying the weight of past missteps. No abandoned tools. No half-migrated modules. No architectural compromises made under pressure. You’re standing at the edge, not trying to climb out of something tangled.

The challenge is that a clean slate can feel overwhelming. Organizations here often get stuck in familiar patterns:

Debating the “right” end state for years.

• Designing future architecture before agreeing on today’s problems.
• Delaying decisions because nothing feels fully baked or safe enough.

The way forward usually isn’t a grand vision exercise. It’s smaller and more practical.

Instead of asking, “What should our IBM i environment look like in five years?” start with questions grounded in daily reality:

• Where do releases slow down or pile up?
• Which jobs make teams uneasy every time they run?
• Where do manual steps show up repeatedly in incident reviews?

Starting with real friction doesn’t give you a perfect roadmap. But it gives you something better: a place to begin that reflects how the system actually behaves, not how you wish it did. And that’s often the smartest first move.

2. The UI First Jump Start

Modernization often starts where frustration is most visible.

A green screen from decades ago gets a web makeover. Browsing becomes more fluid. Training new employees is simpler. The design matches other systems in the company. On paper, this is a quick win. But little has changed on the inside. The same tasks are running. The same programs are being executed. The same data is flowing. The business logic from the pre-modernization era is still in charge.

Teams at this point often feel a slight twinge of irritation after the initial rush. They know the surface layer is improved, but the limitations beneath that shiny new layer are still present:

• The database layout is the same.
• The dependencies are still a mess.
• Cross-module workflows are still a black box.

Progress often stalls at this point. The surface layer is complete, but the next steps like unscrambling logic, building APIs, or rethinking data models are not quick wins.

A useful perspective in this situation is to recognize that this initial UI phase is actually an entry point into further discovery. You already have more user attention and have demonstrated that change is possible. Now you can:

• Backtrack a few important user paths from the new screens to the underlying core programs and files.
• Employ analysis tools (and sometimes AI-assisted code analysis) to identify groups of logic that move together.
• Identify areas where performance or data problems are being covered over by the new interface.

The point isn’t to re-architect everything at once. It’s to leverage the UI effort to identify which pieces of the backend are causing you the most pain, and why.

3. The Low Code Phase That Started Out Helpful

Low-code platforms have good intentions when they first arrive.

There’s a queue of requests and not enough developers. Your team needs a quick workflow or small app. A low-code platform offers something usable in weeks, not months.

It sounds good and works great for a bit. Some processes become easier. The team no longer uses spreadsheets. Everyone sees improvement.

But over time, a new pattern emerges:

• Multiple teams use the platform in isolation.
• Applications are built for slightly different use cases, with different standards.
• Back-end integration with IBM i increases but isn’t documented consistently.
• After a few years, no one really knows what’s going on.

Some applications are in use and critical. Others are barely supported but still running. A few are abandoned but still hooked up to live data. At this point, the low-code platform is a secondary architecture with its own rules, owners, and technical debt.

Low code in itself isn’t the problem. Without a clear boundary, low code platforms will start to creep in ways that are difficult to control. This is the point where you need to stop thinking of low code as modernization. You should think of it as just another tool.

Some ways to do this:

• Identify the most critical apps related to revenue, compliance, or core business. Ensure that ownership and integration points are well understood.
• Determine which work should remain in low code and which should be moved to traditional development or IBM i directly.
• Establish light guardrails around new app integrations, change tracking, and handoffs when people change jobs.

The point is not to kill low code. It is to ensure that it does not become the go-to solution for every problem, especially those that indicate deeper architecture problems.

4. The Mixed Methods Landscape

In some organizations, modernization does not happen in one way. It comes in waves.

Some years back, some RPG code was refactored and made more robust. Later, APIs were introduced for external partners. Another team refactored a module in .NET or Java. A data team created cloud-based reports from nightly extracts. Another team investigated low code for a particular business process.

Each one was a good decision at the time. However, when put together, it can feel like several incomplete strategies layered on top of each other:

• Some parts are modernized in one way but built with old thinking in another.
• Some business processes span three or four different technologies.
• Incident analysis meetings involve representatives from several teams who know only their part of the story.

It all works, but it is increasingly difficult to understand. This is what leaders talk about as a patchwork or a bridge over an old bridge. Teams are reluctant to change because the risk is difficult to quantify. A small change can have ripple effects in other areas.

Being this situation, you may think you need a grand, sweeping solution. In truth, the best initial approach is to rediscover and analyze what you already have.

This may involve:

• Creating a map of current processes and dependencies, not in minute detail, but enough to understand the overall points.
• Identifying which areas cause the most operational pain, not simply which areas are old.
• Being willing to consider that some areas are old but sound and do not require immediate changes.

At this point, modernization efforts should be based on impact, not age. You may decide to:

• Turn off functionality that no longer has a clear purpose.
• Merge duplicated logic in two layers.
• Standardize new integration construction to make future changes easier.

In this context, progress is often less about making big changes and more about simplifying with care.

5. The Effort That Slowed Down Halfway

The most difficult starting point is the one that’s in the middle. You started the modernization journey. Things started to change. Perhaps some applications were rewritten in a new stack. Perhaps deployment was improved. Perhaps automated testing or new methods of working between teams were implemented.

But then the progress slowed.

Sponsors lost interest. Other projects took precedence. Budgets changed. A few key people left. Work did not cease, but it lacked the initial momentum. The original rallying cries and timelines no longer applied.

It is easy to categorize this as a failed modernization effort. But, in reality, it is more complex than that. There are some benefits that exist in the production process. Some of the lessons learnt were good. The problem is that there is no clear end.

Big changes in many industries follow this pattern. Some goals are achieved, but not the ones that were promised in the beginning. The reasons aren’t just about choices; it’s difficult to stay aligned and focused for years.

If this sounds familiar, here are two things to avoid:

• Acting as if the previous effort never happened and beginning a new program as if you’re starting from scratch.

Being so committed to the original plan that you can’t adapt to the current situation.

A more effective way to handle the stall is to consider it a checkpoint:

• Take a look at what’s actually working in production, not what was planned on paper.
• Ask for honest feedback from people at different levels.
• Break up pieces that are still strategically valuable and pieces that are no longer needed.

You can keep some parts, cut back on others, and retire a few. The point is to make decisions based on what the business needs today, not on what was promised yesterday.

From the outside, this can look like taking a step backward. From the inside, it’s often the only way to move forward without repeating the same pattern.

What These Patterns Have in Common

If you recognize elements of your situation in a number of these patterns, it doesn’t mean you’re particularly disorganized. It means you’ve been modernizing in the real world, with real-world limitations.

Looking at all five patterns, a number of themes appear:

• The system remembers shortcuts. Quick fixes remain in place. Modernization doesn’t remove them; it puts them back in the spotlight.
• Effort isn’t usually the issue. Most teams aren’t fighting change. They’re trying to meet many demands and avoid upsetting key systems.
• The challenge is often perspective. Various teams understand different aspects of the environment. The architects, developers, operations teams, and business users all understand parts of the puzzle, but very few understand the entire picture.

When programs plateau, it’s not a lack of concern. It’s people making decisions based on incomplete knowledge and inherited limitations. Realizing which category you are in is helpful, but it doesn’t solve all problems on its own.

Progressing from Motion to Meaningful Progress

Before your next major commitment (tool, rewrite, or pilot), take a moment to reflect and consider:

• What have we already attempted, and what have we learned?
• Which previous decisions are still influencing the system’s behavior today?
• Where do developers, operations teams, and business users experience the greatest pain? Are these areas the same or different?

These questions reflect both technical and organizational truths. They reveal how your teams work together as much as they reveal your code.

Modernization projects will often go more smoothly when these truths are understood early on, rather than mid-project.

The Next Step: Modernization Clarity Before Modernization Spend

Before committing to a rewrite, tool, or migration roadmap, leaders need one thing:

A clear operational map of where IBM i creates friction, cost, and risk today.

Damco’s IBM i Modernization Assessment helps executive teams identify:

• Where modernization ROI is real vs cosmetic
• Which workflows carry the most risk concentration
• What should be modernized, retired, or stabilized
• The fastest path to measurable change without disruption

Modernization doesn’t begin with transformation.

It begins with truth.