Mainframe COBOL and CICS to APIs, then cloud in slices
Cohash modernizes mainframe applications without a big-bang rewrite. We expose tested CICS and IMS transactions as REST APIs first, which gets new channels off screen scraping and file drops. Next, bounded functions are rebuilt as cloud services and run alongside the old ones, with outputs compared until the business signs off. The mainframe keeps doing what it does well until each slice is proven.
- 01Application and data inventory
- 02API layer over existing transactions
- 03Offload read traffic
- 04Carve out one bounded function
- 05Repeat and retire
The story
Told without the client's name or anything that could identify them.
A payments processor's core systems ran COBOL, CICS and Db2 on IBM Z, and every new digital channel depended on a nightly file extract or screen scraping. Read-only inquiry traffic kept pushing MIPS costs up, and an earlier full rewrite had stalled and been cancelled. We mapped programs, transactions and batch schedules to business functions, then exposed tested CICS transactions as REST APIs secured with OAuth and mapped to RACF identities. Inquiry traffic moved to a cloud store fed by change data capture. After that we carved out one bounded function at a time, ran it beside the mainframe and compared every output until the business signed off.
why it was urgentOn 1 October 2026, IBM moved z/OS 2.5 to service extension, which puts a 3.x upgrade on most sites' plans anyway. CICS TS 6.3 has been generally available since September 2025. It brings Java 21 and OpenTelemetry tracing, plus an MCP server for CICS region data, so API and observability work gets easier on the platform you already have.
- openEvery new digital channel needs a nightly file extract from the mainframe.
- recurringThe COBOL developers who really understand the core batch cycle are close to retiring.
- blockedMIPS costs climb each year with read-only inquiry traffic.
- openA previous full-rewrite project stalled after years and was cancelled.
The estate, before and after
Before: channels reach the mainframe through screens and files
Digital channels either scraped 3270 screens or waited for nightly batch extracts to get at mainframe data. Every inquiry ran on mainframe capacity, however simple.
After: an API layer on the mainframe and functions moved to cloud in slices
Channels now call REST APIs through a mainframe API gateway that maps OAuth to RACF. Inquiry reads come from a cloud store fed by change data capture, and the functions we carved out run as cloud services, checked in parallel against the mainframe.
How we run it, phase by phase.
5 phases take you from COBOL, CICS and Db2 on IBM Z to APIs and cloud services, moved in slices. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Application and data inventory
Map programs, transactions, copybooks, JCL, Db2 tables, VSAM files and batch schedules to business functions. Static analysis turns up the dead code and the call graph.
- phase 02
API layer over existing transactions
Expose high-value CICS and IMS transactions as REST APIs through a mainframe API gateway, secured with OAuth and mapped to RACF identities. New channels call the APIs, not the screens.
- phase 03
Offload read traffic
We replicate Db2 or VSAM data to a cloud store using change data capture and point inquiry traffic there. Writes keep going to the system of record.
- phase 04
Carve out one bounded function
Choose one function with clean inputs and outputs, a rating rule or a statement job, say. We rebuild it as a cloud service, run it next to the mainframe version and compare every single output.
- phase 05
Repeat and retire
Move the next slice once the last one is stable. Retire programs, batch jobs and MIPS capacity as functions leave, and keep the rest on a supported z/OS release.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
New channels call APIs, not screens or files
We put high-value CICS and IMS transactions behind a mainframe API gateway as REST APIs, so web, mobile and partner channels stopped scraping screens and waiting for file drops.
- result 02
Inquiry reads come off the mainframe
We replicate Db2 and VSAM data to a cloud store with change data capture. Inquiries read from that store, and writes keep going to the system of record.
- result 03
Each migrated function is proven by comparison
We ran every carved-out function in parallel with the mainframe and compared outputs until the business signed off on the slice.
- result 04
Every API and service has an explicit access design
We mapped OAuth on the gateway to RACF identities and gave each new cloud service an identity of its own, so none of them borrows a mainframe profile.
- result 05
Retired code leaves the batch schedule
Programs and batch jobs were retired slice by slice as functions moved. Because the batch schedule was mapped first, no downstream step lost the file it expected.
Risks we plan for
-
Undocumented business rules
Decades-old COBOL holds rules nobody wrote down. Parallel runs with output comparison are the only reliable way to prove a slice behaves the same.
-
Batch window dependencies
Moving one job can break a downstream step that expects its file at 2 a.m. The batch schedule is mapped before anything leaves.
-
Data consistency across two platforms
During the transition the same data lives in two places. For each entity one side stays the system of record, and we watch replication lag.
-
Security model mismatch
RACF profiles don't map one-to-one to cloud IAM, so each API and new service gets an identity and access design worked out on purpose.
Where AI helps, and where it needs guardrails
CICS TS 6.3 ships with an MCP server for CICS region data, and AWS Transform has a mainframe agent for analysis and refactoring. We use AI to explain COBOL and to draft test cases from copybooks, then treat its output as a hypothesis until a parallel run proves it. Agents can read source and region data. Production transactions are off limits.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Program, transaction and batch inventory mapped to business functions
yours to keep - inventory02
API catalog for exposed CICS and IMS transactions
yours to keep - design03
Data replication design with system-of-record rules
yours to keep - report04
Parallel-run comparison reports per migrated function
yours to keep - plan05
Slice roadmap with retirement and MIPS reduction steps
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01MCP server
- Software that gives agents tools over the Model Context Protocol. If you switch on authorization, it treats agents like any other API client and checks their OAuth tokens.in context →
- 02Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 03Change data capture
- Streaming every insert, update and delete out of a database's log as events, so other systems see changes as they happen.in context →
- 04Extension
- Your own code sitting on top of the standard product, which stays untouched underneath. Business Central extensions are written in AL, Finance and Operations ones in X++.in context →
- 05OAuth
- A way for programs to sign in with tokens that expire quickly, so a leaked one doesn't work for long. Zendesk's last 30 minutes by default.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Why not rewrite or rehost everything at once?
Big rewrites are riskiest, since the rules nobody wrote down tend to surface at the end. Going slice by slice proves each piece while the business keeps running. For some estates, rehosting COBOL on an emulator is reasonable, and we'll put it next to the slice approach fairly.
02How long does this take?
It depends on the size of the code base, how tangled the batch cycle is and how many functions you want off the platform. The API layer often comes first because it pays off without moving code.
03Do we need to upgrade z/OS first?
Not for the API work, but you need a supported release either way. z/OS 2.5 is in service extension, so we often plan the 3.x upgrade alongside.
04Can you staff mainframe engineers?
Yes. COBOL developers, CICS and IMS specialists, systems programmers and RACF administrators, on contract, contract-to-hire or permanent terms.
Often on the same roadmap
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case studyHand-built cloud to Terraform or OpenTofu
Bringing console-built AWS, Azure and Google Cloud resources under Terraform or OpenTofu with import blocks, clean state and pipelines, without rebuilding.
read the case studyCloud landing zone and account vending
AWS Control Tower with Account Factory for Terraform, or Azure landing zones on Azure Verified Modules, built as code with guardrails, logging and vending.
read the case studydaa87f5b - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it