Most of the cost in modernizing a legacy system is not typing new code. It is figuring out what the old code actually does, for whom, and why it was written that way in the first place. A 40-year-old Pick BASIC subroutine or a tangled, undocumented PHP file can encode a business rule that took years to get right, with no comment explaining it and no one left at the company who remembers writing it. That comprehension work has always been the slow, expensive part. It is also the part where AI genuinely helps — and the part where trusting it too much causes real damage.
Where the acceleration is real
The most useful thing I do with an AI model on a modernization project is generate a first hypothesis, fast, about what a piece of legacy code does. Pointed at an unfamiliar subroutine, a model can produce a plain-language summary, guess at what a cryptically named variable probably represents, or draft a description of a stored procedure’s intent — in minutes, across hundreds of files, instead of days of manual reading.
That is a real speedup on the triage step every modernization project needs: deciding which of hundreds of legacy programs actually matter, which touch money or compliance, which run on a schedule that nobody can currently explain, and which are simply dead code nobody has called in years. A model does not answer that question correctly by itself, but it turns an unmanageable pile of undocumented code into a ranked list of things worth a human’s time to verify.
The same acceleration applies to two other places:
- Test scaffolding. Parity testing — running old and new logic against the same inputs and comparing outputs — needs a wide set of representative and edge-case inputs. A model is useful for drafting that input list. It is not a substitute for the expected outputs, which still have to come from the legacy system itself, not from the model’s guess about what it should produce.
- Draft translation of well-understood logic. Once I actually understand a tightly scoped routine, having a model produce a first-draft C#/.NET (or other modern-stack) equivalent gives me something to review and correct line by line against the original behavior, instead of starting from a blank file. It is a starting point for a human review, not a finished migration.
Where I do not trust it
Fluency is not the same as correctness on a system this idiosyncratic, and a model will describe a wrong assumption about legacy business logic with exactly the same confidence as a right one. A few boundaries I hold firm on:
- Nothing touching money, compliance, or a contractual obligation gets AI-drafted logic without full parity testing against real production data before it ships. The cost of being wrong there is not proportional to how quickly the draft was produced.
- If there is no way to verify an AI-authored change against real behavior, it does not go in. An unverified migration is a liability, not an accelerant, regardless of how plausible it reads.
- Sending proprietary or regulated code and data to a third-party model is a decision, not a default. Many legacy systems in healthcare, finance, and distribution carry data-handling obligations that were never written with an external API call in mind, and that constraint has to be checked before a single file gets pasted into a prompt.
- A confident explanation is a hypothesis, not ground truth, until it has been checked against what the system actually does in production.
What has to be decided before any of this starts
None of the following questions get easier because AI is involved — they still require a person who understands the business to answer them.
What does “correct” mean here? Which behaviors are load-bearing business rules, and which are incidental artifacts of how the system happened to be built. Only someone who understands the business can draw that line; no amount of code reading, by a model or by me, answers it from the code alone.
Where does the real risk actually live? A mis-migrated reporting query is an inconvenience. A mis-migrated payment calculation, tax rule, or compliance check is a business-ending mistake. Deciding upfront which pieces of the system get the heaviest verification — parallel runs, full parity suites, manual sign-off — matters more than which tool wrote the first draft.
Is there a way back? A rollback or parallel-run plan means a mistake caught late is recoverable instead of catastrophic. This requirement does not change whether AI touched the migration or not, but skipping it is a much bigger risk once a model is helping generate volume faster than a team can independently verify it.
Who wins when the draft and the legacy system disagree? The legacy system’s actual, observed behavior does — never the AI-generated explanation of what it “should” do. I have seen confidently wrong explanations of legacy behavior long before AI models existed; the tool changed, the discipline of checking against reality did not.
The honest framing
AI has made the comprehension and drafting phases of legacy modernization meaningfully faster for me. It has not made the verification phase optional, and it has not changed what a business needs before starting: a clear sense of which behaviors must be preserved, a plan for proving they were, and a way to recover if something was missed. The businesses I work with on modernization don’t need less rigor because a model is in the loop — they need the time that used to go into slow manual reading redirected into verification, which is the step that was always the actual safeguard.