How Do You Inventory a Legacy Silverlight App Before Migrating?
Why inventory first
The most expensive mistake in legacy migrations is estimating from memory. Silverlight apps are often a decade or more old, their original developers are gone, and what the organization believes the app does has drifted from what the code shows. An inventory pass — a week or two of focused work, usually — turns "probably a few months?" into a defensible plan. It is also step one of managing the app as an end-of-life asset in the sense that NIST's patch-management guidance uses: you cannot isolate, restrict, or retire what you have not located.
What to catalog
Screens and workflows. Walk the running app and list every view, dialog, and report, noting which are actively used. Usage matters enormously: teams routinely discover that a third of the screens serve workflows nobody has run in years, and every screen you can drop is a screen you don't port.
Custom and third-party controls. List every third-party Silverlight control suite and every in-house custom control. These are the strongest predictor of migration effort, because none of them carry over directly — each needs a modern equivalent, an HTML/CSS re-creation, or a decision to simplify the UI.
The service layer. Identify how the client talks to the backend: WCF RIA Services, SOAP, custom endpoints. Silverlight-specific service technologies have no modern client, so this seam almost always gets rebuilt as a web API regardless of the destination framework. Microsoft's Web Forms-to-Blazor migration guide illustrates the general pattern: carry the business logic, replace the plumbing.
Silverlight-specific features. Flag anything using the HTML bridge, elevated trust, isolated storage, printing APIs, or media playback — especially smooth streaming or DRM. Each has a different answer in each destination framework, and media/DRM in particular can dominate a project.
Deployment footprint. Record where the app runs: which machines, which browsers, which policy exceptions keep it alive. This doubles as the containment map discussed in risks of keeping Silverlight deployed.
Business logic worth saving. Finally, mark the code that encodes real business rules — calculations, validations, domain models. This is the portable core, and knowing its size tells you how much of the app is rewrite versus carry-over.
Turning the inventory into a decision
With the catalog in hand, the framework question usually answers itself. Windows-only internal users and heavy XAML investment point toward WPF; browser reach and mixed devices point toward Blazor, whose hosting options are laid out in the official Blazor documentation. The complexity scorer on the home page is a quick way to sanity-check your read of the inventory against the factors that typically drive effort.
One habit that pays off
As you inventory, record behavior, not just structure — capture what each screen does, its edge cases, and its quirks, from the running app. When the original documentation is gone, the running application is the specification, and it only stays observable while the legacy environment still works. Teams that document behavior during inventory avoid the worst late-project surprise: discovering, after the old environment is gone, that nobody knows what "correct" looked like.