I’ve been working in and around large-scale mainframe applications and environments for a long time. Over the years, and especially recently, I’ve found myself having more and more quiet, off-the-record conversations through my LinkedIn network. The questions tend to sound similar:
Where should we start?
How should we think about modernization right now?
What would you do if you were sitting in my chair?
This post is my attempt to answer those questions plainly, without a sales pitch, and without pretending there’s a single right answer.
Assume the Hard Parts Are Already Happening
If I were sitting on the customer side of the table today, I would begin by assuming that the most difficult forces are not hypothetical risks, but present realities.
Experienced COBOL talent is retiring faster than it can be replaced. Run costs are disconnected from delivered business value. AI is advancing quickly, but much of what is marketed today is still immature when applied to complex, business-critical systems.
Most application portfolios are not as well understood as leadership believes they are.
Starting from acceptance, rather than denial, is what allows a plan to form.
Stop Treating Modernization as a Single Decision
One of the most common mistakes I see is framing modernization as a single strategic choice: rewrite, replatform, retain, or replace. In reality, long-lived application portfolios are collections of very different systems built at different times, for different reasons, under different constraints. A single answer rarely applies to all of them.
A more useful way to think about it is to ask:
- What must remain stable?
- What is actively blocking progress elsewhere?
- What genuinely drives cost versus what is simply inconvenient?
- What do we not understand well enough to safely change?
Progress comes from addressing these questions incrementally. Not from committing to a single sweeping move.
Buy Understanding Before Buying Change
Before approving any large-scale transformation effort, I would insist on confidence in three areas.
- First, a demonstrable understanding of how the application behaves today, including structure, data flow, and dependencies.
- Second, the ability to transfer that understanding to people who were not part of the original build. If knowledge cannot survive attrition, it is already at risk.
- Third, a clear path to proving functional equivalence. Confidence based on inspection and evidence matters more than confidence based on optimism.
Separate Cost Reduction from Modernization, but Run Them in Parallel
Another pattern I see is trying to solve cost reduction and long-term modernization with a single initiative. That often creates unnecessary coupling and delays. If I were making the decisions, I would pursue cost reduction efforts that do not require functional change as near-term levers, while independently investing in modernization efforts that reduce future dependency and risk.
Handled properly, short-term savings can help fund longer-term change rather than compete with it.
Start Small, but Not Trivially
I would avoid proofs of concept that demonstrate tooling in isolation but never reach production. A better starting point is a small, real slice of an application that runs in the target environment, reaches production, and delivers a measurable outcome. The key question is whether that first step can be repeated predictably, not whether it looks impressive in isolation.
Optimize for Control Before Speed
Speed is attractive, but control is what sustains programs through audits, outages, leadership changes, and shifting priorities. I would favor approaches that reduce reliance on individual experts, turn undocumented behavior into durable assets, allow pacing to change without restarting the effort, and leave ownership with the organization rather than the vendor.
In Closing
Modernization is rarely about boldness. It is about clarity and sequencing.
Clarity about what is known and unknown. Sequencing that respects complexity and risk. Incremental progress that builds confidence rather than resets it.
If I were on the other side of the table, that is how I would start.
