The vendor matrix
The mainframe modernization vendor matrix
Every serious option, one table — including the matchups we’re not in. Where we compete, we say so and recuse.
PalmDigitalz Research · 16 min read · July 2026
“Mainframe modernization” is one phrase covering at least five different activities. One vendor means moving your workload to new hardware without touching the code. Another means recompiling the same COBOL on Linux. A third means machine-translating it to Java. A fourth means running an AI copilot on the mainframe you keep. A fifth — us — means extracting the business rules with evidence and letting you choose the destination. All five bill it as modernization. Only some of them end with less mainframe than you started with.
This page is the table we wish had existed when buyers first started asking us “versus whom?” It lists every option we consider serious, described by what it actually does, at the level of each vendor’s own public positioning. If you want the doctrine behind the choices — when each of the 7 Rs is the right call — that lives in The Exit Doctrine.
A word on why it looks the way it does. Most vendor-comparison pages on the internet are rankings, and rankings require a single axis; this market does not have one. A bank exiting a data center by December, an insurer whose pricing logic must land inside S/4HANA, and an agency that simply needs its COBOL maintained for another decade are not shopping in the same aisle — the “best vendor” for one is a category error for the others. So this table ranks nothing. It tells you what each option produces, who it genuinely serves, and where its bill arrives later than its brochure.
How to read this page
- Columns are capability categories, not rankings. There is no weighted score and no winner’s badge. Different estates need different rows.
- Every cell is drawn from public positioning — vendor sites, documentation, and announcements. Where a characterization is contestable, we hedge it rather than harden it into a verdict, and we publish no benchmark numbers about competitors.
- PalmDigitalz is in this table. Where we’re a player we won’t pretend to be the referee: our row is marked player · judge for yourself, and the head-to-head sections below the matrix cover only matchups we are not in.
First, the vocabulary
The approach column uses five words with precise meanings. They are not interchangeable, and most vendor disappointment starts with treating them as if they were.
- rehost
- Move the workload, keep the code. Emulation or compatible execution on new infrastructure. Fastest; changes nothing about the software.
- replatform
- Recompile the same language on a new platform. COBOL stays COBOL; the hardware bill changes.
- refactor
- Automated translation into a new language, structure largely preserved. The language changes; the design mostly does not.
- rewrite
- New code, human- or machine-authored, built from a specification. Highest ceiling, highest risk — the risk is the specification.
- rules extraction
- Recover the business rules first, with source lineage, then choose any of the above with evidence in hand. The approach this site exists to argue for.
The matrix
Every serious option, one table
Scroll sideways on smaller screens. The watch for column is each vendor’s genuine caveat, stated the way we’d want ours stated.
| Vendor / approach | Approach | Primary target | Who it’s really for | Strongest when | Watch for | Lock-in surface |
|---|---|---|---|---|---|---|
| IBM watsonx Code Assistant for Z | Refactor in place — modernize on Z | IBM Z: better-maintained COBOL, or Java that runs on Z | Estates committed to staying on the mainframe | The platform decision is “stay” and the pain is developer scarcity | Designed to make life on Z better, not to end it — workload and MIPS stay unless you add a separate exit program | IBM Z hardware and software stack, plus watsonx tooling |
| AWS Transform blu age lineage | Automated refactor to Java | AWS-hosted Java in a managed runtime | Organizations already committed to AWS as the destination | AWS-hosted Java is where the business was always going and speed matters | One destination; evaluate a sample of the generated Java against the maintainability bar of the team that will own it | AWS cloud, managed runtime, and tooling |
| Micro Focus / OpenText | Replatform — recompile | .NET or JVM on Windows, Linux, or any cloud | Teams that want off the hardware while keeping COBOL as COBOL | The deadline is the data center, not the language | The COBOL remains COBOL — skills dependency and application complexity carry over intact | COBOL runtime licenses on the new platform, ongoing |
| Kyndryl | Services — run, then transform with partners | Hybrid; customer’s choice via hyperscaler partnerships | Estates that want one accountable operator for the whole environment | The mainframe must be run well today while the exit is planned | Run-and-transform under one roof needs explicit decommission milestones so both halves of the business pull the same way | Operational dependency on the provider relationship |
| Accenture / large SIs | Program delivery across all of the Rs; tooling assembled per engagement | Whatever the statement of work says | Enterprises that want a single accountable partner for a multi-year program | Delivery scale, staffing, and change management are the hard part | Labor-based pricing; the understanding your program generates can live in the engagement team unless you contract for artifacts | Knowledge and momentum concentrated in the engagement team |
| LzLabs | Rehost — managed software container, no recompilation | Linux, on-prem or cloud | Estates that need the workload moved with minimal change to code | Leaving the hardware is the goal and touching the code is off the table | The application arrives unchanged — modernizing the code itself is a separate, later program; review runtime licensing and support posture with your counsel | The compatibility runtime layer |
| Astadia amdocs company | Rehost / refactor migration factory | Azure, AWS, or GCP reference architectures | Mid-to-large estates that want a specialist migration partner | Your stack matches a path the factory has walked many times before | Factory speed depends on your estate matching the pattern — inventory the exceptions before you sign for the average | Target-cloud commitments made during the move |
| Heirloom | Automated refactor — compile COBOL/PL/I to Java | Java on cloud platforms | Teams wanting fast automated conversion at compile-level fidelity | Like-for-like functional equivalence, quickly, is the whole brief | The generated Java preserves the original program structure — decide whether that is the codebase your engineers want to own | The compilation framework and its runtime libraries |
| TSRI | Automated rewrite — model-based transformation | Java, C#, and other modern languages | Public-sector and defense-adjacent estates, often with unusual source languages | The language is exotic and the code must be transformed wholesale | Translated code mirrors the legacy structure unless refactoring passes are explicitly scoped in | Low on output — the code is yours; re-engagement for further passes |
| Generic LLM / GenAI DIY | Probabilistic translation and explanation with a foundation model | Anything — that is the appeal | Teams exploring, documenting, prototyping | Drafting documentation, explaining code to humans, low-stakes assistance | Probabilistic: same prompt, different output each run; in our benchmark, roughly 30% of extracted rules were correct, with no source lineage | None contractually — but unverifiable output becomes its own dependency |
| PalmDigitalz player · judge for yourself | Rules extraction first — extract, verify, forward-engineer | Your choice: open microservices on any cloud or on-prem, or your ERP | Estates that want the logic off the mainframe with evidence attached | The destination must stay your decision and auditors need lineage | We are a player in this table, so read this cell skeptically; if your strategy is to stay on Z, we are the wrong tool | None by design — target-agnostic; the extracted asset is yours |
capability categories · not rankings · sourced from public positioning · july 2026
One reading note before the head-to-heads: real programs combine rows. A rationalization pass decides that a third of the portfolio should simply retire; a rehost or replatform clears the hardware deadline for the workloads that only need a new home; extraction handles the crown jewels whose logic must survive the move intact and provable. The estates that get into trouble are rarely the ones that picked the “wrong” vendor — they are the ones that applied a single row to an estate that needed three.
Refereed
The matchups we’re not in
A vendor page that only compares itself favorably is a brochure. These three head-to-heads are decisions our readers actually face, in which PalmDigitalz is not a contender. We referee them straight, because the trust is worth more to us than the deflection.
AWS Blu Age vs Micro Focus replatforming
These two compete for the estate that wants off the hardware without a full rewrite budget, and they solve it in opposite ways. AWS Transform’s mainframe capability descends from Blu Age, the automated-refactoring firm AWS acquired : it machine-translates COBOL into Java that runs in an AWS managed runtime. The language changes, the platform changes, and the COBOL skills dependency ends. Micro Focus — now part of OpenText — goes the other way: your COBOL stays COBOL, recompiled under its enterprise runtime to run on .NET or the JVM, on Windows, Linux, or any cloud. Nothing about the code changes except where it executes.
The tradeoff is continuity against transformation. Replatforming is usually the shorter, lower-drama path: your team’s knowledge transfers on day one, the test surface stays familiar, and the data-center deadline gets met. The bill is that the language clock keeps ticking — you still need COBOL engineers, now plus runtime licenses on the new platform, indefinitely. Refactoring to Java ends the language dependency, but hands your team a generated codebase whose structure was decided by a transformation engine rather than an architect; the sensible move is to evaluate a converted sample against your own maintainability bar before committing the estate.
Choose the Blu Age path if AWS is a settled destination and retiring COBOL matters more than continuity. Choose replatforming if the deadline is infrastructure and your COBOL bench is stable for another decade. When neither fits: if the real goal is to understand what the code does — because an ERP consolidation or a genuine rewrite is coming — neither option moves you an inch toward that. That is the extraction-first case.
IBM watsonx Code Assistant for Z vs staying put
The honest competitor to watsonx Code Assistant for Z is not another vendor. It is inertia — running the estate exactly as it runs today. If your platform decision is “stay,” CA4Z is a genuine upgrade over staying blind: it explains decades-old COBOL, assists refactoring, and converts selected programs to Java that still runs on Z. Developer scarcity is the quiet crisis of every Z shop, and modernize-in-place tooling attacks it directly.
What it does not change is the denominator. The workload, the MIPS, and the platform premium all remain; the calculation is a tooling subscription plus adoption effort, weighed against reduced key-person risk and faster maintenance. On a stable estate with a retiring bench, that math can genuinely work — a documented mainframe beats an undocumented one every day of the week, and if that is your situation we will say so in the meeting.
The distinction worth writing down: staying put with modern tooling is a strategy; staying put by default is a drift. CA4Z makes the first honorable and the second more comfortable, and only one of those is in your interest. When neither fits: if the board’s answer is exit, both flavors of staying — assisted or blind — are renovations to a room you are leaving. The moment the question becomes “what exactly would leave, and can we prove it,” that is the extraction-first case.
Kyndryl vs the large SIs
Kyndryl spun out of IBM’s infrastructure-services business in 2021 and operates mainframe estates at a scale few can match ; its modernization play grows out of operations — stabilize, manage, then transform alongside hyperscaler partners. Accenture and the other large SIs come from the opposite pole: the transformation program itself is the product — target architects, delivery factories, and change management at organizational scale, with the run side historically someone else’s job.
Choose the operator model when day-two reality dominates: the estate must keep running flawlessly through a multi-year transition, and you want the party accountable for uptime also accountable for the exit ramp. Choose a large SI when program complexity is the hard part — hundreds of applications, thousands of users retrained, a dozen workstreams that must land in order. Both are, structurally, labor businesses; neither model is wrong, but both deserve the same two contract questions: which artifacts survive your departure, and which milestone actually shrinks the estate rather than merely reporting on it.
When neither fits: when the missing ingredient is not hands but ground truth — a verifiable account of what the code actually does — headcount cannot produce it at any billing rate. That is the extraction-first case, and it is also why some of our best engagements run alongside an SI rather than instead of one.
Due diligence
Questions to ask any vendor on this page
- 1. When your engagement finishes, where does my business logic live — and in what form can my own team read it? “Where it always did” and “in our tooling” are both answers worth hearing early.
- 2. Run your process twice on the same program. Are the two outputs identical? If not, ask which of the two you are supposed to sign off.
- 3. For any rule, line, or screen you produce, show me the exact source lines it came from. Lineage is either a property of the pipeline or a promise about the future.
- 4. What does my team need to own the output — which skills, which licenses, which runtime, at what annual cost? The day-two bill is part of the price.
- 5. If we later leave your target platform, what do we take with us and what do we forfeit? The answer is the lock-in surface, stated by its owner.
- 6. Which parts of our estate would you advise us not to modernize at all? A vendor whose answer reduces their own fee has told you something about every other answer.
These six travel well in any first meeting. The full forty — organized by phase, with the answers that should worry you — are in the RFP kit. Ungated, like everything else here.
Full disclosure
Where PalmDigitalz fits — and where we don’t
We are the rules-extraction row. Palm 360 rationalizes the portfolio so you modernize only what earns it. Palm Key maps the estate — every program, job, and dependency. Palm Ark extracts the business rules deterministically, around 95% accurate in our benchmark, every rule carrying its source lines. Palm Ray forward-engineers them to the target you choose — open microservices on any cloud or on-prem, or straight into your ERP. Target-agnostic is the point: the asset we produce is yours to point anywhere, forever.
And where we don’t fit: if your strategy is to stay on the mainframe, in-place tooling like watsonx will serve you better than we ever will. If you need a pure infrastructure rehost finished by Q4, call a rehost specialist and go — extraction would slow you down, and we would say so in the first meeting. That kind of honesty is cheaper than the other kind.
The head-to-heads we are in, argued properly: vs AWS Transform · vs IBM watsonx · vs generic LLMs · vs lift-and-shift SIs.