Esri's VBScript Deprecation in ArcGIS: The September 2025 Cutoff and Your Migration Roadmap

Esri drew a line in the sand on September 2, 2025, officially deprecating VBScript across its entire ArcGIS platform effective immediately. The move forces GIS professionals to abandon an aging scripting engine that has quietly powered countless map labels, symbology rules, and field calculations for over two decades. With Microsoft already executing a phased removal of VBScript from Windows, Esri is aligning its products to avoid a future where critical workflows simply stop working when the runtime finally disappears from the operating system.

The Microsoft Countdown: From Enabled to Extinct

Microsoft publicly announced VBScript’s deprecation in October 2023, laying out a three‑phase retirement plan. Phase 1 kept VBScript available as a Feature on Demand (FOD) and enabled by default. Phase 2—expected around 2027—will disable the FOD by default, though administrators can still re‑enable it. Phase 3, the final act, will strip VBScript DLLs from Windows entirely. No firm date has been set for that complete removal, but the company’s message is unambiguous: the clock is ticking.

Windows Server 2025 still ships with VBScript as a preinstalled FOD, but that reprieve is temporary. Esri’s decision to deprecate VBScript across ArcGIS Pro, ArcGIS Enterprise, and related tools in September 2025 is a proactive step. It ensures that ArcGIS users are not blindsided when a future Windows update or server release suddenly breaks every map and tool that depends on the obsolete engine.

Why This Hits ArcGIS Hard

Walk through any mature GIS environment and you’ll likely stumble upon VBScript snippets buried in label expressions, conditional symbology, or custom field calculator formulas. Many of these scripts were written years ago and have been silently working ever since. The problem is that they rely entirely on a Windows‑hosted interpreter—remove that interpreter, and maps go blank, routing costs miscalculate, and automated tasks fail with cryptic errors.

Esri’s deprecation is not just a warning; it triggers concrete product changes. ArcGIS Pro 3.5, for instance, will completely remove support for VBScript‑based Network Analyst evaluators. That means any network dataset that still uses VBScript for cost attributes, restrictions, or descriptors will fail to build or package. The same is true for Calculate Field operations and label expressions—while they may continue to render for a while, the editing interfaces are being locked down, and the code will eventually cease to execute.

The Full Scope of Affected Features

A practical inventory reveals the breadth of impact:

• Label expressions: VBScript in label expressions will keep rendering until the runtime vanishes from Windows, but Esri advises migrating immediately to Arcade—its preferred language for cartographic expressions—or Python when Arcade cannot handle the logic.
• Field calculator expressions: Any Calculate Field operation using VBScript must be rewritten in Python or Arcade. Esri’s documentation provides side‑by‑side syntax examples to ease the transition.
• Network Analyst evaluators: This is the most urgent area. VBScript field scripts and element scripts in network datasets are being phased out entirely in ArcGIS Pro 3.5, with no fallback. These must be converted to Python.
• Symbology rules: Custom symbology that uses VBScript for conditional logic needs a rewrite in Arcade or Python.
• Custom automation and installer scripts: Any standalone .vbs files or embedded scripts that interact with ArcGIS components will break on Windows machines that ship without VBScript.

A Clear (but Not Static) Timeline

Here is how the key dates stack up:

Windows Server 2025 and Windows 11 24H2 still include the FOD, but Esri’s deprecation means that by September 2025, ArcGIS itself will block new VBScript expression creation and urge conversion in the user interface. The editorial tools will be gone; the runtime might linger on the OS for a while, but relying on it is akin to playing chicken with a freight train.

A Practical Migration Playbook

Moving away from VBScript is not a one‑click operation. Large organizations with hundreds of map documents and published services need a structured approach.

1. Inventory Everything (Immediate)

Search all project files (.aprx, .lyrx, .mxd), geodatabases, script libraries, and automation repositories for VBScript signatures. Use grep or dedicated GIS tools to find patterns like [FIELD], the string “VBScript”, or .vbs files. Export a master list of every expression, label, evaluator, and script that touches VBScript.

2. Prioritize Ruthlessly (1–2 Weeks)

Not all VBScript is equally critical. Production web maps, live routing services, and scheduled geoprocessing jobs that feed daily decisions must go to the top of the list. Simple label expressions that only concatenate two fields? Those are quick wins. Complex Network Analyst evaluators that encode cost matrices? Those demand immediate attention because they will break first.

3. Convert and Test (2–8 Weeks per Batch)

• Label and symbology expressions: Rewrite in Arcade. Example: [Name] & " (" & [Type] & ")" becomes $feature.Name + " (" + $feature.Type + ")".
• Field calculations: Python is the workhorse. Replace [Distance] * 1.609 with !Distance! * 1.609. Arcade can be used when the expression must run in both Pro and web maps.
• Network Analyst evaluators: Follow Esri’s detailed conversion guide. A VBScript evaluator like [DrivingTime] * 60 becomes the Python equivalent !DrivingTime! * 60. Watch for unit discrepancies and default value handling.
• SQL: Use for simple attribute filters or computed columns in the underlying database.

Build unit tests for each converted expression. Use sample features with known outputs and verify that labels, calculated fields, and network costs match the old VBScript results exactly.

4. Staged Rollout and Verification (Ongoing)

Deploy converted logic first in a staging environment. Republish web layers, run routing analyses on test network datasets, and visually inspect map outputs. Keep a versioned backup of the original state—if a converted expression produces a subtle null‑handling glitch, you need to roll back instantly.

5. Retire and Document (Final)

Once all VBScript has been eradicated, remove leftover .vbs files and update runbooks. Maintain a conversion map that links each original VBScript snippet to its new Arcade/Python counterpart. This aids future audits and helps new staff understand the logic.

Choosing the Right Language

Esri offers three viable replacements, each with distinct strengths.

Arcade is the safest bet for anything that appears on a map—it is sandboxed, cross‑platform, and purpose‑built for GIS. Python gives you the full power of ArcPy and third‑party packages but runs only on the desktop or server where ArcGIS is installed. SQL keeps work in the database, avoiding data movement.

Automation and Tooling to Speed Things Up

For shops with dozens or hundreds of projects, manual conversion won’t scale. Consider:

• Pattern‑matching scripts: Use Python’s re module to locate square‑bracket field references and suggest the corresponding Arcade or Python syntax. Validate manually.
• ArcGIS Project parsing: .aprx files are ZIP archives containing XML. Write scripts to extract expression elements and report which ones still use VBScript.
• Esri’s own documentation: The VBScript deprecation blog post and Network Analyst migration guide provide line‑by‑line examples that can serve as templates for automated refactoring.

Risks and Edge Cases You Cannot Ignore

Blindly swapping syntax will create bugs. VBScript, Python, and Arcade diverge in how they handle:

• Nulls and empty strings: VBScript’s Null propagates differently than Python’s None. A concatenation that previously yielded an empty string might now produce “None”.
• Type coercion: "10" + 5 in VBScript results in 15 (if Option Explicit is off), while Python throws a TypeError. Arcade has its own strict typing rules.
• Date arithmetic: VBScript’s DateAdd and DateDiff have no direct equivalent; Python’s datetime module and Arcade’s DateAdd() function handle things differently.
• ArcObjects legacy: Some ancient VBScript macros made COM calls that are impossible in Arcade and tricky in Python. Those require a full rewrite into a Python add‑in or toolbox.
• Network Analyst nuances: Evaluator scripts that use magic numbers or legacy unit constants must be carefully ported to ensure route costs remain identical. Esri warns that building or packaging networks with VBScript evaluators will fail in ArcGIS Pro 3.5, so test early with sample network builds.

Testing is not optional. Allocate dedicated QA time for side‑by‑side comparison of outputs from the old VBScript and the new implementation.

The Silver Lining

While the migration is forced, it also brings modern, maintainable code into your GIS stack. Arcade expressions work seamlessly in web maps and mobile apps, something VBScript never could. Python scripts can be unit‑tested and version‑controlled like professional software. SQL expressions push computation to the database, improving performance. This is a rare, organization‑wide opportunity to pay down technical debt and standardize your GIS scripting on languages that will be supported for decades.

Final Word

September 2025 is not a distant speculation. Esri’s deprecation means ArcGIS itself will lock out VBScript editing and gradually remove execution support. While Microsoft may not yank the runtime from Windows until 2027 or later, Esri is making sure you cannot wait that long. Inventory your VBScript usage now. Convert Network Analyst evaluators first—they have the hardest deadline with ArcGIS Pro 3.5. Move labels and field calculations to Arcade or Python. Document everything and test thoroughly.

This is a predictable, necessary step in platform hygiene. The transition is well‑defined, Esri and Microsoft provide ample guidance, and the end result is a more robust, future‑proof GIS environment. The only wrong move is to do nothing.