Silverlight Migration & Modernization

A Silverlight application is rarely just a UI. It’s a rich client built on XAML and C#, a set of services it calls behind the scenes, and a body of business logic that the company has run on for a decade — much of it written for a browser plugin that no longer exists anywhere. That’s why “rebuild the Silverlight app” is never as simple as it sounds, and why staying on Silverlight isn’t a stable choice at all: the platform it ran in has already been taken away.

Why Silverlight is already out of runway

Unlike a product with a future retirement date, Silverlight’s status is settled, and on more than one front:

Milestone	Date	Status
Chrome drops NPAPI plugin support	2015	Silverlight stops running in Chrome
Firefox drops NPAPI plugin support	2017	Silverlight stops running in Firefox
Silverlight end of support	October 12, 2021	End of life — no updates, ever
Internet Explorer 11 retired	June 15, 2022	The last browser that ran Silverlight, gone

Dates are Microsoft’s Lifecycle figures and the browsers’ own plugin-removal milestones. The picture is harsher than an ordinary end-of-life: Silverlight didn’t just stop receiving updates on October 12, 2021 — the browser plugin model it was built on had already been removed from every modern browser years earlier, and the one browser that could still run it, Internet Explorer 11, was itself retired in June 2022. The line that matters is not “this will become unsupported” but this already has no place to run. A Silverlight app isn’t “old but fine” — it’s a client for a runtime the entire web has removed.

What end of life actually means for a Silverlight app

Silverlight’s situation raises the stakes over an ordinary unsupported component, for three reasons.

• The runtime is gone, not just unsupported. Most legacy software keeps running while you plan a move. Silverlight largely doesn’t — modern browsers refuse to load it — so organizations are often already pinned to a frozen browser or VM just to keep the app open. That’s a holding action with no exit of its own.
• It collides with compliance. Keeping a Silverlight app alive usually means keeping a retired, unpatched browser alive alongside it. PCI DSS, SOC 2, and HIPAA all expect systems in scope to be patchable, and an end-of-life browser propping up an end-of-life plugin is a finding waiting to be written.
• It blocks the business. A Silverlight client can’t move to mobile, can’t be embedded in a modern portal, and can’t adopt current identity or security standards. It’s not just risky — it’s a ceiling on where the application can go.

The migration options

There is no single right move; there’s a right move for your application, and it turns on how much of it is presentation versus genuine business logic.

• Rebuild the UI on modern web standards — HTML5 with a current SPA framework — when the value is mostly in the screens and the data behind them. The most direct route back to a browser that actually runs the app.
• Move to Blazor when the team wants to stay close to .NET and reuse C# logic from the Silverlight client. A natural target for a .NET-centric shop, keeping much of the language and mental model while leaving the dead plugin behind.
• Re-express incrementally behind a facade rather than rebuilding everything at once. The same destination, reached screen by screen, so users keep working and the undocumented behavior is captured as you go.

The decision is rarely about the framework — Silverlight has to go either way, because it has nowhere to run. It’s about separating the durable business logic from the dead presentation layer: the rules and workflows are worth carrying forward; the XAML-for-a-plugin is not. That separation is what makes a Silverlight migration a modernization project rather than a straight port.

Modernizing off it, slice by slice

We treat the application the same way we treat any legacy system: not a single risky rewrite, but a sequence of small, reversible steps.

A strangler facade lets the legacy Silverlight application and the modern web path run side by side during the move. We break the rebuild into slices — a screen, a workflow, a calculation — and before any slice carries live work, we prove it behaves identically to the legacy: same results, same outputs, reconciled against the original. AI-accelerated discovery reads the XAML, the C# code-behind, and the service calls end to end and captures what the application actually does — including the undocumented logic the original authors never wrote down — under senior-engineer review. Work shifts only on green, rollback stays a flag away, and the Silverlight application is retired only once nothing depends on it.

Real urgency, but not blind panic

We won’t manufacture urgency that isn’t there, but Silverlight is one of the cases where the urgency is genuinely structural: the runtime has already left the modern web, so “wait and see” usually means “keep a retired browser on life support.” Where an application is small, internal, and genuinely tolerable inside a contained legacy environment for a defined period, a planned migration on a sensible timeline is reasonable — panic isn’t required. And where a packaged product now does what the Silverlight app does, buying beats rebuilding, and we’ll point you there rather than quote a build. The slice-by-slice rebuild earns its place when the app holds real business logic, when the legacy-browser workaround is itself a compliance or security problem, or when the application is blocking what the business needs next. Matching the effort to the actual value is part of the assessment, not an afterthought.

Where to start

The first step is small and bounded: understand what the application is really worth before committing to a path. A discovery call scopes how much business logic lives in the Silverlight client, what’s propping it up today, where the compliance exposure sits, and whether the right target is HTML5, Blazor, or a packaged product — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.