Can you do DevOps on a mainframe? The question sounds counterintuitive. DevOps is associated with modern, cloud-native toolchains, while mainframes are perceived as legacy infrastructure. Yet many of the most business-critical applications in banking, insurance, government, and retail still run on mainframes — and those workloads deserve the same delivery discipline as any microservice running in a Kubernetes cluster.
This article explains what DevOps means in practical terms, why extending it to mainframe environments is worthwhile, and what concrete steps and tooling can help engineering teams close the gap between MIPS-based workloads and modern CI/CD pipelines.
What DevOps Actually Means
DevOps is the practice of breaking down the organisational and tooling barriers that have historically separated software development teams from IT operations teams. When developers and operators work in silos, code changes accumulate, feedback loops lengthen, and deployments become high-risk events. DevOps addresses this by aligning people, processes, and tooling around a shared goal: shipping reliable software quickly and continuously.
The key outcomes DevOps is designed to deliver include:
- Continuous integration (CI): Developers merge code changes frequently, with automated builds and tests validating every change.
- Continuous delivery (CD): Software is always in a deployable state; releasing to production becomes a low-friction, routine operation rather than a stressful event.
- Faster feedback: Automated monitoring, alerting, and observability tools surface problems quickly so they can be fixed before users are affected.
- Agility: Teams can scale workloads, adopt new frameworks, and respond to changing requirements without being blocked by manual processes or organisational handoffs.
None of these outcomes are platform-specific. They apply just as meaningfully to COBOL batch jobs on z/OS as they do to Python microservices running in Docker containers.
Why Mainframes Belong in Your DevOps Workflow
The DevOps conversation has understandably centred on distributed, cloud-native infrastructure. Containers, orchestrators, and hosted CI/CD platforms are all relatively new and genuinely benefit from DevOps practices. However, focusing exclusively on these technologies means ignoring a substantial portion of enterprise computing infrastructure.
As Compuware CEO Chris O’Malley has argued, there are several strong reasons to bring DevOps discipline to mainframe environments:
1. Business-Critical Workloads Live There
Core transaction processing, large-scale batch analytics, and record-of-system databases in many large enterprises still run on mainframes. If development and operations teams cannot apply CI/CD practices to those workloads, they create a two-speed IT organisation: rapid delivery for greenfield applications and slow, risky releases for the systems that matter most. That inconsistency undermines the value of DevOps across the board.
2. Mainframes Are Infrastructure — Not Magic
A mainframe is ultimately a hardware and software platform. It has source code, build processes, test suites, deployment pipelines, and operational runbooks — all of which can be versioned, automated, and measured. The languages (COBOL, PL/I, Assembler, JCL) and the operating environment (z/OS, CICS, IMS) differ from those on distributed systems, but the engineering principles that govern good software delivery do not change.
3. Mainframes Offer Scale and Security That Complements DevOps Goals
Modern mainframes are highly scalable, fault-tolerant, and built with security as a first-class concern. These properties align with what DevOps teams want from infrastructure. Integrating mainframes into a DevOps toolchain can therefore extend those reliability and security guarantees to workflows that previously lacked them.
The Real Challenges of Mainframe DevOps
Recognising the value of mainframe DevOps is easier than implementing it. Several genuine challenges must be addressed:
- Tooling gaps: Popular CI/CD platforms, version control systems, and observability tools were built for distributed, Linux-based workloads. Many do not natively understand z/OS job control, VSAM datasets, RACF security, or SMF records.
- Language and skills differences: Developers who work in Java, Python, or Go are rarely familiar with COBOL or JCL, and mainframe specialists often have limited exposure to modern DevOps tooling. Bridging this skills gap requires deliberate cross-training and shared tooling.
- Cultural inertia: Organisations that have operated mainframe workflows for decades have established release rhythms, approval processes, and change control gates that predate DevOps thinking. Changing those processes requires organisational will, not just technical tooling.
- Observability and data access: Mainframe diagnostic data — SMF records, RMF metrics, SYSLOG output, and job logs — is typically stored in proprietary formats and isolated from the observability platforms that distributed teams use for monitoring.
How to Integrate Mainframes into DevOps Workflows
Despite these challenges, a practical path to mainframe DevOps exists. The following approaches address the most common barriers.
Version Control for Mainframe Source Code
COBOL and PL/I source, JCL procedures, copybooks, and configuration members should be managed in the same version control system used by the rest of the organisation — typically Git. Tools exist to synchronise z/OS Partitioned Data Sets (PDS) with Git repositories, enabling standard pull-request workflows, code review, and branch-based development for mainframe code alongside distributed code.
Automated Build and Test Pipelines
CI pipelines for mainframe workloads should trigger automated compiles, link-edits, and unit or integration tests whenever source changes are committed. Vendors such as Compuware (Topaz), IBM (Dependency Based Build), and others provide tooling that can be invoked from Jenkins, GitLab CI, or similar orchestrators. The goal is identical to distributed CI: catch defects early, in an automated way, before code progresses toward production.
Streaming Mainframe Data into Modern Observability Platforms
One of the most practical integration points is getting mainframe operational data — SMF records, job logs, performance metrics — into platforms that DevOps teams already use for monitoring and analytics. Solutions designed for this purpose can stream mainframe machine data into platforms such as Splunk, enabling operations staff to monitor mainframe workloads alongside distributed services in a single pane of glass. Syncsort’s Ironstream product (referenced in the original source article) is one example of a commercial tool built for this use case.
Integrating Mainframe Data with Big Data Pipelines
Many organisations need to combine mainframe batch output with data held in Hadoop, cloud object storage, or streaming platforms such as Apache Kafka. ETL and data integration tools that understand both mainframe data formats (EBCDIC, packed decimal, VSAM) and distributed data formats can bridge this gap without requiring manual extract-and-convert steps. This is relevant not just for analytics but for end-to-end delivery pipelines where mainframe jobs are one stage in a larger data workflow.
Shared Observability and Application Performance Management
Abend codes, transaction response times, and resource consumption on the mainframe are as important to measure and act on as error rates and latency in a distributed system. Integrating mainframe APM data — from tools such as Compuware Abend-AID or IBM OMEGAMON — into shared dashboards and alerting systems ensures that mainframe incidents are visible to the whole team, not siloed in a specialist team’s ticketing queue.
The Cultural Dimension
Technology alone will not deliver mainframe DevOps. The organisational change required is significant. Teams that have operated under a traditional change-management model — where mainframe releases go through lengthy approval cycles measured in weeks — need to adopt a different mindset. This means:
- Treating mainframe engineers as full members of the software delivery team, not as a separate silo accessed only through formal change requests.
- Establishing shared definitions of done, deployment checklists, and post-incident review processes that apply equally to mainframe and distributed workloads.
- Investing in cross-training so that mainframe specialists understand modern DevOps tooling and distributed engineers understand enough about z/OS to contribute meaningfully to shared pipelines.
- Starting small: pick one mainframe application, instrument it with version control and automated testing, connect its logs to a shared observability platform, and use that experience to build organisational confidence before scaling the approach.
Summary
Mainframes are not going away. For many large organisations they remain the authoritative system for the workloads that matter most. Leaving them outside the DevOps boundary creates a dangerous inconsistency: fast, automated delivery for lower-stakes applications and slow, manual releases for the systems that underpin core business operations.
The path to mainframe DevOps is technically achievable today. It requires integrating mainframe source code into standard version control, building automated CI/CD pipelines that understand z/OS artefacts, streaming mainframe operational data into shared observability platforms, and — critically — making the organisational and cultural changes that allow mainframe and distributed teams to work together rather than in parallel silos.
The organisations that get this right will have a meaningful competitive advantage: end-to-end delivery velocity across their entire technology estate, not just the newest parts of it.