When old code hid policy
AI is changing the economics of legacy migration in the present, not as a distant forecast. In April 2025, Ed Mollick wrote on X that the market for software migration from legacy systems has been limited to about $30B a year because migration is expensive and maintenance is easier. In the same post, Ed Mollick wrote on X in April 2025 that older firms have a real backlog of scoped cheaper migration projects being unlocked by AI surprisingly fast.
That changes what gets proposed in meetings. Work that sat in the backlog for years can now look newly practical. A team can point to a modern target stack, an AI-assisted rewrite path, and a shorter cost model than anyone expected six months ago. The risk is not that the code cannot be rewritten. The risk is that newly possible work gets mistaken for work that is already safe to approve.
The old system was often doing more than the documentation said. It carried policy in branches, exceptions in data handling, and workarounds that survived because nobody wanted to reopen the underlying business decision. Legacy software often became the place where unresolved rules lived: who gets an exception, which record is accepted despite a missing field, when a payment is held, which customer case is escalated, which report is treated as final.
When that logic is rewritten by AI, the code may come across cleanly while the policy does not. The loss is not only technical fidelity. The loss is accountability. A team can inherit a system that appears to behave correctly and still miss that it is enforcing old judgments no one has reviewed in years. If nobody names those judgments, approval moves from business owners to the generated output by default.
A recent signal of the scale of ambition is public. In February 2025, The Rundown AI said on Instagram that Cisco's long-term goal is rewriting 98% of its legacy code within 24 months. Whether a particular target is met matters less here than what the target reveals: rewrite volume is becoming thinkable at a level that forces decision review into the foreground.
Write the decision register
The useful response is simple and specific. Before approving an AI-led migration, create a decision register. A decision register is a running list of undocumented rules the old system appears to enforce, with an owner beside each rule and a recorded approval, rejection, or deferral. At work, it looks like a plain list reviewed in migration meetings whenever the new system matches, changes, or drops a legacy behavior.
This keeps the human role where it matters. Not in typing every line by hand, and not in giving broad reassurance that the rewrite looks good, but in deciding which behaviors deserve business sign-off. If the old system silently waived a check for one class of account, someone should explicitly decide whether that exception stays. If a report rounded numbers in a way finance came to rely on, someone should decide whether that remains policy or becomes a bug to remove.
A decision register also separates two questions that are easy to blur together. One is whether the AI-generated system can reproduce legacy behavior. The other is whether the legacy behavior should survive. Those are different approvals. Combining them is how decision debt rolls forward into a cleaner codebase.
One practical takeaway for this week
Pick one migration candidate and review the legacy behavior that users call strange but necessary. List each exception, infer which ones are really business rules, and assign each one an owner who can approve, reject, or defer it. That list is small enough to start now and concrete enough to change the quality of the next approval meeting.
Human Runtime Core™ is designed for the mental edge you need to survive in an AI-run world.