Understand the system that is actually running
Classic ASP applications often depend on more than their .asp files. Database connections, COM components, server permissions, scheduled tasks, mail services and hosting settings can all be part of the working system.
We begin by establishing the application, database and infrastructure dependencies, the code and access available, and the business journeys that must keep working. Its age alone does not tell us its condition.
Support before replacement
The immediate priority may be a failed form, slow report, broken integration or change requested by customers. We separate that urgent work from longer-term modernisation so you can make a sensible decision about each.
Areas for assessment can include parameterised database access, output handling, authentication, permissions, errors and backups. We investigate the implementation rather than asserting that every Classic ASP application has the same vulnerabilities.
Three routes to consider
| Route | When it may fit |
|---|---|
| Maintain | The application is useful and a defined support or stability problem can be addressed. |
| Extend | The existing business logic is valuable and a new integration or bounded feature can solve the requirement. |
| Modernise in stages | Dependencies, maintainability or new requirements make replacement worthwhile, but business continuity matters. |
A full rewrite is another option, but it needs a stronger justification than a preference for newer technology.
Plan coexistence and migration
A staged approach may retain some current screens while moving a defined function or integration. That requires explicit decisions about database ownership, authentication, transactions and error handling. Two applications sharing a database are not automatically a safe migration design.
We establish how users and data will move, how the change will be checked and what happens if the release fails. Microsoft documents Classic ASP configuration within IIS; hosting and component support must be checked for your particular environment.
What we need to assess the work
Useful starting information includes source files, database details, hosting access, known dependencies, example faults and the process the system supports. If documentation is missing, discovery becomes part of the scope rather than something silently assumed away.
We agree access and backups before changing a live system. The proposed work should leave an understandable release record and a practical handover, not another undocumented patch.
Common questions
Does Classic ASP automatically need replacing?
No. Assess the real application, infrastructure, dependencies and business requirements. Maintenance, targeted improvement and replacement are different decisions.
Can Classic ASP connect to modern services?
It may be possible directly or through an intermediate component. Authentication, protocols, data formats and hosting capabilities need checking for the particular integration.
Can you quote from screenshots?
Screenshots explain the visible requirement, but they do not reveal code condition or dependencies. A reliable quote may require access and a bounded assessment first.