Relicbridge

VBScript deprecation: measuring what your Classic ASP app is exposed to

Microsoft put VBScript on a deprecation path in October 2023, and the clock has been ticking in public ever since: VBScript became a Feature on Demand (installed, but detachable) in Windows 11 24H2 and Windows Server 2025, with a stated plan to disable it by default in a later release and remove it after that. Microsoft's VBScript deprecation notice and the VBScript FAQ are the primary sources; read them yourself before you quote a date to anyone, because the dates move and this post will age.

If you run a Classic ASP application, that notice is about you. Server-side ASP written in VBScript runs on the same vbscript.dll scripting engine. Microsoft has not published an end-of-support date for the IIS ASP component itself, and I am not going to invent one. What you can act on is narrower and more useful: your application is now dependent on a component that the platform owner has publicly said it intends to remove, and nobody has told you which Windows release will break you.

This tutorial is how we measure that exposure on a real Classic ASP estate in about a day, and what we do with the answer. It is inventory and evidence, not panic.

What is actually at risk

Four different things get called "VBScript" in a typical shop, and they have different risk profiles:

  1. Server-side Classic ASP — .asp files with <%@ Language="VBScript" %> running under asp.dll on IIS. This is the main body of work.
  2. Windows Script Host scripts — .vbs files run by cscript.exe from Task Scheduler, SQL Agent job steps of type "ActiveX Script", or login scripts. Often invisible and often load-bearing.
  3. HTA applications — .hta internal admin tools, usually written by someone who left.
  4. Client-side VBScript — <script language="vbscript"> in pages. This died with Internet Explorer in 2022; if it is still in the codebase it is already dead code in every supported browser, and you should confirm that rather than migrate it.

Note what is not on the list: VBA. Excel and Access VBA are a separate engine with a separate roadmap and are not covered by the VBScript deprecation. If your Access application is the worry, that is a different conversation.

Step 1: find every VBScript surface

Run this from the root of a copy of the application. It takes minutes and it is the whole basis for the estimate.

# Server-side ASP: file count and total lines
$asp = Get-ChildItem -Recurse -Include *.asp,*.inc
"{0} ASP files, {1} lines" -f $asp.Count, (($asp | Get-Content | Measure-Object -Line).Lines)

# Script-host scripts and HTAs anywhere on the box
Get-ChildItem C:\ -Recurse -Include *.vbs,*.hta -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime | Export-Csv vbs-inventory.csv -NoTypeInformation

# Client-side VBScript still shipped to browsers
Select-String -Path .\*.asp,.\*.htm,.\*.html -Pattern 'language\s*=\s*"?vbscript' -SimpleMatch:$false

Then the ones people forget. Scheduled tasks:

Get-ScheduledTask | Where-Object { $_.Actions.Execute -match 'cscript|wscript' } |
  Select-Object TaskName, @{n='Cmd';e={$_.Actions.Arguments}}

And SQL Agent, where ActiveX Script job steps are themselves deprecated but still run on older instances:

SELECT j.name AS job_name, s.step_name, s.subsystem
FROM msdb.dbo.sysjobsteps s
JOIN msdb.dbo.sysjobs j ON j.job_id = s.job_id
WHERE s.subsystem IN ('ActiveScripting', 'CmdExec')
ORDER BY j.name;

Keep the CSV. On the last estate we inventoried, the .asp count was the number the client already knew; the eleven scheduled .vbs files gluing an FTP drop to a nightly import were the ones nobody had mentioned, and two of them wrote directly to production tables.

Step 2: measure the real runtime exposure

Your exposure is not "VBScript is deprecated." It is "this application will stop running on the Windows version we will be forced onto, on a date we do not control." So pin down the Windows side.

Get-ComputerInfo -Property OsName, OsVersion, OsBuildNumber, WindowsInstallationType

Match that against the Microsoft lifecycle page for the specific server OS. Windows Server 2012 R2 left extended support in October 2023. Windows Server 2016's extended support ends in January 2027. Those dates are concrete and published; the VBScript removal date is not. In every engagement I have run, the OS lifecycle date arrives first and forces the move, and the VBScript question only becomes urgent because the new box is a newer Windows.

The useful test is cheap: stand up a Windows Server 2025 VM, install IIS with the ASP role service, deploy the application, and run it. You want to know today whether it works there, and what breaks first.

Install-WindowsFeature Web-Server, Web-Asp, Web-ISAPI-Ext, Web-Metabase, Web-WMI

Then force the failure mode on purpose. VBScript on Windows Server 2025 is a Feature on Demand, so you can remove it and see exactly what your application does without it:

# Inspect, then remove on a throwaway VM only
Get-WindowsCapability -Online -Name "VBSCRIPT*"
Remove-WindowsCapability -Online -Name "VBSCRIPT~~~~"

Do that on a disposable VM, never on anything anyone depends on. The failure you see is the failure you will get later, and it is worth seeing once with your own eyes rather than reading about it.

Two more things will bite on a modern box before VBScript does, so check them in the same pass: 32-bit COM components registered on the server that force the app pool into 32-bit mode, and ODBC drivers for whatever the data really lives in. The Jet 4.0 provider for .mdb files and the VFP OLE DB provider are the two that most often have no path onto a current 64-bit server at all.

Step 3: decide, and write the decision down

You have three honest options. Pick one per application, not one per company.

Do nothing yet, with a review date. Legitimate when the application is genuinely low-traffic, internal, on a server with years of support left, and slated for replacement by a purchased product. Write down the review date and the trigger. "We looked and chose to wait" is an answer; "nobody looked" is not.

Port the scripts, keep the application. For the .vbs and SQL Agent pieces, rewriting to PowerShell or a small .NET 8 console app is usually a few days of work each and removes a real dependency. This is the highest-value, lowest-risk work on the list, and it is worth doing regardless of what you decide about the web application.

Strangle the application. The ASP body of code is the expensive part, and the answer there is the same as it always is: characterization tests on the paths that carry money, one slice at a time behind a routing shim, rollback available at every step. We wrote up both halves of that separately — taking inventory of a Classic ASP application before you estimate and the routing shim: YARP in front of a legacy IIS app.

What I would not do is a straight VBScript-to-JScript conversion of the ASP pages to escape the deprecation. JScript's ASP engine is old too, the conversion touches every file, and you finish with the same application on the same architecture having spent real money to move the expiry date an unknown distance. If you are going to touch every file, get something for it.

What this changes about sequencing

The deprecation does not make your Classic ASP application urgent by itself. It removes your ability to keep deferring the decision indefinitely, because the platform vendor has now said out loud which way this ends.

Concretely, that means the assessment moves earlier. If you have a Classic ASP application on Windows Server 2016, your forcing date is January 2027, and a slice-by-slice migration of a mid-sized ASP application is measured in months per slice. Counting backwards from a hard date is the only estimate that means anything, and you cannot count backwards until you have the inventory from step 1.

Run the inventory. It costs a day. Then you are arguing about a spreadsheet instead of a feeling.