This article is based on an opinion piece by Chris O’Malley, CEO of Compuware, originally published on DevOps Digest.
The Mainframe Is Not a Legacy Problem—It’s a DevOps Opportunity
Most DevOps discussions assume that “dev” means modern programming languages—Java, Python, Go—and that “ops” means cloud or distributed infrastructure. The mainframe, running decades of COBOL, PL/I, and Assembler code, rarely enters the conversation. That omission is a serious strategic mistake.
There are at least three compelling reasons why mainframe environments deserve their own dedicated DevOps strategy—plus a fourth that makes the case practically undeniable.
Reason 1: Necessity
Much of the world’s most economically critical code still runs on mainframes. Every time someone hails a ride, completes a bank transfer, or processes an insurance claim, there is a good chance a mainframe is executing the underlying transaction. Global banks and large enterprises continue to process billions of transactions worth trillions of dollars on platforms running COBOL and related languages.
Despite repeated predictions of the mainframe’s demise, mainframe owners consistently report that their workloads are growing, not shrinking. The platform itself continues to evolve: IBM’s mainframe line supports Linux and Java workloads alongside traditional COBOL applications, and its economics for high-volume, compute-intensive workloads are often more favorable than equivalent distributed or cloud deployments.
Leaving this volume of high-value application logic outside the DevOps discussion is indefensible. If it is worthwhile to apply continuous delivery practices to consumer-facing web applications, it is at least as worthwhile—arguably more so—to apply them to the code that powers international finance and critical infrastructure.
Reason 2: Unique Challenges That Require Their Own Strategy
In principle, code is code. The cognitive difference between managing the lifecycle of a COBOL application and a Java application is largely syntactic. In practice, however, mainframe DevOps involves a specific set of challenges that don’t appear in most cloud-native pipelines:
- Complex, underdocumented codebases. COBOL programs are often large, heavily modified over decades, and poorly documented. Inter-application dependencies are deep and non-obvious. Code-parsing, runtime analysis, and automated dependency mapping become critical capabilities rather than nice-to-haves.
- Tooling mismatch. Mainframe development teams have historically used toolsets that bear little resemblance to the IDEs, version control systems, and CI/CD pipelines used by modern application teams. Integrating mainframe code management into a broader enterprise DevOps toolchain typically requires deliberate re-tooling and integration work.
- Cultural inertia. Mainframe shops have spent decades optimizing for stability and hyper-rigorous change management—with good reason, given the criticality of their systems. Shifting that culture toward Agile iteration, fast feedback loops, and continuous delivery is a significant leadership challenge, separate from any tooling or process change.
None of these obstacles are insurmountable, but they do require a targeted discussion, a clear strategy, appropriate tooling choices, and sustained leadership commitment. A generic DevOps playbook written for cloud-native teams will not transfer directly to the mainframe environment without adaptation.
Reason 3: Significant Business Upside
The strongest argument for mainframe DevOps is commercial. The COBOL codebase running on a mainframe is, in many cases, the digital DNA of the business—encoding how it operates, measures performance, and serves customers. A business whose core systems are slow and unresponsive cannot compete effectively in fast-moving markets, regardless of how modern its customer-facing applications appear.
Conversely, a mainframe-centric organization that successfully adopts DevOps practices gains a meaningful competitive advantage over peers that have not. This is especially relevant as mainframe applications increasingly serve as backends for mobile apps and analytics platforms. The ability to update core transaction logic quickly and safely translates directly into better customer experiences and more actionable data.
The economic case extends beyond agility. The mainframe platform offers a cost-effective foundation for any workload that demands high throughput, reliability, and security at scale. But organizations will only route new workloads to the mainframe if they can develop and maintain those workloads efficiently. DevOps enablement is therefore a prerequisite for realizing the platform’s full economic potential.
Reason 4: It Is Already Happening
Forward-thinking IT organizations are already running DevOps on the mainframe and reporting tangible returns. This is not a theoretical future state—it is a practical, actionable initiative that organizations are executing today. The existence of real-world success stories means that best practices, tooling, and organizational patterns already exist to learn from.
If your organization has a mainframe and has excluded it from your DevOps initiatives, you are leaving competitive advantage on the table. The platform is not going away. Mainframes have outlasted multiple generations of technology predicted to replace them, and there is no credible evidence that the next wave will be different.
Key Takeaways for DevOps Engineers and Architects
- Do not treat the mainframe as someone else’s problem. If your enterprise has one, it belongs in your DevOps pipeline.
- Audit your mainframe toolchain. Version control, automated testing, and CI/CD integration are achievable on the mainframe but require deliberate tooling decisions.
- Invest in dependency mapping and code analysis. The complexity and age of COBOL codebases make automated analysis tools more valuable here than in greenfield environments.
- Plan the cultural change explicitly. Stability-focused mainframe teams need a different change management approach than cloud-native teams.
- Look for early wins. Mainframe DevOps initiatives can and should demonstrate ROI quickly to build organizational momentum.
Original opinion piece by Chris O’Malley, CEO of Compuware, via DevOps Digest.