Establish what the business relies on
List users, critical processes, peak periods, data stores, integrations, scheduled tasks and reports. Include the informal knowledge held by staff and the original developer. Record how the application is deployed, backed up and recovered. A small-looking interface may contain years of business rules that are not written down anywhere else.
Separate observed incidents from assumptions about age. A measured performance bottleneck needs a different response from an unsupported component or a missing development owner.
Compare three routes
| Route | Useful when | Main obligation |
|---|---|---|
| Maintain | The system serves the business and its risks can be managed | Support, backups, access and controlled changes |
| Modernise in stages | Parts need replacement while continuity matters | Clear boundaries and coexistence testing |
| Rebuild or replace | The current design cannot reasonably meet the agreed need | Requirements, data migration and transition planning |
Check current vendor support for the exact framework, operating system and dependencies. Do not assume that every application sharing a technology label has the same support position.
Recover control before changing architecture
Confirm source-code access, accounts, licences, build instructions and a tested recovery process. Record how to release a change safely. If the only deployment process is somebody’s memory, first make it repeatable. Build useful acceptance checks around important workflows and exceptions. This preparation helps whether the eventual decision is to retain the system or replace it.
For Classic ASP and Web Forms, investigate database access, COM dependencies where present, authentication, session behaviour and third-party integrations individually.
Find a sensible boundary for staged work
A staged approach might replace a reporting module, an external integration or one user journey while the rest continues operating. The boundary must be technically and commercially useful. Decide how users authenticate, how records remain consistent and how failures are handled while old and new components coexist. Microsoft documents incremental migration approaches for ASP.NET Framework applications; suitability still depends on the particular application.
Do not describe staged modernisation as risk-free. Coexistence introduces work of its own.
Make a rebuild prove its case
A replacement proposal should identify the outcomes the current system cannot meet, the information to migrate and the rules to preserve or intentionally change. Assess parallel running, staff training, reconciliation and rollback. A new screen design does not establish functional equivalence. Test representative records and difficult cases rather than accepting that imported row counts prove a successful migration.
Include the support model after launch. Otherwise the new application can quickly become another undocumented dependency.
Decide using an evidence record
Compare the routes against continuity, current risk, change capability, costs and the organisation’s ability to maintain the result. State uncertainty explicitly: inaccessible source or undocumented integrations may require discovery before a firm plan. We prefer a defensible next step to an impressive replacement roadmap that cannot be delivered. Review the decision when the business requirement or support position changes, rather than treating it as permanent.
Common questions
Must we rewrite a working Classic ASP application?
Not automatically. Inspect its dependencies, support environment, code, business requirements and operational risks before choosing a route.
Can old and new applications run together?
Sometimes. Shared authentication, state, data and deployment need explicit design and testing; coexistence is not simply switching one page at a time.