Mainframe Modernization with AI
Modernize the mainframe with AI. Engineers prove it.
AWS Transform agents analyse the estate, extract the business rules and translate COBOL to Java. Our engineers verify the result against production behaviour before anything is cut over — with the scope, the price and the week-level timeline published before you sign.

What the Mainframe Question Actually Costs
Two figures from the AWS ecosystem, two from our own record. Nothing here is a projection of what your estate will do — that number comes out of the assessment.
- 7 months Bridgestone modernized its mainframe with AWS Transform in seven months, against the multi-year norm (source: AWS)
- 50%+ of a traditional modernization project is testing — the first thing agentic tooling automates (source: AWS Transform FAQ)
- $0 the AWS Transform mainframe agent itself — you pay for the engineering that proves the result (source: AWS Transform pricing)
- 3 weeks our fixed-price readiness assessment: inventory, dependency map, wave plan and a priced proposal you keep either way
Third-party figures are attributed and were checked against the vendors' own published pages in August 2026. We publish no mainframe client metrics because we have no mainframe case study to attach them to yet.
What is AI-powered mainframe modernization?
What is AI-powered mainframe modernization?
It is the practice of moving mainframe workloads — COBOL programs, JCL jobs, CICS transactions, DB2 and VSAM data — to cloud platforms using AI agents for the mechanical work: analysing the codebase, extracting business rules with traceability back to the source line, translating COBOL to Java, and generating the tests that prove the new system behaves like the old one. Engineers own the architecture, the data migration and the cutover decision.
How is it different from a traditional mainframe migration?
A traditional migration spends its first year on discovery: reading undocumented COBOL, reconstructing what each job does, and hand-writing a test suite that never existed. Agentic tooling compresses that phase and generates the regression tests, which is where most of a mainframe budget historically went. The engineering judgement — what to move, in what order, and what to leave — does not change.
What does AWS Transform do, in plain terms?
AWS Transform is an agentic AI service from AWS. Its mainframe agents analyse an uploaded codebase (dependencies, complexity, dead code), document what each program does, extract business rules traced to their exact source files and lines, plan migration waves, translate COBOL to Java, generate tests and produce deployment artefacts. AWS publishes the mainframe modernization agent as free; the delivery work around it is what a partner is paid for.
Six Honest Paths for a Mainframe Workload
No estate takes one path. The assessment assigns a path per workload, with the reasoning and the cost behind each one written down.
-
Refactor
Translate COBOL to modern Java with AWS Transform, keeping the behaviour identical. The default for large, stable batch and transaction estates where the business logic is still correct.
-
Reimagine
Extract the business rules, then rebuild the workload cloud-native from those requirements instead of translating line by line. For systems whose logic is worth keeping but whose structure is not.
-
Replatform
Move the workload to a cloud runtime with minimal change — an emulation or rehosting layer — when the driver is exiting the hardware and the licence, not improving the code.
-
Replace
Sometimes the honest answer is a product you buy. Payroll, core insurance administration and similar workloads often have a mature SaaS equivalent that beats any rewrite. We will say so.
-
Retire
Estates carry jobs nobody has run in years. Analysis finds the dead code and low-utilization workloads before anyone pays to migrate them.
-
Retain
Some workloads should stay on the mainframe for now, integrated rather than moved. A modernization plan that cannot say this about anything is a sales plan.
Which path fits your workloads?
The assessment answers it →
The Process, Week by Week
Assess
Weeks 1–3Everything you need to decide, and nothing you have to buy afterwards.
Codebase analysis: dependencies, complexity, dead code
A path assigned to every workload, with the reasoning
Wave plan sequenced on business priority and risk
Fixed-price proposal — yours to keep, with any partner
Pilot
Weeks 4–10One business-critical workload, modernized and proven, before the programme is funded.
One workload transformed end to end
Parity tested against production data
Run in parallel with the mainframe
Published acceptance criteria: parity passes, or we do not advance
Wave delivery
Per waveRepeat the proven pattern, one wave at a time.
Transformation, data migration, parity testing
A pod per wave: mainframe SME, Java engineers, data engineer
Engineer sign-off gate at the end of every wave
Your ops team trained on the new stack as it lands
Parallel run & cutover
Per waveThe old system keeps running until the new one has earned the traffic.
Old and new run side by side on real volume
Batch windows and response times measured, not assumed
Rollback path retained through the whole run
Runbooks and handover on the way out
What's Included
Portfolio Assessment
Portfolio Assessment
The codebase read in full before anyone proposes a plan: what runs, what calls what, what has not executed in years, and what each workload would cost to move.
What's included
- Full inventory: programs, copybooks, JCL, CICS, DB2 and VSAM
- Dependency and complexity mapping across the estate
- Dead-code and low-utilization census
- Wave plan and fixed-price proposal you keep either way
Business Rule Extraction
Business Rule Extraction
Decades of undocumented logic turned into readable specifications, each rule traced back to the source file and line it came from, so an auditor can follow it.
What's included
- Functional documentation per program
- Business rules traced to exact source lines
- Entry points and functional groups identified
- Specifications your own team can review
Code Transformation
Code Transformation
COBOL translated to modern Java with AWS Transform, then refactored by engineers into code your team will still be able to read in five years.
What's included
- COBOL to Java transformation on AWS Transform
- Engineer review and refactoring of generated code
- Target architecture designed before translation begins
- Coding standards and structure your team agrees to
Testing & Parity Proof
Testing & Parity Proof
The part that decides whether a modernization succeeds. Characterization tests capture what the mainframe does today; the new system has to match it, on production data.
What's included
- Characterization tests generated from current behaviour
- Parity runs on production data, old versus new
- Performance testing: batch windows and response times
- Regression environment maintained through the programme
Data Migration
Data Migration
DB2 and VSAM moved to cloud databases with the parity checks applied to data as strictly as to code.
What's included
- DB2 and VSAM to managed cloud databases
- Schema conversion and data type mapping
- Row-level reconciliation between source and target
- Cutover rehearsal before the real one
Landing Zone & Operations
Landing Zone & Operations
The AWS platform underneath, and the handover that decides whether your team owns this afterwards or you call us forever.
What's included
- Landing zone, networking and security baseline
- Infrastructure as Code in Terraform or CloudFormation
- Observability, alerting and runbooks
- Ops-team enablement: your mainframe operators trained on the new stack
AI Where It Is Measured. Engineers Own the Outcome.
Agentic tooling changes the economics of modernization. It does not change who is accountable when a batch job produces a different number.
Analysis and documentation
AGENTSAWS Transform reads the whole codebase: file classification, effective lines of code, cyclomatic complexity, dependency maps, and functional documentation per program.
Business rule extraction
AGENTSEvery rule is extracted with a trace back to the source file and line, so a reviewer — or an auditor — can follow any behaviour to the code that produced it.
Translation and test generation
AGENTSCOBOL becomes Java, and the characterization tests that legacy code never had are generated alongside it. This is the half of the project that used to be hand-written.
Architecture and code review
ENGINEERSGenerated code is reviewed and refactored to a structure your team agreed to. Nothing reaches a repository because an agent produced it.
Parity and performance sign-off
ENGINEERSFunctional parity on production data, and performance parity against the real constraint: the nightly batch window and transaction response times. Both are gate criteria, not report lines.
Cutover decision
ENGINEERSA named engineer signs off each wave. The mainframe keeps running in parallel until that signature, and the rollback path stays open throughout.
Your code stays in your AWS account
Transformation runs in your own AWS environment under your IAM controls, with the full audit trail of what each agent did and which source line it came from. Data residency and retention follow your account policy, not ours.
Where This Fits, and Where It Does Not
A shorter list of what we do not take on is worth more than a longer list of what we do.
A good fit
- z/OS estates written in COBOL, with JCL batch and CICS transactions
- DB2 and VSAM data that has to move with the applications
- Batch-heavy portfolios where the nightly window is the real constraint
- Teams facing a retirement cliff in mainframe skills
- Organizations that need the audit trail as much as the migration
- Estates where a first workload can be carved out and proven on its own
Scoped separately, or not at all
- PL/I, RPG, Assembler and Natural/Adabas: AWS Transform targets COBOL, so these need a scoped alternative and we price that honestly
- IMS and IDMS data stores: possible, but they change the data-migration plan and the cost with it
- Estates with no test data and no way to generate it — parity cannot be proven against nothing
- Programmes that need a single big-bang cutover on a fixed date
- Workloads whose regulator has not been consulted about leaving the mainframe
- Anything where the honest answer is Retain, and the decision has already been made otherwise
Packages & Pricing
Published because a mainframe programme is the last place a buyer should have to guess. The assessment price is fixed and the deliverables are yours whether or not you continue with us.
-
Most popular
Readiness Assessment
Three weeks, fixed scope, yours to keep
Fixed $15,000- Full inventory and dependency map of the estate
- A path assigned per workload, with the reasoning
- Wave plan sequenced on business priority and risk
- Fixed-price proposal for the pilot and the waves
- Up to roughly 1M lines of code or 10 applications
Pilot Modernization
One workload, proven in parallel
From $60,000- One business-critical workload transformed end to end
- Characterization tests and parity runs on production data
- Performance tested against your batch window
- Parallel run beside the mainframe
- Acceptance criteria published before we start
Modernization Waves
Per wave, scoped in the assessment
Priced per wave- A delivery pod per wave: mainframe SME, Java engineers, data engineer
- Transformation, data migration and parity testing
- Engineer sign-off gate at the end of each wave
- Your ops team enabled as each wave lands
- Runbooks and handover included
The three objections every mainframe team raises
Will the new system still finish the nightly batch in time?
That is a gate criterion, not a hope. During the parallel run the modernized workload processes the same volume as the mainframe and the batch window is measured. If it does not fit, the wave does not advance — tuning or a different target architecture comes first.
What happens to our mainframe team?
They are the people who know what the code is supposed to do, and the programme depends on them. Ops-team enablement is a workstream, not a footnote: your operators are trained on the new stack as each wave lands, and the runbooks are written with them rather than handed to them.
How do we prove to an auditor that nothing changed?
Every extracted business rule carries a trace to the source file and line it came from, every parity run is recorded with its inputs and outputs, and each wave ends with a named engineer sign-off. That evidence trail is a deliverable, not a by-product.
Model the run-cost side of the business case
Our cloud migration calculator gives you a five-year run-cost projection in a few minutes. It will not tell you what a mainframe transformation costs — that comes out of the assessment — but it sizes the half of the business case that is about what you stop paying.


- 5 templates Ready to fill in
- Free Instant PDF access
The mainframe decision, reduced to a worksheet.
The inventory worksheet, the AWS Transform readiness checklist, the wave-planning template and the cutover gates we use on real engagements. Written to be filled in, not read once.
- Inventory worksheet: what to count before anyone quotes you
- Readiness checklist and wave-planning template
- The cutover gate criteria, including performance parity
Published by Dedicatted, AWS Premier Tier Services Partner. Instant PDF access.
Your download is starting.
Click here if the download hasn't started automaticallyMainframe Modernization, Answered
How much does mainframe modernization cost?
The readiness assessment is $15,000 and takes three weeks, and it produces the number for everything after it: effort per workload, the wave sequence, and a fixed-price proposal. A pilot on one business-critical workload starts at $60,000. Waves are priced individually because the honest drivers are estate size, data complexity, integration count and how much test data exists. The AWS Transform mainframe agent itself is free (per AWS pricing), so what you are buying is engineering, not tooling.
How long does mainframe-to-AWS modernization take?
Assessment takes three weeks and a first pilot workload runs weeks four to ten. After that, delivery is wave by wave rather than one date: you see modernized workloads in production within months. For scale, AWS reports Bridgestone modernizing its mainframe with AWS Transform in seven months. What your estate takes depends on how many waves it needs, which the assessment tells you before you commit.
Which languages and platforms can you modernize?
COBOL on z/OS with JCL, CICS, DB2 and VSAM is the core path, because that is what AWS Transform targets for transformation. PL/I, RPG, Assembler and Natural/Adabas are not covered by that tooling: they need a scoped alternative, and we price that separately instead of pretending it is the same job. IMS and IDMS are possible but change the data-migration plan. The assessment states which of your workloads fall where.
How do you prove the new system behaves identically to the old one?
Three ways, in order. Every extracted business rule is traced to the source file and line it came from. Characterization tests capture the current behaviour before anything changes, and the modernized workload has to match it on production data. Then the two run in parallel on real volume, including the nightly batch, until a named engineer signs the wave off. Parity is a gate, not a report.
Will the modernized system meet our batch windows and response times?
Functional parity is not enough on a mainframe, so performance is part of the gate criteria. During the parallel run we measure batch completion against your actual window and transaction response times against your current baseline. If either misses, the wave does not advance until the architecture or the tuning fixes it.
Is our source code used to train AI models, and where does it run?
The transformation runs inside your own AWS account, under your IAM controls and your data-residency policy, with an audit trail of what each agent produced and which source lines it came from. AWS publishes its own data-handling terms for the service, and we will walk through them with your security team during the assessment rather than summarising them for you here.
Do we have to move everything off the mainframe?
No, and a partner who says otherwise is selling. Retain is one of the six paths, and for some workloads it is the right one — integrated with the cloud estate rather than migrated. Retire is another: most estates carry jobs nobody has run in years, and the analysis finds them before you pay to move them.
You have no published mainframe case study. Why should we trust you with this?
Because the engagement is structured so you do not have to take it on faith. The assessment is fixed-price and zero lock-in: the inventory, the wave plan and the proposal are yours to use with any partner. The pilot has acceptance criteria published before it starts. And the underlying tooling is AWS Transform, which is AWS’s own service, not a black box of ours. We are an AWS Premier Tier Services Partner and the only AWS Generative AI and MSP partner in Canada, and our record in cloud migration and modernization is on the rest of this site.
Question not answered? Ask a mainframe engineer directly — a senior engineer replies within one business day.
Mainframe Modernization Services on AWS
Dedicatted delivers mainframe modernization services on AWS: COBOL to Java migration, business rule extraction, DB2 and VSAM data migration, and the parity testing that proves a modernized workload behaves exactly like the mainframe it replaced. We are an AWS Premier Tier Services Partner and build our mainframe practice on AWS Transform, the agentic AI service AWS provides for mainframe analysis, transformation and test generation.
Typical engagements start with a fixed-price readiness assessment covering the full estate — programs, copybooks, JCL, CICS transactions, DB2 and VSAM — and produce a wave plan that assigns each workload one of six paths: refactor, reimagine, replatform, replace, retire or retain. Delivery runs wave by wave with parallel running and engineer sign-off at each cutover, never a single big-bang migration.
Related services: AI-driven application modernization for distributed and cloud-hosted legacy systems, and cloud migration for infrastructure and data platform moves.
What We Deliver
- Mainframe portfolio assessment and dependency mapping
- COBOL to Java transformation on AWS Transform
- Business rule extraction with source-line traceability
- Characterization testing and functional parity proof
- Performance parity: batch windows and transaction response times
- DB2 and VSAM migration to managed cloud databases
- AWS landing zone, Infrastructure as Code and observability
- Parallel running, wave cutover and ops-team enablement
featured technology partners
Talk to a mainframe engineer
Tell us what the estate looks like — languages, rough size, what is forcing the question. A senior engineer, not a sales rep, replies within one business day.
Thanks — we have it.
Our team replies within one business day, with relevant experience and a first read on your problem.
