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.
Read the diagram as text
- CICS and IMS transactions → Db2 and VSAM: reads · writes
- Batch cycle → Db2 and VSAM: batch updates
- CICS and IMS transactions → Screen scraping: 3270 sessions
- Screen scraping → Web and mobile channels: scraped data
- Batch cycle → Nightly file extracts: JCL output
- Nightly file extracts → Web and mobile channels: nightly extract
- Nightly file extracts → Partners: file drop
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.
Read the diagram as text
- Web and mobile channels → Mainframe API gateway: REST + OAuth
- Partners and new apps → Mainframe API gateway: REST + OAuth
- Mainframe API gateway → CICS and IMS transactions: transactions
- Mainframe API gateway → RACF: identity mapping
- CICS and IMS transactions → Db2 and VSAM: writes
- Db2 and VSAM → Cloud read store: change data capture
- Web and mobile channels → Cloud read store: inquiry reads
- CICS and IMS transactions → Carved-out cloud service: parallel run
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
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 - 01IBM: z/OS service extension table (June 2026)ibm.com ↗
- 02IBM Community: CICS Transaction Server 6.3community.ibm.com ↗
- 03IBM: z/OS 3.2ibm.com ↗
- 04AWS Transformaws.amazon.com ↗
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