Classic ASP in the modern era: keep it running while you plan an exit
A manufacturer came to us with an order desk written in Classic ASP in 2002. Twenty-two years of business rules, three original developers all long retired, and a SQL Server that had never been patched on a schedule. The system was too critical to rewrite quickly and too old to ignore. That is the Classic ASP story, over and over.
Here is how we think about these systems.
First: stop the bleeding
The urgent work on old ASP is almost always the same list:
- SQL injection. Classic ASP code from that era builds queries by string concatenation. We audit every query, fix the injection points, and move the risky ones to parameterized ADODB commands.
- Patches. The server is usually years behind on Windows updates because someone rebooted once and the app “broke”. We set up a maintenance window and a smoke test so patching stops being a hostage negotiation.
- Backups. Half the time the backup job has been failing silently for months. We verify restores, not just backups.
This phase usually takes one to two weeks and buys the business the thing it does not have: time.
Then: run it properly on modern servers
IIS on Windows Server 2022 still runs Classic ASP, but there are traps. Session state configuration, the 32-bit application pool setting, COM component registration, error page behavior. We have a checklist for these migrations because we have hit every item on it at least once.
The goal is not to modernize the ASP. The goal is to put it on infrastructure that is supported and monitored, so the risk stops accumulating.
The exit strategy
Nobody rewrites a 22-year-old ERP because they feel like it. The exit has to pay for itself. In the manufacturer’s case, we rebuilt their customer portal in Laravel, module by module, while the ASP system kept handling everything else. Quotes first, then orders, then invoicing. Each module cut over with parallel runs comparing outputs until the numbers matched.
They get to decide when the old system retires. A crash does not decide for them.
The honest version
Classic ASP can keep running for years if someone is actively looking after it. What kills these systems is neglect plus a deadline: a server that dies, a compliance audit, a developer who retires. If you run one of these, the cheapest time to plan the exit is before any of that happens.
If you want us to look at your ASP system, tell us what it does and we will give you a read on the risk first, before anyone talks about rewriting anything.
Dealing with something similar?
Describe your situation and we will give you an honest read within 24 hours, including whether you need us at all.
Get in touch