If your mainframe plan was built on the AWS Mainframe Modernization service and you hadn’t signed up yet, that door is closed. AWS stopped accepting new customers for the service on July 30, 2026. Existing customers can keep using it. For new projects, AWS points people to AWS Transform for mainframe and to offerings bought directly from the vendors that used to be packaged inside the service.
The mainframe exit itself is still very doable. What changed is how you put it together. Instead of one AWS console bundling the replatform, data replication and runtime tools, you now assemble the pieces yourself: an AI-assisted refactoring toolchain, a rehosting vendor contracted directly, or a staged offload that keeps the mainframe running while work moves off it piece by piece. This guide is for CIOs and mainframe program leads at banks, insurers, airlines and state agencies who need to re-plan.
What exactly did AWS change?
On June 30, 2026, AWS published a list of services moving to maintenance. AWS Mainframe Modernization – Self-Managed Experience was on it. AWS said services moving to maintenance would no longer be open to new customers starting July 30, 2026, and that customers already using them could continue.
The service’s availability change page covers both versions of the service:
- Self-managed experience. No longer open to new customers. AWS lists the affected capabilities as Replatform with Rocket, Data Replication with Precisely, Replatform with NTT DATA, Assembler Conversion with mLogica, and SPARC Virtualization with Stromasys. AWS says it will not add new features but will keep providing security updates and service availability. For similar capabilities, it points to vendor-direct offerings and AWS Transform.
- Managed Runtime Environment experience. Also closed to new customers. This was the managed version of the Rocket replatforming runtime. AWS says existing customers keep full support and that AWS ProServe can help them move to self-managed options.
In short, what’s gone is the ability for a new customer to start on the service. What isn’t gone: the service itself for existing customers, the underlying vendors, and AWS Transform for mainframe.
What does this mean if we were planning on it?
It depends on where you were.
- Already running on the service. You can keep going. AWS says it will keep the service available and patched so ongoing projects can finish. But no new features are coming, so plan for where the workload lives long term. We’d treat it as a place to finish the current project, not something to build the next ten years on.
- Mid-evaluation, not yet onboarded. Your business case probably assumed AWS’s bundled tooling and one bill. Redo it with the vendors contracted directly, or with the refactoring path, and recheck the timeline.
- Still deciding whether to leave the mainframe. Not much changes. The decision was never about one AWS service. It comes down to cost, risk, skills and how tangled the applications are.
What are the realistic paths now?
Can we refactor with AWS Transform and coding agents?
This is where AWS is putting its effort. On October 12, 2026, AWS described a workflow in which AWS Transform for mainframe reverse-engineers COBOL, PL/I and JCL into a catalog of business functions and extracted business rules. Each rule traces back to the source lines it came from, and the output is written as technology-agnostic requirements. A coding agent (Devin, in that post) then turns approved requirements into service specifications, a backlog, code, tests and migration scripts, with each change arriving as a pull request for the team to review.
Two details in that post matter for planning. First, AWS says a business owner confirms the extracted requirements are the intended behavior before anything is built on them. Second, merges still need human review. So the tools can speed up the reading and the typing, but your people still have to make the decisions.
AWS Transform can be driven from a web console, from an IDE, from a CLI or through MCP, and all of them share the same workspace. In practice, architects and approvers can work in the console while engineers stay in their editors.
This path fits applications you want to redesign as cloud-native services, not just move. It’s also where “cobol to java conversion using ai” ends up. We’ve written more on what AI does and doesn’t do in COBOL modernization.
Can we still replatform with the rehosting vendors?
Yes. The vendors that used to sit inside the service, including Rocket, Precisely, NTT DATA, mLogica and Stromasys, still exist, and AWS’s own guidance points to buying from them directly. Replatforming keeps most of the COBOL as is and runs it on an emulated mainframe environment in the cloud. It’s usually the fastest way to get off the hardware or out of a data center contract, and it leaves the application logic for a later phase.
The trade-off is that you now negotiate licensing, support and runtime operations with the vendor yourself, instead of through one AWS service. Get clear answers on who runs the runtime, who patches it, and how licensing scales.
What about a staged offload?
Many organizations don’t need, or can’t risk, a single cutover. A staged offload (the strangler pattern) moves pieces off one at a time: reporting and analytics first, then read-heavy inquiry functions, then batch jobs, then the transactional core. Data replication keeps the mainframe and the new platform in sync while both are live.
This approach takes longer and means paying for two platforms for a while. In return, each step is small enough to test, reverse and explain to auditors. For a bank or a state agency with strict uptime and audit needs, that’s often worth it.
Should we just stay and optimize?
Sometimes, yes. If the mainframe is stable and the main problem is cost, start by cutting the usage that drives your software bill: tuning peak workloads, moving batch jobs off peak, and offloading eligible work to specialty engines. IBM’s Tailored Fit Pricing changes how that usage is metered. We cover the mechanics in why your z/OS software bill follows the peak. Staying put for three years while you build skills and clean up the code is a legitimate plan, as long as it’s a decision and not a default.
What still needs a human team, whatever tools we pick?
No toolchain removes these, and they’re usually where schedules slip:
- Business-rule sign-off. Extracted rules tell you what the code does today. Someone in the business has to say whether that’s what it should keep doing, including the odd rules nobody can explain.
- Data cutover. EBCDIC to ASCII, packed decimal, VSAM and IMS structures, sort orders and date formats. Moving data correctly, and on schedule, is its own project.
- Parallel runs. Running old and new side by side on real volumes, and comparing outputs line by line, is how you earn the right to turn the old one off.
- Proving equivalence. Regulators, auditors and your own risk team will want evidence that interest calculations, claims rules or benefit determinations didn’t change. Plan the test strategy before you write the code.
- Operations and batch. JCL schedules, restart and recovery, month-end and year-end jobs. These rarely appear in demos and always appear in production.
The tool reads the code. A person still has to approve what the code is supposed to do.
How should we scope and buy the engagement?
Start with an assessment
Before committing to a path, pay for a bounded assessment, typically a few weeks. It should produce an inventory of programs, copybooks, JCL, data stores and interfaces; a map of dependencies; a classification of each application by path (retire, keep, replatform, refactor); and a sequencing plan with the first wave defined. If someone proposes a fixed price for the whole migration before seeing the code, ask how they priced it.
Questions to ask any firm
- Which of these paths have you delivered, and what did you do when extracted rules were wrong?
- How will you prove functional equivalence, and who signs off?
- What’s your data migration and reconciliation approach?
- How long do you plan to run in parallel, and what are the exit criteria?
- Who owns the code, tests and documentation at the end?
- What does our team need to learn to run the new system without you?
Red flags
- A promise of automated conversion with little or no testing budget.
- No business-side owner named for rule approval.
- A cutover plan without a rollback plan.
- Pricing that only covers code conversion and leaves out data, testing and operations.
- A plan that depends on one tool or service with no fallback. As this change shows, that dependency can shift under you.
FAQ
Is AWS Mainframe Modernization being shut down?
AWS hasn’t announced a shutdown. It says the service is closed to new customers and will keep running, with security updates, for existing customers. No new features are planned.
When did AWS Mainframe Modernization stop accepting new customers?
AWS announced the change on June 30, 2026, and said new customers lost access starting July 30, 2026.
What does AWS recommend instead?
For self-managed capabilities, AWS points to vendor-direct offerings and AWS Transform. For the managed runtime, AWS points existing customers to the self-managed version and offers ProServe help with the move.
Is AWS Blu Age still an option?
AWS’s own guidance for refactoring now centers on AWS Transform for mainframe, which AWS describes as the refactor capability. Ask AWS directly about the specific tooling and licensing your project would use.
Can AI convert COBOL to Java on its own?
AI can speed up reading legacy code, extracting rules and writing new code and tests. AWS’s own workflow still has people approving requirements and reviewing every merge. Plan for that time.
How long does a mainframe exit take?
It depends on code size, data complexity, how tangled the applications are, and how much parallel running your risk team requires. An assessment is the honest way to get a number.
Where do we fit?
We help teams scope and run mainframe migration work: the assessment, the path decision for each application, and the engineering that the tools don’t cover, from data cutover to parallel runs. If AWS’s change has left your plan with a gap, book a call and we’ll walk through where you are.
