Every company past a certain age owns software it's afraid of: the billing system only one person understands, the .NET Framework app pinned to an OS version, the "temporary" PHP service from 2014 that processes half the revenue. Modernization projects have a deservedly bad reputation — long, expensive, and prone to producing a shinier version of the same mess. But the calculus has shifted. AI tools have attacked the three most expensive parts of modernization: understanding old code, backfilling tests, and executing repetitive upgrades. Here is the playbook we run, updated for that reality.
Step 1: Assess — with AI as your archaeologist
Modernization fails when it starts from vibes ("this code is awful") instead of inventory. The assessment answers: what do we have, what does it actually do, what depends on it, and where does it hurt? This used to take a discovery team months of spelunking. Now an AI coding agent with access to the repository builds the map in days: module summaries, dependency graphs, dead-code candidates, and plain-English explanations of the scariest files. In our experience the comprehension phase compresses more than any other — weeks of "what does this even do?" become an afternoon of asking.
For each application, note the classic 6 Rs as a shorthand for its fate: retire (delete it), retain (leave it alone), rehost (move it as-is), replatform (small adaptations, e.g. to containers or managed databases), refactor (restructure the code itself), or replace (rewrite or buy). Most portfolios need a mix — and more "retire" than anyone expects.
Step 2: Stabilize before you beautify
Never modernize a system you can't safely change. Before touching structure:
- Backfill characterization tests. Tests that pin down what the system currently does — bugs included — so any change that alters behavior gets caught. This was always the right move and never got budget because it was months of tedium; AI test generation has made it days of tedium, which changes everything.
- Get CI and one-command deploys working. If shipping is scary, every subsequent step is scary.
- Add observability. You need to see errors and latency before and after each change, or "did we break it?" becomes a matter of opinion.
Step 3: Modernize incrementally
With a safety net in place, modernize in slices that each deliver value on their own: upgrade the framework version by version, extract the one module that changes weekly, convert the UI layer screen by screen (our UI modernization piece covers that pattern), or peel a service off the monolith along a domain seam (covered in depth in our monolith-splitting guide). AI agents shine here at the mechanical middle: dependency upgrades with breaking-change fixes applied across hundreds of call sites, API migrations, and framework version jumps that are individually documented but collectively soul-crushing.
The rule that keeps projects alive: every slice must ship to production and prove itself before the next begins. A modernization that goes six months without a production release is a rewrite wearing a disguise.
Step 4: Measure, or it didn't happen
Pick the two or three numbers the project exists to move and report them monthly: deployment frequency, lead time for a change, incident count, infrastructure cost, time-to-onboard a new engineer. These are what keep executive sponsorship alive in month seven — and what tell you whether to keep going, change course, or declare victory early.
Rewrite vs refactor: the honest test
Rewrites are still usually the wrong answer — the old system encodes years of edge cases that the new one rediscovers in production. AI has strengthened the refactor side of the argument, because comprehension and test backfill (the hard parts of refactoring) got cheap. A rewrite earns its place only when the platform is genuinely dead (unsupported language or runtime you can't hire for), the domain has changed so much the old model actively fights you, or the system is small enough to replace inside one quarter. Even then, run it strangler-style with the old system live until the new one proves itself.
Team shape: pod or fixed bid?
Modernization work maps cleanly onto the two engagement models. A well-bounded slice — "upgrade to .NET 8," "convert these 40 screens," "extract the reporting service" — suits a fixed-scope outsourced delivery with accountability on us. A longer arc where scope will evolve suits an augmented pod — typically two or three AI-assisted senior engineers embedded with your team, so the system knowledge lands in your organization, not ours. Many clients combine them: fixed-bid the assessment and first slice, then convert to a pod. Our case studies include both shapes.
Key takeaways
- Run the sequence: assess, stabilize, modernize incrementally, measure — and never skip stabilize.
- AI collapses the three costliest chores: legacy code comprehension, characterization-test backfill, and mechanical framework upgrades.
- Sort the portfolio with the 6 Rs first; expect more "retire" than anyone admits.
- Every slice ships to production before the next begins — six dark months means you're secretly rewriting.
- Refactor beats rewrite even more often than it used to; when you must rewrite, do it strangler-style.
- Fixed-bid the bounded slices, use an embedded pod for the evolving arc — or sequence one into the other.
Have a system everyone's afraid of? Tell us about it — an AI-accelerated assessment is a low-risk first step that pays for itself in clarity.