Silverlight Legacy Maintenance

Analogy categoryAnalogies

Maintaining Legacy Silverlight Applications

Microsoft ended mainstream support for Silverlight years ago, and every major browser removed NPAPI/ActiveX plug-in support entirely, meaning a genuine Silverlight .xap can no longer run in a standard modern browser at all. Organizations still running Silverlight line-of-business apps today are almost always doing so through a locked-down legacy browser (often IE11 in Enterprise Mode, or a sandboxed old Firefox ESR build) or by having already migrated the front end while keeping the backend WCF services intact. Maintenance work in this environment is less about adding features and more about triage: keeping a fragile, frozen stack alive without breaking anything.

🏏

Cricket analogy: Keeping a retired stadium's original hand-operated scoreboard running today means relying on an outdated part supply chain rather than upgrading it to digital, similar to running Silverlight only inside a locked-down legacy browser rather than a modern one.

Browser and Runtime Compatibility Constraints

Because the Silverlight plug-in relied on NPAPI (in Firefox/Chrome) and ActiveX (in Internet Explorer), and both mechanisms were removed from mainstream browsers, the only realistic way to run a real Silverlight .xap today is Internet Explorer 11 in Enterprise Mode on a Windows machine where the Silverlight runtime is still installed via group policy, since Microsoft continued supporting Silverlight in IE11 under extended enterprise agreements longer than in other browsers. Any maintenance plan must therefore start by confirming exactly which browser and OS combination the target users are actually on, since a fix that assumes a normal modern browser is meaningless in this context.

🏏

Cricket analogy: A player who can only bowl on turf pitches struggles the moment the tour moves to synthetic surfaces, similar to Silverlight code being meaningless outside the one specific browser environment (IE11 Enterprise Mode) that still runs it.

Managing Risk in a Frozen Codebase

Since NuGet packages, third-party Silverlight controls, and even Visual Studio's Silverlight tooling are no longer actively maintained, the safest legacy maintenance strategy is minimal-diff patching: change only the specific lines needed to fix a reported bug, avoid upgrading dependencies (a newer version of a third-party control library is unlikely to exist and unofficial forks carry real risk), and keep a pinned, working build environment (often an older Visual Studio version with the Silverlight SDK) preserved in a VM or container image so the team can still compile the project at all. Any refactor that isn't strictly required to fix the reported bug should be treated as unnecessary risk, not an opportunity for cleanup.

🏏

Cricket analogy: A groundskeeper maintaining a century-old pitch makes only the minimal repairs needed rather than relaying the whole square, similar to minimal-diff patching in a frozen Silverlight codebase.

xml

<!-- Example: pinning a known-working legacy toolchain in a build script comment/README -->
<!--
  Required environment for this Silverlight 5 solution:
  - Visual Studio 2015 (last version with Silverlight project support)
  - Silverlight 5 SDK and Silverlight 5 Tools for Visual Studio
  - .NET Framework 4.5 targeting pack
  Do NOT open this solution in a newer Visual Studio without first
  verifying Silverlight project support is still available.
-->

Document the exact working toolchain (OS version, Visual Studio version, Silverlight SDK version, browser and enterprise policy settings) in the repository README. When the one team member who remembers how to build the project moves on, this documentation is often the only thing standing between a working legacy app and a project nobody can compile anymore.

Planning an Eventual Migration Path

Because Silverlight has no future beyond its currently frozen state, the responsible long-term maintenance strategy includes an explicit migration plan even while day-to-day work stays minimal-diff. The most common and lowest-risk path is to leave the existing WCF or REST backend services largely untouched — since they are typically plain ASP.NET/WCF and have no dependency on the Silverlight plug-in — and rebuild only the front end as a modern web SPA (React, Angular, or Blazor WebAssembly) that consumes those same services, migrating screen by screen rather than attempting a risky big-bang rewrite.

🏏

Cricket analogy: A team rebuilding for a new era keeps its proven bowling attack intact while gradually rebuilding the batting order one player at a time, similar to keeping the WCF backend intact while migrating the Silverlight front end screen by screen.

Do not attempt a big-bang rewrite of both the front end and backend simultaneously for a legacy Silverlight system — that combines platform migration risk with business logic re-implementation risk. Migrate the front end first against the existing, already-battle-tested backend services, and only modernize the backend afterward as a separate, independently scoped project.

Modern browsers removed NPAPI/ActiveX entirely, so a real Silverlight .xap only runs today in IE11 Enterprise Mode with the plug-in installed via policy.
Confirm the exact supported browser/OS/policy combination before attempting any fix — assumptions about a normal modern browser are invalid.
Third-party Silverlight controls and tooling are no longer maintained, so avoid dependency upgrades wherever possible.
Use minimal-diff patching: fix only the reported bug, and treat unrelated refactors as unnecessary risk.
Pin and document the exact working toolchain (VS version, SDK version, OS) in the repository so the project remains buildable.
Plan an eventual migration even while day-to-day maintenance stays minimal, since Silverlight has no future beyond its frozen state.
Migrate the front end to a modern SPA against existing WCF/REST backends first, screen by screen, rather than a risky big-bang rewrite.