In the drive to modernize IT systems, “modernize everything” is not a reality-based approach.

But that is the message we have heard for a decade or two now. The enterprise has been told that wholesale transformation is the way forward. It’s a familiar—even boring by now—narrative: if you don’t replace the old with the new (or refactor, or recode, or re-whatevs) everywhere, you will lose your competitiveness. Or efficiency. Or both.

There are plenty of smarter, more sustainable paths, based on the reality of the enterprise estate today.

As organizations grapple with tightening budgets and increasing complexity, accelerated to a remarkable degree by AI, I see customers moving away from transformation for transformation’s sake in many areas of IT. Modernization efforts are increasingly evaluated directly against the standard of measurable business value, enabling a new perspective and framework that regards strategic evolution and puts guardrails around revolution.

This is especially true in mainframe computing, where applications are mission-critical and their disruption generally intolerable to the enterprise.

Why Transform Wholesale?

Let’s put this into a critical context in the mainframe: own code. When you attempt to modernize an entire codebase at once, you aren’t just updating syntax; you are often migrating decades of accumulated business logic. Much of this logic is undocumented or, at best, cryptically documented, resulting in nearly impenetrable legacy code that current teams can’t fully understand.

Trying to convert this wholesale can lead to:

• Architectural Flaws: Automated translation tools can carry over the bad habits of old code into the new language, creating “Frankenstein” applications that are modern in syntax but archaic in structure.
• Business Disruption: The sheer scale of many total recodes on the mainframe increases the surface area for bugs and outages, threatening the mission-critical operations the application supports.
• Diminishing Returns: Not every line of code provides equal value when recoded. Expending resources to modernize stable, functional code that does not require new features is effectively wasted budget.

Why Not Modernize Selectively?

Here’s where the logical, measured approach stands out. If wholesale transformation is tech’s equivalent of “burn it all down and start over,” selective modernization is more akin to a careful restoration project. Not every structure needs to be rebuilt from the foundation up. The wise path is to avoid applying the same modernization brush everywhere and instead to identify what is ripe for strengthening, repair, or enhancement, since it already works.

I recently spoke with BMC Software, a vendor with plenty of experience in this area, about this. In their view, selective modernization in the mainframe is best anchored by three principles: start by ensuring stability; make sure you understand the architecture; and don’t waver from keeping business value as the guidepost.

Here’s how it looks in practice:

1. Stability First: If a component or system is battle-tested and consistently delivers, leave it alone (provided it does not inhibit or slow innovation). The goal is to ensure that code is maintainable, enabling continuous innovation. This also sidesteps the risk (and cost) of fixing what isn’t broken.
2. Architectural Integrity: Modernization decisions should be grounded in a thorough understanding of system dependencies. Before touching even one line of code, map out how everything fits together to avoid compounding legacy technical debt.
3. Business Alignment: Focus limited resources on areas where agility matters most—high-impact features, frequent updates, integration points. Don’t just chase the latest technological trend.

BMC Software has an approach they call Adaptive Business Code, reflecting this. By emphasizing a thorough understanding of existing systems, careful modularization of code, and prioritization of high-value areas for modernization, Adaptive Business Code aims to address the challenges of mainframe modernization while managing risk.

The idea is that organizations can target improvements to reduce risk and allocate resources better, a/k/a the proverbial 80/20 rule: 20% of systems drive 80% of change. In the three principles outlined above, I’d say that the first is very much the realm of the mainframe; the second is a welcome recognition of the broad impact of system integration in enterprise environments, while also being a particular issue with mainframes; and the third is a general IT principle too often forgotten in the excitement of modernization initiatives.

From Theory to Practice

The mainframe has experienced dramatic changes in recent years, most significantly with respect to generative AI, of course, but also through the accelerated adoption of cloud and open-source tools, DevOps methodologies, and sustainability practices spanning the stack. Modernization is no longer a one-time effort but an ongoing, adaptive journey. As workforces evolve, business needs shift, and technology advances, modernization approaches must continuously adapt. This ensures that systems remain maintainable and capable of supporting continuous innovation.

The mainframe vendor community has played a pivotal role in providing these adaptive solutions, with contributions that emphasize understanding and architecture over fleeting trends. Among these, offers such as BMC’s AMI (Automated Mainframe Intelligence) generative AI solutions exemplify how vendors are helping organizations navigate this continuous evolution.

The Real Imperative in the Mainframe

Every IT investment is under a microscope now, or about to go there (welcome to the club, AI!). The tolerance for grand, speculative projects is low, especially outside of AI. Under these conditions, the argument for wholesale transformation can’t really stand up to scrutiny because “wholesale” isn’t firmly rooted in either operational stability or ROI.

Selective modernization, in contrast, aligns with real business needs. Being selective empowers CIOs and technical leaders to focus on efficient impact rather than making changes for appearance’s sake. With this kind of reality-based mindset, organizations can strengthen their core systems without stressing resources—resources that can be better employed on organizational progress. That, to me, is worth hyping.

It’s a good time to bring selective, adaptive evolution into the mainstream of mainframe strategies—all IT strategies, really. Technology exists to serve the organization’s goals and plans, of course, and “modernization” is only a goal (or plan) within the context of higher goals. So we should focus modernization on the areas that really serve those higher goals. For everything else, the smartest move might be to leave what works alone so that it can keep on working for you.

To learn more, watch the webinar Modernizing Mainframes: From Monolithic Code to Modular Architecture.