If you have tried to find a straight answer to this question online, you will have noticed that nobody gives one. Consultancies say "it depends." Forums say "get a quote." Blog posts talk about methodology without ever mentioning a number.

That is partly because it genuinely does vary — but it is also because most people writing about .NET migration are selling migration services and have a commercial interest in keeping you in a conversation rather than giving you a number you can take to your board.

So here is a direct answer: a typical SME-scale .NET Framework migration costs between £15,000 and £120,000 in developer time, depending on codebase size and complexity. Large enterprise migrations run higher. Simple single-application migrations can fall below the lower end. The sections below explain what puts you where in that range.

Why you cannot find a standard price

A .NET migration is not a product with a fixed specification. The effort — and therefore the cost — is almost entirely determined by what is already in your codebase. Two companies with applications of similar age and size can face very different migration costs depending on the decisions that were made when the code was written.

This is not an excuse for vagueness. It is the reason that the most valuable thing you can do before budgeting a migration is to have someone who knows what they are looking for spend structured time in your codebase — before any migration work begins.

The four things that actually drive cost

1. Codebase size and project structure

Larger codebases cost more to migrate — but not always in proportion to size. A 300,000-line application with clean architecture and clear separation of concerns can migrate faster than a 60,000-line solution where business logic is embedded in the UI layer, database calls happen in event handlers, and there are circular dependencies between projects.

The question is not how much code you have — it is how well it is structured and how clearly the layers are separated. Poorly structured code costs significantly more to migrate safely.

2. Third-party dependency compatibility

This is the most common source of budget overrun in migration projects. NuGet packages that worked on .NET Framework 4.8 do not always have .NET 10 equivalents. When a core dependency — a reporting library, an integration wrapper, a legacy database driver — has no modern equivalent, the team has to find an alternative or rewrite the functionality. Either option takes time that was not in the original estimate.

The packages most likely to cause problems: Crystal Reports, older SSRS integration code, COM interop wrappers, Windows-specific print or document libraries, and anything wrapping a third-party API that has since changed its SDK. If your codebase uses any of these, budget more.

3. UI complexity

WinForms runs on .NET 10 — Microsoft ported it. So if your application has a WinForms front-end, you can migrate the framework without touching the UI. Whether you should is a separate question.

If the goal is a long-term maintainable application, the UI modernisation — typically WinForms to Blazor or a web front-end — is eventually necessary. That workstream carries its own cost: a modest WinForms application typically costs £20,000 to £50,000 to migrate to Blazor depending on complexity. A large one with bespoke controls and complex data binding can exceed £100,000.

The important budgeting point: plan the UI migration as a separate line item. Teams that lump it in with the framework migration consistently underestimate both.

4. Team experience with migration work

A developer who has migrated several .NET Framework applications will move significantly faster than one doing it for the first time. Migration work has a specific learning curve — understanding the compatibility shims, knowing which deprecated APIs have clean replacements and which need rethinking, handling the inevitable build errors that are symptoms rather than causes.

If you are using your existing development team and none of them have done a migration of this kind before, build a contingency into your estimate. A 20 to 30 per cent buffer is not excessive for a first migration.

The hidden costs most teams forget

Developer time is the largest line item, but it is not the only one. These are the costs that appear in retrospect:

  • Testing time. A migration touches the entire codebase. If your test coverage is low, you need to either build confidence through manual testing — which is slow and expensive — or invest in automated tests before or during the migration. Neither is free.
  • Parallel running. Many organisations run the old and new systems in parallel during a transition period to validate correctness. That means two systems to maintain, deploy, and monitor for weeks or months.
  • Infrastructure changes. .NET 10 applications often run in containers where .NET Framework applications ran on bare Windows servers. Moving to Docker, updating your CI/CD pipeline, and retraining your operations team on the new deployment model all carry cost.
  • Downtime risk management. Depending on the criticality of the system, you may need a detailed cutover plan, rollback procedures, and out-of-hours deployment. That planning time is real cost.
  • Training. If the migration includes a move from VB.NET to C#, or from WinForms to Blazor, your development team needs time to become productive in the new technology. Factor in at least two to four weeks of reduced velocity after the migration is complete.

Rough cost ranges by project size

Based on migration work across UK businesses, these are realistic developer-cost ranges — excluding infrastructure, testing investment, and training:

  • Small application (1–3 projects, clean structure, few external dependencies): £8,000 to £20,000
  • Mid-size application (5–15 projects, moderate dependencies, some WinForms): £25,000 to £70,000
  • Large application (15+ projects, significant dependencies, VB.NET, WinForms): £70,000 to £150,000
  • Enterprise estate (multiple applications with shared infrastructure): phase-based — budget the assessment first, then each application separately

These are developer day-rate costs at typical UK contract rates. If you are using a software house or consultancy, add their margin — typically 40 to 80 per cent on top of the underlying developer cost.

The cost of doing nothing

Every year a .NET Framework application stays on the old runtime is a year of compounding risk. Security patches for .NET Framework are becoming less frequent. The pool of developers willing to maintain legacy .NET Framework codebases is shrinking and the day rates for those who will are rising. Third-party libraries drop .NET Framework support without warning. And the longer the migration is deferred, the more the codebase drifts — new features added in the old architecture, new dependencies taken on the old platform, making the eventual migration larger and more expensive.

The cost of inaction is real. It just does not appear on a single invoice.

Before you commit a budget

The most expensive migration mistake is committing development budget based on an estimate formed without looking properly at the codebase. The second most expensive is discovering mid-migration that the budget was wrong and having to stop.

A structured codebase audit — done before any migration work begins — maps the dependency graph, identifies the packages without .NET 10 equivalents, flags the high-risk areas, and produces a written effort estimate specific to your system. It turns a conversation based on assumptions into a plan based on evidence.

That is what the fixed-price audit at JM BTS provides: a written report delivered in five working days, covering your migration path, risks, effort estimate, and prioritised action plan. From £399 — before you commit a development budget.