Most .NET Framework migrations take between 4 and 16 weeks for a typical SME-scale application. Large enterprise codebases with significant third-party dependencies, WinForms UIs, or VB.NET components can run to six months or more. If someone quotes you a fixed number without looking at your codebase first, treat that estimate with caution.

That is the honest short answer. The longer answer — the one that actually helps you plan — is about the three things that drive every timeline, and the one thing that delays almost every migration regardless of codebase size.

The three factors that actually drive the timeline

1. Codebase size and structure

The number of projects in your solution is a better predictor of migration effort than lines of code. A single 200,000-line application with clean layering often migrates faster than a 50,000-line solution with fifteen interdependent class library projects, each carrying their own NuGet dependencies pinned to specific versions.

The structural question to ask is: how many things does each project depend on, and how many things depend on it? Deeply tangled dependency graphs — where changing one project forces rebuilds across half the solution — are where timelines stretch.

2. Third-party dependencies

This is the single biggest source of surprise in migration projects. A team will estimate two weeks based on their own code, then discover that two of their NuGet packages have no .NET 10 equivalent and need replacing entirely. The replacement is not always obvious, and sometimes there is no direct equivalent — the functionality has to be rewritten.

The packages most likely to cause problems are older Windows-specific libraries, COM interop wrappers, report generation libraries (Crystal Reports is the classic culprit), and anything that wraps a legacy database driver. Budget extra time for anything in those categories.

3. UI complexity

If your application has a WinForms or WPF front-end, that is a separate workstream from the .NET Framework to .NET 10 migration and should be planned as one. WinForms does run on .NET 10 — Microsoft ported it — so in some cases you can migrate the framework without touching the UI. But if the goal is a modern, maintainable, web-deployable application, a WinForms to Blazor migration is the natural next step, and it needs its own timeline.

A modest WinForms application — a few dozen forms, mostly data entry — typically takes 6 to 10 weeks to migrate to Blazor. A complex one with bespoke controls, printing, and tightly coupled business logic can take six months. The two workstreams can run in parallel with the right team structure, or sequentially if you have limited resource.

VB.NET to C# is a separate question

If your codebase is in VB.NET, you have an additional decision to make before you migrate: do you convert to C# as part of this project, or migrate the VB.NET codebase to .NET 10 first and convert later?

The answer depends on your team. VB.NET runs on .NET 10 — Microsoft still supports it. So converting to C# is not technically required to modernise the framework. But most teams choose to do both together, because the C# ecosystem is where all tooling investment is going and because maintaining VB.NET expertise long-term gets harder as the developer pool shrinks.

Converting VB.NET to C# adds roughly 30 to 50 per cent to the migration timeline. Automated tools handle the mechanical translation, but they produce C# that reads like VB.NET — it builds and runs, but it is not idiomatic and it accumulates technical debt. Budget time for a human review pass if quality matters to you, and it should.

The thing that delays every migration

It is not the code. In 21 years of .NET migrations, the most consistent cause of timeline overrun is the same every time: the migration starts before anyone has a clear picture of what is actually in the codebase.

Teams begin with an estimate based on what the developer who built the thing remembers. Then, three weeks in, they discover a dependency that nobody documented, a third-party library that has not been updated since 2014, or a COM component that is called in seventeen places and has no obvious modern equivalent. The project stalls while the team figures out what to do.

The fix is straightforward: spend time at the start on a structured assessment of the codebase before the migration work begins. Map the dependency graph. Identify the packages with no .NET 10 equivalent. Flag the COM interop points. Estimate the UI workstream separately. That work — done properly, by someone who knows what they are looking for — is what turns a vague budget conversation into a reliable plan.

Realistic timelines by size

As a rough guide, based on migration work across a range of UK businesses:

  • Small application (1–3 projects, few external dependencies, no WinForms): 3 to 6 weeks
  • Mid-size application (5–15 projects, mixed dependencies, some WinForms): 8 to 16 weeks
  • Large or complex application (15+ projects, significant third-party dependencies, VB.NET, WinForms): 4 to 9 months
  • Enterprise multi-system estate (multiple applications, shared libraries, legacy integrations): plan in phases; the first phase assessment takes 4 to 6 weeks alone

These ranges assume a competent team with dedicated migration time — not a developer squeezing migration work around feature delivery. Splitting attention is the other reliable way to double a timeline.

Before you commit developer time

The most useful thing you can do before putting a migration in your roadmap is to get a clear written picture of what you are actually dealing with. Not a verbal estimate from the developer who built it — a structured assessment that maps the dependencies, flags the risks, and gives you a realistic effort range specific to your codebase.

That is exactly what a fixed-price codebase audit provides. In five working days, you get a written report covering your migration path, the risks specific to your system, a realistic effort estimate, and a prioritised action plan — before you commit a single sprint of development time.

If you are at the stage of trying to work out what a .NET Framework migration will actually cost and take, that is the right place to start.