Migrating from .NET Framework to Modern .NET: Realistic Timeline and Scope

The official migration documentation describes a mechanical process: upgrade project files, resolve breaking changes, update packages. On a small, well-structured codebase that is approximately accurate. On a production system with years of accumulated dependencies and multiple contributors, the migration is a new project that reuses existing code.

What the work consists of

There is no viable in-place upgrade path. The migration creates a new project, new hosting configuration, and new data access configuration. Application code moves across, and the effective method is incremental, controller by controller, service by service, because a substantial set of APIs heavily used in .NET Framework do not exist in modern .NET.

The core work:

• New SDK-style project files targeting the current runtime
• Resolution of removed and changed APIs
• Replacement of NuGet packages with no modern equivalent
• Rebuilt deployment and hosting configuration
• Verification that the application behaves identically after the move

The last item is where most of the schedule goes, and it is the item most often omitted from initial estimates.

What extends the timeline

System.Web dependencies. Anything depending on System.Web (Web Forms, HttpContext.Current accessed statically, and a range of session and authentication APIs) requires the most work. These have no direct replacements. The functionality has to be reimplemented against a different model, not renamed.

Web Forms is the extreme case: the UI layer has no migration path and is rewritten regardless of what happens to the business logic underneath.

Third-party packages with no modern equivalent. Common in older codebases. Some have successors with comparable functionality; others are abandoned. Replacement is rarely a substitution, particularly when the package handles something the application depends on heavily. Reporting engines and document generation are the recurring examples, and either can dominate the estimate.

Windows-specific code. Direct Windows API calls, COM interop, registry access, and Windows service patterns require rework, or an explicit decision to remain Windows-only and forgo cross-platform deployment. That decision is legitimate and should be made deliberately rather than discovered.

Absent test coverage. Migrations without automated coverage require manual regression testing across the full application. This is slow, less reliable, and on a complex application adds weeks. It is the single largest variable in the estimate. The same application with and without coverage differs by a factor of two to three.

Timeline and cost ranges

These assume a developer with prior .NET migration experience. A team performing their first migration should expect the upper end of each range.

• Small application. Under 50k lines, minimal System.Web usage, current dependencies, reasonable test coverage: two to four weeks, $10,000–$13,000
• Medium application. Active business logic, some System.Web usage, a mix of current and dated dependencies: one to three months, $15,000–$25,000
• Large or complex application. Heavy System.Web usage, legacy package dependencies, Windows-specific integrations, substantial manual testing: three to six months, $35,000 and up

Large migrations are best executed in stages, which reduces the exposure at any point and allows test coverage to be established incrementally ahead of each stage.

The assessment that sets the range

A few days of inspection before committing to a timeline identifies which range applies.

What to establish:

• Project count in the solution, and which projects reference System.Web
• Full external dependency inventory with modern-equivalent status for each package
• Existing test coverage, and what it covers
• Windows-specific API usage, counted
• Whether class libraries and business logic can be migrated separately from the web layer

That last point matters on larger codebases. Staging the migration (moving business logic and data access first, then the web layer) reduces risk substantially and is only identifiable through this inspection.

Paying for an audit before committing to a full migration project is proportionate. Committing to a timeline without one is how teams commit to two months and finish at five.

When migration is the right investment

.NET Framework is not being removed. It ships with Windows and continues to receive security updates. It receives no new feature work.

Migration is not justified by version number alone. The case is strongest when:

• The application needs capabilities available only in modern .NET
• Cross-platform or container deployment is a requirement
• The application is under active development and the team needs current tooling and performance characteristics
• Hiring is constrained by the platform
• Dependencies in the current stack are themselves reaching end of support

For a stable, well-understood application that is not under active development, migration may not be the right use of resources. The question to answer before starting is which specific problem the migration resolves for the organization, stated in terms a budget holder can evaluate.