Moving a WinForms or WPF application to the web without a big-bang rewrite

In many companies, especially in manufacturing, logistics and wholesale, the most important program is not a web application. It is a desktop application in WinForms or WPF, built ten or fifteen years ago, and the whole business runs on it.

And it works. That is also the problem, because nobody wants to touch something that works. But around it, things pile up that cost more and more.

First, the honest truth: WinForms and WPF are not dead

WinForms and WPF are supported on .NET 10. If you move the application from .NET Framework to current .NET, it can keep running for years.

So the problem isn’t that it will stop working. The problem is everything around it.

Where a desktop application starts to cost money

• Installing it on every PC. A new version means walking round the PCs, or a script that fails on half of them. And then five people work on five different versions.
• Working from home and on the road. Access from outside needs Citrix or remote desktop, with licences and servers to pay for.
• A tablet in the warehouse, a phone in the field. The desktop application doesn’t run on them.
• A database password on every PC. Most old desktop applications connect straight to the database, so the database username and password sit in the configuration on every PC. Whoever has a PC has access to the database. It is a security hole most managers don’t know about.
• It is harder and harder to find people. New developers build for the web, and fewer and fewer people maintain desktop applications.

Three routes

Route	What it means	Risk	When it makes sense
Stay on the desktop	Move to .NET 10, everything else the same	Low	When a few people use it in the office and nobody needs it from outside
Rewrite everything at once	A new web application, the old one switched off on cut-over day	High	Rarely: when the old application is small and simple
Step by step	New technology screen by screen, alongside the old application	Low	Almost always when the application is large and important

A full rewrite sounds clean, but in practice it means a year or two in which the new application is being built and the old one stands still. When the new one finally arrives, half of it works differently from what people are used to, and everything breaks at once.

The step-by-step route few people know about

Microsoft has a component called BlazorWebView. It embeds Blazor screens directly into an existing WinForms or WPF application.

That means new screens are written in Blazor but shown inside the old application. Users don’t notice any migration, only that one screen is new. Once all screens have moved, the same Blazor components go into a web application, without being rewritten.

This is a new Blazor screen inside an existing WinForms application:

var services = new ServiceCollection();
services.AddWindowsFormsBlazorWebView();

var ordersView = new BlazorWebView
{
    Dock = DockStyle.Fill,
    HostPage = @"wwwroot\index.html",
    Services = services.BuildServiceProvider(),
};
ordersView.RootComponents.Add<OrderList>("#app");

ordersTab.Controls.Add(ordersView);

And later, the same component in the web application:

@page "/orders"

<OrderList />

For WPF it works the same way, with AddWpfBlazorWebView. The components live in a shared library used by both the desktop and the web application.

What it looks like step by step

1. LogicBusiness rules behind an API
2. New screensBlazor inside the old application
3. WebThe same components in the browser
4. DoneDesktop retired when nobody needs it

1. Business logic behind an API. Rules and database access are pulled out of the screens into a shared part behind an API. Along the way, the database password disappears from users’ PCs, because only the API now talks to the database.
2. New screens in Blazor. Every new or reworked screen is written in Blazor and shown inside the old application.
3. Web version. Once enough screens have moved, they open in the browser, on a PC at home, a tablet in the warehouse or a phone in the field.
4. Retiring the desktop. The old application goes only when nobody needs it any more, not on some risky cut-over date.

At every point you have an application that works. There is no year of just waiting.

If the application is still on .NET Framework, the first step is usually migrating to .NET 10, because BlazorWebView runs on current .NET.

What you can check this week

Open the desktop application’s configuration file on one PC and look for the connection string. If it contains a database username and password, that password is on every PC in the company.

Then count: how many people would need the application outside the office, on a tablet or in the field, and can’t use it today?

How we work

This is exactly what we do: we move old .NET applications to the web with Blazor step by step, screen by screen, without downtime and without a year of waiting. We start by reviewing the application and deciding which screen goes first, and you usually see the first new Blazor screen inside your existing application within a few weeks. The first step is a free 30-minute call.