Classic ASP support and migration

A 1990s web technology still in service

Classic ASP was Microsoft’s first server-side web technology, released in 1996. A page is a file ending in .asp that mixes HTML with script, almost always VBScript, and talks to a database through ADO. ASP.NET replaced it in 2002 and it has had no development since 2000, yet IIS still runs it as an optional Windows component.

It turns up in ordering systems, intranets, booking sites and back-office tools written around the turn of the century and patched ever since. Often the site has outlived both the people and the company that wrote it.

Where the risk lies

• SQL built from strings. Many pages assemble SQL statements by joining text with values taken straight from the query string or a form. That is the textbook route to SQL injection, and Classic ASP has no built-in protection against it.
• COM components nobody can rebuild. Sites often call compiled components for email, file uploads, PDF generation or business rules. They are usually 32-bit, have to be registered by hand on any new server, and their source code may be lost.
• Errors are swallowed. On Error Resume Next tells a page to carry on after a failure, so faults surface later as wrong data instead of an error message.
• Old servers. Sites this old tend to sit on servers of a similar age. Windows Server 2012 and 2012 R2 left support in October 2023, and Windows Server 2016 follows in January 2027.
• The code exists only on the server. There is often no source control, and years of changes made directly on the live site leave behind copies of pages that nobody dares delete.
• VBScript is on the way out. Microsoft has announced that VBScript is deprecated and will be removed from a future version of Windows.
• Hard to hire for. Few developers know VBScript, and fewer want to work in it.

Your options

Keep it and harden it. If the site does its job and changes rarely, this is often enough for now. Injection points are closed by switching to parameterised commands, stored passwords are protected, the site moves to a supported Windows Server, and the code goes into source control.

Migrate to ASP.NET Core in stages. The choice for a site with years of life ahead. Sections are rebuilt one at a time and take over their existing addresses, while the remaining ASP pages carry on serving the rest. The database usually stays as it is.

Replace it. If the site is a shop, a brochure site or a booking form with nothing unusual about it, a current off-the-shelf platform may do the job for less than a rebuild.

How we work on a Classic ASP site

We start by taking a copy of the site, its database and its components and getting it running on a test server. That alone tends to reveal dependencies nobody had written down: a mapped drive, a scheduled script, a component registered years ago. From there we review every page that touches the database and fix the injection risks first, beginning with pages that can be reached without a login.

When migration follows, ASP.NET Core and Classic ASP run side by side on the same IIS server. The two do not share session state, so the main technical task is carrying a signed-in user from one to the other. The old pages serve as the specification for the new ones, which matters when there is no documentation.

If you have inherited a site like this with no one to look after it, see software takeover. For the server it runs on, see the Windows Server end-of-support dates. If you are unsure which option fits, the maintain, modernise or replace tool is a quick way to think it through.