Most lists of modernization tools you'll read right now are wrong, and not by a little.

The AWS tooling that anchored 2024 shortlists (Migration Hub, Application Discovery Service, App2Container, Microservice Extractor for .NET) stopped accepting new customers on November 7, 2025. Amazon Q Developer, the transformation engine everyone was citing last year, blocked new signups in May 2026 and ends support on April 30, 2027. Azure Data Studio, which shipped the SQL Server migration extension, retired outright on February 28, 2026. Bloop, the startup best known for COBOL-to-Java, shut down in April 2026.

That churn isn't a footnote. If your shortlist is a year old, part of it is already dead: there's a table of fourteen retirements near the end of this post. So this one starts from what's actually alive in August 2026, groups tools by the job they do rather than by vendor, and says plainly where the published evidence stops and the marketing starts.

One thing to be upfront about before the list starts: this is a map of a category, not an account of our own stack. Nobody has run all of these, us included, and a page that implied otherwise would be worth less to you. So the rule here is that every capability claim is traceable: vendor figures are labeled as vendor figures, benchmarks are linked to the paper, and where a tool's own documentation contradicts its marketing, the documentation wins.

What is application modernization software?

Application modernization software is tooling that helps you understand, transform and re-host an existing codebase without rewriting it from scratch. Legacy application modernization work splits across static and runtime analysis of what you already have, automated or AI-assisted code transformation, containerization and cloud replatforming, database migration, and verification that the new system behaves like the old one.

The category is broader than most vendors admit. A portfolio scanner and a COBOL-to-Java agent are both sold as software modernization, and they solve unrelated problems. Legacy modernization also gets used interchangeably with legacy system modernization, application modernization and software modernization by vendors who mean quite different things by each. Getting the shortlist right starts with naming which problem you actually have.

Which jobs does modernization tooling actually do?

Seven, and almost no product covers more than two or three of them well. Application modernization tools get sold as one category and bought as one line item, which is how teams end up with a portfolio scanner when what they needed was a test-generation agent. Treat this table as the map and the sections below as the detail.

Which tools assess a legacy estate before you touch it?

Start here, always. Application modernization assessment splits into two layers: portfolio scanners that rank hundreds of applications by risk and cloud-readiness, and deep analyzers that reconstruct the call and data graph of one application. You need the first to decide what to work on, and the second to work on it.

CAST Highlight scans a whole portfolio and produces cloud-readiness, open-source risk and tech-debt scores per application. It's broad and shallow by design, which is exactly right for rationalization. It's also one of the few vendors in this space that publishes a number: package tiers by app count, with a single-app Complete Insights license listed at $6.8K / €6.3K annually.

CAST Imaging is the deep counterpart. It reconstructs a full call and data-dependency graph down to database tables and stored procedures, claims coverage of 450+ languages, frameworks and databases, and now serves that graph to AI coding agents over the Model Context Protocol (MCP). That last part matters more than it sounds — an agent with the real dependency graph in context behaves very differently from one guessing at a codebase.

vFunction takes a different route: it combines static analysis with runtime Java Virtual Machine (JVM) and Common Language Runtime (CLR) tracing, so it sees the coupling that only shows up under load. It's specific to Java 1.6+ and .NET 4.0+ monoliths, and it exports proposed service boundaries as tickets in Jira or Azure DevOps. vFunction reports that Trend Micro cut a 2-million-line Java refactor from more than a year to under three months, with deployment time dropping from 24 hours to one. Their case studies aren't dated, so treat the figure as vendor-reported rather than independently verified.

Mainframe estates have their own analyzers, covered in the mainframe section below. The short version: Rocket Enterprise Analyzer and IBM watsonx Code Assistant for Z are the two names, and both changed hands or changed names since 2024.

One thing static analysis won't give you is what's actually running. Dynatrace Smartscape, rebuilt in January 2026 with agentless cloud discovery, maintains a live topology graph you can traverse with a query language across millions of relationships. If your estate has undocumented runtime coupling, and it does, that view is worth having before you plan waves.

Worth saying plainly: if you're reading this to build the business case rather than to choose a tool, the tooling question is premature. Start with what technical debt actually is and how to measure it, then come back.

Which tools handle mass refactoring across many repositories?

When the change is known and safe but has to happen in 600 places, you want determinism, not an agent improvising. This is the category where 2026 tooling is genuinely strong, and where the published evidence is best.

Moderne with OpenRewrite is the reference implementation. OpenRewrite parses code into a Lossless Semantic Tree (a compiler-accurate, type-attributed representation) and applies recipes against it, so a refactor either type-checks across the whole tree or fails loudly. The number worth quoting: a single Log4Shell recipe fixed 38,000 call sites across 400 repositories with zero regressions. There are 10,000+ recipes available. OpenRewrite's core is Apache 2.0 and Moderne moved its governance to the Commonhaus Foundation; the platform itself is enterprise-priced and not publicly disclosed. Moderne was named a Leader in the August 2026 Gartner Magic Quadrant.

Sourcegraph Agentic Batch Changes attacks the same problem from the search side: one prompt, find the affected repos with Deep Search, validate the change on a few, then roll out across hundreds while iterating against continuous integration (CI) failures and merge conflicts. It delegates complicated per-repo edits to Claude Code or Codex. Mercari used it in preview to patch a GitHub Actions environment-variable injection vulnerability across roughly 80 repositories. It's in public beta, at no extra cost for Sourcegraph Cloud customers. Note that Cody isn't part of this: Cody Free and Pro were discontinued in July 2025.

In the open-source and Red Hat world, Konveyor and its productized form Migration Toolkit for Applications 8.2 cover analysis-to-refactor for Java, Jakarta EE, .NET, Node.js and Go, with an AI-assisted editor integration (Red Hat Developer Lightspeed for MTA, generally available since October 2025). Worth knowing before you commit: Konveyor has been a Cloud Native Computing Foundation (CNCF) Sandbox project since 2022 and hasn't progressed to incubation, with its last release in October 2025. It's alive, not fast-moving.

Which AI tools transform legacy code, and how much can they really automate?

They can automate a lot of the typing and very little of the judgment. The honest range, from published benchmarks, is that a well-scoped mechanical migration lands most of its changes automatically, while a full idiomatic modernization succeeds closer to a quarter of the time.

The tools first.

GitHub Copilot app modernization assesses a Java, .NET or C++ application, then applies transformations, patches the build, migrates unit tests, fixes known vulnerabilities (CVEs) and containerizes for Azure — with a human-confirmed diff at each step. It's been generally available for Java and .NET since September 2025 and for C++ since June 2026, and it's included in any Copilot plan rather than sold separately. Microsoft states up to 70% less time on migration efforts and 50% less effort on upgrades; that's a vendor figure with no published methodology, so treat it as a claim, not a measurement. Microsoft was also named a Leader in the 2026 Magic Quadrant.

AWS Transform is where all of Amazon's transformation work now lives, with separate agents for mainframe COBOL to Java, .NET Framework to cross-platform .NET on Linux, VMware estates to EC2, and custom language and dependency upgrades. Its pricing is the most transparent in the category: assessment and the Windows, mainframe and VMware agents cost nothing, and the custom transformation agent is $0.035 per agent-minute, which AWS illustrates as roughly $2.52 for a 17,000-line Java upgrade. The customer numbers AWS publishes are substantial: Thomson Reuters at 1.5 million lines a month at 30% lower cost, Teamfront at 800,000 lines in two weeks, QAD saving more than 7,500 developer hours a year.

General-purpose agents belong on this list too. Cursor publishes the most specific customer evidence anyone has: National Australia Bank cut a Silverlight and .NET monolith's pre-development from two months to one week and the full migration from six months to about two, ran a mainframe Assembly migration at roughly three times expected speed, and standardized more than 6,000 developers on it. Claude Code is marketed for the same work (dependency graphs, dead-code identification, test generation before refactoring, documenting undocumented systems) with named customers but no published metrics. Both were Leaders in Gartner's separate May 2026 Magic Quadrant for Enterprise AI Coding Agents, where AWS and Google were pushed down to Challengers.

What the research actually shows

Three published studies are worth more than every vendor page combined.

• Google's int32-to-int64 migration across a 500-million-line Ads codebase: 80% of code modifications in landed changelists were AI-authored, with total effort roughly 50% lower. A JUnit3-to-JUnit4 migration hit around 87% of AI-generated changes committed without edits, covering 5,359 files and 149,000+ lines in three months. The caveats are in the paper: the team had to deliberately rate-limit the pipeline so it wouldn't overwhelm human reviewers, and review and rollout stayed largely manual.

• MigrationBench (Amazon, 2025) evaluated 300 curated Java 8 Maven repositories. The baseline scored 62.33% on a first attempt at a minimal migration and 27.00% on a maximal, idiomatic one. That gap is the whole story: getting code to compile and pass tests on a newer runtime is mostly solved; making it good is not.

• FreshBrew (2025) migrated 52.3% of 228 high-coverage Java repositories to Java Development Kit (JDK) 17 with its best-performing agent. The benchmark was built specifically to detect reward hacking (agents that pass by weakening or deleting tests) and it needs high pre-existing test coverage even to evaluate.

Read together, those three say something useful: AI transformation works best where the change is mechanical, the tests are already good, and a human reviewer is the actual bottleneck. On an untested legacy estate, none of those conditions hold yet, which is why the verification section below matters more than this one.

Which tools handle mainframe and COBOL modernization?

Five names matter, and they've converged on the same three-step shape: understand the estate, convert the code, then prove the conversion behaves identically. Mainframe modernization tools are the one corner of this market where that third step is treated as non-negotiable, which is why the tooling looks more mature here than anywhere else on this page.

If you're searching for legacy modernization tools and landing on mainframe vendors, that's why: the mainframe end of the market got organized first, and it set the vocabulary everyone else now borrows.

AWS Transform for mainframe (the service most people still search for as AWS mainframe modernization) refactors COBOL, copybooks, JCL, procedures, DB2 definitions and CICS into Java, and it's been generally available since May 2025, with the refactor path reaching general availability across 18 regions in March 2026. Code transformation moved to no cost, and AWS dropped the three-tier certification requirement it used to impose. If you're comparing on price alone, this is the cheapest serious entry point.

IBM watsonx Code Assistant for Z runs a seven-stage workflow (Understand, Generate, Explain, Optimize, Refactor, Transform, Validate) across COBOL, PL/I, REXX, Assembler and JCL, targeting Java. Release 2.8 added agentic workflows over the Model Context Protocol and business rule discovery. One caution on the numbers in circulation: the frequently cited 50% faster Db2 patching figure belongs to watsonx Assistant for Z, a different product, and shouldn't be attributed to the code assistant.

Google Cloud ships four generally available pieces: Mainframe Assessment Tool for business-rule extraction and test-case generation, Mainframe Modernization Agents for conversion to Java or C#, Dual Run for replaying live production traffic against the converted system, and Mainframe Connector for data movement.

Rocket Enterprise Analyzer covers the understanding step alone: code and data flow visualization, business-rule extraction, impact analysis across IBM Z, COBOL and PL/I. It's the product formerly sold as Micro Focus, then OpenText, Enterprise Analyzer; Rocket closed a $2.275B acquisition of OpenText's Application Modernization and Connectivity business, so the old vendor path is dead. Mechanical Orchard's Imogen takes the opposite emphasis, building synthetic replicas of production data flows to diff transactions between old and new.

One shift worth flagging: general-purpose coding agents are now being pointed at COBOL directly rather than through a specialist vendor. Claude Code markets COBOL analysis explicitly, and Cursor reports that National Australia Bank ran a mainframe Assembly migration with it at roughly three times expected speed. Whether that holds up across regulated estates with forty years of undocumented exception paths is genuinely unproven — but the specialist vendors no longer have the category to themselves.

We should be straight about our own position here: mainframe modernization isn't work we do. This section exists because "application modernization software" and "mainframe modernization tools" are the same search for a lot of people, and a list that quietly omitted the mainframe options would be a worse list. If your estate is COBOL on IBM Z, the five names above are where to start, and a systems integrator with mainframe practice is a better partner than a product studio.

What handles containerization and replatforming?

For getting a legacy app into a container and onto a platform, the strongest default in 2026 is buildpacks rather than hand-written Dockerfiles, because centralizing the base image is what lets you patch CVEs across an estate later.

Cloud Native Buildpacks graduated from the CNCF on August 11, 2026, with adopters including DigitalOcean, GitLab, Google, Bloomberg and Salesforce. Paketo provides the production implementations for Java, GraalVM, Go, .NET Core, Node.js, PHP, Python and Ruby. Both are free.

Above that, the platform choice is mostly about how much Kubernetes you want to own. Red Hat OpenShift 4.21, generally available since February 2026, adds cross-cluster live migration of virtual machines, which is genuinely useful when VMs and containers have to coexist for two years mid-migration. Azure Migrate's App Containerization tooling handles ASP.NET and Java web apps into App Service or Azure Kubernetes Service (AKS), though the classic Azure Migrate experience is being phased out over roughly three years from May 2025.

At the other end, Upsun (renamed from Platform.sh), Render, Fly.io and Railway all publish per-seat and metered pricing and remove Kubernetes from the equation entirely (often the right answer for a Web App that never needed a cluster).

For infrastructure as code during a migration, OpenTofu reached 1.12.0 in May 2026 and is the license-safe path. Terraform is now IBM's, with all commercial product lines renamed after operations transitioned on September 1, 2025. Pulumi publishes real numbers (Team at $40/month base, Enterprise at $400/month base) and ships Neo, an infrastructure agent that proposes changes and reviews pull requests.

Two things to remove from any older shortlist: AWS App2Container closed to new customers on November 7, 2025, and Google Migrate to Containers lost its console interface and migctl back in May 2024, leaving only a maintenance-mode local command-line tool.

What handles the database, the part that ruins timelines?

The data layer is where modernization schedules go to die, and the tooling answer is almost always incremental replication rather than a big-bang cutover.

AWS Database Migration Service does homogeneous and heterogeneous migrations with ongoing change data capture (CDC), so old and new can run in parallel until you're confident. DMS Schema Conversion, built on the old Schema Conversion Tool engine, is free beyond S3 storage and added generative-AI conversion across nine more regions in March 2026. The standalone AWS Schema Conversion Tool desktop app is still downloadable, but its last build is dated May 2023: treat it as frozen and use DMS Schema Conversion instead. Google Cloud Database Migration Service covers Oracle and SQL Server into Cloud SQL and AlloyDB, with Gemini-powered conversion quality assessments generally available since May 2026.

On Azure, the path changed materially. Azure DMS classic's SQL Server scenarios retired on March 15, 2026, and Azure Data Studio's migration extension retired on February 28, 2026. The current route is SQL Server enabled by Azure Arc, using Managed Instance link for real-time replication or Log Replay Service for continuous backup and restore.

The open-source layer is where the interesting work is. Debezium (3.6 as of August 2026) is the standard mechanism for strangler-fig migration at the data layer: log-based change data capture streaming row-level changes so you can keep a legacy store and a new one in sync without dual writes.

pgroll applies Postgres schema changes as expand-and-contract migrations that expose multiple schema versions at once, so old and new application versions read and write concurrently (the cleanest current answer to zero-downtime schema evolution, though it's still pre-1.0). Flyway and Liquibase get the schema under version control in the first place, which is the unglamorous prerequisite for all of it. Note that Liquibase Pro no longer exists: it became Liquibase Secure in September 2025, under the Functional Source License.

How do you prove the new system behaves like the old one?

This is the question 2026 tooling is organized around, and the reason to be skeptical of any vendor selling translation alone. Google built Dual Run to replay live production traffic against the migrated app and compare outputs. IBM built a Validate stage for COBOL-to-Java semantic equivalence. Mechanical Orchard's Imogen builds synthetic replicas of production data flows and diffs transactions, reporting rates exceeding 10,000 lines of code per engineer per week, a vendor figure with no named customer behind it.

Even that has limits worth naming. As Hyperframe Research put it about Imogen, behavioral proof is only as strong as behavioral coverage. Synthetic replicas can't guarantee every seasonal pattern and undocumented exception path is captured.

For everyone not modernizing a mainframe, the practical stack is smaller and mostly free:

• Verify (31.20.0, June 2026) is the current golden-master approach for pinning legacy .NET behavior before you refactor. Use it instead of ApprovalTests.Net, whose own README now says it isn't actively maintained.

• Diffblue autonomously writes and verifies unit tests across a Java or Python codebase, orchestrating Copilot or Claude Code, a fast way to build a characterization-test net on untested legacy code.

• opendiffy/Diffy multicasts each request to candidate, primary and secondary instances, subtracts noise, and tells you whether the new build is safe. Cite the opendiffy fork; the original twitter/diffy was archived in 2020.

• GoReplay (now part of Probe Labs) captures live HTTP traffic and replays it into a test environment. Speedscale and Keploy do the same at the Kubernetes and kernel layers respectively.

• Pact and PactFlow prove a decomposed service still satisfies the consumers the monolith served. Testcontainers makes the resulting integration tests deterministic.

If you only adopt one category from this whole list, adopt this one. Every published benchmark above depends on test coverage that most legacy estates don't have, which means verification tooling isn't the last step of a modernization program. It's the second, right after working out what you have.

What got discontinued since 2024?

Enough to invalidate most shortlists. This is the table to check your own against.

How should you choose?

Match the tool to the risk you're carrying, not to the vendor demo you sat through. Four questions get you to a shortlist:

1. Do you know what you have? If not, a portfolio scanner for a large estate or a dependency analyzer for one gnarly application. Weeks, not months.

2. Can you tell if you broke it? If the estate has no meaningful test coverage, buy verification tooling before transformation tooling. Every benchmark on this page assumes coverage you may not have.

3. Is the change mechanical or does it need judgment? Deterministic recipes for the same safe change in hundreds of places. AI agents for framework upgrades and language ports where a human reviews the diff. Neither, for anything where the seam is a product decision.

4. Can you afford to run both systems in parallel? If yes, change data capture and traffic replay de-risk the cutover enormously. If no, your tooling budget should shift toward proving equivalence up front.

Note what this list deliberately doesn't settle: whether to rehost, replatform or refactor in the first place, and what the sequencing looks like across a multi-year program. Those are strategy questions that come before tool selection, and the closest thing we've written to an answer is three approaches to a technology stack revamp.

Where tooling stops

Tooling tells you the graph. It doesn't tell you where to cut.

When we modularized the ClearanceJobs iOS app, discovery was never the problem. Everyone could see the app had outgrown its structure: it started as a job search product and accumulated live streaming, a busy social feed, real-time chat with attachments, and full company search. Clean builds had crept up to five to ten minutes, and developers were losing around 1.5 hours a week to compilation alone. Splitting it into Swift Packages brought a clean build down to roughly 30 seconds, which Paulo Leite wrote up in detail.

No tool on this page would have made that call. The dependency graph was legible enough. The real question was which seams were worth the cost of cutting, and which modules would still make sense in two years. A product judgment, not a code one.

The same held when we took DoneDone from a monolithic .NET application to a Vue.js single-page app, and when we moved our own marketing site off monolithic WordPress to a headless setup and watched the PageSpeed score go from 24 to 93. In each case the tooling did the mechanical work and a person decided what the thing should become. That ratio hasn't changed as much as the 2026 launch announcements suggest, and it's worth being honest about when you're building the plan.

There's a related trap with AI-assisted work specifically: generated code that compiles isn't the same as code you can maintain, and technical debt accrued by an agent looks exactly like technical debt accrued by a human until you go looking. We've written about that tradeoff elsewhere.

How to read this list in a year

This post opened by pointing out that most modernization shortlists are out of date. This one will be too, eventually, so it's worth naming what should still hold when the product names have moved on.

The tools got dramatically better at translation this year, and better at proving the translation, which matters more. What none of them do is decide which parts of a system deserve to survive. On most legacy estates that's the decision determining whether the program is worth running at all, and no roadmap slide from any vendor on this page will make it for you.

So pick the tool for the job actually in front of you, keep the estate's test coverage ahead of whatever agent you point at it, and read every published percentage as a ceiling somebody else reached under conditions you don't have.