Can AI actually modernize a legacy codebase, or does it just make a mess?

Why the question is being asked now

Support dates. SQL Server 2016 left extended support in July 2026. .NET 8 reaches end of support in November 2026, which surprises teams that migrated to it recently and thought they were finished. Windows Server 2012 R2 ended in 2023 and is still running in more data centres than anyone will admit. Every one of those dates turns a system nobody touches into the most urgent thing in the company.

The reason those systems were never modernized is not a mystery. The people who wrote them left, nothing is documented, there are no tests, and every rewrite estimate came back at a number the business declined. Those four facts are exactly the ones AI changes.

What AI actually does well here

Reading. A model can read two hundred thousand lines nobody understands in an afternoon and produce a map of what talks to what, what has not executed in years, and where the risk concentrates. The map is mostly right. “Mostly” is the job: it tells a human where to look, and the human corrects it in days instead of a quarter.

Characterization tests. Tests that record what the system does today, right or wrong, so the migrated version can be held to the same behaviour. These were never written because nobody could afford to write them. A model drafts hundreds from observed inputs and outputs; a person who knows the domain prunes them to the ones that matter.

Drafting the migration. Moving one module from one framework or runtime to another used to be a week. It is now a day, most of which is review.

What it does not do

It does not know which behaviours are load-bearing, which bugs customers have quietly come to depend on, or which module to move first so that a failure is survivable. That is judgment. A migration run by AI without it produces code that compiles, passes the tests it wrote for itself, and fails in a way nobody finds until a customer does.

The order that holds up

1. Map the system and write a risk map before touching anything.
2. Characterize before moving. Tests from real behaviour, pruned by someone who knows the domain.
3. One boundary at a time. Runtime, then framework, then the modules with the fewest dependents. Old and new run side by side until the new one has earned the traffic.
4. Remove with evidence. Dead code and abandoned dependencies come out, each with a reason recorded.
5. Leave a practice behind. Review gates and rules for what AI may touch, so the codebase does not rot again by 2028.

You can stop after any module and be better off than you started. That is not true of a rewrite at the halfway point, and it is the strongest argument for doing it this way.

The honest answers for the common cases

ASP.NET Web Forms. It never made it to modern .NET, and Microsoft’s own guidance says so. The UI layer is a rewrite regardless of what any tool claims. The business logic and data access underneath usually are not, and that is where the migration starts. Anyone who tells you Web Forms migrates cleanly is selling the first month.

.NET Framework 4.x to .NET 8 or 10. The most common request and the most tractable, with the UI caveat above. Plan for .NET 10, which is the current long-term-support release; a migration landing on .NET 8 in late 2026 lands on a runtime with weeks of support left.

SQL Server 2012 through 2016. The upgrade itself is the easy part. The schema and query debt underneath is where the work is, and the modernization is usually the first time anyone has looked at it in a decade.

Classic ASP, VB6, Access. Less common, more urgent when they appear, and usually holding up the process the business depends on most.

The question to ask any vendor

“What happens to the tests you wrote if we stop after phase two?” If the answer is that they stay with you and keep running against the old system, you are talking to someone who has done this. If the answer is a pause, keep looking.