Microsoft will stop accepting calls to Azure Computer Vision API versions 1.0 through 3.1 after September 13, 2026. Not “end of support” — the calls will simply fail. Any application, script, or workflow still hitting those endpoints after that date will break, regardless of whether the underlying Azure resource appears healthy. The clock is ticking for every team that relies on the older Analyze Image service.

The retirement covers Computer Vision API v1.0, v2.0, v2.1, v3.0, and v3.1, according to a Microsoft Learn advisory. The recommended replacement is the generally available Computer Vision 3.2 API, which preserves the established Analyze Image model, feature set, and JSON response structure. However, there is a newer, flashier alternative — Image Analysis 4.0 — that comes with its own contract changes and a separate lifecycle clock. Choosing the right path now can mean the difference between a controlled migration and a scramble.

The retiring versions and the hard deadline

Five specific API versions are going dark on September 13, 2026:

  • v1.0
  • v2.0
  • v2.1
  • v3.0
  • v3.1

This is not a standard deprecation where old calls might keep working. Microsoft states that calls to these versions will fail after the cutoff. That means a Computer Vision resource could show green in the Azure portal while your application silently errors out.

Version references often hide in unexpected places: configuration files, reusable libraries, API Management policies, desktop utilities, background services, test harnesses, Power Automate flows, Logic Apps, and infrastructure-as-code templates. Azure Advisor does surface a “Service Upgrade and Retirement” recommendation that identifies impacted resources, but it cannot detect hard‑coded URLs inside your source code or third‑party packages. You have to go hunting.

What this really means for you

If you maintain anything that calls a Computer Vision endpoint, the retirement forces a concrete set of actions. Here’s how different groups are affected:

For application developers and architects — Any code that constructs a request to a /vision/vX.X/analyze endpoint (or uses an SDK that binds to those versions) must be updated. A quick test of a single image will not guarantee safety; production workloads vary in feature usage, error handling, and downstream consumption of response fields. Even if you think your code is on a newer SDK, verify the actual HTTP request path. A wrapper library may still be targeting an older version.

For IT and platform administrators — API gateways, private endpoints, and firewall rules may be silently routing traffic to deprecated backends. A gateway might transform a modern-looking request into a retired version that nobody monitors. Logs, cost dashboards, and availability metrics will not show the version discrepancy; they’ll only show a successful call until the day it fails.

For low‑code and automation owners — Power Automate flows, Logic Apps, and scheduled tasks rarely appear in source‑code scans. Yet they often contain hard‑coded endpoint URLs. The retirement applies equally to them. If a critical business process depends on an image‑analysis step, a post‑September‑13 outage could be hard to triage because the flow itself might still run, only to fail at the API call.

For teams managing integration partners — If you expose a Computer Vision‑powered API to external consumers, the retirement is also their problem. Their code may be calling your service through an older contract. Strictly speaking, the retirement only affects direct Azure API consumers, but any intermediary that shapes its own calls based on the same version strings is also vulnerable.

How we arrived at this point

Azure AI services have been continuously evolving. The computer vision stack split into two main branches: the original Analyze Image API (with a flat feature‑selection model) and the newer Image Analysis service, which debuted version 4.0 with a redesigned API and SDK contract. The older v1.x through v3.1 versions belong to the original lineage, and Microsoft has been nudging customers forward for years. Version 3.2 was released as a compatibility bridge that keeps the same operations and response shapes, making it the least‑disruptive upgrade path.

Image Analysis 4.0, meanwhile, was introduced with more modern capabilities — dense captions, people detection, smart crops, improved read, and so on — but it also changed how features are requested and how responses are structured. It runs on a different route and API‑version model. In a surprising twist, Microsoft’s own documentation now labels Image Analysis 4.0 as deprecated, with a retirement date of September 25, 2028. That means choosing 4.0 today is not merely a compatibility decision; it’s a strategic architectural move that comes with a second migration deadline down the road.

The two migration paths: a practical comparison

Computer Vision 3.2 — the compatibility play

The core REST endpoint for v3.2 is {endpoint}/vision/v3.2/analyze. It uses the same query‑parameter‑based feature selection (visualFeatures) and returns the familiar JSON structure with top‑level keys like categories, tags, objects, faces, adult, color, and description. For most workloads that existing code consumes, this is a version‑string change.

Choose v3.2 when:
- Your code parses a v2.x or v3.x Analyze Image response and downstream systems expect that exact shape.
- Your workload uses the classic feature model and you have no tested reason to change it.
- You need the lowest‑effort retirement migration, with minimal coordinated changes across applications, dashboards, and data pipelines.
- You maintain SDK‑based code that is difficult to rewrite, such as a Windows service, a desktop line‑of‑business app, or a shared internal library.

Remember: even a version‑string change requires thorough testing. Authentication, error codes, timeout behavior, and rate‑limit handling might differ slightly. The migration is low‑risk, but not zero‑effort.

Image Analysis 4.0 — the deliberate redesign

Image Analysis 4.0 is not a drop‑in replacement. Its REST request shape and API versioning differ from v3.2. The SDK contract has been rewritten, meaning that code using the old ComputerVisionClient will not simply compile against the new packages. Feature names, response objects, and even availability of certain capabilities may have changed. For example, some features that were previously part of the Analyze API are now only accessible through direct REST calls or alternate Azure services in the 4.0 family.

Consider 4.0 only after you:
- Identify every feature your application consumes and verify its 4.0 equivalent.
- Test not just a single successful call but the full range of inputs — including invalid images, large payloads, and edge cases.
- Account for the 2028 retirement date. If you adopt 4.0 today, you are committing to another migration within roughly two years.

For most legacy workloads, 4.0 is overkill. It is appropriate only when your application genuinely requires the new capabilities and you have the resources to manage the implementation differences and the future lifecycle.

What to do right now

1. Build a dependency register

Create a spreadsheet or a lightweight database with one row per consumer. Do not lump everything under “Computer Vision.” For each consumer, record:
- Application or workflow owner
- Azure subscription and resource details
- Environment (production, test, development)
- Current API version and full request path
- SDK name and version, if applicable
- Features requested and query parameters
- Input type (public URL, binary upload)
- Response fields consumed by the application
- Retry, timeout, and error‑handling behavior
- API Management, proxy, firewall, or private‑endpoint dependencies
- Proposed migration target (3.2 or 4.0)
- Test evidence, approval, and deployment date

Start with Azure Advisor to see impacted resources, then move to repository scans.

2. Scan your code and configuration

On Windows, you can run a PowerShell search from the root of each source or infrastructure repository:

Get-ChildItem -Recurse -File |
  Select-String -Pattern '/vision/v1\.0/','/vision/v2\.0/','/vision/v2\.1/','/vision/v3\.0/','/vision/v3\.1/','computerVision','ComputerVisionClient'

Extend the scan to:
- App Service, Function, container, and VM configuration files
- Azure API Management policies and backend definitions
- ARM, Bicep, or Terraform templates
- Power Automate, Logic Apps, and scheduled‑job definitions
- Shared SDK wrappers and internal NuGet packages
- Environment‑variable templates and secret‑reference names
- Build and release scripts

A critical warning: do not bulk‑replace version strings across repositories. A versioned URL may be embedded in a gateway rule while the application’s SDK and response parser require an independent change. Bulk replacement can create partial, hard‑to‑diagnose migrations.

3. Run a feature‑parity test, not just a connectivity test

For each dependency‑register row, collect a small set of representative images: normal cases, images with text (if OCR is involved), images that should trigger adult‑content detection, and inputs that typically cause failures. Then:

  • Capture the current contract. Save the existing request parameters, HTTP status, relevant headers, and a sanitized response body from the retiring version while it still works.
  • Create a v3.2 test call. Point a non‑production configuration to /vision/v3.2/analyze and request only the features the application actually consumes. Confirm the expected success response and that errors are handled.
  • Compare consumed fields, not whole JSON documents. Identify every value the application reads — captions, tags, object coordinates, OCR text, confidence values, metadata — and verify type, presence, and business meaning with the application owner.
  • Test failures deliberately. Use an invalid image URL, unsupported input, and an inaccessible remote image. Confirm that retry handlers do not loop forever and that error logging clearly identifies the target endpoint and version.
  • Run the real downstream workflow. A 200 OK from the API is insufficient if a database import, Windows service, report, or Power Automate flow rejects a slightly changed field.

If evaluating Image Analysis 4.0, repeat from the business requirement. Map every old feature and consumed field to the new API or an alternate service. Mark anything without a verified replacement as a blocker.

4. Cut over with a reversible configuration change

The safest deployment pattern is to make the endpoint version configurable, not hard‑coded.

  • Add a dedicated configuration setting (app setting, environment variable, parameter) for the Computer Vision base endpoint or request path in each environment.
  • Deploy code that can use the new setting while retaining the current production value.
  • Route a non‑production environment to v3.2 and complete the parity tests.
  • During a monitored change window, flip the production configuration to v3.2.
  • Monitor application logs, gateway telemetry, workflow runs, and downstream processing for request failures or parsing errors.
  • Keep the prior configuration value available for immediate rollback until acceptance testing is complete.

Rollback is useful only before September 13, 2026. After that date, reverting to v1.0–v3.1 will not restore service.

5. Avoid these common traps

  • “The Azure resource is healthy, so the app is fine.” Resource availability does not override a retired request path.
  • “Our SDK abstracts the version.” SDK package references, client construction, generated code, and wrappers can still bind your application to older operations.
  • “API Management will handle it.” A gateway may preserve an old backend path or transform requests in ways you never see.
  • “A 200 response proves parity.” It proves connectivity. It does not prove that a caption, tag, OCR result, coordinate, confidence value, or error behavior remains suitable for your business process.
  • “We can wait until mid‑2026.” The deadline is firm. Testing, validation, and coordinated cutover across multiple teams takes weeks or months. Start now.

Outlook

The September 13, 2026 cutoff is just one piece of a broader Azure AI lifecycle refresh. Document Intelligence workloads have their own looming retirements, and the Image Analysis 4.0 deprecation date (September 25, 2028) means that any team choosing 4.0 today must plan for a second migration within roughly two years. The dependency‑register discipline you build for the Computer Vision retirement will serve you well for other Azure AI services. Now is the time to inventory, test, and cut over — while the old APIs still answer.