Blazor enterprise migration: when to move from WebForms, WPF or ASP.NET MVC in 2026

The system has been in production since 2008. It works. Nobody touches it willingly because every change risks breaking something, and the developer who built it left the company in 2014. New developers look at it the way archaeologists look at an artifact: with respect mixed with discomfort. The CTO knows its limitations, understands it will eventually need replacing, but every year the "migration" line item gets pushed to the next budget because there are more urgent priorities.

This story repeats itself in hundreds of companies across Europe. WebForms from 2008, WPF from 2011, ASP.NET MVC 4 from 2012: applications that have done their job for years and continue to do so, but that cost more to maintain every year, become harder to extend and riskier to modify. And meanwhile, Blazor, the Microsoft framework for modern web applications in C#, has become mature enough to represent a concrete destination for these migrations.

The question is not "Is Blazor good?" In 2026, the answer is clearly yes. The right question every CTO and IT manager must address is: in my specific case, when does migrating make sense, what does it really cost, and how do you structure the project so it does not paralyze the business during the transition?

This guide is not a technical tutorial on Blazor. It is a practical decision framework for those who need to make the decision, present it to management and plan it in a way that succeeds. Real numbers, concrete scenarios, clear criteria.

Migrating to Blazor is not a technical question: it is a business decision with an immediate cost and a measurable return over time. Ignoring it does not make it disappear: it makes it more expensive.

What is Blazor and why it is not just another framework of the month

Framework fatigue is real in the web ecosystem. For every IT manager who has watched Angular replace AngularJS, React overtake React, Vue grow and then plateau, the reaction to any "new Microsoft framework" announcement is understandable skepticism.

Blazor is different for one specific reason: it is not a framework for those who want to learn JavaScript or keep up with frontend trends. It is a Microsoft framework, written by Microsoft, supported by Microsoft, deeply integrated into the .NET ecosystem, that lets you write web interfaces in C# sharing code with the backend. For companies that already have a .NET team, this is not a stylistic innovation: it is a revolution in team structure and development costs.

The signals of Blazor's enterprise maturity in 2026 are concrete. Microsoft uses it internally for productivity tools and company portals. The component ecosystem, with libraries like MudBlazor, Radzen Blazor and Telerik UI for Blazor, covers all standard enterprise interface patterns. Documentation is extensive, the community is active, and known issues are documented with established solutions. We are not talking about a beta framework used by experimental startups: we are talking about technology that European banks, insurers and manufacturing companies use in production.

How Blazor works in summary for those who decide, not implement

Blazor allows the existing C# team to develop web interfaces without writing JavaScript. User interface components are written in C# with a syntax that blends HTML markup and C# logic (.razor files). Blazor handles updating the interface in response to user events.

There are two main execution modes, with very different implications for architecture and scalability, described in the dedicated section. The key element for the IT manager is that the existing .NET team can start producing value in Blazor with a learning curve of weeks, not months, and without hiring frontend specialists.

The signals that tell you it is time to migrate: the concrete list

How do you recognize the point where the cost of maintaining the old system exceeds the cost of migrating? It is not always obvious, but there are predictive signals that, when they appear together, make migration urgent.

Technical signals

The system only runs on .NET Framework. .NET Framework 4.8 is the last version and receives no functional updates, only security patches. This means no ability to use modern .NET 8/9 APIs, lower performance compared to the modern runtime, and a growing divergence from the NuGet ecosystem where new packages target only modern .NET.

Third-party dependencies are no longer updated. Libraries used in the legacy application that have stopped receiving updates, that have unpatched CVE vulnerabilities because the supported version requires modern .NET, that force maintaining old versions of other components for compatibility.

Deployment requires IIS on Windows Server with manual configuration. Inability to containerize, to deploy on Azure App Service with standard configuration, to use modern CI/CD pipelines without workarounds. Every deployment is a manual event with human error risk.

The browser has stopped supporting features the application uses. ActiveX, specific plugins, IE-only behaviors: if the WebForms application depends on features that modern browsers have deprecated or removed, you are running on a timer.

Organizational signals

Team turnover takes away undocumented knowledge. Every developer who leaves takes with them understanding of the legacy application that is not written down anywhere. If onboarding a new developer onto the system takes more than three months to reach acceptable productivity, the cost of turnover is already unsustainable.

New features consistently take longer than estimated. When an experienced team estimates a feature in a week and it takes three, the problem is not the team: it is the accidental complexity accumulated in the system. This entropy has a direct cost on market response speed.

The business asks for integrations the legacy system cannot support. RESTful APIs for mobile apps, cloud service integration, real-time data export for analytics: every business request the legacy system cannot satisfy is a measurable opportunity cost.

Senior developers decline the project. The best developers on the market, when informed they will work on WebForms or legacy WPF, frequently decline the offer. You are losing competitiveness in attracting talent for a system that already costs more to maintain.

WebForms: when Blazor migration is urgent

ASP.NET WebForms has the strongest case for migration. Microsoft has officially stated that WebForms will not be ported to .NET Core and will receive no new features. It is not end-of-life in the sense that it stops working: it will work as long as .NET Framework 4.8 is supported, until 2029. But every passing year, the gap between what is possible with WebForms and what the business demands grows wider.

The specific problem with WebForms: codebehind

WebForms has an intrinsic architectural flaw that makes migration technically more complex than other legacy systems: the codebehind pattern. In a typical WebForms application, business logic, presentation logic and data access logic are mixed in .aspx.cs files. A single Button_Click method can query the database, perform business calculations, format output and update the user interface, all together, without separation.

This architecture, reasonable for its era, makes direct migration to Blazor practically impossible without preliminary work to separate responsibilities. Before migrating WebForms code to Blazor, the team must extract business logic into separate services, isolate data access in dedicated repositories or classes, and reduce codebehind to pure presentation logic.

This preparatory work, often called pre-migration refactoring, has a real cost but produces an immediate benefit: it makes the code testable and understandable before Blazor even enters the picture. Many companies that have done this on legacy WebForms have rediscovered bugs and undocumented behaviors that had been hidden in codebehind complexity for years.

When WebForms to Blazor migration is urgent

Migration becomes urgent when at least one of these conditions is met: the system does not work on modern browsers without compatibility mode, the system uses third-party commercial components the vendor has declared end-of-life, the system cannot be secured due to vulnerabilities in non-updatable dependencies, or the team can no longer deliver features at a pace acceptable to the business. In these scenarios, every month of delay has a measurable direct cost.

WPF: Blazor Hybrid as an alternative to full rewrite

WPF (Windows Presentation Foundation) is a different case from WebForms. It is not dead: Microsoft continues to support it and it receives updates on modern .NET. A WPF application on .NET 8 can run with excellent performance, can use modern libraries, can be partially containerized. The problem with WPF is not technological in an absolute sense: it is strategic.

WPF only runs on Windows. In a world where the business demands access from browsers, tablets and non-Windows devices, this limitation becomes increasingly costly. An HMI interface for industrial machines that needs to be accessible from operators' tablets, an ERP system that the sales team wants to use from home on a Mac, a management dashboard the CFO wants on an iPad: all these cases require an answer WPF cannot provide.

Blazor Hybrid: the least invasive modernization path for WPF

Blazor Hybrid, via .NET MAUI, allows hosting Blazor components inside an existing WPF or WinForms desktop application. This is not a different framework: it is a bridge that lets you insert Blazor interface parts into an existing WPF window, leaving the rest of the application unchanged.

The recommended migration pattern for WPF to Blazor Hybrid is incremental: identify a relatively isolated functional module (the reporting module, the configuration module, the advanced search module), rewrite that module as a Blazor component, host the Blazor component inside a WPF window via WebView2. The rest of the application continues to work normally during migration.

The advantages of this approach: no big bang rewrite with its attendant risk, the team learns Blazor on low-risk modules before touching the application core, the business experiences no interruption, and at the end of migration the application can be distributed both as a desktop app and as a web app with the same Blazor code.

When to consider Blazor Desktop over Blazor Hybrid

If the ultimate goal is to completely eliminate WPF and have a web-first application, Blazor Desktop (MAUI) is the destination, not an intermediate step. If the goal is to modernize the interface while keeping a desktop application with local resource access (filesystem, specific hardware, COM interop), Blazor Hybrid inside WPF or WinForms is the endpoint, not just the path.

For industrial and SCADA applications where direct hardware access is a non-negotiable requirement, the hybrid approach is almost always the right answer. We have covered this in detail in the article on migrating SCADA HMI from WPF to Blazor.

ASP.NET MVC: when migrating to Blazor makes sense and when it does not

ASP.NET MVC on modern .NET (ASP.NET Core MVC) is in a completely different position from WebForms and legacy WPF. It is not a dying technology: it is fully supported, receives updates, scales, containerizes, and integrates with modern cloud services. The reason to migrate from ASP.NET Core MVC to Blazor is not system survival, but optimization of development costs and user experience.

When MVC to Blazor migration makes sense

Migration from ASP.NET Core MVC to Blazor makes economic sense when the application has a significant amount of client-side interactivity currently requiring custom JavaScript. If the MVC team has a 5,000-line JavaScript file written over the years to handle complex interactions, dynamic validations, partial page updates and real-time communications, migrating to Blazor eliminates that JavaScript technical debt and consolidates everything in C#.

It also makes sense when the team needs to grow and the frontend/backend distinction creates bottlenecks: if every feature requires coordination between the C# developer and the JavaScript developer, and the team does not have enough JavaScript developers, Blazor solves the problem structurally.

When MVC to Blazor migration does not make sense

It does not make sense if the MVC application works well and has little custom JavaScript: the migration overhead is not justified by proportional benefits. It does not make sense if the system has critical SEO requirements needing optimal server-side rendering: Blazor Server has SSR limitations compared to MVC for certain SEO patterns, even though this has improved in .NET 8/9 with Blazor United. It does not make sense if the budget does not cover a proper migration: a hurried MVC to Blazor migration without architectural refactoring creates Blazor component performance problems worse than the starting point.

The practical rule: if you are considering migrating from ASP.NET Core MVC to Blazor mainly to "keep up with the times" without an identifiable concrete benefit, do not migrate. If you have a specific problem that Blazor solves and MVC does not, evaluate migration on that problem before deciding for the entire application.

The real cost of a Blazor migration: with numbers

Cost estimation is where most migration evaluations fail: they systematically underestimate, projects run over budget, the business loses confidence in the initiative. Let us look at the real factors that determine cost and verified ballpark figures from real projects.

Factors that determine migration cost

Number of views/screens to migrate. This is the primary cost driver. A simple view with few fields and linear logic requires 8-16 hours of development to migrate to Blazor (analysis, rewrite, testing). A complex view with intricate JavaScript logic, undocumented business constraints and many dependencies requires 40-80 hours. The weighted average on typical enterprise applications is 20-30 hours per view.

Quality of existing code. An application with clear separation between business logic and presentation costs 30-40% less to migrate than one with everything in codebehind or controllers. Code without automated tests requires additional effort to write tests before migration (to verify post-migration behavior is identical).

Integration complexity. If the legacy system integrates with other internal systems via SOAP web services, COM interop, direct database calls: each integration requires specific analysis and often an adaptation layer. Integrations are typically 20-30% of total migration cost.

Team cost. In Europe in 2026, a senior .NET developer with Blazor experience costs 55-85 euros/hour as an external consultant, or the equivalent of 70,000-100,000 euros/year total employment cost for a permanent hire. A team of 2-3 developers for 6-9 months is the typical size for medium-complexity applications.

Ballpark figures by application type

Small WebForms application (20-40 views, clean architecture): 400-800 hours, 4-6 months with a team of 2 developers, indicative cost 25,000-65,000 euros.

Medium WebForms application (60-100 views, coupled codebehind): 1,200-2,000 hours, 8-12 months with a team of 2-3 developers, indicative cost 75,000-160,000 euros. Includes pre-migration refactoring cost.

Large WebForms application (150+ views, mission-critical system): 2,500-4,000+ hours, 12-18 months with a team of 3-4 developers, indicative cost 150,000-300,000 euros. In these cases, incremental module migration is almost always preferable to big bang.

WPF application with Blazor Hybrid migration (incremental approach): cost depends on how many modules are migrated. A single medium-complexity module requires 200-400 hours. Full migration of a typical enterprise WPF application (30-50 windows) requires 1,500-3,000 hours over 12-24 months.

Add 15-20% for project management, acceptance testing and team training. And consider indirect costs: time internal developers spend collaborating with the migration team (typically 20-30% of their time during the active phase), and the cost of regression testing on integrated systems.

Blazor Server vs Blazor WebAssembly: which to choose for your enterprise

The choice between Blazor Server and Blazor WebAssembly is not a matter of technical preference: it is an architectural decision with direct implications on infrastructure costs, scalability, security and user experience. Here are the concrete criteria for the choice.

Blazor Server: when it is the right choice

In Blazor Server, the application runs entirely on the server. The browser receives and displays HTML, but every click, every input, every event is transmitted via WebSocket (SignalR) to the server, which processes the response and sends only the necessary DOM differences back. The browser is an intelligent terminal; the server is the brain.

Blazor Server is the right choice for internal enterprise applications with users on the local network or VPN: SignalR latency is imperceptible on fast, stable connections. It is preferable when the team has limited experience managing the security of REST APIs exposed to the browser (in Blazor Server, C# code with data access is never exposed to the client). It is ideal when the application has real-time requirements: push notifications, live dashboard updates, bidirectional communication. It scales vertically effectively on dedicated servers or Azure App Service with appropriate plans.

The limit of Blazor Server: each active user maintains a WebSocket connection with the server. This means server memory consumption grows linearly with simultaneous users. For an internal application with 50-200 simultaneous users, it is manageable. For a public portal with 10,000 simultaneous users, infrastructure costs become significant.

Blazor WebAssembly: when it is the right choice

In Blazor WebAssembly, the application is downloaded into the user's browser and runs locally via the .NET runtime compiled to WebAssembly. The server exists only as a REST API providing data. After the initial download (typically 5-15 MB), the interface responds without network latency.

Blazor WebAssembly is preferable for applications targeting external users on heterogeneous connections: no dependency on SignalR latency. It is the right choice when you want to reduce server load for high-user-volume applications. It is necessary for applications that need to work offline (with PWA capabilities). And it is the right direction when you want a clear separation between frontend and backend, with APIs reusable also for mobile.

The limit of Blazor WebAssembly: the initial application download is heavier compared to a traditional JavaScript SPA. Security management is more complex because the code runs on the client (you cannot hide sensitive logic in the client as in Blazor Server). And CPU-intensive operations on the client have lower performance than on the server.

Blazor United and hybrid mode in .NET 9

With .NET 8 and .NET 9, Microsoft introduced the ability to mix the two modes in the same Blazor application: some parts run in Server, others in WebAssembly, with static rendering for non-interactive pages. This hybrid approach, called Blazor United or Blazor with render modes, is the direction Microsoft is pushing and represents the most flexible way to build new applications. For migrations from legacy, starting with Blazor Server (faster and simpler to develop) and adding WebAssembly for modules that benefit from it is a reasonable strategy.

How to structure the Blazor migration project: the 4 steps

The difference between a migration that succeeds and one that becomes an endless project with 200% overrun is almost always in the project structure, not in team capabilities. These are the four steps that produce predictable, controllable results.

Step 1: Assessment and scope definition (2-4 weeks)

Before writing a line of Blazor code, the team must have a complete picture of what needs to be migrated. The assessment includes: inventory of all views/screens with complexity estimates for each, dependency mapping between modules, identification of external integrations and systems the legacy communicates with, inventory of coupling points between business logic and presentation (the most predictive signal of migration cost), and evaluation of the state of existing automated tests.

The output of this step is an assessment document with three elements: a cost and timeline estimate for the defined scope, a strategy recommendation (big bang vs incremental vs strangler fig), and a prioritized list of modules to migrate first based on risk and business value.

Step 2: Pre-migration refactoring (20-30% of total time)

Pre-migration refactoring is the preparatory work that separates business logic from presentation in the legacy system before touching Blazor. This is not about rewriting the application: it is about extracting business logic into C# services that can be reused in the Blazor project without modification.

This step is the one companies most often skip to save time, and the one that causes most of the overruns and failures in migration projects. A WebForms application with 100 views where every view has business logic in codebehind requires this step without exception. Without it, you are rewriting not just the presentation but all the business logic, with the risk of introducing regressions on behaviors that were not documented anywhere.

Step 3: Incremental module migration (core of the project)

The actual migration happens module by module, in the priority order defined in the assessment. The strangler fig pattern applied to Blazor migration works like this: the legacy system continues running in production, new Blazor modules are added progressively alongside it, a reverse proxy (or the application configuration itself) routes traffic to the legacy module or the Blazor module depending on the route.

This approach guarantees the business never has a downtime window during migration. Acceptance tests for each migrated module are run in parallel with legacy production, and cutover happens module by module only when the team is confident of functional parity.

Recommended migration sequence: start with the least critical and least complex modules (to allow the team to learn Blazor on low-risk code), then high-visibility but low-complexity modules (to demonstrate value to the business quickly), then core modules.

Step 4: Consolidation and optimization (10-15% of total time)

Once all modules are migrated, the final phase consolidates the result: decommissioning of the legacy system, Blazor performance optimization (bundle size, lazy loading of modules, caching), security review of the entire application, updated documentation and team training on established Blazor patterns. This phase is often underestimated: decommissioning a legacy system with integrations distributed across dozens of points in the broader enterprise ecosystem is not trivial.

ROI of Blazor migration: the metrics to monitor

A migration project must be justified to management not just with technical arguments, but with a business case that quantifies the expected return. Here are the most concrete metrics and how to calculate them for your specific case.

Maintenance cost reduction

The maintenance cost of a legacy system grows over time. Every year, the team spends more hours on the same changes (code entropy), bugs become harder to diagnose, and business requests the system cannot fulfill accumulate. The conservative estimate of maintenance cost reduction after migration to Blazor on Italian medium-complexity WebForms applications is 35-50% in the first year post-migration, with further reduction in subsequent years as the team gains familiarity with the new codebase.

To quantify: calculate the current annual maintenance cost of the legacy system (developer hours dedicated x hourly rate), estimate a 40% reduction, project it over 5 years. This is the expected savings on the maintenance front alone.

Time-to-market reduction for new features

A modern Blazor system on .NET 8/9 allows adding new features in less time thanks to separation of responsibilities, code testability and availability of reusable components. The average estimate of time-to-market reduction per feature after a proper migration is 25-40% compared to the legacy system. For the business, this means more features released per sprint, faster response to market demands, more value produced by the same team.

Infrastructure and licensing savings

A Blazor application on .NET 8 can run on Linux (dramatic reduction in Windows Server licensing costs), can be containerized on Kubernetes with automatic scaling, can leverage cheaper Azure App Service tiers with autoscaling. For applications currently on Windows Server with IIS and on-premises SQL Server, migrating to cloud infrastructure can reduce operational costs by 20-40% in the long run.

Security risk reduction

This element is the hardest to quantify in advance but the most expensive when it materializes. A legacy system with non-updatable dependencies has a growing risk profile over time. The average cost of a data breach for a medium-sized European company is estimated between 150,000 and 500,000 euros in remediation, sanctions and reputational damage. Risk reduction through modernization is a real benefit even if it cannot be precisely accounted for.

The ROI calculation: practical formula

ROI = [(Annual maintenance savings + Time-to-market savings + Infrastructure savings) x years - Migration cost] / Migration cost x 100.

For a medium WebForms application with a migration cost of 120,000 euros and expected savings of 60,000 euros/year, the ROI is already positive in the second year after migration completion, and at the third year it reaches 50%. Projected over 5 years, ROI exceeds 100% on maintenance savings alone, excluding benefits on development velocity and risk reduction.

For related topics on the modernization theme, read also the guide on legacy software modernization approaches and on the economic impact of unmaintained legacy software.

Conclusion: Blazor migration is not a technical project, it is a strategic decision

Blazor in 2026 is a mature technology, supported by Microsoft, with a consolidated ecosystem and a large community. Betting on it is no longer a technological risk. The real risk, for companies with WebForms, legacy WPF or MVC systems with heavy JavaScript, is continuing to wait.

The cost of doing nothing is not zero: it is the growing cost of maintenance, the opportunity cost of unreleased features, the security risk cost of systems with non-updatable dependencies, the turnover cost on a codebase no developer wants to touch. These costs grow every year that passes without a modernization plan.

Blazor migration should not be experienced as a technical project to be fully delegated to the development team. It should be experienced as a strategic decision that the CTO or IT manager makes based on a cost-benefit analysis, with a structured plan, defined success metrics and business commitment. Done this way, it produces measurable and predictable results. Done as a crisis response, in an emergency, without structure, it is the most risky and expensive investment possible.

Companies that plan migration today, methodically and without urgency, get the same technology at one third the cost of those who will do it in an emergency eighteen months from now.

If you have a WebForms, WPF or MVC system and want to understand exactly how much migration costs in your specific case, which strategy is most appropriate and how to present the business case to management, our .NET modernization experts can guide you through a detailed assessment and a concrete migration plan.