.NET Framework to .NET 8: Legacy Modernization with AI (Strangler Fig)
Using AI to plan and execute a .NET Framework to .NET 8 migration with the Strangler Fig pattern — readiness assessment, incremental CQRS extraction, and zero-downtime cutover prompts, with a worked sequencing example.
Migrating a .NET Framework codebase to .NET 8 is rarely a technical rewrite problem — it's a risk-sequencing problem. The code that's hardest to migrate is usually the code that's riskiest to touch. AI is most useful here not for generating the migration itself, but for producing the readiness assessment and sequencing plan first.
Start with a migration readiness assessment, not a rewrite
Before moving a single line of code, prompt for an inventory: which dependencies have no .NET 8 equivalent, which APIs are Windows-only (registry, WMI, GDI+), which projects have circular references that block incremental migration, and which have the heaviest test coverage (safest to move first) versus none at all (move last, add characterization tests first).
Context: [paste the solution's .csproj list with target frameworks, and packages.config / PackageReference contents for each project]
Task: Assess .NET 8 migration readiness for this solution.
Output format: A table with columns: Project | Blocking dependency (if any) | Windows-only API usage (if any) | Test coverage estimate (High/Medium/None) | Recommended migration order position (1 = first).Worked example: sequencing a five-project solution
| Project | Blocking dependency | Windows-only API | Test coverage | Order |
|---|---|---|---|---|
| Shared.Contracts | None | None | High | 1 |
| Pricing.Engine | None | None | High | 2 |
| Notifications.Worker | System.DirectoryServices (LDAP lookups) | Yes — DirectoryServices | Medium | 4 |
| Reporting.Legacy | Crystal Reports SDK, no .NET 8 support | Yes — COM interop | None | 5 (last, needs replacement library first) |
| Api.Gateway | None once dependents are migrated | None | Medium | 3 |
This table alone answers the sequencing question: start with the dependency-free, well-tested core (Shared.Contracts, Pricing.Engine), migrate the gateway once its dependencies are ready, and treat Reporting.Legacy as a separate project — replace Crystal Reports before attempting the framework migration, not during it.
The Strangler Fig pattern, prompted incrementally
- Identify a bounded, low-traffic seam in the legacy system to extract first (from the readiness table, that's Shared.Contracts + Pricing.Engine).
- Stand up the new .NET 8 service behind a routing layer (e.g. YARP) that can direct traffic to old or new implementation per-route.
- Migrate that seam, verify behavior parity with golden-master or approval tests against the legacy implementation.
- Cut traffic over incrementally, monitor, and only then decommission the legacy path.
Context: Pricing.Engine has been reimplemented in .NET 8, sitting behind a YARP gateway that currently routes 100% of /api/pricing/* traffic to the legacy .NET Framework implementation. Both implementations are running side by side.
Task: Produce a staged cutover plan.
Constraints: Zero downtime. Must be reversible at every stage (instant rollback to legacy on error-rate spike). Assume we can route by percentage in YARP config.
Output format: A numbered list of stages, each with the traffic percentage, the metric to watch, and the rollback trigger.Don't block the .NET 8 migration on a full CQRS rewrite. Migrate the platform first; introduce CQRS incrementally on the seams that actually need it (high write contention, complex read models) once they're already running on .NET 8.
The Existing Project Analysis & Modernization program builds all of this out: legacy system modernization, the Strangler Fig migration plan, and a .NET Framework → .NET 8 migration readiness assessment as named, reusable prompts.