We wrote a phased roadmap for migrating legacy .NET Framework applications to .NET 10 without a big-bang rewrite. AI tooling doesn't replace any of those phases — but it noticeably speeds up specific, grinding parts of them. Here's where it actually helps on real engagements, and where we still don't trust it unsupervised.

Key takeaways
  • AI tooling is most useful for comprehension, dependency analysis, and mechanical refactors — not for making architectural or business-logic decisions.
  • Characterization tests, not AI review, are what actually catches a behavior-changing refactor. Generate them before you let AI touch legacy code.
  • Code review bar stays the same or goes up for AI-assisted changes, not down — confidently wrong output looks identical to confidently correct output.
  • The workflow that works: AI-assisted comprehension, human-reviewed plan, AI-assisted mechanical changes in small batches, tests and human review before merge.

Where it genuinely helps

Four places on a typical modernization engagement where AI tooling has measurably cut the time we spend:

  • Comprehension of undocumented code. Asking an AI assistant to summarize what an eight-hundred-line, poorly named method actually does — as a starting hypothesis to verify, not a final answer — is faster than reading it cold. It's also a reasonable first draft of the documentation that codebase never had.
  • Dependency and risk scanning. Flagging deprecated APIs, Windows-only calls, and patterns known to break under .NET 10 across a large codebase is exactly the kind of high-volume pattern-matching AI tooling does well, and much faster than a manual grep-and-read audit.
  • Mechanical, repetitive refactors. Converting a pattern across hundreds of files — old-style using statements to file-scoped namespaces, null checks to modern pattern matching — is tedious for a human and low-risk for AI-assisted find-and-replace, provided every change still goes through review.
  • First-draft characterization tests. Generating an initial set of tests that capture a legacy method's current behavior, which a human then reviews and extends, is faster than writing them from scratch — and it's exactly the safety net the migration roadmap calls for before refactoring business logic you don't fully trust.

Where we're careful

Two places AI tooling reliably falls short, and where we still lean entirely on human judgment:

  • Ambiguous business logic. When legacy code encodes an undocumented business rule — a discount that only applies on the third Tuesday of certain fiscal quarters — AI tooling will confidently produce a plausible-sounding explanation that may simply be wrong. It has no way to know the difference between "the intended behavior" and "a bug someone relied on for a decade."
  • Architectural decisions. Whether to split a monolith, which bounded contexts make sense, what the migration sequencing should be — these require context about the business, the team, and the risk tolerance that isn't in the codebase to begin with.

An illustrative characterization test, AI-drafted and human-reviewed

Given an undocumented pricing method, an AI assistant can produce a reasonable starting test based on the method's current behavior — which a human then verifies against actual business intent before it's trusted:

csharp
[Theory]
[InlineData(100.00, "STANDARD", 100.00)]
[InlineData(100.00, "PREMIUM", 90.00)]
[InlineData(0.00, "PREMIUM", 0.00)]
public void CalculatePrice_MatchesCurrentBehavior(decimal basePrice, string tier, decimal expected)
{
    // Captures existing behavior of LegacyPricingEngine.Calculate as-is.
    // Verified against product/business owner before relying on it as a spec.
    var result = LegacyPricingEngine.Calculate(basePrice, tier);
    Assert.Equal(expected, result);
}
Important distinctionThe comment in that test matters as much as the assertions. A test that says “this is what the code does today” is a safety net. A test that quietly gets treated as “this is what the code should do” without business sign-off can enshrine a bug as a permanent feature.

The workflow we actually use

In practice, AI tooling slots into the existing phased plan rather than replacing any part of it:

  1. Inventory the codebase as usual — AI-assisted scanning speeds this up, doesn't replace it.
  2. AI-assisted comprehension pass over unfamiliar modules, verified by a developer who knows the domain.
  3. Human-reviewed refactor plan — sequencing, risk, and rollback strategy stay a human decision.
  4. AI-assisted mechanical changes, applied in small, reviewable batches rather than one sweeping commit.
  5. Full test suite plus human code review before anything merges — the review bar is the same as for any other change, AI-authored or not.

The net effect isn't that modernization gets riskier with AI in the loop — it's that the grinding, low-judgment parts get faster, which frees up more of the team's time for the parts that actually require judgment: the architecture decisions, the business-rule questions, and the go/no-go calls that were always going to need a human anyway.

Need help with this in production?

astrivo helps teams design, build, and modernize systems like this. Let's talk about your context.