Introduction
Modernizing a mainframe that runs your core transaction processing is not like migrating a web app. One misstep in a COBOL batch job can disrupt payroll, claims processing, or regulatory reporting overnight.
That risk keeps many organizations stuck. They know their mainframe is expensive to maintain and hard to staff, but they can't risk breaking what works.
AWS Transform for Mainframe is an agentic AI-assisted modernization capability. It analyzes legacy code, extracts business logic, and helps teams decide what to keep, change, or retire—without treating the work as a simple lift-and-shift.
This article covers what the service actually does, how a realistic modernization workflow unfolds, and which decision factors matter most. It also addresses the governance questions regulated organizations need answered, and where an AWS Partner like Cloudtech fits into the plan.
Key Takeaways
- AWS Transform analyzes legacy code, extracts business logic, and generates modernization artifacts; verify capabilities against current AWS docs.
- "Reimagine" and "refactor" solve different problems; your choice depends on criticality, dependencies, and risk tolerance.
- AI accelerates analysis and transformation, but human review and functional testing remain non-negotiable.
- Start with a scoped pilot, not a single big-bang migration.
Why Mainframes Need a Different Modernization Approach
Mainframe applications are deeply interconnected. A single COBOL or PL/I program might call dozens of others, read from VSAM files or DB2 tables, and depend on JCL scripts that trigger nightly batch jobs in a specific sequence. Break that sequence, and a bank's overnight settlement or an insurer's claims cycle stalls.
Three factors make these systems uniquely hard to modernize:
- Tight coupling between programs, data structures, and batch schedules that resist isolated changes
- Undocumented business rules buried in decades of code patches, often known only to a handful of long-tenured employees
- Shrinking specialist talent as COBOL and PL/I programmers retire faster than they're replaced
Kyndryl's 2025 survey of 500 senior leaders at mainframe-using organizations found 70% struggled to find the skills needed to modernize, while 56% reported increasing their mainframe use rather than decreasing it. The takeaway: these systems aren't going away soon, so modernization has to happen carefully, in place or in parts.
Migration Isn't Modernization
People often use these terms interchangeably, but the approaches differ:
| Approach | What Changes | Disruption Level |
|---|---|---|
| Rehost | Infrastructure only (move to emulator or cloud) | Low |
| Replatform | Runtime environment, minimal code changes | Low-Medium |
| Refactor | Code rewritten in a new language, logic preserved | Medium-High |
| Reimagine | Business capabilities redesigned for cloud-native operation | High |
A line-by-line code conversion (refactor) keeps the original design, including its limitations. Reimagining instead asks what the business function actually needs to do, then builds that fresh. Both are valid, but they solve different problems.
What AWS Transform for Mainframe Modernization Does
AWS Transform for Mainframe became generally available in May 2025, initially covering US East (N. Virginia) and Europe (Frankfurt), and the supported Region list has expanded since then. Confirm current availability and Region support directly with AWS before committing source code or workloads.
The service works with z/OS applications written in COBOL and PL/I, along with associated JCL, CICS transactions, BMS screens, Db2 databases, and VSAM files. AWS documents automatic refactoring specifically for COBOL-based workloads to Java. Don't assume identical automatic conversion exists for every PL/I program without checking current documentation.
Analysis and Decomposition Capabilities
Before any code changes, the service analyzes what's actually there:
- Generates technical documentation from existing code
- Extracts business rules embedded in legacy logic
- Performs activity analysis using system usage records
- Maps data lineage and dependency graphs across programs and files
AWS's documentation refers to decomposition inputs as "seeds" (sometimes described as "semantic seeds" in AWS articles), used to identify business functions, domains, and flows within large codebases. This supports breaking a monolithic application into smaller, independently deployable pieces.
Outputs and Testing Support
Expect application blueprints, domain decomposition recommendations, data lineage maps, and modernization plans as reviewable artifacts, not production-ready deployments.
For testing, AWS Transform generates a prioritized natural-language test plan, JCL scripts to collect existing mainframe test data, and separate scripts for functional-equivalence testing. The test plan itself doesn't generate new test data or run execution scripts automatically. Those are distinct capabilities, and human teams still own test sign-off.
How This Differs From Other AWS Services
| Service | Scope |
|---|---|
| AWS Transform for Mainframe | Mainframe-specific analysis, decomposition, refactoring |
| AWS Transform Custom | General code and framework transformation (directs COBOL workloads to Transform for Mainframe) |
| AWS Application Migration Service | Server/infrastructure lift-and-shift |
| AWS Database Migration Service | Database replication and schema conversion |
These tools solve different problems. Choose your application's disposition first, then match the right service to each layer of work.
How the Mainframe Modernization Workflow Works
A realistic modernization effort moves through distinct phases. Skipping any of them tends to surface problems later, usually during testing or cutover.
Portfolio discovery — Inventory every program, copybook, JCL script, database, file, interface, batch schedule, and transaction volume. Identify owners, compliance requirements, and operational dependencies.
Context gathering — Collect business documentation, architecture diagrams, sample code, test data, runbooks, exception-handling rules, and input from the subject-matter experts who actually understand the system's quirks.
Assessment and analysis — Use the gathered inputs to map business logic, surface hidden dependencies, classify applications, and prioritize candidates by business value, complexity, and risk.
Planning and design — Select target architecture, decide on domain decomposition, plan API or event-driven integration, choose a data migration approach, and define cutover sequencing with a rollback plan.
Transformation and testing — Generate code and architecture changes, then run functional-equivalence testing, regression testing, performance testing, and security review. Human approval gates every step before production.
A Hypothetical Pilot Example
Picture a mid-sized insurer with a claims-processing mainframe. Rather than tackling the entire system, the team picks a bounded component — say, a low-risk batch job that calculates claim status updates overnight.
They run it through AWS Transform and review the extracted business rules against what claims adjusters actually do. The team validates generated test cases and compares output against the mainframe for several processing cycles.
Only after that validation holds up do they expand scope to higher-risk components. This is illustrative, not a documented case, but it reflects how most successful modernization programs sequence their work.
Benefits, Risks, and Decision Factors
What Speeds Up
Agentic AI accelerates the slow parts of modernization:
- Faster portfolio analysis across thousands of programs
- Better documentation where none existed before
- Repeatable testing scaffolding instead of starting from scratch
- More modernization candidates evaluated in the same timeframe
AWS reported in its one-year retrospective that customers transformed and tested 250,000-line mainframe applications in six weeks. That figure is vendor-reported and unnamed — treat it as a directional benchmark, not a guarantee for your environment. Run your own pilot to establish a realistic baseline.
Speed Isn't Production Readiness
Generated code, inferred business rules, decomposed services, and test cases all require human review. Mainframe specialists, application owners, security teams, and business stakeholders each need a seat at the table.
An AI-extracted rule that looks correct can still miss an exception case that only shows up once a quarter.
A Decision Framework
| Choose This | When |
|---|---|
| Retain | Application is stable, low-change, and modernization risk outweighs benefit |
| Rehost | Need quick infrastructure relief without touching code |
| Replatform | Want modest cloud benefits with minimal code disruption |
| Refactor | Logic is sound but language/platform needs modernizing |
| Reimagine | Business capability itself needs redesigning for cloud-native operation |
| Retire | Functionality is obsolete or duplicated elsewhere |
Base the choice on business criticality, change frequency, performance requirements, data coupling, and regulatory obligations — not on which option sounds most modern.
Risks Worth Naming
- Incomplete source inventories that surface mid-project
- Undocumented exception handling that generated code misses
- Inaccurate business-rule inference requiring manual correction
- Batch-window disruption during cutover
- Loss of institutional knowledge if SMEs aren't involved early
Security, Governance, and Readiness Requirements
Before uploading any source code or mainframe artifacts to a modernization service, regulated organizations need clear answers on several fronts.
Core Controls to Verify
- Identity and access management with least-privilege roles and multi-factor authentication
- Encryption at rest and in transit, including options for customer-managed keys
- Logging and audit trails covering every API call and data access event
- Data residency confirming which Region actually processes and stores your data
- Network boundaries and separation of duties between teams handling source code versus deployment
For sensitive test data, masking, tokenization, or synthetic data are standard practices, but verify directly with AWS which of these your workflow actually supports before assuming native capability exists.
Governance for AI-Generated Changes
Treat every AI-generated artifact like code from a new contractor: review it before it ships. That means:
- Version-controlled outputs with clear change history
- Immutable audit trails from source code to target implementation
- Explicit approval gates before anything reaches production
- A documented process for rejecting or correcting generated results
A Readiness Checklist
Before starting, confirm you have:
- A reasonably complete source code and dependency inventory
- Existing test coverage mapped against business-critical functions
- SME availability during the assessment and validation phases
- A defined target AWS architecture
- Measurable business success criteria
- A tested rollback plan
Don't assume every AWS Region or every compliance framework is automatically supported. Confirm current service availability and compliance documentation for your specific workload before committing regulated data.
Where an AWS Partner Can Help
Mainframe modernization touches architecture, security, testing, and change management all at once. Most internal IT teams are stretched thin just keeping the mainframe running day to day, let alone running a parallel modernization assessment.
An experienced AWS Partner typically helps with:
- Portfolio assessment and prioritization
- Target-state architecture design
- Business-case development for leadership buy-in
- Security and compliance planning specific to the workload
- Pilot selection and migration-wave sequencing
- Testing strategy and change management
Cloudtech is a boutique AWS Partner working with U.S. small and medium-sized businesses, built by a team that's 70% former AWS employees with over 100 AWS certifications between them. The firm's approach centers on translating AWS capabilities into an actionable plan rather than handing clients a stack of documentation and walking away.
That means helping a mid-market healthcare or financial services organization scope what a mainframe assessment should cover, how to sequence a pilot, and which governance controls must be in place before any sensitive data moves. That scoping draws on the same AWS architecture review process Cloudtech already runs for cloud migration and modernization engagements.
Cloudtech doesn't replace AWS documentation or deep mainframe subject-matter expertise. It bridges the gap between what AWS Transform offers and what your organization needs to execute safely.
If you're weighing a mainframe modernization assessment, architecture review, or pilot plan, Cloudtech's AWS consulting team can help you scope the next step.
Frequently Asked Questions
What is the AWS Migration Service?
AWS offers several migration services, including AWS Application Migration Service and AWS Database Migration Service. AWS Transform for Mainframe is separate and focuses on mainframe-specific analysis and modernization.
Does AWS have mainframes?
No. AWS provides cloud infrastructure and modernization services rather than customer-owned mainframe hardware. AWS Transform and related services support migrating or modernizing mainframe workloads onto AWS cloud infrastructure instead.
What are the top 5 AWS services?
There's no universal top-five list; the right services depend on your use case. Common picks include compute (EC2), storage (S3), databases (RDS), networking (VPC), and migration tools matched to the workload.
Is the AWS Migration Hub still available?
AWS Migration Hub stopped accepting new customers as of November 7, 2025, though existing customers can continue ongoing projects. AWS now recommends AWS Transform for new migration and modernization initiatives.
What are the 3 types of storage services offered by AWS?
AWS offers object storage (Amazon S3), block storage (Amazon EBS), and file storage (Amazon EFS). Mainframe modernization projects typically also need database, archival, backup, and data-transfer services beyond these three categories.
