Microsoft's VBScript Sunset: What Breaks in 2026–27 and What You Should Do

Roughly three decades of Windows automation is heading for a reckoning. According to AskWoody’s Martin Brinkmann, Microsoft is phasing out VBScript, with the next major compatibility hit landing around 2026–27. As the VBScript sunset approaches, anyone who has ever relied on a .vbs file to automate a logon, tidy a folder, or drive a legacy business process should start paying attention now.

The good news is that you have some runway. The bad news is that VBScript has quietly become the duct tape holding together a surprising amount of infrastructure that most people never think about. Here’s what actually changes, why one sibling technology is spared, and how to audit your systems before the lights go out.

What the VBScript sunset actually means

VBScript—short for Visual Basic Scripting Edition—arrived in the mid-1990s as a lightweight scripting language built into Windows. For years it powered logon and logoff scripts, Windows Script Host (WSH) automation, and server-side Classic ASP pages. It was never fast or elegant, but it was everywhere, and it was simple enough for anyone to tweak without a formal programming background.

The writing has been on the wall for a while. In modern Windows, VBScript is disabled by default rather than simply unavailable, and Microsoft has steadily nudged users toward PowerShell for anything resembling real automation. The 2026–27 window AskWoody flags is the point where the deprecation stops being a gentle nudge and starts breaking things.

What actually breaks in 2026–27

The precise mechanics of the change depend on how Microsoft ultimately structures the final compatibility hit, but the practical outcome is clear: scripts written in VBScript will stop running the way they do today. That includes .vbs files executed through the Windows Script Host, any automation that leans on VBScript’s built-in objects, and legacy processes that were never modernized.

What’s trickier is how widespread the impact turns out to be. VBScript rarely runs in isolation—it’s often buried inside larger workflows, scheduled tasks, or third-party tools that call it under the hood. The scripts that bite you in 2026–27 are usually the ones nobody remembers writing, let alone documenting.

Why VBA survives when VBScript doesn’t

One of the most common follow-up questions is why VBA—Visual Basic for Applications, the engine behind Excel macros and Office automation—appears to be spared. The distinction matters, and it isn’t just semantics.

VBScript and VBA share a name and a heritage, but they live in different worlds. VBScript runs as a standalone interpreter tied to the Windows operating system, which is exactly why an OS-level deprecation can kill it. VBA, by contrast, lives inside Office applications like Word, Excel, and Access. Its fate is tied to Microsoft Office rather than to Windows itself, so an OS-level VBScript sunset doesn’t automatically take it down with it.

How to audit your systems before the lights go out

The single most useful thing you can do right now is find out where VBScript actually runs in your environment. That means hunting down .vbs files, checking scheduled tasks, reviewing logon scripts, and—crucially—asking the people who’ve been maintaining legacy systems what they’re actually running.

Look especially for the scripts that aren’t documented. Those orphaned automation jobs are the ones most likely to break silently, and they’re the ones hardest to replace once the switch flips. A careful inventory now turns a surprise into a planned migration rather than an emergency.

What this means for you

For most everyday Windows users, the VBScript sunset won’t touch the desktop experience. You don’t run VBScript to browse the web, answer email, or run your favorite apps. If you’ve never touched a .vbs file, there’s genuinely nothing to do today.

The change really lands for people and organizations that depend on legacy automation—small businesses running custom inventory scripts, IT teams managing older deployments, or anyone who inherited a system someone else built. For them, 2026–27 is a real deadline, not a suggestion.

How to prepare

If VBScript is part of your workflow, start mapping it out now. Inventory every .vbs file and the process it feeds into. For straightforward tasks, PowerShell is the natural successor and can often replicate VBScript behavior with far more power and flexibility. For anything deeply embedded, budget time to rewrite or replace it before the compatibility hit arrives.

The runway is real, but it isn’t infinite. The teams that avoid a 2026–27 scramble are the ones auditing today, not the ones hoping the problem outlives them.

Source: AskWoody

Over to you: What legacy VBScript automation do you still rely on, and how are you planning to replace it before 2026–27?