WPF has been the backbone of enterprise .NET software for over fifteen years — and for good reason. But the way businesses work has changed. Teams are remote, staff expect tools in the browser, and 'install this and connect to the office VPN' is a hard sell. This guide walks through how I migrate a WPF desktop app to Blazor Server without throwing away the years of logic you've already paid for.
Why Move from WPF to Blazor at All?
WPF's three biggest limitations are structural: it requires installation on every machine, manual updates whenever you ship a fix, and local network access to reach line-of-business data. Blazor Server removes all three — it runs in any browser, updates the moment you deploy, and is reachable from anywhere with a login. You keep the rich, stateful, component-based UI model that made WPF productive; you lose the deployment headaches.
What You Keep, and What You Rewrite
The good news first: the expensive part of your app — the business logic — largely comes with you. Your C# services, EF Core data access, LINQ queries, validation rules, and domain models move across with little or no change. What changes is the presentation layer: XAML becomes Razor markup, and code-behind event handlers become component methods and lifecycle hooks.
Phase 1 — Extract the Business Logic
Start by separating logic from UI. Anything in a `.xaml.cs` file that touches the database, calls an API, or runs a calculation should be pulled into plain C# service classes. These become injectable Blazor services with zero logic changes — and as a bonus, they're now unit-testable in isolation.
// Before: WPF code-behind
private void LoadData()
{
var items = _db.Products.Where(p => p.Active).ToList();
ProductGrid.ItemsSource = items;
}
// After: Blazor service (identical logic)
public class ProductService
{
public List<Product> GetActiveProducts() =>
_db.Products.Where(p => p.Active).ToList();
}Phase 2 — Map XAML Controls to Razor
Most WPF controls have a direct Blazor equivalent, especially if you use Syncfusion or Telerik — both ship WPF and Blazor component suites with near-identical APIs, so a DataGrid becomes an SfGrid and a chart stays a chart. The mental shift is from imperative (`grid.ItemsSource = data`) to declarative data binding.
<!-- WPF: XAML markup + code-behind wiring -->
<DataGrid ItemsSource="{Binding Products}" />
// grid.ItemsSource = _service.GetActiveProducts();
@* Blazor: declarative binding, data supplied in code *@
<SfGrid DataSource="@products" />
@code {
private List<Product> products = default!;
protected override void OnInitialized() =>
products = ProductService.GetActiveProducts();
}Phase 3 — Rethink Threading and State
This is the phase teams underestimate. In WPF you marshal work back to the UI with `Dispatcher.Invoke`; in Blazor Server you call `InvokeAsync(StateHasChanged)` to re-render after a background update. State that lived in a window now lives in a scoped or singleton service, and you have to be deliberate about what is per-user versus shared. It's not hard — but it's different, and it's where a developer who knows only one stack gets into trouble.
// WPF — marshal back to the UI thread
Dispatcher.Invoke(() => StatusText.Text = "Done");
// Blazor Server — request a re-render on the UI context
await InvokeAsync(() =>
{
_status = "Done";
StateHasChanged();
});Phase 4 — Real-Time Comes (Almost) Free
If your WPF app pushed live data — order status, dashboards, stock tickers — this gets easier, not harder. Blazor Server already runs over a SignalR connection, so pushing UI updates when server state changes is built in. What took a custom notification layer in WPF is often just a service event and a `StateHasChanged` in Blazor.
Migrate Screen by Screen — Don't Big-Bang It
The riskiest way to migrate is to freeze the old app, rebuild everything in parallel for months, and attempt one nerve-wracking cutover. I don't work that way. I extract the shared logic, rebuild screens in Blazor a few at a time, and run both apps side by side so the business keeps moving. Users get migrated features as they're ready, and there's always a working product in production.
Blazor Server or WebAssembly?
For a WPF migration, Blazor Server is almost always the right first target. Its stateful, server-side model is the closest thing to how WPF already works, so the migration is the most direct and your logic stays on a trusted server near your data. Blazor WebAssembly makes sense later if you need offline support or want to offload compute to the client — but starting there turns a migration into a bigger re-architecture.
Common Pitfalls
Four things trip up first-time WPF-to-Blazor migrations: modal dialogs (WPF's blocking `ShowDialog()` has no direct equivalent — you model dialogs as component state), direct file-system access (a browser can't reach the user's C: drive — file work moves server-side or through uploads), long-running operations that assumed a persistent desktop process, and per-user state that was implicit on the desktop but must be explicit in a shared server app. None are blockers — all are decisions to make on purpose, not discover in production.
Realistic Timeline and Cost
A mid-size WPF app — 10 to 15 screens across a few modules — typically takes 6 to 10 weeks to migrate with a developer who genuinely knows both stacks. Simpler tools go faster; apps heavy on custom controls, complex dialogs, or real-time desktop features take longer. For a full breakdown by phase, the free Project Cost Estimator will give you a tailored range in under a minute.
The best migrations aren't rewrites — they're careful extractions. Keep the logic that already works, modernise the layer that doesn't, and ship it screen by screen.— Kathan N. Patel
If you have a WPF app you're planning to bring to the browser, I'd be glad to talk it through. See how I work, send me the details, or get an instant migration cost estimate to start with a number.
