AI Legacy Modernization
Somewhere in your company there is a system nobody wants to touch. It still runs orders, or payroll, or the thing customers actually pay for, and the last person who understood it left years ago. Coding agents now read all of it, write the tests that were never there, and take over one capability at a time while the system keeps running. That is what makes modernization affordable without betting two years of budget on a rewrite.
AI legacy modernization is the work of moving an old system that still runs the business onto a foundation that can be changed safely, with coding agents doing the mechanical part that used to make the project unaffordable. Oleg Sotnikov runs it as a strangler-fig migration: agents read an entire codebase nobody remembers and produce the dependency map and the missing test harness in days rather than quarters, then one capability at a time moves onto new code while the old system keeps serving traffic. Sequencing, risk calls, and the decision of what not to move stay with a human. He has 25+ years in IT, 1,000+ projects, and enterprise experience that includes running IT for a Glencore subsidiary.
What AI-Assisted Modernization Involves
Six pieces of work. The assessment decides how much of each your system needs.
Assessment and dependency mapping
What the system is made of, what calls what, and which parts carry real load. Undocumented integrations and scheduled jobs nobody remembers are what turn migrations into outages, so they get found before anything is planned.
AI-assisted code comprehension
Agents read the whole codebase, including every stored procedure and every branch that has not executed in years, and produce the map that used to take a room of consultants a quarter to assemble. This is where the cost of modernization dropped the most.
A test harness before anything moves
Legacy systems are usually untested, which is exactly why nobody dares change them. Agents generate characterization tests from the behavior already in the code, including the behavior that looks like a bug and turns out to be load-bearing. Nothing migrates until that net is underneath it.
Incremental strangler-fig migration
New code takes over one capability at a time behind a routing layer while the old system keeps serving everything else. Agents do the mechanical rewriting inside each increment; what moves next, and what stays where it is, remains a human call. Every step is releasable and reversible, so you are never left with a half-finished rewrite as the only thing that works.
Data migration safety
Schema changes and data moves are where a reversible migration quietly stops being reversible. Dual writes, backfills, reconciliation between the old and new stores, and a restore-tested rollback for every cutover. Data moves late, and it moves in a way you can undo.
The cost of keeping the old stack
An aging system bills you twice: the infrastructure it needs to stay upright, and the payroll of the people whose job is keeping it upright. Both belong in the business case, and the second number is usually the larger one.
How Modernization Runs
Assessment
Agents read the code and produce the dependency map. I rank the risks by what they would actually cost you and pull out the quick wins worth doing regardless of the larger plan. You get a written picture of what you own, including the parts that are cheaper to leave alone.
Plan
A migration sequence ordered by risk and business value, with the test coverage each step needs before it starts and a rollback for each one. Tests are the safety net that makes an incremental plan honest instead of optimistic.
Execute
The migration runs in increments, and something reaches production in the first month instead of on a launch date two years out. Stop after any step and you keep everything gained up to that point, which is the property a big-bang rewrite does not have.
Why Me
- 25+ years in IT and 1,000+ projects, most of them involving systems that were already running before I arrived
- Enterprise IT background, including Head of IT at a mining subsidiary of Glencore, where the old systems were the business
- Advised QueueStone on modernizing its ERP platform for mental-health providers, from architecture through delivery
Frequently Asked Questions
Should we modernize or rewrite?
That gets decided after the assessment, and the answer is rarely all-or-nothing. Whether you call it app modernization or legacy code modernization, the economics are the same. A rewrite earns its price when the core data model is wrong for the business you have now, or when the stack blocks something you must ship. Otherwise incremental modernization wins, because the system keeps earning while it changes. Big-bang rewrites are where modernization budgets die: the new system has to reproduce years of accumulated behavior before it can carry a single user, and until that day arrives you are paying for two systems and shipping from neither.
How does AI change legacy modernization?
It changed the cost of the two phases that used to make modernization unaffordable. Understanding an undocumented codebase meant months of people reading code; agents now read the whole system and produce a dependency map in days. Writing the characterization tests that make a migration safe was work nobody would fund, and agents generate that harness from the behavior already in the code. Sequencing, risk calls, and the decision of what not to move still need a human. That part did not get automated.
Can you handle our stack? It is very old.
The assessment comes first, and I do not make promises about a specific technology before I have read the system. The approach itself is stack-agnostic: agents map the system, tests characterize its behavior, then capabilities move out one at a time behind a routing layer. That holds for a monolith nobody has tested as much as for a batch system that predates the current team. If what you have needs a specialist I am not, I will tell you that instead of learning on your budget.
How long does legacy modernization take?
That comes out of the assessment, because the honest answer depends on how much undocumented behavior the system carries and how tightly it is wired into the rest of your operation. The useful part of working incrementally is that you are not waiting for an end date. Value lands from the early increments: a capability moved off the old system, a test harness that did not exist before. That value stays yours even if priorities shift and the work pauses.
What does legacy modernization cost?
It is scoped per engagement, after the assessment, because a two-service system and a fifteen-year-old platform with a database nobody has migrated are not the same job. Ongoing work runs as a fractional CTO engagement at $5,000–10,000 per month, month to month, or as advisory from $3,000 per month; both rates are published on my pricing page. When part of the question is the team keeping the old system alive, the $5,000 Team & AI Audit is a good fixed-price entry point: five business days across the system and the people around it.
Start With an Assessment
Before anyone argues about rewriting, it is worth knowing what the system actually contains. That starts as a conversation, not a proposal.
English or Russian, US Pacific hours, async-first. NDA on request.
Related reading
Architecture, migrations, and what old systems really cost to keep.
