What Drives the Cost of a Silverlight-to-Blazor Migration?

Why there is no standard price

Asking what a Silverlight-to-Blazor migration costs is like asking what a house renovation costs: the answer depends almost entirely on what is behind the walls. Two Silverlight apps with the same number of screens can differ enormously in effort, because cost is driven by what the screens do, not how many there are. What you can do is understand the drivers, so an estimate — yours or a vendor's — can be sanity-checked line by line.

A structured inventory of the Silverlight app is the prerequisite for any credible estimate. Everything below is a question that inventory should answer.

The big cost drivers

• Screen count and complexity. Simple forms-over-data screens translate to Blazor components fairly mechanically. Screens with drag-and-drop, complex validation flows, or deeply nested layouts each become small design projects.
• Custom and third-party controls. This is often the largest single driver. Every third-party Silverlight control (grids, charts, schedulers) needs a modern equivalent found, licensed, and relearned — or rebuilt by hand. Hand-built custom controls must be rewritten as Blazor components.
• Backend coupling. Silverlight apps commonly talked to services through patterns that have no direct modern counterpart. If the app used tightly coupled data services, the service layer may need rework alongside the client — effectively two migrations priced as one.
• Business logic location. Logic living in plain C# classes with few Silverlight dependencies can often move across with modest changes; .NET code reuse is one of Blazor's genuine advantages, as Microsoft's own Web Forms-to-Blazor migration guidance illustrates for a comparable legacy stack. Logic tangled into code-behind files and UI event handlers must be untangled first, and untangling is slow.
• XAML volume. Blazor uses Razor markup, not XAML, so every view is rewritten even when its logic survives. Data-binding concepts carry over; the syntax does not. (Where XAML itself is the team's core asset, WPF may deserve a look instead.)
• Media and graphics. Video features, custom drawing, and animation-heavy UI were Silverlight strengths with no one-to-one Blazor equivalent, and typically need per-feature redesign.
• Testing and parallel running. If the app matters enough to migrate, it matters enough to verify. Budget for test writing, a period of running old and new side by side, and user retraining.

Cost levers you control

A few decisions move the total meaningfully:

• Hosting model. Blazor Server versus Blazor WebAssembly changes the architecture work; Microsoft's hosting models documentation lays out the trade-offs. Choosing early avoids paying for the decision twice.
• Scope discipline. Migrations quietly become redesigns. Rebuilding the app as-is, then improving it in a second phase, is usually cheaper than doing both at once — and far easier to estimate.
• Dropping dead weight. Inventory data often reveals screens nobody has opened in years. Every screen you decline to migrate is the cheapest screen in the project.
• Team familiarity. A team that already knows C# and .NET starts well ahead, since Blazor keeps them in that ecosystem — one reason it's the natural first candidate, as discussed in whether Blazor is the Silverlight replacement.

Reading an estimate skeptically

When a quote arrives, check that it itemizes the drivers above rather than pricing by screen count alone. Ask specifically how third-party controls and the service layer were assessed — those are where surprises hide. And plan for the tail of the project — edge cases, printing quirks, the rarely used admin screens — to take longer than the first working screens might suggest; budgeting some contingency for that tail is prudent in any rewrite. An estimate that assumes the last screens go as fast as the first ones is the estimate to question.