Keep what runs well on z/OS, expose it through APIs, and move what doesn't belong there.
A mainframe estate is rarely one decision. Some COBOL batch should stay where it is on a newer z/OS. Some CICS transactions need an API in front of them. Some applications should move off the platform. We sort the portfolio, do the engineering on each path, and staff the hard-to-find z/OS and RACF skills.
Digital appsweb · mobile · partnersIdentity governancejoiner · mover · leaver
02 · Integration
API layerREST · OAuth
03 · Mainframe
z/OSz/OS workloadsCOBOL · CICS · IMS · batchRACFusers · groups · profilesDB2 and datasetsVSAM · sequential
04 · Target platforms
Refactored servicesJava · containersParallel run checksoutput comparison
IBM Z MainframeMuleSoftSailPointRed Hat OpenShift
in short·15-second read
Mainframe modernization means changing how mainframe applications and infrastructure are run, integrated or replaced, from upgrading z/OS and COBOL compilers to exposing CICS and IMS transactions as APIs to refactoring applications for cloud.
Cohash assesses mainframe portfolios, runs z/OS and Enterprise COBOL upgrades, builds API layers, cleans up RACF security, plans moves with tools like AWS Transform for mainframe, and staffs z/OS specialists.
you probably need this if
You're still on z/OS 2.5, and IBM's standard support ended on 30 September 2026.
Mobile and web teams screen-scrape 3270 sessions because there's no API.
RACF profiles grew for decades and nobody can say who has access to which datasets.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Mainframe Modernization, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · mainframe modernization3 open
openYou're still on z/OS 2.5, and IBM's standard support ended on 30 September 2026.
recurringMobile and web teams screen-scrape 3270 sessions because there's no API.
blockedRACF profiles grew for decades and nobody can say who has access to which datasets.
exposure
Portfolio assessmentz/OS and compiler upgradesAPI enablementRACF security cleanupRefactor and replatformMainframe skills staffing
z/OS
startrehearsehandover
Inventory
Decide per application
Engineer each path
Prove and cut over
we are here
ready to hand over
The site has an upgrade path with dates and known ISV dependencies.
The mobile app calls an API now, so screen changes no longer break it.
The auditor gets an effective access report for the in-scope datasets.
Application portfolio with a modernization path per application
chapter 01 · where it hurts
Why teams reach out
You're still on z/OS 2.5, and IBM's standard support ended on 30 September 2026.
Mobile and web teams screen-scrape 3270 sessions because there's no API.
RACF profiles grew for decades and nobody can say who has access to which datasets.
chapter 02 · what we change
How we solve it
Portfolio assessment
z/OS and compiler upgrades
API enablement
RACF security cleanup
Refactor and replatform
Mainframe skills staffing
chapter 03 · how it runs
Our approach
Inventory
Decide per application
Engineer each path
Prove and cut over
chapter 04 · where you end up
What changes
The site has an upgrade path with dates and known ISV dependencies.
The mobile app calls an API now, so screen changes no longer break it.
The auditor gets an effective access report for the in-scope datasets.
Application portfolio with a modernization path per application
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Each application sorted by business value, change frequency, code quality, data dependencies and skills risk, then assigned a path: keep and upgrade, wrap with APIs, refactor, replatform or retire.
We run z/OS release upgrades and Enterprise COBOL compiler migrations, with recompile testing to catch behavior changes. IBM ended support for z/OS 2.5 on 30 September 2026, so any site still on it is now outside standard support.
REST APIs in front of CICS and IMS transactions so cloud and mobile applications can use mainframe logic without screen scraping, with authentication tied to your enterprise identity platform.
Review of RACF users, groups, dataset and general resource profiles, removal of unused access, and integration of mainframe accounts with your identity governance platform for joiner, mover and leaver events.
Code analysis, conversion and testing for applications that should leave the mainframe, using tools such as AWS Transform for mainframe and IBM watsonx Code Assistant for Z, with parallel runs that compare outputs.
z/OS systems programmers, COBOL, CICS and DB2 developers, and RACF administrators on contract, contract-to-hire or permanent terms.
capability 01 / 06in production
z/OS
Portfolio assessment
Each application sorted by business value, change frequency, code quality, data dependencies and skills risk, then assigned a path: keep and upgrade, wrap with APIs, refactor, replatform or retire.
We run z/OS release upgrades and Enterprise COBOL compiler migrations, with recompile testing to catch behavior changes. IBM ended support for z/OS 2.5 on 30 September 2026, so any site still on it is now outside standard support.
REST APIs in front of CICS and IMS transactions so cloud and mobile applications can use mainframe logic without screen scraping, with authentication tied to your enterprise identity platform.
Review of RACF users, groups, dataset and general resource profiles, removal of unused access, and integration of mainframe accounts with your identity governance platform for joiner, mover and leaver events.
Code analysis, conversion and testing for applications that should leave the mainframe, using tools such as AWS Transform for mainframe and IBM watsonx Code Assistant for Z, with parallel runs that compare outputs.
We pieced these together from Mainframe Modernization situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Still on z/OS 2.5 after the end of standard support
composite · not a client story
Beforethe situation
A site runs production on z/OS 2.5. Standard support ended on 30 September 2026. The upgrade kept slipping because ISV products needed new versions and the systems programmers were tied up with daily operations.
What we dothe work
Check IBM's support options to cover the gap and build the ISV compatibility list for the target release. Upgrade a sandbox LPAR first. Development and production follow in order, with IPL and backout steps rehearsed.
Afterwhere you end up
The site has an upgrade path with dates and known ISV dependencies. The systems programmers get extra hands for sandbox and test work.
case file 02
3270 screen scraping behind a mobile banking feature
composite · not a client story
Beforethe situation
The mobile app reads account details by driving 3270 screens through middleware. Change a screen and it breaks. Every request is seconds slower than it needs to be.
What we dothe work
Find the CICS transactions behind the screens. Expose them through the API layer as REST APIs with OAuth authentication, then run the old and new paths side by side until the response data matches.
Afterwhere you end up
The mobile app calls an API now, so screen changes no longer break it.
case file 03
RACF access nobody can explain to the auditor
composite · not a client story
Beforethe situation
Auditors ask who can update production payroll datasets. Answering means untangling nested groups and generic profiles, plus user IDs for people who left years ago.
What we dothe work
Extract the RACF database and report who has effective access to the in-scope datasets. Remove revoked and orphaned users. Then hook RACF up to the IGA platform, so new access goes through request and review.
Afterwhere you end up
The auditor gets an effective access report for the in-scope datasets. New grants go through the same review as any other application.
Where mainframe workloads connect to the rest of the estate
Core COBOL programs run under CICS, IMS and batch on z/OS, with RACF controlling access. An API layer exposes selected transactions to cloud and digital applications, identity governance manages mainframe accounts, and chosen workloads move to cloud after parallel runs.
Where mainframe workloads connect to the rest of the estateCore COBOL programs run under CICS, IMS and batch on z/OS, with RACF controlling access. An API layer exposes selected transactions to cloud and digital applications, identity governance manages mainframe accounts, and chosen workloads move to cloud after parallel runs.01 · CONSUMERS02 · INTEGRATION03 · MAINFRAME04 · TARGET PLATFORMSAPI callsCICS transactionsprovisionaccess controlread and writerefactorlegacy outputnew outputDigital appsweb · mobile · partnersSPIdentitygovernancejoiner · mover ·leaverMUAPI layerREST · OAuthz/OSz/OS workloadsCOBOL · CICS · IMS ·batchRACFusers · groups · profilesDB2 and datasetsVSAM · sequentialOPRefactoredservicesJava · containersParallel run checksoutput comparison
01 · Consumers
Digital appsweb · mobile · partners → API layer · API calls
API layerREST · OAuth → z/OS workloads · CICS transactions
03 · Mainframe
z/OS
z/OS workloadsCOBOL · CICS · IMS · batch → DB2 and datasets · read and write→ Refactored services · refactor→ Parallel run checks · legacy output
RACFusers · groups · profiles → z/OS workloads · access control
DB2 and datasetsVSAM · sequential
04 · Target platforms
Refactored servicesJava · containers → Parallel run checks · new output
Parallel run checksoutput comparison
Read the diagram as text
Digital apps → API layer: API calls
API layer → z/OS workloads: CICS transactions
Identity governance → RACF: provision
RACF → z/OS workloads: access control
z/OS workloads → DB2 and datasets: read and write
z/OS workloads → Refactored services: refactor
z/OS workloads → Parallel run checks: legacy output
Refactored services → Parallel run checks: new output
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Inventory
Applications, programs, copybooks, JCL, datasets, interfaces and batch schedules, with dependencies mapped from code and job logs.
step 02
Decide per application
Assign a path to each application with cost, risk and skills considerations agreed with the business owners.
step 03
Engineer each path
Upgrades, API work, refactoring or migration run as separate workstreams with their own test approach.
step 04
Prove and cut over
Run old and new in parallel and compare outputs. Check batch timings. Cut over in stages, with a rollback plan for each stage.
you keep
What you're left with
We write these for your Mainframe Modernization setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Application portfolio with a modernization path per application
yours to keep
inventory02
Dependency map of programs, datasets, jobs and interfaces
yours to keep
tests03
z/OS and compiler upgrade plan with test results
yours to keep
design04
API designs for priority CICS or IMS transactions
yours to keep
design05
RACF cleanup report and identity integration design
yours to keep
report06
Parallel run comparison reports for migrated workloads
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
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
z/OS systems programmer
RACF security administrator
COBOL and CICS developer
DB2 for z/OS DBA
Mainframe API developer
Mainframe migration test lead
due diligence · mainframe modernization
Questions to ask any partner, including us.
Put these to anyone bidding on your Mainframe Modernization work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you decide which applications stay on the mainframe?
A partner who recommends moving everything, or nothing, isn't assessing. Ask for the criteria and how they're scored per application.
Q2
How will you map batch dependencies before estimating a migration?
Job schedules, datasets and file transfers tie applications together. Missed dependencies are the main source of migration surprises.
Q3
How will you prove migrated code produces the same results?
AI-assisted conversion speeds up the code changes. It doesn't prove the new code is right. Parallel runs that compare outputs are where that evidence comes from.
Q4
Which ISV products block our next z/OS upgrade?
Third-party products often need their own upgrades first. Ask about them, and the answer tells you whether the partner has done z/OS upgrades for real.
Q5
How will mainframe access join our identity governance program?
RACF often sits outside IGA. Bringing it in gives auditors one access review process across platforms.
01Should we move off the mainframe?
Sometimes, for some applications. High-volume transaction and batch work often runs well and cheaply where it is. Applications with heavy change needs, few remaining skills or low volume are better candidates to move. Most estates end up split.
02Is z/OS 2.5 still supported?
IBM ended standard support for z/OS 2.5 on 30 September 2026. z/OS 3.2 became generally available on 30 September 2025. If you're still on 2.5, check your IBM support options and plan the upgrade now.
03Can AI convert our COBOL?
AI tools like IBM watsonx Code Assistant for Z and AWS Transform for mainframe help people understand, document and convert code. You still have to test what they produce against real data, and parallel runs are where the conversion errors turn up.
04Is AWS Mainframe Modernization still available?
AWS says the AWS Mainframe Modernization service is no longer open to new customers, and points new projects to AWS Transform and vendor-direct offerings. Existing customers can continue using it.
05How long does a mainframe modernization take?
That depends on how many applications there are, which paths you choose and how much testing each one needs. Putting an API layer over a few transactions is a short project. Moving a big batch application off the platform takes a lot longer.
06Is it hard to find mainframe staff?
It can be. In Kyndryl's 2025 mainframe modernization survey, 70% of organizations said they were struggling to find the right multi-skilled talent. Our staffing practice places z/OS, COBOL, CICS and RACF specialists.
related
Often paired with
Projects on Mainframe Modernization usually end up touching one of these, so they're worth a look.