Classic ASP

The Reality

Classic ASP (Active Server Pages using VBScript) has not received a framework update since 2002. Microsoft moved to ASP.NET and never looked back. Yet Classic ASP applications persist across thousands of businesses, running intranets, order management systems, customer portals, reporting dashboards, and internal tools. They run on IIS, they work, and in many cases they have been doing their job without incident for over two decades.

The technology itself is limited by modern standards. There is no built-in protection against SQL injection or cross-site scripting. There is no MVC separation, no ORM, no dependency management, no templating engine beyond inline code mixed with HTML. Session management is basic. Error handling is rudimentary. But the applications built with it were often well-suited to their purpose, and the people who use them daily are productive with them. Classic ASP was adequate for its time. Today it is a security liability running on a stack that gets harder to maintain with every passing year.

The Risks of Doing Nothing

• Active security vulnerabilities. Classic ASP applications almost universally lack protection against modern attack vectors. SQL injection, XSS, and session hijacking are common weaknesses. No amount of IIS hardening fully compensates for application-level gaps.
• IIS and Windows Server dependency. Classic ASP only runs on IIS. As Microsoft pushes toward cloud-native infrastructure, the on-premise Windows Server environments these applications require become increasingly expensive and difficult to justify.
• No ecosystem. There are no libraries, no packages, no community. When something breaks, there is no Stack Overflow thread from last week to help. The knowledge base is frozen in time.
• Developer availability. Finding someone willing and able to work on Classic ASP in 2026 is genuinely difficult. Those who can command a premium because the supply is so thin.

How We Approach This

We begin with a security assessment. Before any migration planning, we need to understand the current exposure. Classic ASP applications often have vulnerabilities that should be mitigated immediately, even if the full migration is months away. Basic input sanitisation, parameterised queries, and IIS hardening can reduce the attack surface significantly while buying time.

For the migration itself, we map every page, every form, every database query, and every integration point. Classic ASP applications tend to be relatively straightforward in structure. The complexity is in the volume of pages and the business logic embedded in them, not in architectural abstraction. This makes them well-suited to a systematic, page-by-page migration to a modern framework. We typically stand up the new application alongside the old one and use URL rewriting to route traffic progressively: new pages go to the new system, unmigrated pages continue to be served by Classic ASP. Users experience a gradual transition, not a sudden switch.

Where the Classic ASP application talks to a database, we keep the same database during migration. The new application reads and writes to the same tables, ensuring data continuity. Schema changes come later, after the application migration is complete.

What You End Up With

• A modern, secure web application delivering the same functionality
• Elimination of known security vulnerabilities
• Independence from IIS and legacy Windows Server infrastructure
• A codebase that current developers can maintain and extend
• Progressive migration with no big-bang switchover

What We Have Seen

We migrated a Classic ASP customer portal for a distribution company that had been running since 2004. The application had over 200 pages, a SQL Server backend, and was the primary way customers placed orders. We ran both systems in parallel for three months, migrating page groups in fortnightly releases. The security audit we conducted at the start identified four critical SQL injection vulnerabilities that we patched in the existing ASP code within the first week, before any migration work began. The full migration completed without a single hour of downtime.

How Much Time Have You Actually Got?

Classic ASP is the one legacy platform with a genuine, externally-imposed clock on it, and most owners do not know it exists.

The clock: VBScript is being removed from Windows. Microsoft has declared VBScript deprecated and set out a phased retirement, first as a feature-on-demand and eventually removed altogether. Almost every Classic ASP application in existence is written in VBScript. When the runtime finally goes from the server operating system you are running, the application stops. Not degrades. Stops.

That makes the question simple: what Windows Server version is it on, and what is that version’s support end-date? Everything else in this section is secondary to that answer.

You have years, not months, if: it runs on a Windows Server release with years of support left, has few external integrations, and a developer who can still work on it.

You are inside two years if: the server is one release from end-of-support, or your hosting provider has started talking about platform upgrades.

You have a hard deadline if: a Windows Server end-of-support date is inside your planning horizon, or your host has issued a migration notice. Classic ASP does not survive a modern server rebuild by accident.

What Breaks First

1. A server move. Classic ASP applications carry undocumented dependencies: registered COM components, ODBC DSNs, filesystem paths, ActiveX. They routinely fail to start on a rebuilt server, and the person who configured the original is usually long gone.
2. TLS and browser changes, which break outbound calls to payment gateways and partner APIs.
3. Database drivers. Old ADO connection strings to a SQL Server that has since moved on.
4. The VBScript runtime, eventually. That is the hard stop.
5. The code itself rarely breaks at all. It just becomes unmovable.

Check These Six Things This Week

• Which Windows Server version is it on, and what is that version’s published end-of-support date? This is the single most important fact about your application.
• Could you rebuild this server from scratch if it died tonight? If the honest answer is no, you do not have a legacy problem, you have a business-continuity one.
• List every COM/ActiveX component it registers. Anything not from Microsoft is a migration risk with no owner.
• What does it connect out to: payment providers, partner APIs, mail servers? Those endpoints will change on somebody else’s schedule.
• Is it on the public internet? Classic ASP applications are frequently unpatched and unmonitored.
• Does a test copy exist anywhere? If every change goes straight to live, that is the constraint to fix first, ahead of any rewrite.

When You Genuinely Don’t Need To Act

If it is internal-only, on a server with years of support remaining, doing a narrow job well, and you can rebuild it, then it can wait, and the money is better spent elsewhere. Classic ASP being old is not the argument. The VBScript retirement and your server’s support date are.

Get those two dates written down. Then decide.

Facing the Classic ASP Question

If you are still running Classic ASP, you already know the situation is not sustainable. The question is how to move forward without disrupting the business that depends on it. A planned, incremental migration is the safest path, and the sooner it starts, the more options you have. Let us help you plan it.

For context on how we approach legacy system replacement more broadly, Legacy Modernisation sets out the method we use across different platforms. If your Classic ASP application talks to external services you want to preserve, Connecting Old Systems to Modern APIs covers the integration layer work that often runs alongside migration. And if you have Old PHP Systems in the mix too, the considerations are similar enough that it is worth reading both together. The Legacy Systems Overview covers the full range of approaches we use when older software needs attention.