Most lists of modernization tools are out of date, and not by a little. The AWS tooling that anchored 2024 shortlists, including Migration Hub, Application Discovery Service and App2Container, stopped accepting new customers on November 7, 2025. Amazon Q Developer ends support on April 30, 2027. Azure Data Studio retired on February 28, 2026. Bloop, the COBOL-to-Java startup, shut down in April 2026.

So this is what's alive in 2026, weighted toward the kind of modernization we actually do: Web Apps and Mobile Apps, framework and runtime upgrades, Front-End rewrites, data-layer moves. It's a map of a category, not an account of our own stack: where a figure comes from a vendor it says so, and where it comes from published research it's linked. No tool here is ranked above another, because they mostly solve different problems.

Best application modernization software in 2026, at a glance

The tools, one by one

GitHub Copilot app modernization

What it does: Assesses a Java, .NET or C++ application, then applies transformations, patches the build, migrates unit tests, fixes known vulnerabilities and containerizes for Azure, with a human-confirmed diff at each step.

Best for: Teams already on GitHub and Azure doing framework and runtime upgrades who want the agent to propose and a person to approve.

How it works: Runs in VS Code, IntelliJ, Visual Studio or the Copilot CLI, producing a per-app modernization plan and then executing it step by step.

Where it fits well: No separate purchase: it's included in any Copilot plan. Generally available for Java and .NET since September 2025 and for C++ since June 2026. Covers JDK 8 through 25 and Java EE to Jakarta EE 10.

Documented limits: Gradle Kotlin DSL is unsupported and Maven needs wrapper v5+. One project at a time. IntelliJ support is Windows and macOS only. Targets are Azure-oriented. Microsoft's "up to 70% less time" figure carries no published methodology, so treat it as a vendor claim.

Pricing: Included in any Copilot plan; consumes premium requests with model multipliers.

Claude Code

What it does: A general-purpose coding agent used for the understanding half of modernization: building dependency graphs, identifying dead code, generating tests before a refactor, and documenting systems nobody documented.

Best for: The first two weeks of a project on a codebase whose original authors have left.

How it works: Runs against the repository directly; you define the workflow rather than following a vendor's staged process.

Where it fits well: Language-agnostic, including COBOL analysis. Strong at producing the characterization tests that every AI transformation benchmark assumes you already have. Named a Leader in Gartner's Magic Quadrant for Enterprise AI Coding Agents, May 2026.

Documented limits: No modernization-specific product, workflow or assessment stage, so you build the process. The code modernization page carries customer logos but no published outcome metrics, so there's no benchmark to hold it to.

Pricing: Seats and usage under Claude Enterprise; no modernization-specific pricing published.

Cursor

What it does: An agentic IDE used for migration work, with organization-specific skills that encode how your team wants changes made.

Best for: Standardizing a migration across a large in-house engineering team that already works in an IDE all day.

Where it fits well: The most specific published customer evidence in this category. 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. Also a Gartner MQ Leader for Enterprise AI Coding Agents.

Documented limits: It's a general IDE, not a migration platform: no portfolio assessment, no wave planning, no verification stage. The NAB numbers are vendor-published and single-customer.

Pricing: Public per-seat plans; enterprise negotiated.

Moderne + OpenRewrite

What it does: Applies deterministic refactoring recipes across every repository at once, using a compiler-accurate representation of the code rather than pattern matching.

Best for: A change you already know is correct that has to happen in hundreds of places: a Spring Boot bump, a Jakarta namespace move, a CVE patch.

How it works: OpenRewrite parses source into a Lossless Semantic Tree, so a refactor either type-checks across the whole tree or fails loudly instead of silently half-applying.

Where it fits well: A single Log4Shell recipe fixed 38,000 call sites across 400 repositories with zero regressions. Over 10,000 recipes exist. The core is Apache 2.0 and governance moved to the Commonhaus Foundation. Named a Leader in the inaugural Gartner Magic Quadrant for AI-Augmented Code Modernization Tools, August 2026.

Documented limits: Strongest in Java, JVM languages and Spring; other languages are platform-only rather than open source. Platform pricing isn't publicly disclosed. A recipe has to exist or be written. This isn't the tool for a change you can't specify.

Pricing: OpenRewrite core free (Apache 2.0); Moderne platform enterprise quote.

Cloud Native Buildpacks + Paketo

What it does: Turns application source into a container image without a Dockerfile, and lets you patch base images across an estate by rebasing rather than rebuilding.

Best for: Containerizing a legacy app when you'd rather not own a Dockerfile per service, and want CVE patching to be one operation later.

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

Documented limits: Less control than a hand-written Dockerfile, and an unusual runtime setup may not fit an existing buildpack. Does nothing for the application code itself.

Pricing: Free, open source.

Debezium

What it does: Streams row-level database changes from the transaction log, so a legacy store and a new one stay in sync without your application dual-writing.

Best for: The strangler-fig pattern at the data layer: running old and new in parallel and moving traffic across gradually.

Where it fits well: Version 3.6 is stable as of August 2026. Connectors cover Postgres, MySQL, Oracle, SQL Server, Db2 and MongoDB. Free under Apache 2.0. This is the mechanism that makes an incremental cutover possible instead of a big-bang weekend.

Documented limits: Needs Kafka or Debezium Server to run, which is real operational overhead. Commercial support only via the Red Hat build, which isn't publicly priced.

Pricing: Free; Red Hat build subscription not publicly disclosed.

pgroll

What it does: Applies Postgres schema changes as expand-and-contract migrations that expose multiple schema versions simultaneously, so old and new application versions read and write concurrently.

Best for: Zero-downtime schema evolution on Postgres while two versions of your app are live.

Where it fits well: Reversible, avoids long locks, benchmarked across Postgres 14.8 to 18.0. The cleanest current answer to the schema half of an incremental migration, and free.

Documented limits: Postgres only. Still pre-1.0, with no 1.0 milestone published, so the API may change under you.

Pricing: Free, open source.

Diffblue

What it does: Autonomously writes, compiles and verifies unit tests across a codebase, orchestrating Copilot or Claude Code to do it.

Best for: Creating the safety net on untested legacy Java before any refactoring starts, the prerequisite most modernization plans skip.

Where it fits well: Covers Java 8, 11, 17, 21 and 25 plus Python, and claims up to 81% coverage. Generally available for Copilot and Claude Code orchestration.

Documented limits: Java and Python only, with more languages listed as coming during 2026. Pricing isn't publicly disclosed. The 81% coverage figure is vendor-stated with no published methodology.

Pricing: Not publicly disclosed.

Testcontainers

What it does: Spins up real dependencies (databases, brokers, browsers) as throwaway containers inside the test suite.

Best for: Making a legacy integration test suite deterministic, so you can trust it as a baseline before changing the code beneath it.

Where it fits well: OSS libraries are free. Testcontainers Cloud per-seat licenses are waived for Docker Pro, Team and Business, with 100, 500 and 1,500 cloud runtime minutes per month respectively.

Documented limits: Needs a container runtime available in CI. Cloud minutes are metered beyond the plan allowance at $4 per 100 minutes on demand.

Pricing: OSS free; Cloud minutes bundled with Docker subscriptions.

AWS Transform

What it does: An agentic service 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.

Best for: Estates being moved specifically onto AWS, and the only serious option with published per-unit pricing.

Where it fits well: Assessment and the Windows, mainframe and VMware agents cost nothing; the custom transformation agent is $0.035 per agent-minute. AWS illustrates roughly $2.52 for a 17,000-line Java upgrade. Published customer figures include Thomson Reuters at 1.5 million lines a month at 30% lower cost and QAD saving more than 7,500 developer hours a year.

Documented limits: AWS targets only. Human-in-the-loop is mandatory, and AWS states assessment cost outputs are "directional estimates… not quotes". It absorbed several now-retired AWS tools, so older tutorials and docs will send you to dead products.

Pricing: As above.

CAST Highlight

What it does: Scans an entire application portfolio and scores each app for cloud readiness, open-source risk and technical debt, so you can rank what to touch first.

Best for: Deciding which of several hundred applications to modernize, and in what order, before any budget is committed.

Where it fits well: One of very few vendors here publishing real numbers: package tiers by application count, with a single-app Complete Insights license at $6.8K / €6.3K annually. Language-agnostic and deliberately portfolio-wide.

Documented limits: Broad and shallow by design: it won't give you a dependency graph, which is CAST Imaging, a separate product. Annual subscription with 60-day cancellation notice. Hard to justify below roughly fifty applications.

Pricing: Package tiers by app count; $6.8K / €6.3K per named application annually.

If your estate is a mainframe

Mainframe modernization tools are a separate shortlist, and the market there is more mature on one specific point: proving the converted code behaves identically. Five names matter.

• AWS Transform for mainframe converts COBOL, copybooks, JCL, DB2 definitions and CICS into Java. Generally available since May 2025, refactor path across 18 regions since March 2026, at no cost.

• IBM watsonx Code Assistant for Z runs a seven-stage workflow across COBOL, PL/I, REXX, Assembler and JCL, including a Validate stage for semantic equivalence.

• Google Cloud mainframe modernization covers assessment, conversion agents, and Dual Run, which replays live production traffic against the converted system.

• Rocket Enterprise Analyzer covers understanding only: code and data flow visualization, business-rule extraction, impact analysis. Formerly the Micro Focus and then OpenText product; Rocket closed a $2.275B acquisition of that business, so older vendor paths are dead.

• Mechanical Orchard Imogen builds synthetic replicas of production data flows and diffs transactions. As Hyperframe Research notes, behavioral proof is only as strong as behavioral coverage.

We should be straight about this section: mainframe modernization isn't work we do. It's here because "application modernization software" and "mainframe modernization tools" are the same search for many people, and a list that omitted these would be a worse list. If your estate is COBOL on IBM Z, a systems integrator with a mainframe practice is a better partner than a product studio.

What got discontinued since 2024

Enough to invalidate most shortlists, which is the main reason to distrust an undated list of modernization tools.

How to choose

Match the tool to the risk you're carrying, not to the 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 difficult application. Weeks, not months.

2. Can you tell if you broke it? With no meaningful test coverage, buy verification before transformation. Every benchmark below 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 upgrades and ports where a human reviews the diff. Neither, where the seam is a product decision.

4. Can you run both systems in parallel? If yes, change data capture and traffic replay de-risk the cutover enormously. If no, spend more on proving equivalence up front.

This list deliberately doesn't settle whether to rehost, replatform or refactor in the first place. That decision comes before tool selection.

How much can AI actually automate?

Three published studies are worth more than every vendor page combined, and they bound the claims in this list.

• Google's int32-to-int64 migration across a 500-million-line 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 changes committed without edits across 5,359 files. The team had to deliberately rate-limit the pipeline so it wouldn't overwhelm human reviewers.

• MigrationBench evaluated 300 curated Java 8 Maven repositories: 62.33% first-attempt success on a minimal migration, 27.00% on a maximal, idiomatic one. Compiling and passing tests on a newer runtime is largely solved. Making the result good is not.

• FreshBrew migrated 52.3% of 228 high-coverage Java repositories to JDK 17. It was built to detect reward hacking, meaning agents that pass by weakening or deleting tests, and it needs high existing coverage even to run.

Read together: AI transformation works best where the change is mechanical, the tests are already good, and a human reviewer is the bottleneck. On an untested legacy estate none of those hold, which is why verification tooling comes before transformation tooling.

Where tooling stops

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

When we modularized the ClearanceJobs iOS app, discovery was never the problem. The app started as a job search product and accumulated live streaming, a social feed, real-time chat with attachments and company search. Clean builds had crept to five to ten minutes, and developers were losing around 1.5 hours a week to compilation. Splitting it into Swift Packages brought a clean build to roughly 30 seconds, which Paulo Leite wrote up in detail. No tool on this page would have made that call. The question was which seams were worth cutting and which modules would still make sense in two years. A product judgment, not a code one.

There's a related trap with AI-assisted work: generated code that compiles isn't the same as code you can maintain, and debt accrued by an agent looks exactly like debt accrued by a human until you go looking. We've written about that tradeoff separately, and what technical debt actually is if you're still building the business case.

How to read this list in a year

This list will go out of date, the same way the ones it replaces did. So it's worth naming what should still hold once 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.

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.