Classic ASP is living on borrowed time: what to do in 2026
Classic ASP has no end-of-life date of its own because Microsoft never gave it one: it still ships as an optional IIS feature on current Windows Server, and its lifecycle follows the operating system underneath it. In every other sense it is finished. The final version, ASP 3.0, shipped in 2000; ASP.NET superseded it in January 2002; and in October 2023 Microsoft announced the deprecation of VBScript, the language most Classic ASP is written in, with removal from Windows in stages. A Classic ASP system in 2026 runs on a frozen platform in a deprecated language, and the sensible response is a planned exit, not panic.
Classic ASP is the rare Microsoft technology without an end-of-life date, and that is less reassuring than it sounds. Nobody is coming to switch it off; nobody has developed it since the early 2000s either. Here is the precise position as of July 2026.
The answer in one paragraph
Classic ASP is not formally end of life. It still ships as an optional feature of IIS on current Windows Server, so its support lifecycle is simply the lifecycle of the Windows underneath it: there is no roadmap because there is no development. The final version, ASP 3.0, shipped with IIS 5 in 2000. ASP.NET superseded it in January 2002, and Classic ASP has been feature-frozen ever since. Then, in October 2023, Microsoft announced the deprecation of VBScript, the language the great majority of Classic ASP is written in, with removal from Windows in stages. So the honest verdict: not dead, but frozen for more than two decades, written in a language its own vendor is retiring, and maintained by a shrinking pool of people. Living on borrowed time, in other words, and nothing will force a decision until something breaks. The sensible move is to decide first.
How to tell what you are actually running
Plenty of businesses inherit these systems with no documentation and nobody who remembers the build. The signs are consistent:
- Page addresses end in .asp, not .aspx. That single letter separates Classic ASP from its .NET successor.
- The source files hold code between
<%and%>markers, almost always VBScript (look for Dim, Set and Response.Write), occasionally JScript. - Database access goes through ADO: search the code for ADODB.Connection, and nearby you will usually find a connection string written out in plain text, often in a shared include file or global.asa.
- Behind it all sits SQL Server or a Microsoft Access .mdb file, depending on how grand the original project was.
If that matches, you have a Classic ASP system, almost certainly built between about 1998 and 2005: an intranet, an order tracker, a quoting tool, a customer portal. The kind of software a business quietly stands on.
Every era, every date
| Date | What happened | Where that leaves you in 2026 |
|---|---|---|
| December 1996 | ASP 1.0 ships with IIS 3 | The platform your system was born into is approaching its thirtieth birthday |
| 2000 | ASP 3.0 ships with IIS 5 | The final version. Every Classic ASP system today runs on a release from 2000 |
| January 2002 | ASP.NET released | The successor arrives; Classic ASP is feature-frozen from this point on |
| October 2023 | Microsoft announces the deprecation of VBScript | The language most Classic ASP is written in is being phased out of Windows in stages |
| July 2026 | Classic ASP still ships as an optional IIS feature on current Windows Server | It runs, but its lifecycle is borrowed from the operating system, and its language is on the way out |
The second row is the one to sit with. The last new Classic ASP feature shipped in 2000, when the millennium bug was still a fresh memory. Everything the web has learned since, on security, accessibility, mobile layouts and sensible APIs, happened after this platform stopped moving, and none of it reached the platform itself.
The 2023 row matters for a different reason: it is the clearest signal Microsoft has ever sent about this stack. Deprecating VBScript does not instantly break server-side pages, and the staged removal concerns Windows rather than a dated switch-off of your site. But the direction of travel is now written down by the vendor, which is more notice than most legacy platforms ever give.
Why “it still runs” hides the risk
A Classic ASP system that ran yesterday will very likely run tomorrow, and that sentence is exactly how the risk hides.
Developer scarcity is the sharpest edge. Advertise for a UK developer who wants to work in VBScript on a platform frozen since 2002 and see what comes back. The people who built these systems are retiring, and nobody younger is learning the stack, for the sound reason that it has no future. Support, in practice, is whoever still knows your system.
The habits of the era are liabilities now. Connection strings sitting in plain text inside include files; queries assembled by joining strings together, which is the classic route to SQL injection; password handling from an age before anyone worried much. None of this was negligent in 1999. All of it is a finding in a 2026 security review, and unsupported, unmaintained software also sits badly with Cyber Essentials and with insurers.
Session state pins you to one machine. Classic ASP holds its session data in the memory of a single web server, so the system cannot fail over or scale out gracefully. The result is one specific server everybody is nervous about restarting, which is not a resilience strategy.
Your honest options
Three, in rising order of ambition.
Stay and contain. Reasonable when the system is genuinely stable, changes are rare, and it does not face the public internet. Do the containment properly: get the source, the include files and every credential somewhere safe; image the server; test a restore; restrict what can reach it. Staying put is a decision to renew every year with open eyes rather than a permanent answer, but for a static internal tool it can be the right one.
Lift the database first. The data usually matters more than the code. Moving an ageing Access back end to a proper server database, or getting a neglected SQL Server patched and backed up, removes the most fragile component without rebuilding the screens, and it makes any later rebuild cheaper because the data work is already done.
Rebuild as a modern web application, with parallel running. The full exit: the same workflows rebuilt on a current, hireable stack, while the old system stays live beside it until the numbers match week after week. Nobody big-bangs a cutover on our projects; the method is written up in migration without downtime.
The database is half the job
Which database sits behind the .asp pages shapes the work more than the pages do. SQL Server is the lucky case: a proper server product, still current and supported, from which extracting clean data is routine. If that is you, the rebuild conversation is mostly about screens and workflows, and the quote lands at the calmer end.
Access is the careful case. An .mdb that has spent twenty years behind a website has usually collected quiet damage: validation living in the ASP code rather than the database, orphaned records, fields repurposed away from their labels. The warning signs are catalogued in seven signs an Access database is at breaking point, and the fix is the measured extraction work described on the Access database replacement page: dry runs, reconciliation, no optimism.
What to do about it, calmly
Not panic. The platform has been frozen for over two decades; another quarter of careful planning changes nothing except how well the exit goes.
The sequence we recommend: locate the source code, global.asa, the include files and every connection string, and copy them somewhere safe. Image the server. Test a restore, actually. Then map the options against what the system does all day, and decide with numbers rather than nerves. We compare staying, containing and rebuilding honestly on the Classic ASP migration page, and the free Legacy Risk Audit applies the same comparison to your specific system: a 30-minute call, then a one-page written risk summary, whichever way the answer points.