"Let's just rewrite it" is a tempting response to an old ASP.NET application, and often the wrong first answer. A full rewrite carries real risk: the old application usually encodes years of business rules that nobody's written down elsewhere, and a rewrite has to rediscover all of them. Working through the following checklist before committing to an approach tends to produce a better decision.
1. Inventory what the application actually does
Before deciding how to modernize, write down what's actually in use. Legacy applications accumulate features nobody uses anymore alongside the ones the business depends on daily. Talk to the people who use it, not just the people who requested changes to it historically.
2. Identify the real risks, not just the old-looking parts
An application "looking old" (Web Forms, an older .NET Framework version, dated styling) isn't automatically a business risk. The risks worth prioritizing are usually:
- Running on a framework version or Windows Server version that's approaching or past end of support.
- Dependencies (NuGet packages, COM components, third-party libraries) that are unmaintained or insecure.
- No automated tests around business-critical logic, making any change risky to verify.
- Hard-coded credentials, missing input validation, or other concrete security gaps.
3. Assess the database layer separately from the application
Often the database (and the business rules encoded in its schema, triggers, and stored procedures) has more lasting value than the application code sitting on top of it. Understand what's really in the data layer before assuming the whole stack needs replacing together.
4. Decide: modernize in place, or rewrite
A full rewrite makes sense when the application's architecture actively prevents the changes the business needs, or when the technology is genuinely unsupportable going forward. Modernizing in place — upgrading the framework, replacing risky dependencies, extracting well-tested business logic behind a clean interface piece by piece — is usually faster, safer, and cheaper when the application's core logic is sound and just needs a more maintainable foundation.
5. If modernizing in place, plan the sequence
- Get a safety net in place first: even basic tests around critical business logic before changing anything else.
- Upgrade the framework and dependencies in isolated steps, verifying behavior after each one, rather than as one large jump.
- Extract business logic away from the UI layer incrementally, so it can eventually be reused or replaced without touching the parts that already work.
6. Plan for deployment and hosting, not just code
Modernizing the application without addressing where and how it's hosted (an aging on-premises server, for example) leaves half the risk in place. Decide early whether hosting changes (a cloud migration, for instance) are part of this project or a deliberately separate one.
TODO: Add any client-approved examples of legacy ASP.NET modernization work, and specific framework versions or migration paths (e.g. ASP.NET Framework to ASP.NET Core) you want to highlight as direct experience.