Blazor Server vs. Blazor WebAssembly: Which Fits a Former Silverlight App?

Once a team decides Blazor is the destination for a Silverlight app — the case for that is laid out in our Blazor-as-replacement guide — a second decision immediately follows: which hosting model? Blazor's official hosting models documentation describes the options; this page frames them specifically for people coming from Silverlight.

The core difference

Both models let you write UI in C# and Razor components. The difference is where your component code executes.

Blazor Server runs your components on the web server. The browser gets a lightweight page that maintains a real-time connection; UI events go up, rendered updates come back down.
Blazor WebAssembly compiles your .NET code to run inside the browser itself, on the WebAssembly runtime built into every modern browser — no plugin, no install.

Which one feels like Silverlight?

Architecturally, Blazor WebAssembly is the closer cousin. Silverlight ran your C# in the client, kept UI state in the client, and called services over the network. Blazor WebAssembly has the same shape: client-side execution, offline-tolerant once loaded, server contacted only when the app chooses to. If your Silverlight app did significant client-side work — local validation, rich interactivity, in-memory data manipulation — WebAssembly preserves that design. The difference from Silverlight is the crucial one: it runs on a web standard rather than a proprietary plugin, which is why it did not die the way plugins did.

Blazor Server, by contrast, feels like Silverlight to the user but not to the architect. The interactivity is there, but every interaction round-trips to the server, and the app stops working if the connection drops.

Practical trade-offs for a migration

Startup and payload. Blazor Server pages appear quickly because almost nothing downloads. Blazor WebAssembly ships the .NET runtime and your assemblies to the browser, so first load is heavier — usually fine on office networks, more noticeable on weak connections.
Server load and scale. Blazor Server holds per-user state and a live connection on the server for every active user. WebAssembly pushes that work to each client machine.
Latency sensitivity. With Blazor Server, a laggy network makes every click feel laggy. WebAssembly keeps interaction local.
Where secrets live. Blazor Server code never leaves your server. WebAssembly code is downloaded to the client — like Silverlight was — so anything sensitive belongs behind an API, a discipline Silverlight teams already know.
Old-machine tolerance. Blazor Server asks very little of the client device, which can matter for aging enterprise desktops.

A reasonable default

For internal line-of-business apps on reliable networks — the classic Silverlight habitat — either model works, and Blazor Server is often the faster first step. For apps whose value was rich client-side behavior, or that face users on varied networks, Blazor WebAssembly preserves more of the original architecture. Microsoft's migration guidance for legacy .NET UI apps also makes a point worth internalizing: your Razor components are largely the same code either way, so this choice, while important, is not a one-way door. Before choosing, it is worth inventorying the existing app to see how much logic actually lives client-side today.

Blazor Server vs. Blazor WebAssembly: Which Fits a Former Silverlight App?