The short answer: is Classic ASP still supported?
Yes, today. Microsoft’s support article on ASP (KB 2669020) says: “The use of ASP pages with Microsoft Internet Information Services (IIS) is currently supported in all supported versions of IIS.” Because IIS ships with Windows, it adds that “both ASP and IIS support lifetimes are tied to the support lifecycle of the host operating system.”
So there’s no single Classic ASP shutdown date to circle. Your app’s support clock is the Windows Server version it runs on. If that version is past its support dates, your Classic ASP app is effectively unsupported too, however well it still runs.
Where your Windows Server version stands
Dates are from Microsoft’s lifecycle pages, linked in the table. Recheck them before you decide, since Microsoft occasionally adjusts them.
What Microsoft has actually said about IIS, Windows and VBScript
Three Microsoft sources matter most. Read together, they say Classic ASP is supported wherever IIS is supported, and that VBScript, the language Classic ASP uses by default, is on its way out of Windows.
ASP is an optional part of IIS
Classic ASP is a module you add to IIS; on IIS 7.0 and later it isn’t installed by default. Its support follows IIS, and IIS follows Windows, per the KB article above. By that wording, ASP on the IIS that comes with a currently supported Windows Server, 2025 included, is supported today.
The VBScript deprecation timeline, in three phases
Microsoft’s IIS configuration reference lists VBScript as the default ASP script language, which is why this timeline matters. In its May 2024 Windows IT Pro post, “VBScript deprecation: Timelines and next steps”, Microsoft says it announced the deprecation in October 2023 and sets out three phases:
Classic ASP on Windows Server 2025: VBScript is still included, for now
Microsoft’s list of features removed or no longer developed in Windows Server says: “VBScript is available as an FOD and preinstalled in Windows Server 2025, before its removal from the operating system in a later release.”
What Microsoft hasn’t said
The VBScript post mentions ASP once, while describing where VBScript has been used. None of these sources says what happens to server-side Classic ASP pages in Phase 2 or Phase 3. The post’s advice to move webpages to JavaScript is about VBScript running inside old browsers. Classic ASP runs its VBScript on the web server, so a page that works in Chrome or Edge tells you nothing about the server side. Anyone quoting a firm Classic ASP shutoff date is guessing.
The reasonable reading: if your pages are written in VBScript, your app depends on a component Microsoft has said it will remove from future Windows versions. You don’t know the date, but you know the direction, which is enough to start planning before a Windows upgrade forces the issue.
The real risks of staying put on Classic ASP
Nothing in Microsoft’s posts switches your app off next month. The risk creeps instead, and it tends to surface during something routine: a server upgrade, a staff change, a new integration.
Server upgrades get harder each year
Moving to a newer Windows Server means reinstalling the ASP module, re-registering every COM component, recreating IIS settings and retesting each page. When nobody is sure what the app needs, the old server stays in place, and its support dates pass.
32-bit COM components
A Classic ASP app may call COM components for email, file uploads, PDFs or charts. A 32-bit component DLL only loads in an application pool with the enable32BitAppOnWin64 setting turned on, and it’s off by default. If the vendor is gone or the installer is lost, that one DLL can block a server move.
Classic ASP security risks nobody patches for you
Windows updates patch the platform, not your code. In older Classic ASP code we look for three things first: SQL built by pasting form input into a string (SQL injection), user input written back to pages without encoding (cross-site scripting), and database passwords sitting in include files. They stay until someone fixes them, page by page.
Fewer people who can maintain it
When the developer who built and patched the app leaves, the business rules buried in it leave too. Replacing that person means finding someone comfortable with VBScript, ADO and COM, then giving them time to learn your app. If that’s where you are now, start with what to do in the first 48 hours after your developer disappears.
Phones and modern integrations
“Our field crews need to do this from their phones.” Pages built as wide desktop tables mean pinching and zooming on a job site. VBScript also has no built-in JSON support, so every new connection to a modern REST API becomes custom plumbing. Both can be fixed as pages are rebuilt; see making an existing web app mobile-friendly.
Your four options: maintain, rehost, migrate page by page, rewrite
The choices come down to four paths, and you can combine them: maintain now, rehost to buy time, then migrate page by page.
Example (hypothetical): choosing a path
Picture a parts distributor (an illustration, not client data) that runs quoting and order entry on about 120 .asp pages on Windows Server 2016, with a 32-bit COM component that produces PDF quotes. Server support ends in January 2027, the sales team asks for changes every week, and reps want to build quotes on tablets.
A rewrite would freeze changes for too long, and rehosting alone leaves the PDF component and VBScript in place. A sensible plan: confirm the PDF component installs on a supported server and rehost there now, then migrate page by page, starting with the quote screens reps use most and the PDF step itself.
Want a structured second opinion on your own app? The rewrite-or-refactor scorecard weighs value, pressure, risk, data and readiness, then recommends a path with the reasons behind it.
How to inventory a Classic ASP application before you decide
You can’t choose a path, or get an estimate worth trusting, until you know what the app is made of. Sit down with the web server, the source folder and the database, and list these:
Write the business rules down as you go
In a long-lived Classic ASP app, the code is often the only specification. When you find a rule (a discount tier, an approval limit, a rounding quirk finance relies on), write it in plain English and have the person who owns that process confirm it. Rules you no longer follow can be dropped before anyone rebuilds them.
Migrating Classic ASP page by page while the old site keeps running
A page-by-page migration replaces the app in small slices instead of one big switchover. People keep using the old pages they rely on while new ones go live beside them, and each slice is checked on real work before the next starts. The general method is in our guide to modernizing an old web application without a risky rewrite; here’s how it applies to Classic ASP.
- Stand up the new app beside the old one. Build it on a current, supported stack that fits your team and hosting, pointed at the same database.
- Route by URL. A routing rule or reverse proxy sends migrated paths to the new app and everything else to the old site, so users see one system.
- Solve sign-in early. Classic ASP keeps its session data to itself, so decide up front how people stay signed in as they move between old and new pages.
- Pick the first slice by pain and risk. Start with the pages people use most, or the ones blocking a server move, such as a page that depends on a 32-bit COM component.
- Compare old and new before switching. Run the same inputs through both on a staging copy and compare totals, statuses and outgoing emails before the new page takes over.
- Retire, redirect, repeat. Remove each old page once its replacement is live, redirect its old URL, and move to the next slice.
When the last VBScript page is retired and any scheduled .vbs scripts are replaced, the VBScript question goes with it, and so does the app’s dependence on the ASP module.
Planning a Classic ASP migration?
Your first call is with an engineer. Tell us what the app does, where it runs and what worries you most, and we’ll talk through which of these paths fits.
Keeping a Classic ASP app stable and secure while you plan
Whichever path you choose, the current app has to keep working in the meantime. This checklist lowers the risk without changing what users see.
- Back up everything you’d need to rebuild the server: code, database, IIS configuration and the installers for every COM component.
- Set up a staging copy on a separate server or IIS site, so fixes and Windows updates are tried away from the live app.
- Patch the server and note its support end date from Microsoft’s lifecycle page.
- Run the app in its own application pool under the built-in ApplicationPoolIdentity, not LocalSystem or an administrator account, with rights only to the folders it needs.
- Give the app’s database login only the permissions it uses. An app that reads and writes a few tables shouldn’t connect as a database owner or system administrator.
- Parameterize queries. Replace SQL built from form input with ADO Command objects and parameters, the first defense in OWASP’s SQL injection prevention guidance. Start with sign-in, search and anything public.
- Encode output. Pass user-supplied text through Server.HTMLEncode before writing it to a page.
- Keep detailed errors off the browser. IIS’s scriptErrorSentToBrowser setting is off by default; confirm nobody switched it on while debugging.
- Audit old components and accounts. List each COM component with its vendor and version, remove the ones nothing calls, and disable stale server, database and FTP accounts.
If the app is already misbehaving, or nobody has the passwords, stabilize first: get access, back up, document, then fix. Software maintenance and support covers keeping an app like this running, and software project rescue covers stepping in when the previous developer is gone.
For more plain-language guides on old systems, portals and integrations, browse our guides.