Business Challenge
Mainframe modernisation is the longest, most expensive and least reversible programme most organisations will run. It is also the one where the reference architecture is most likely to have been drawn a year before anyone starts, and never revisited.
The classic framing is a choice between two patterns: refactor, converting COBOL into a modern stack, or replatform, recompiling the application largely unchanged onto a supported runtime. Both were reachable through one AWS service. Neither is, for anyone starting now.
The Managed Runtime Environment experience “has stopped accepting new customers”, and “New projects will be directed to the self-managed version.”
The self-managed experience is “no longer open to new customers”, directing you instead to “capabilities from vendor-direct offerings and from AWS Transform”.
Read in sequence, the first sends a new customer to a door the second says is shut. Both notices are accurate for the audience each was written for — the managed notice speaks to existing customers, for whom self-managed is genuinely available — but a new reader arriving at the top of the page gets a loop.
The self-managed change is not one product. AWS lists exactly what it covers: Replatform with Rocket, Data Replication with Precisely, Replatform with NTT DATA, Assembler Conversion with mLogica, and SPARC Virtualization with Stromasys.
That list is more useful than it first appears. Those five are not gone — they are the vendors whose software this was packaging. What closed is the route to them through AWS. The capability is still purchasable; the procurement path changed from one AWS service to five separate commercial relationships.
Existing customers “can continue using the service with no disruption to their ongoing modernization projects”. AWS will not add new features, but commits to “providing security updates and maintaining service availability”.
There is no end-of-life date, no forced migration and no countdown. For a programme already under way that is genuinely reassuring. For a programme being planned it is the whole problem: the service will keep working, keep being documented, and keep appearing in search results, while being unavailable to you.
Refactor or replatform is the question every mainframe workshop opens with, and it is the right question when both are available on comparable terms. They are not.
Refactoring has a live AWS path: AWS Transform for mainframe. Replatforming does not — it has a live vendor path, contracted directly. A workshop that weighs the two purely on technical merit is comparing an AWS service against a procurement exercise, and will reach a conclusion the commercial reality then overturns.
Architecture
The technical patterns are unchanged. What changed is who you buy each one from, and that is the part a reference architecture does not usually record.
What the self-managed version actually is
The FAQ is the clearest statement on the page: the self-managed version “provides runtime functionality for both Rocket Software (replatform) and AWS Transform for mainframe (refactor) capabilities”.
So the two patterns were never one implementation. Refactoring runs through AWS Transform; replatforming runs on Rocket Software, formerly Micro Focus. The service was the wrapper around both, and it is the wrapper that closed — which is why the two halves ended up with different futures.
Managed and self-managed were runtime models, not patterns
The managed runtime and the self-managed runtime were two ways to operate the same third-party software: AWS runs it, or you do. That is an operational choice, and closing the managed one narrows how you run it rather than what you can build.
For existing managed customers the transition path is explicit, and it is a services engagement rather than a migration tool: “AWS ProServe can be enlisted to assist with the transition to using self-managed options.” That is a reasonable answer and it is worth reading as what it is — moving off a managed runtime onto one you operate is a project, not a setting.
What a new customer can contract for today
| Pattern | Live path for a new customer | Bought from |
|---|---|---|
| Refactor — convert the application stack | AWS Transform for mainframe | AWS |
| Replatform — recompile largely unchanged | Rocket Software, or NTT DATA | The vendor, directly |
| Data replication off the mainframe | Precisely | The vendor, directly |
| Assembler conversion | mLogica | The vendor, directly |
| SPARC virtualisation | Stromasys | The vendor, directly |
| Any of the above, already contracted | Continue as you are | Unchanged |
One AWS relationship became one AWS relationship plus up to four vendor relationships. That is a procurement, legal and support-model change before it is a technical one, and it lands on a programme that is already the most contractually complex thing in the portfolio.
Why This Architecture Holds Up
A service closed to new customers occupies a state that architecture documents have no notation for. It is not deprecated. It is not end-of-life. It has no sunset date. Its documentation is complete and maintained, its console works, and everything written about it before the change is still technically accurate.
It is simply unavailable to you, and the only place that is recorded is a banner on a documentation page that nobody reads when they are copying a reference architecture from a slide deck.
Mainframe programmes are where this costs the most. They are planned furthest ahead, they involve the most external parties, and the gap between drawing the architecture and procuring against it is measured in quarters. A plan drawn a year ago against a service anyone could buy is now a plan that cannot be executed as drawn, and nothing in the plan says so.
Key Architecture Decisions
| Decision | Take this | Because |
|---|---|---|
| Framing the pattern choice | Ask what you can contract for, before asking refactor or replatform | Only one of the two still has an AWS-purchasable path for a new customer |
| If you are already a customer | Continue, and finish the programme you started | No disruption, continued security updates, no sunset date |
| Existing managed runtime customers | Plan the move to self-managed as a project, with ProServe if useful | AWS names ProServe as the transition mechanism, which tells you its size |
| Replatforming as a new customer | Approach Rocket Software or NTT DATA directly | The capability is intact; only the route through AWS closed |
| Refactoring as a new customer | AWS Transform for mainframe | It is the live AWS path and the one the closure notices point at |
| Vendor management | Budget for the contracts, support model and legal review you no longer inherit from AWS | One relationship became several, and that cost is invisible on a technical diagram |
| Any reference architecture older than a quarter | Re-check availability of every named service before committing to it | Closed-to-new-customers has no deprecation signal and no end date to notice |
Closing Thought
None of this makes mainframe modernisation on AWS harder to do. The patterns work, the software is the same software, and AWS Transform is a real path for the refactoring case. What changed is that the answer to "how do we buy this" is no longer one line.
The lesson generalises past mainframes. Closed to new customers is the failure mode with no signal — no deprecation notice in your console, no expiry date, no warning in a bill. The only way to catch it is to check availability at the moment you commit, rather than trusting a document written when the service was open.
Comments