Modernising Legacy .NET Applications with AI: The Enterprise Playbook (UK, 2026)

You have 200,000 lines of .NET Framework 4.6 and a board presentation in six weeks

Your CTO wants a cloud migration roadmap. Your lead developer just handed in their notice. The compliance team is asking about the .NET Framework support timeline. And the Azure costs for running those IIS VMs keep climbing.

This is the reality for hundreds of UK enterprises running production workloads on .NET Framework 4.x. The framework still works. The applications still run. But the gap between “works” and “modern” widens every quarter, and the cost of bridging it later is higher than bridging it now.

The good news: .NET Framework applications are among the best candidates for AI-assisted modernisation. The codebase is strongly typed. The patterns are well-documented. The target platform (.NET 10) shares enough DNA with the source that AI tools can handle much of the mechanical translation. The less-good news: “AI-assisted” does not mean “AI-automated.” You still need a strategy, a sequence, and senior engineers making architectural decisions.

This playbook provides that strategy.

Why .NET is the best legacy stack for AI-assisted modernisation

Not all legacy stacks are equal when it comes to AI-assisted migration. COBOL mainframe code, for example, requires AI to bridge a vast semantic gap between procedural batch processing and modern architectures. The translation is more invention than migration.

.NET Framework sits in a different position entirely. The type system gives AI tools a rich set of constraints to work within. Method signatures, interface contracts, and generic types all provide structure that AI can reason about with high confidence. When Claude Code reads a public async Task<IEnumerable<OrderDto>> GetOrdersByCustomer(int customerId) signature, it has enough information to generate a correct .NET 10 equivalent without guessing.

Three properties make .NET particularly suited to AI-assisted modernisation:

Strong typing reduces ambiguity. AI code generation is most reliable when the input and output types are explicit. .NET Framework’s type system, generics, and nullable reference types (available in later versions) give AI tools the constraints they need to produce correct translations. Dynamically typed languages offer AI tools fewer guardrails.

Pattern consistency across the ecosystem. .NET Framework applications tend to follow recognisable patterns: MVC controllers, repository pattern data access, dependency injection (even before it was built-in), service layers. AI tools trained on the .NET ecosystem recognise these patterns and can map them to their modern .NET equivalents reliably.

Microsoft’s migration path is well-documented. The .NET Upgrade Assistant, try-convert tool, and Microsoft’s own migration documentation provide a foundation that AI tools can build on. Claude Code does not need to invent migration patterns; it applies documented ones at scale.

For a deeper look at how to configure Claude Code for .NET projects specifically, see our Claude Code for .NET developers guide.

The four pillars of .NET modernisation

We structure every .NET modernisation engagement around four pillars, applied in sequence. Each pillar has different risk profiles, different levels of AI automation potential, and different business impacts.

Pillar 1: Language migration

What it covers: Moving from .NET Framework 4.x to .NET 10 (the current LTS). This includes project file conversion (.csproj format changes), namespace migrations, API replacements, and NuGet package updates.

AI automation potential: High (60-80% of changes). The mapping from .NET Framework APIs to .NET 10 equivalents is well-defined. Claude Code handles project file conversion, using statement updates, API replacements (HttpWebRequest to HttpClient, ConfigurationManager to IConfiguration), and test framework migration effectively.

What still needs humans: Decisions about which .NET 10 features to adopt (minimal APIs vs controllers, top-level statements), handling of APIs with no direct equivalent, and verification that business logic behaves identically after migration.

Key tools:

• Claude Code with a project-specific CLAUDE.md file defining migration rules and conventions
• .NET Upgrade Assistant (Microsoft.DotNet.UpgradeAssistant) for initial analysis and project file conversion
• try-convert for project file format migration

Typical timeline: 4-8 weeks for a 100k-200k line codebase, depending on complexity and test coverage.

For a detailed walkthrough of language migration, see our .NET Framework to .NET 10 migration guide.

Pillar 2: Platform modernisation

What it covers: Moving from Windows Server/IIS to cloud-native hosting. This typically means Azure App Service, Azure Container Apps, or AKS (Azure Kubernetes Service), depending on the application’s requirements.

AI automation potential: Moderate (40-60%). AI tools can generate Dockerfiles, Azure Bicep templates, CI/CD pipelines (GitHub Actions), and Kubernetes manifests. The configuration is templatable. What AI cannot do is make the hosting decision itself: that depends on your scaling requirements, compliance needs, budget, and operational maturity.

What still needs humans: Hosting strategy selection, networking and security architecture, data residency decisions, cost modelling, and operational runbook creation.

Key decisions:

• App Service for straightforward web applications with predictable load
• Container Apps for microservices or applications that benefit from scale-to-zero
• AKS for complex workloads requiring full Kubernetes orchestration

Typical timeline: 2-4 weeks after language migration, often overlapping.

Pillar 3: Architecture transformation

What it covers: Restructuring the application architecture. This might mean decomposing a monolith into services, replacing synchronous communication with async messaging, or migrating from Web Forms to Blazor.

AI automation potential: Low to moderate (30-50%). Architecture transformation involves design decisions that AI tools cannot make independently. AI is useful for generating boilerplate (service boundaries, message contracts, API gateways), but the decomposition strategy itself requires human understanding of the business domain.

What still needs humans: Service boundary definition, data ownership decisions, consistency model selection (eventual vs strong), and migration sequencing.

Common transformations:

• Web Forms to Blazor (significant UI rewrite; see below)
• WCF to gRPC for internal service communication (see our WCF to gRPC migration guide)
• Monolith to modular monolith (often a better first step than full microservices)
• EF6 to EF Core (data access layer modernisation)
• .NET Remoting to REST or gRPC

Typical timeline: 4-12 weeks per major component, depending on complexity.

Pillar 4: Integration modernisation

What it covers: Updating how the application communicates with other systems. Legacy .NET applications often rely on SOAP web services, file-based integrations, direct database connections, or .NET Remoting. Modern equivalents include REST APIs, gRPC, Azure Service Bus, and event-driven architectures.

AI automation potential: Moderate (40-60%). AI tools can generate API clients, message contracts, and adapter patterns. They are particularly effective at converting SOAP clients to REST clients because the transformation is largely mechanical. Event-driven architecture design, however, requires human input.

What still needs humans: Integration sequence planning (which integrations to modernise first), error handling and retry strategy, data transformation rules, and third-party system coordination.

Key patterns:

• SOAP to REST (often the quickest win)
• Direct database calls to API-mediated access
• File-based batch processing to event-driven streaming
• Synchronous calls to async messaging via Azure Service Bus

Typical timeline: 2-6 weeks per integration, depending on complexity and third-party coordination.

How the pillars sequence in practice

The four pillars are not independent workstreams. They have dependencies and natural ordering.

Language migration comes first. You cannot run on .NET 10 until the code compiles and passes tests on .NET 10. This is the foundation for everything else.

Platform modernisation runs second or in parallel. Once the code targets .NET 10, containerisation and cloud deployment become straightforward. In practice, we often start platform work (Dockerfiles, Bicep templates, CI/CD) during language migration so that the first .NET 10 build deploys to Azure automatically.

Architecture transformation is the longest and highest-risk pillar. It runs third because it benefits from having the code already on .NET 10 (more patterns available, better tooling support) and already in the cloud (easier to test at scale). Not every application needs architecture transformation. If the monolith works well and scales adequately, a modular monolith on .NET 10 running in Azure may be the right answer.

Integration modernisation runs throughout. Some integrations need updating as part of language migration (deprecated APIs). Others can be modernised independently. We typically prioritise integrations that are blocking other work or creating operational risk.

Pillar 1: Language Migration          [==========]
Pillar 2: Platform Modernisation          [========]
Pillar 3: Architecture Transformation         [============]
Pillar 4: Integration Modernisation    [====]   [====]   [====]
                                      Week 1              Week 14+

How we use Claude Code in .NET modernisation

Claude Code is a terminal-based AI coding tool from Anthropic that operates directly on your codebase. Unlike IDE-based assistants that work file-by-file, Claude Code can read, reason about, and modify entire directory structures. For large-scale migration work, this matters.

Setting up CLAUDE.md for .NET projects

Every .NET modernisation project starts with a CLAUDE.md file in the repository root. This file gives Claude Code the context it needs to generate project-consistent code rather than generic translations.

A typical CLAUDE.md for a .NET migration project:

# Project: [ProjectName] Migration

## Target
- Migrating from .NET Framework 4.8 to .NET 10
- Target hosting: Azure Container Apps
- CI/CD: GitHub Actions

## Conventions
- Use file-scoped namespaces
- Use primary constructors where appropriate
- Use ILogger<T> for logging (replace log4net)
- Use IOptions<T> pattern for configuration
- Nullable reference types enabled project-wide

## Migration rules
- HttpWebRequest -> HttpClient via IHttpClientFactory
- ConfigurationManager -> IConfiguration with appsettings.json
- Thread.Sleep -> await Task.Delay (async all the way)
- Global.asax -> Program.cs with WebApplicationBuilder
- web.config transforms -> appsettings.{Environment}.json
- EF6 DbContext -> EF Core DbContext (keep table/column names)

## Testing
- xUnit (migrated from MSTest)
- FluentAssertions for assertions
- NSubstitute for mocking (replace Moq)

## Do not
- Add async to methods that don't need it
- Change business logic during migration
- Rename database tables or columns
- Remove XML documentation comments

Using /compact for large codebases

.NET Framework solutions often have dozens of projects and hundreds of thousands of lines. Claude Code’s /compact command compresses the conversation context, allowing you to work through large migration sessions without hitting context limits. We typically run /compact after completing each major component migration.

Migration workflow

Our standard Claude Code migration workflow for a .NET component:

1. Analyse: Ask Claude Code to read the component and produce a migration plan (changed APIs, removed dependencies, new patterns needed)
2. Migrate: Execute the migration file by file or project by project, with Claude Code applying the rules from CLAUDE.md
3. Verify: Run the test suite after each component. Claude Code can fix failing tests if the failures are migration-related (API changes, namespace moves)
4. Review: A senior developer reviews the changes. AI-generated code gets the same review scrutiny as human-written code

This workflow produces our reported metric of approximately 84% AI-authored code in production deliveries (see our AI Velocity Report for methodology). The remaining 16% is architectural decisions, complex business logic, and edge cases that require human judgement.

For IP and licensing considerations around AI-generated code in your deliverables, see Who Owns AI-Written Code?

When modernisation is not the right answer

This is a modernisation playbook, but we would be doing you a disservice if we pretended modernisation is always the answer. Sometimes a rebuild is genuinely the better option.

Rebuild when:

• The architecture is fundamentally wrong for the business domain (not just outdated, but structurally mismatched)
• The codebase has accumulated so much technical debt that the tests are unreliable and the business logic is undocumented
• The application needs to move to an entirely different paradigm (desktop to web, monolith to event-driven, on-premise to SaaS product)
• The original development team is entirely gone and there is no institutional knowledge of the system

Modernise when:

• The core business logic is sound and tested
• The architecture is reasonable but the technology is outdated
• You need to preserve existing integrations and data flows
• You have time pressure (modernisation delivers value incrementally; rebuilds do not until completion)
• The team knows the system and can validate migration correctness

For a structured decision framework, see our Modernise, Rebuild, or Replace guide.

The assessment before the migration

Starting a migration without a structured assessment is the most common and most expensive mistake we see. The assessment answers three questions:

1. What do we have? Codebase analysis: size, complexity, dependencies, test coverage, architecture patterns, technical debt hotspots.
2. Where do we want to be? Target state definition: which pillars apply, which hosting model, which architecture changes.
3. What is the sequence? Migration plan: which components migrate first, what are the dependencies, what are the risks.

AI tooling has compressed assessment timelines significantly. Claude Code can analyse a 500k-line codebase in hours rather than the weeks it takes for manual code review. It identifies dependency trees, maps API usage patterns, flags unsupported APIs, and produces structured reports.

But AI analysis is not the same as assessment. The analysis is input to the assessment. A senior architect still needs to interpret the analysis, understand the business context, and make strategic decisions about sequencing and trade-offs.

For a detailed scoring framework to assess your .NET estate’s modernisation readiness, see our Legacy .NET Assessment Framework.

Common migration patterns in detail

Web Forms to Blazor

This is the most labour-intensive migration pattern in the .NET ecosystem. Web Forms and Blazor share almost no architectural DNA despite both being Microsoft web frameworks.

What changes:

• Page lifecycle model (Web Forms events) is replaced by a component model
• ViewState is replaced by component state and cascading parameters
• Server controls are replaced by Razor components
• Code-behind files are replaced by @code blocks or separate .razor.cs files
• PostBack model is replaced by SignalR-based (Blazor Server) or WebAssembly-based (Blazor WASM) interactivity

AI automation potential: Lower than other migrations (30-40%). Claude Code can convert individual controls and generate Razor component scaffolding, but the page lifecycle differences mean most pages need rethinking rather than translating. The data binding model is fundamentally different.

Our recommendation: For Web Forms applications, consider whether Blazor is the right target. If the application is primarily data entry forms, Blazor Server is a reasonable fit. If the application has complex client-side interactions, React (or React with a .NET API backend) may be a better target. Do not assume the Microsoft migration path is automatically the right one.

EF6 to EF Core

Entity Framework 6 to EF Core is one of the smoother migrations, but it has gotchas.

What Claude Code handles well:

• DbContext configuration migration (fluent API syntax changes)
• LINQ query translation (most queries work, but .Include() behaviour differs)
• Migration file generation for the new EF Core format

What needs human attention:

• Lazy loading behaviour changes (EF Core defaults to no lazy loading)
• ObjectContext and ObjectQuery usage (EF Core only supports DbContext)
• Complex inheritance mapping differences (table-per-hierarchy vs table-per-type defaults differ)
• Database-first workflows (EF Core’s scaffolding tools are different from EF6’s)

// EF6 configuration
public class OrderConfiguration : EntityTypeConfiguration<Order>
{
    public OrderConfiguration()
    {
        HasKey(o => o.Id);
        HasMany(o => o.Lines)
            .WithRequired(l => l.Order)
            .HasForeignKey(l => l.OrderId);
    }
}

// EF Core equivalent (generated by Claude Code)
public class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> builder)
    {
        builder.HasKey(o => o.Id);
        builder.HasMany(o => o.Lines)
            .WithOne(l => l.Order)
            .HasForeignKey(l => l.OrderId);
    }
}

WCF to gRPC

WCF (Windows Communication Foundation) has no .NET 10 equivalent from Microsoft. The three main replacement options are gRPC, REST (minimal APIs or controllers), and CoreWCF (community compatibility layer).

gRPC is the closest architectural match to WCF for internal service communication: it is contract-first, supports streaming, and has strong typing through Protocol Buffers. For a full treatment of this migration path, see our WCF to gRPC migration guide.

.NET Remoting replacement

.NET Remoting is not supported on .NET 10 and has no direct replacement. The migration path depends on how Remoting is used:

• Cross-process communication on the same machine: Replace with named pipes or gRPC over Unix domain sockets
• Cross-machine RPC: Replace with gRPC or REST APIs
• Event notifications: Replace with Azure Service Bus or SignalR

AI tools can identify Remoting usage patterns and generate replacement code, but the architectural decision (which replacement pattern for which use case) requires human input.

What we have seen in practice

These examples are representative of our modernisation engagements. Details are anonymised.

[CLIENT EXAMPLE: Financial services client, 450k LOC .NET Framework 4.6 monolith, heavy WCF usage for inter-service communication, EF6 data access layer. 14-week migration to .NET 10 with Claude Code. Language migration (Pillar 1) took 5 weeks with ~65% AI-authored code. WCF services migrated to gRPC (Pillar 3). Platform moved from on-premise IIS to Azure Container Apps (Pillar 2). Total AI-authored code in final delivery: ~72%. Key challenge was EF6 lazy loading behaviour differences that caused subtle data loading bugs caught during integration testing.]

[CLIENT EXAMPLE: Healthcare SaaS provider, 180k LOC .NET Framework 4.7.2 Web Forms application with SQL Server backend. Assessment revealed that Web Forms to Blazor migration would take longer than a targeted rebuild of the UI layer with React, keeping the .NET backend. 10-week engagement: backend migrated to .NET 10 minimal APIs (Pillar 1 + 3), frontend rebuilt in React (not a migration). Claude Code used extensively for API contract generation and backend migration. ~80% AI-authored code on the backend migration, ~60% on the React frontend.]

[CLIENT EXAMPLE: Education technology company, 320k LOC across 12 .NET Framework microservices with a mix of WCF and REST APIs, Azure Service Fabric hosting. Migrated to .NET 10 on Azure Container Apps over 16 weeks. Key complexity was the Service Fabric dependency (stateful services needed redesign for Container Apps). Claude Code handled service-by-service language migration effectively. Architecture transformation (Pillar 3) required significant human design for the stateful service replacement using Azure Cosmos DB and distributed caching.]

Cost and timeline expectations

Modernisation costs depend on codebase size, complexity, and which pillars apply. We do not publish fixed prices because every estate is different, but we can share typical ranges to help with budgeting.

Assessment phase (2-3 weeks): A structured codebase analysis and migration plan. This produces a detailed scope, timeline, and cost estimate for the full migration. It is a fixed-price engagement.

Language migration (Pillar 1): The most predictable pillar. AI tooling compresses this significantly. A 200k-line codebase typically takes 6-10 weeks with 2-3 engineers.

Platform modernisation (Pillar 2): Often the shortest pillar. 2-4 weeks for containerisation and Azure deployment. Overlaps with Pillar 1.

Architecture transformation (Pillar 3): The most variable pillar. 4-12 weeks per major component, depending on the transformation scope. Not every application needs this.

Integration modernisation (Pillar 4): 2-6 weeks per integration. Parallelisable with other pillars.

For a business-case analysis with worked cost examples, see The Real Cost of Legacy .NET.

The critical point: AI-assisted modernisation does not make the work free. It compresses timelines, reduces the cost of mechanical translation, and lets senior engineers focus on the decisions that actually matter. In our experience, AI-assisted modernisation reduces total project cost by 30-45% compared to fully manual migration, primarily by compressing the language migration and integration modernisation pillars.

Getting started

If you are managing a .NET Framework estate and considering modernisation, the first step is always an assessment. Not a sales call. An assessment: structured, technical, and honest about what modernisation will and will not achieve for your specific situation.

Our Legacy .NET Assessment is a 2-3 week engagement that produces:

• A codebase analysis (automated with AI tooling, reviewed by a senior architect)
• A four-pillar migration plan with sequencing and dependencies
• A timeline and cost estimate for each pillar
• A risk register with mitigation strategies
• A recommendation on whether modernisation, rebuild, or a hybrid approach is the right strategy

If the assessment concludes that modernisation is not the right answer for your situation, we will tell you. We would rather lose a project than deliver the wrong strategy.

Book a free Legacy .NET Assessment consultation to discuss your specific estate.

Further reading

This guide is the hub for our .NET modernisation content cluster. For detailed guidance on specific topics:

• .NET Framework to .NET 10 Migration with Claude Code: step-by-step language migration guide
• Legacy .NET Assessment Framework: scoring framework for modernisation readiness
• WCF to gRPC Migration: service layer modernisation
• The Real Cost of Legacy .NET: business case and cost analysis
• Why .NET Is the Best Legacy Stack for AI Modernisation: thought leadership on .NET’s AI advantages
• Claude Code for .NET Developers: getting started with Claude Code for .NET
• Modernise, Rebuild, or Replace: general decision framework
• Signs Your Legacy System Is Costing You More Than You Think: understanding hidden costs