Microsoft’s VBScript Deprecation: What Houston Businesses Need to Know

A decades-old scripting engine is being removed from Windows in stages, for both modernization and security reasons.

VBScript deprecation means Microsoft has scheduled VBScript for removal from Windows, moving it first to an optional Feature on Demand and eventually deleting it, so any script, installer, or application that depends on it will stop working once removal is complete.

Microsoft announced the deprecation in October 2023 and has confirmed a staged rollout rather than a single cutoff. The reasoning is two-part. First, modernization: PowerShell and JavaScript cover everything VBScript did, with better tooling and stronger controls. Second, security. VBScript has been a favorite delivery mechanism for malware families, and Microsoft has named it as a vector abused in campaigns tied to malware such as Lokibot, Emotet, Qbot, and DarkGate. Pulling the engine out of Windows closes that door. In 35 years doing this, the pattern is familiar: the technology a business forgets it depends on is exactly the one that turns into an emergency the week it is removed.

• It is a removal, not a patch. Once Windows drops the VBScript DLLs in the final phase, there is no toggle to turn it back on. Anything that needs it has to be migrated before then.
• The trigger is a Windows update, not a calendar reminder. Your exposure changes when a machine moves to a build where VBScript is off by default, which can happen quietly during normal patching.
• Old and inherited scripts are the real risk. The dependencies that bite are the ones nobody wrote recently: a legacy installer, a vendor tool, a logon script copied years ago.

Microsoft's plan runs in three stages, giving businesses a window to migrate before the engine is gone.

The VBScript deprecation runs in three phases: Phase 1 keeps VBScript available and enabled by default as a Feature on Demand starting with Windows 11 version 24H2; Phase 2, around 2026 to 2027, disables it by default; Phase 3, on a date Microsoft has not set, removes it from Windows entirely.

The phases matter because your exposure is different in each one. Here is what Microsoft has published:

• Phase 1 - available and on by default. Starting with Windows 11 version 24H2, VBScript ships as a Feature on Demand that is pre-installed and enabled. Existing scripts keep running. This is the migration window, and it is happening now.
• Phase 2 - off by default (around 2026-2027). The VBScript Feature on Demand stays available but is no longer enabled by default. Any machine on a build in this phase will not run VBScript until an administrator manually re-enables the feature, which is a stopgap, not a fix.
• Phase 3 - removed entirely (date not announced). Microsoft retires VBScript from future Windows releases and removes its DLLs. At that point there is no re-enable option, and every dependent script or installer stops working. Microsoft has not published a firm date for this phase.

One Office-specific detail worth knowing: for teams that used VBScript's RegExp object inside VBA macros, newer Office builds add native RegExp support directly to VBA, so those macros can be updated to drop the external VBScript reference. That covers Office macros, not standalone .vbs files or installers, which still need a real migration.

A short readiness checklist that finds your dependencies and moves them off VBScript before a phase change forces the issue.

Preparing for VBScript removal comes down to five steps: inventory where VBScript is used, check third-party apps and installers, rewrite critical scripts in PowerShell, update Office macros, and confirm nothing else silently depends on the engine before Phase 2 disables it.

You do not need to migrate everything at once. You need to know what you have, rank it by how much it would hurt to lose, and work down the list while VBScript is still enabled. Run these steps in order:

• Inventory every VBScript dependency. Search for .vbs files across servers and workstations, review scheduled tasks and logon scripts, and use System Monitor (Sysmon) to log where vbscript.dll actually loads across the network. You cannot migrate what you have not found.
• Check third-party apps, installers, and vendor tools. Legacy line-of-business software and older installers often call VBScript quietly. Ask vendors directly whether their product depends on it and whether they have a supported version that does not.
• Rewrite critical scripts in PowerShell. PowerShell is Microsoft's primary replacement for automation and covers scheduled jobs, data processing, and administration. Migrate the highest-impact scripts first, test them, and retire the VBScript originals.
• Update Office macros that use RegExp. Newer Office builds add native RegExp support to VBA, so macros that reached out to the external VBScript library can be updated to use the built-in class and drop the dependency.
• Confirm nothing is left before Phase 2. Once removal moves VBScript to off-by-default, a missed dependency becomes a broken process. Re-run the inventory, verify replacements work, and document what changed so a future Windows update does not surprise you.

The businesses that handle this well treat it as a small project during Phase 1, not a fire drill during Phase 3. Whether you run one aging installer or a stack of inherited automation, the work is the same shape: find it, rank it, replace it, verify it.

CinchOps is a managed IT services provider based in Katy, Texas, serving small and mid-sized businesses across the Houston metro area.

CinchOps specializes in cybersecurity, network security, managed IT support, VoIP, and SD-WAN for businesses with 10-200 employees. For a Houston SMB facing the VBScript deprecation, that means the migration handled end to end:

• Dependency inventory. We find every .vbs file, scheduled task, logon script, and installer that touches VBScript, including the vendor tools that call it quietly.
• Migration planning. We rank what matters by business impact and build a schedule that clears the critical items while VBScript is still enabled.
• PowerShell rewrites and testing. We move automation to PowerShell, test the replacements against the real workflow, and retire the VBScript originals.
• Ongoing monitoring. We watch for machines moving to builds where VBScript is off by default, so a routine Windows update does not become an outage.

We serve businesses across the Houston area, including Houston, Katy, and Sugar Land, and we know the kind of inherited automation a law firm, CPA practice, or manufacturer tends to accumulate over the years. You do not need to become a scripting expert to get ahead of this - you need a partner who finds the dependencies before Windows does. If you run a business in the Houston metro and are not sure what VBScript your systems still rely on, talk to CinchOps for an inventory and a migration plan.