AI has made the cheap half of a legacy migration cheaper and left the expensive half exactly where it was. Reading an old system was never what killed these projects. Changing it while people depended on it was, and nothing shipped in the last two years has touched that.

The modernization market has repositioned around the first half, and the repositioning is not fake. In an AI-assisted migration, coding agents read a whole repository, map its dependencies, recover business rules nobody documented, profile old data against the new schema, translate code between languages and open pull requests for a human to review. Work that used to be months of archaeology is weeks. The mistake is quoting that compression as the migration timeline. It is the discovery phase, which is a different thing.

Cutover is where these projects are decided: the stretch where the old and new systems are both live and traffic moves from one to the other. We moved RxVantage, a pharmaceutical data platform used by healthcare professionals making decisions about patient care, off a monolith and onto event-driven microservices. Understanding the old code was never the binding constraint. Nobody losing access mid-shift was. So we ran both systems in parallel behind feature flags, moved low-risk services first during off-peak hours, and shifted traffic slowly enough to roll back instantly. The published results were a "50% reduction in server costs", "30% faster deployment times" and "Zero downtime during migration".

Every one of those decisions was a judgment about blast radius, not a code question. Which service goes first. What signal proves the new path is correct rather than merely responding. Who is awake when it flips, and who has the authority to call a rollback at 2am. An agent that translates a repository faithfully hands you all of that work untouched, and hands it to you sooner.

Why faithful translation still breaks things

Legacy migrations fail on behavior nobody wrote down. A system that has run for a decade is a record of every edge case somebody patched and never documented: a rounding rule, an exception for one category of customer, a retry quietly compensating for a broken dependency. An agent reproduces all of it, including the bug a rule was working around, because the old source does not distinguish a decision from an accident. The worst version is a silent data failure, a record that loads cleanly but means something different on the other side, and nobody sees it until a customer does. A passing test suite on translated code is not evidence that the old behavior survived.

The slow rewrite used to double as the audit, the moment someone noticed a function had three callers and one was a cron job nobody owned. Discovery now ends early and looks like progress, so the schedule built on it carries confidence and very little evidence. The evidence arrives when traffic moves.

How to de-risk the cutover

The parallel run is where a migration's budget actually goes. While it lasts you pay for two sets of infrastructure and two on-call rotations. That cost scales with time, so the decisions that set the bill are sequencing decisions. These are the ones we would not cut:

  • Run old and new side by side on real traffic and compare outputs, not just uptime. Reconcile the data, because that is where silent failures hide.
  • Move the lowest-risk slice first, off-peak, behind a flag that controls exactly who sees which system.
  • Keep a rehearsed rollback at every step, measured in minutes rather than a release cycle.
  • Hold the overlap through a full business cycle, including a month-end close, not one quiet week.
  • Name who decides. One person with the authority to pause or reverse a shift.

We staged Sky Sports' live scores platform the same way when Flash was retired: old and new in parallel, A/B tested with real users during real matches, starting with friendlies, then league games, then Champions League finals. The result was "Zero downtime during major events". The dual-running setup gets thrown away at the end, which is why it is the first thing cut from an estimate.

The costliest part of RxVantage was not technical. The team structure was the bottleneck, with everyone waiting on everyone else to ship. We reorganized into small autonomous pods, each owning a slice of the platform end to end: frontend, backend, infrastructure. That did more for delivery speed than any process change we could have made, and no tool has any purchase on it.

If you are scoping a modernization this year, price the two halves separately. Ask what the number covers: code comprehension and translation, or traffic actually moved with a rollback somebody has rehearsed. The first is now a matter of weeks, and should cost less than it did. The second is bounded by your uptime commitment, your data, and how many people have to agree before anything switches. A partner who answers in velocity rather than sequencing is quoting the easy half. The same arithmetic applies to how you staff it: the reading is now a small team's work, and the cutover is where you want the experience.

A migration is not finished when the new code is correct. It is finished when nobody noticed.