Replatform, refactor or convert? How to pick a modernization path for each application

Most legacy portfolios get one plan: modernize everything, starting with whatever team is loudest. The plan fails because applications differ. A payments engine that earns the company's money and a nightly report that three people read need different treatment, and so do an app that runs fine but cannot be staffed and one whose vendor ends support next year.

AI changes the cost of three activities: reading old code, translating it, and writing tests. It does not change who has to decide what each application deserves. This post is a way to make that decision per module before any conversion starts.

Four options, not three

The terms get mixed up, so here are working definitions. Replatforming moves an application to a new runtime or infrastructure with few code changes. Refactoring restructures the code, often into modules or services, without changing what it does. Converting translates the code to another language or stack, such as COBOL to Java. Retiring belongs on the list too, because the cheapest module to modernize is the one you switch off.

Sort modules by value and risk first

Before choosing a path, place each module on two scales. Business value is how much revenue or daily operation depends on it. Modernization risk is how large, tangled and under-tested the module is, and how few people understand it. AI agents can produce most of the inputs: a dependency map, a catalog of business rules written in plain language, a dead-code report and a complexity score. A person who knows the system should review each one.

Then choose a path for what remains

Among the modules you keep, four situations come up often.

Stable but dated

The application runs well and is hard to maintain. Replatform with light refactoring. AI maps dependencies, upgrades libraries and generates tests so the move is safe. The usual mistake is skipping tests because the application has run without trouble for years.

Fragile and undocumented

There are few documents and few people who know the code. Analyze first, then convert in slices. AI extracts the business rules and writes characterization tests before anyone touches the code. The usual mistake is converting before the rules are understood.

Slow to change

Every change takes too long because modules depend on each other. Refactor into modular services. AI helps split coupled modules, draft API contracts and convert in batches. The usual mistake is drawing service boundaries in the wrong places.

Platform near end of life

The vendor or runtime is about to end support. Convert to a supported stack. AI translates the code and helps validate it with parallel runs. The usual mistake is a literal translation that carries old design flaws into the new system.

A worked example

This is an illustrative inventory, not client data.

Six modules produce four different decisions. A single plan for all six would waste effort on two of them and rush the hardest one.

Size the first slice

Pick one bounded module from the high value, low risk quadrant and treat it as a measurement, not a launch.

1. Set the target stack and the standards the new code has to meet.
2. Run the analysis: dependency map, business-rule catalog, dead-code report.
3. Convert in small batches, checked against tests built from the legacy system's real outputs.
4. Measure the acceptance rate (the share of converted changes that land with little or no editing), the reviewer hours per module, and the defects found after cutover. Take a baseline first.

Airbnb's migration of its test files shows the shape of this work. An automated pass moved 75% of the files in about four hours, four days of retries brought that to 97%, and fewer than 100 files needed manual work. A job estimated at about 18 months finished in six weeks. The details are in InfoQ's report on Airbnb's LLM-driven test migration. Bulk automation, retries, and a person for the leftovers fit the low risk quadrants well.

An illustrative first sprint for a small module runs about five days: scope on day one, a domain expert reviews the rules on day two, conversion and the validation loop on day three, a senior engineer reviews the riskiest changes on day four, and a lead decides go or hold on day five. Treat that as a planning shape, not a benchmark.

Where people stay in charge

Automation covers the volume. People hold three gates: sign-off on scope, review of whether the new behavior matches the old, and approval of cutover. Every module has a named owner, because without one nobody is accountable when an agent changes something.

Our full walkthrough of the analyze, convert and validate stages, with a cutover readiness checklist, is in the guide to legacy application modernization with AI.

Which quadrant holds the most modules in your portfolio?