Esri’s announcement that VBScript is deprecated throughout ArcGIS effective September 2025 sets a firm deadline for GIS professionals to stop relying on an aging scripting engine and begin migrating label, symbology, calculator, and evaluator logic to modern, supported expression languages such as Arcade, Python, and SQL. The blog post makes clear the move follows Microsoft’s multi‑phase VBScript deprecation for Windows, and Esri is aligning ArcGIS products to that timetable to avoid broken workflows when the OS no longer ships VBScript by default. (esri.com)
Background / Overview
Microsoft publicly announced the deprecation of VBScript in October 2023 and described a three‑phase removal plan: Phase 1 (VBScript available as Features on Demand and enabled by default), Phase 2 (disabled by default but still enableable), and Phase 3 (full retirement and removal of VBScript DLLs from the OS). Microsoft’s guidance urges customers to migrate to PowerShell or JavaScript where appropriate. The company has not set a firm date for Phase 3 (complete removal), but the timeline explicitly signals a future point where VBScript will no longer be present on new Windows images. (techcommunity.microsoft.com, learn.microsoft.com)Windows Server documentation mirrors that guidance: VBScript is slated to be available as a Feature on Demand and preinstalled in Windows Server 2025, with removal planned in a later Windows Server release. That means server‑side automation and appliances that rely on VBScript must be inspected and migrated ahead of that future removal. (learn.microsoft.com)
Esri’s announcement frames ArcGIS’ deprecation as a proactive alignment with Microsoft’s lifecycle so ArcGIS users are not caught off guard when VBScript is eventually removed from Windows. In practice, that means ArcGIS features that expose VBScript expression editing, execution, or evaluation will either be locked, flagged with warnings, or removed across ArcGIS Pro, ArcGIS Enterprise, and related tools beginning September 2025. (esri.com)
Why this matters to ArcGIS users
- Many ArcGIS workflows still contain VBScript: label expressions, symbology rules, Calculate Field expressions, geoprocessing scripts, and older Network Analyst evaluators.
- When Windows stops including VBScript DLLs, any ArcGIS feature that relies on the OS‑provided VBScript engine will fail at runtime—meaning maps, labels, tools, and networks that depend on that code can stop functioning.
- Esri’s decision to mark VBScript as deprecated in ArcGIS gives users a controlled runway to convert scripts before they break on future Windows releases. (esri.com)
What Esri has said (short summary)
- Esri published a deprecation notice on September 2, 2025 confirming VBScript is deprecated across ArcGIS starting September 2025 and advising users to convert any VBScript expressions to supported languages (Arcade, Python, SQL). (esri.com)
- Esri’s support documentation has already been marking VBScript in specific product areas (for example, Network Analyst evaluators) as deprecated for multiple ArcGIS Pro releases and detailing what will stop working and how to migrate. (support.esri.com)
Which ArcGIS features are affected (practical list)
- Label expressions — VBScript label expressions will still render until VBScript is removed from Windows, but labels using VBScript should be converted to Arcade (preferred for map expressions) or Python where Arcade cannot express the logic. (esri.com)
- Calculate Field / Field calculator expressions — Where VBScript expressions were used, migrate to Python or Arcade depending on the environment (field calculations in ArcGIS Pro generally prefer Python or Arcade). Esri help and Calculate Field usage notes provide syntax and examples for conversions. (esri.com, pro.arcgis.com)
- Network Analyst Field Script / Element Script evaluators — ArcGIS Pro historically supported VBScript and Python evaluators; Esri has been deprecating VBScript evaluators and will remove VBScript evaluator support in ArcGIS Pro 3.5 (functions such as building or packaging networks that rely on VBScript evaluators will cease to work). Users must convert evaluators to Python. (support.esri.com)
- Symbology rules and expressions — Any conditional symbology or custom expression logic that uses VBScript must be rewritten in a supported language.
- Custom installer actions or automation that rely on system VBScript engines will be impacted on Windows images that no longer include the VBScript runtime.
Timeline: what to expect (dates and phases)
- Microsoft: three phases (deprecation announcement → FOD logic changes → retirement/removal). Phase 1 started with an announcement in Oct 2023; Phase 2 is scheduled to disable VBScript FOD by default around 2027; Phase 3 (complete removal) has no firm public date yet. Administrators should treat “around 2027” as a planning milestone for the feature becoming disabled by default, and assume full removal will occur at some later point. (techcommunity.microsoft.com, learn.microsoft.com)
- Windows Server 2025: VBScript available as FOD and preinstalled in that release; removal will come in a later Windows Server release. (learn.microsoft.com)
- ArcGIS: Esri’s internal deprecation is effective September 2025 across ArcGIS to give users time to prepare. This triggers product‑level warnings and locked editors in some releases (for example, ArcGIS Pro has already added warnings in earlier 3.x releases for VBScript evaluators). (esri.com, support.esri.com)
Recommended migration strategy — a practical playbook
- Inventory (immediate)
- Search your projects, map files (.aprx), geodatabases, scripts, toolboxes, and automation repositories for VBScript code or references to .vbs files.
- Export a list of map layers, label expressions, symbology rules, Calculate Field scripts, and Network Analyst evaluators that use VBScript.
- Prioritize (1–2 weeks)
- Rank items by business criticality: production services, published web maps, scheduled scripts, and Network Analyst datasets used in operational workflows come first.
- Identify quick wins: simple label expressions and single‑field Calculate Field cases that convert easily.
- Convert and test (2–8 weeks per priority batch)
- Convert label and symbology expressions to Arcade where the expression is used for rendering in maps or web scenes.
- Convert field calculations and evaluators to Python (ArcPy/field calculator context) when Arcade can’t express the logic or when you need full Python library support.
- Use SQL expressions for straightforward attribute filtering or where database capabilities suffice.
- Build unit tests (sample features and expected outputs) and run them before deploying conversions into production.
- Staged rollout and verification (ongoing)
- Update test/prod deployment rings, republish web maps/services where necessary, and validate visual output and analytical outputs (e.g., routing costs and network results).
- Keep a fallback plan (versioned .aprx or backup geodatabase) to roll back any converted logic if unexpected discrepancies appear.
- Retire and document (final)
- Remove old VBScript artifacts that are no longer needed.
- Document all conversions and maintain a mapping of original VBScript snippets to their converted equivalents for future auditors or new team members.
Language comparisons and conversion notes
- Arcade
- Purpose: Designed specifically for cartographic expressions, popups, and many in‑map calculation scenarios.
- Strengths: Safe, fast, and supported across ArcGIS platforms (Pro, Online, Enterprise). Ideal for label expressions, symbology-driven expressions, and popup formatting.
- When to use: Rendering logic, client‑side expressions, web maps, and when portability across ArcGIS products is needed.
- Python
- Purpose: Full scripting and automation; powerful for field calculations, complex data transformations, and network evaluator logic (ArcPy).
- Strengths: Mature ecosystem, third‑party libraries, and deep integration with ArcGIS Pro geoprocessing.
- When to use: Field calculator operations requiring multi‑step logic, network evaluators that reference many attributes, batch geoprocessing, and automation.
- SQL
- Purpose: Attribute filtering, simple computed fields (when the database supports computed columns), and selection expressions.
- Strengths: Performed server‑side in the database; efficient for simple algebraic expressions or string manipulations supported by SQL dialect.
- When to use: Database level calculations that are simple and when you want to avoid moving large datasets into client‑side processes.
Tooling and automation to speed migration
- Use repository search and grep tools to locate occurrences of common VBScript patterns (e.g., “[”, “VBScript”, “.vbs”, or explicit VBScript keywords).
- For ArcGIS Pro projects, parse .aprx packages and associated .lyrx/.lyr files to extract expressions programmatically if you manage many projects.
- Create small conversion utility scripts (Python) to help translate trivial VBScript field references into Python or Arcade patterns—these can handle bulk replacements but require manual validation for complex cases.
- For Network Analyst evaluators, Esri’s support articles include line‑by‑line examples and conversion notes that help ensure mathematical or conditional logic stays identical post‑migration. (support.esri.com)
Risks, edge cases, and what to watch for
- Behavioral differences: VBScript and Python/Arcade differ in how they handle nulls, type coercion, string handling, and date math. Converted expressions should be tested on edge records (nulls, zeros, empty strings).
- ArcObjects dependencies: Some legacy VBScript macros depended on ArcObjects COM calls that are not available in Arcade or simple field calculators. Those cases will require reimplementation as Python add‑ins or toolboxes that can access ArcPy/ArcObjects equivalents where available. (help.arcgis.com)
- Network Analyst nuance: Network evaluator behavior can be subtle—if VBScript used complex route cost logic, a direct conversion to Python must ensure that all units, default values, and attribute references remain identical. Esri lists operations that will stop working with VBScript evaluators in ArcGIS Pro 3.5; these must be reworked to Python to preserve functionality. (support.esri.com)
- Testing and QA overhead: Large estates with many maps and services will incur nontrivial testing cost. Plan resources accordingly and treat this as a prioritized engineering project, not an ad‑hoc chore.
Benefits and the strategic case for migrating now
- Security and stability: Moving away from deprecated language dependencies reduces future breakage risk when the OS removes the runtime and gives you cleaner, supported code.
- Cross‑platform tooling: Python and Arcade are widely supported, maintained, and have active communities; investing in those languages improves long‑term maintainability.
- Modern workflows: Rewriting and rationalizing expressions is an opportunity to remove hidden technical debt, standardize code style, and implement testable patterns across your GIS portfolio.
Verdict and final recommendations
- Treat Esri’s September 2025 deprecation notice as an urgent but manageable call to action: inventory now, prioritize critical workflows, and begin conversions immediately. Rushing conversions without tests risks producing incorrect map output or analysis results.
- Use Arcade for rendering and map expressions, Python for field calculations and complex automation, and SQL where database‑level calculations suffice.
- Create a documented migration plan with owners, deadlines, and rollback paths. Where you cannot immediately replace VBScript (third‑party appliances, legacy installers), isolate and document those exceptions and work with vendors on long‑term remediation.
- Monitor both Microsoft and Esri communications for any changes to removal dates and follow product release notes for ArcGIS Pro (3.x) and ArcGIS Server/Enterprise updates to track where VBScript editing is being locked or removed. (esri.com, techcommunity.microsoft.com, learn.microsoft.com)
Quick checklist (actionable)
- Inventory all maps, services, scripts, and evaluators for VBScript usage.
- Prioritize: production routing/analysis services and published web maps first.
- Convert simple labels and Calculate Field expressions to Arcade/Python.
- Convert Network Analyst VBScript evaluators to Python (mandatory for ArcGIS Pro 3.5 compatibility).
- Automate and test conversion with unit tests and sample datasets.
- Update documentation, change logs, and runbook entries to reflect conversions.
- Communicate with stakeholders about the schedule and expected visual/analytic verification steps.
This change is a predictable, necessary step in platform hygiene: removing an unsupported runtime is ultimately safer and more maintainable, but it shifts responsibility to administrators and GIS teams to modernize their expressions and automation. The path is well defined—Esri and Microsoft provide conversion guidance and lifecycle timelines—so the prudent response is to plan, prioritize, and execute migrations now rather than wait for a hard break when VBScript is removed from future Windows releases. (esri.com, techcommunity.microsoft.com, learn.microsoft.com)
Source: Esri VBScript is Deprecated in ArcGIS