Support status · Classic ASP
Is Classic ASP still supported?
Classic ASP is still supported. The language your pages are written in is not.
These are two different questions and only one of them has a comfortable answer. ASP still runs on every supported version of IIS, and Microsoft has not deprecated it. Microsoft has deprecated VBScript. That was announced in October 2023, in its own words: "In future releases of Windows, VBScript will be available as a feature on demand before its removal from the operating system." Almost every Classic ASP page in existence is VBScript. When the language goes, the pages stop executing, whatever IIS still supports.
- Classic ASP on IIS
- Supported
- VBScript
- Deprecated since October 2023
- Stated path
- Feature on demand, then removal
- Removal date
- Not yet published
Source: Microsoft: deprecated features in the Windows client. Check it. We would rather you did.
- Dates from Microsoft, linked
- No email needed to read them
- Leaving it alone is a real answer
What that actually means
The position most estates are in
You checked the wrong support status, and it said you were fine
Everyone checks the platform. The platform is supported. The dependency that actually ends you is a scripting engine that ships with the OS, has been deprecated, and has no published removal date, which makes it impossible to plan around and easy to keep ignoring.
There is no layer to lift out
A .asp file holds the markup, the business rule and the SQL that feeds it, in one flow, often for several hundred lines. There is no model to port and no service to wrap. Whatever the application knows, it knows in between a query and a table row.
Nobody can tell you which pages are still reachable
A decade of includes, three generations of naming convention, and a set of pages that are either the live checkout or dead since 2011. Guessing wrong in either direction is expensive, and the file dates do not tell you.
Exposure
What breaks, how likely, what it costs
Stated generically here because it is generic until someone looks at your estate. These are the scenarios that actually land, in the columns your risk register already has.
| Scenario | Likelihood | Impact |
|---|---|---|
| VBScript becomes a feature on demand and is off by default on a new server build | Announced, no date | The application will not run on a fresh install until someone knows to re-enable it |
| VBScript is removed from Windows entirely | Stated intent, beyond the FOD phase | The pages stop executing. No configuration change recovers them |
| A supplier questionnaire asks whether any software in scope is unsupported | Routine, and increasing | A deprecated scripting engine is difficult to answer well and impossible to answer briefly |
| The Windows Server the application runs on reaches end of support | On a published date | The OS decision forces the application decision, usually with no budget allocated |
| A change is needed and nobody on staff writes VBScript | Already true in most estates | A one-line change becomes a procurement exercise |
What we do about it
The work itself
What the pages actually do, written down
Every .asp file read at volume and turned into business rules a reader who has never seen VBScript can follow, including the ones that only exist as a conditional halfway down a page.
The include graph and the dead pages, mapped
What includes what, which entry points are reachable from a real request, and which files are provably unused. This is what makes an order of work possible instead of a guess.
Behaviour pinned before anything moves
Characterisation tests driven through HTTP against the running application, so the replacement is checked against what the site really does, including the bugs that turned out to be load-bearing.
Replaced page by page, both versions live
IIS keeps serving the pages that have not moved while the new stack serves the ones that have. Each page is independently revertible. There is no evening on which everything changes at once.
What decides the cost
The three things worth knowing before anyone quotes
- Data access
- Inline ADO with SQL in the page costs far more to move than calls into stored procedures. This is the single biggest driver, and it is knowable on day one.
- COM surface
- Registered components and third-party DLLs are where this class of project tends to overrun. Some get replaced, some get wrapped, some turn out to be dead.
- Reachable pages
- Not the file count. The number of pages a real request can actually arrive at, which in most estates is a fraction of what is on disk.
The engagement
How the work runs
You tell us what you have
Roughly how many pages, what the database is, and which screen would hurt most if it went wrong.
We read the code
The include graph, the data access, the COM dependencies, and the honest size of the reachable surface.
One page goes first
A real page, ported and in production behind the same URL, so throughput stops being a guess and the estimate stops being a promise.
The rest follows in that order
Measured against the first one, sequenced worst-risk-first, with the old pages still serving until each replacement is accepted.
Questions
Frequently asked
Is Classic ASP still supported?
Yes. Classic ASP is supported on all supported versions of IIS, Microsoft has not deprecated it, and it continues to work on current Windows Server releases. If you were told the platform is end of life, that was wrong. The problem is one level down: the language.
Is VBScript really being removed from Windows?
That is Microsoft's stated intent. VBScript was deprecated in October 2023, and Microsoft's deprecated-features list says it "will be available as a feature on demand before its removal from the operating system". The sequence is public; the removal date is not. Deprecated is not the same as gone, but it is a one-way announcement. Nothing has ever come back off that list.
So will my ASP pages stop working, or not?
Not today, and not on any date currently published. They stop working whenever the VBScript engine is no longer present and enabled on the machine serving them. The realistic first encounter is not a removal at all. It is someone building a new server and finding the application will not start until a feature is turned back on that used to be there by default.
Our ASP is written in JScript, not VBScript. Are we unaffected?
Largely, on this specific point, and that is genuinely unusual: a small minority of ASP is JScript. The other reasons to move are unchanged: the COM dependencies, the hiring problem, and an application whose business rules exist only inside its pages.
Should we move to ASP.NET Core, or to something else?
If the answer is going to be a web application, .NET is a perfectly good target and we will say so when it is the right one, particularly if you have .NET people, .NET hosting and a Windows estate. We build in TypeScript, which suits teams who want the front end and back end in one language and no framework migration in five years. The question worth asking first is not which stack, it is which pages genuinely need to exist.
What happens to the COM objects and the third-party DLLs?
They get found first, which is the part usually skipped. Registered components, anything created with Server.CreateObject, and anything loaded dynamically get inventoried before a plan exists, because unknown dependencies are a common reason this class of project overruns. After that it is case by case: replace, wrap, or delete the ones nothing calls.
Does a deprecated language fail a Cyber Essentials assessment?
Deprecated is not the same as unsupported, so it is not the automatic failure that genuinely end-of-life software is. Under Cyber Essentials, software no longer receiving vendor security updates in scope is an automatic fail. VBScript still receives OS-level servicing today. What you should not do is assume the answer will still be comfortable at your next renewal, because the direction of travel is published.
Have you migrated Classic ASP specifically?
Our deepest delivery experience is ColdFusion, which is the same shape of problem: a tag-and-script page language, business rules living between a query and the markup, and an estate nobody has read end to end in fifteen years. The method does not depend on the language, and reading unfamiliar code at volume is the part we are actually good at. We would rather say that than show you a case study we do not have.
Talk to someone who would read the code
A name, an email, and three optional questions. What comes back is a reply from the engineer who would read the code, and it is either a conversation about replacing it or an honest reason why we are not the right people.
Other platforms