Azure Computer Vision APIs 1.0–3.1 Fail September 13, 2026

Microsoft will retire Azure Computer Vision API versions 1.0 through 3.1 on September 13, 2026, and calls to those versions will fail after that date. Most affected workloads should evaluate the generally available Computer Vision 3.2 API first; choose the 2023-10-01 Image Analysis REST implementation or direct preview REST only when verified feature requirements justify the additional contract and lifecycle risk.

Why the Azure resource name will not identify the risk​

The retirement applies to the API version requested by an application, not simply to the Vision or Cognitive Services resource displayed in Azure. A current resource can still receive calls from an old application that explicitly requests a retiring API version.
Microsoft lists five affected versions:

• Computer Vision API v1.0
• Computer Vision API v2.0
• Computer Vision API v2.1
• Computer Vision API v3.0
• Computer Vision API v3.1

This makes endpoint and caller discovery the immediate task. Teams must locate every application, service, script, scheduled job, integration, and packaged client that sends Computer Vision requests. An Azure resource inventory alone cannot prove that consuming code is safe.
That dependency-first approach reflects a recurring lesson in WindowsForum’s Azure retirement coverage. Reports on Azure API for FHIR emphasized endpoint discovery before database migration, while the Azure AI Document Intelligence guide distinguished the affected cloud API and container instead of treating every v2.x workload as identical. The same precision is required here: identify the caller, requested version, operation, and expected response contract.

Choose the target before changing code​

Use this compact matrix to classify each caller:

Workload or target	Supported decision
Computer Vision API versions 1.0, 2.0, 2.1, 3.0, or 3.1	Evaluate the generally available Computer Vision 3.2 API first; Microsoft recommends 3.2 for affected customers
Current Image Analysis SDK	It calls the generally available 2023-10-01 Computer Vision REST API
Custom-model analysis or segmentation requirement	Direct 2023-04-01-preview REST calls may be required; record this as a preview dependency
Image Analysis 4.0	Account for its scheduled retirement on September 25, 2028

Computer Vision 3.2 is generally the lower-risk choice when the objective is to remove the 2026 retirement dependency without redesigning the application. The newer REST implementation is an architectural choice, not an automatic replacement for every legacy caller.

Inventory legacy Computer Vision calls​

Do not globally replace version strings before establishing what each caller does.

1. Check Azure Advisor without assuming it has found the dependency.
   In the Azure portal, go to Advisor > Reliability > Service Upgrade and Retirement. Select the relevant subscription scope, review available recommendations, and verify whether a recommendation for the affected service or resource actually exists. The retirement-recommendation area is useful evidence, but the absence of a recommendation does not prove that no application calls an old API.
2. Export potentially relevant Azure resources.
   Record the subscription, resource group, resource name, region, environment, owner, endpoint, and associated business application for each Vision or Cognitive Services resource.
3. Search source code and configuration.
   Search repositories, deployment templates, pipeline variables, configuration stores, and scripts for:
   • /vision/v1.0/
   • /vision/v2.0/
   • /vision/v2.1/
   • /vision/v3.0/
   • /vision/v3.1/
   • api-version=
   • Computer Vision endpoint hostnames
   • Vision subscription-key references
   • Computer Vision client construction
   • Relevant SDK and package references
4. Inspect compiled and externally maintained applications.
   A vendor tool, desktop utility, Windows service, or line-of-business application may store only the resource endpoint and credential while selecting the API version internally. Ask its maintainer to identify the exact REST version, operation, and SDK or package version.
5. Inspect operational traffic.
   Use available application, proxy, gateway, and diagnostic logs to identify request paths and active callers. This can uncover test utilities, old automation hosts, or scheduled tasks that are absent from expected repositories.
6. Document each operation.
   Do not record only “Computer Vision.” Identify whether the caller performs image analysis, object detection, tagging, OCR, custom-model analysis, segmentation, or another operation.
7. Capture the consumed contract.
   Record the status codes, headers, JSON properties, arrays, coordinates, confidence values, operation identifiers, and asynchronous behavior on which the application depends.
8. Assign a target and owner.
   Every caller needs a named owner, selected target, test evidence, cutover date, and rollback plan.

WindowsForum’s Azure Anomaly Detector retirement report recommended a similar dependency register built from Advisor evidence, candidate resources, endpoint searches, and credential references. Its value is operational: it turns a broad service announcement into a list of accountable callers. The Azure AD Graph retirement guide likewise treated the deadline as a fixed endpoint for developers and IT teams rather than a warning that could be deferred indefinitely.

Use this caller-register template​

Create one row per independently deployable caller. Duplicate rows when the same application uses different operations, versions, or targets.

Application	Owner	Endpoint/API version	Operation	SDK/package version	Consumed response fields	Target	Preview dependency	Test evidence	Cutover date
Example: image-processing service	Team or person	Current endpoint and exact version	Exact business operation	Package name and pinned version, or direct REST	Required properties, headers, identifiers, and error fields	3.2, 2023-10-01, or approved preview	Yes/No, with justification	Test run, comparison, and approval location	Planned/actual date

Keep unknown values visible rather than guessing. “Vendor confirmation pending” or “traffic capture required” is more actionable than a blank field.

When Computer Vision 3.2 is the safer choice​

Computer Vision 3.2 is the default candidate when a workload already uses a retiring Computer Vision API and does not require capabilities that force a different implementation. Microsoft recommends the generally available 3.2 API for affected customers.
Choose 3.2 first when:

• The goal is to remove the September 13, 2026 dependency with minimal redesign.
• The required operation has a documented 3.2 equivalent.
• Downstream systems depend closely on the existing response structure.
• The current client can be updated without adopting a different programming model.
• The team requires a generally available target and has no verified preview-only requirement.

Do not assume that changing a version value is sufficient. Contract testing remains necessary when code parses OCR results, uses optional parameters, pins an SDK package, polls asynchronous work, or deserializes results into rigid models.
Treat 3.2 as a controlled compatibility migration, not an exemption from future lifecycle planning. Record the exact deployed dependency and continue monitoring Microsoft’s lifecycle guidance.

When 2023-10-01 makes more sense​

The current Image Analysis SDK calls the generally available Computer Vision REST API version 2023-10-01. Consider this route when the team has deliberately selected the newer Image Analysis contract and verified that it supports the required workload.
Choose 2023-10-01 when:

• The application is already undergoing redesign rather than a minimal retirement patch.
• Every required operation is supported by the generally available REST version.
• Developers can update request construction, serialization, result handling, and tests as necessary.
• The team can compare output against representative production images.
• The resulting API version is recorded explicitly in the dependency register.

Avoid project descriptions that say only “upgrade to version 4.” Product labels, SDK generations, and REST identifiers are not interchangeable. Recording 2023-10-01 makes the actual deployed dependency auditable.

Handle custom models and segmentation separately​

Custom-model analysis or segmentation requirements may require direct calls to the 2023-04-01-preview REST API rather than the current SDK’s generally available 2023-10-01 implementation. Confirm the required capability against Microsoft’s current operation-level documentation before selecting the target.
A preview dependency must be recorded separately from a GA migration. Give it an owner, justification, test plan, monitoring plan, and replacement trigger. Do not conceal it behind a generic task such as “move to the new SDK.”
Also include the September 25, 2028 retirement of Image Analysis 4.0 in the architecture decision. Moving from an API that retires in 2026 can resolve the immediate outage risk while creating another planned migration within the application’s expected operating life. That does not automatically rule out the newer implementation, but it does rule out treating it as a universally permanent destination.

Verify the migration end to end​

A successful HTTP response is not sufficient evidence that the application still works.

1. Build a representative image set.
   Include production formats, resolutions, languages, orientations, content types, and image-delivery methods.
2. Capture baseline results.
   Protect credentials and sensitive images, but retain enough request and response data to compare behavior.
3. Run identical inputs against each candidate.
   Test 3.2 and 2023-10-01 separately if both remain under consideration. Test preview REST separately when required.
4. Compare contracts and behavior.
   Check property names, missing or null values, arrays, coordinates, confidence values, headers, errors, and asynchronous handling—not only visual accuracy.
5. Exercise failure paths.
   Test invalid images, unsupported media, inaccessible image locations, authentication failures, timeouts, and throttling according to the application’s test policy.
6. Test downstream consumers.
   Confirm that databases, queues, search indexes, user interfaces, exports, and automation accept the new results.
7. Deploy to nonproduction.
   Keep target configuration separate so testing does not overwrite the known production path.
8. Perform a controlled production cutover.
   Monitor errors and result quality, save test evidence in the register, and retain the previous deployment artifact until verification is complete.

Do not remove old configuration or fallback packages before production verification. Rollback to versions 1.0 through 3.1 remains useful only before September 13, 2026; after retirement, reverting code to those versions will not restore service.

Troubleshooting incomplete inventories​

• Advisor shows no recommendation: Continue source, configuration, vendor, and traffic searches. Lack of a visible recommendation is not proof of safety.
• The endpoint contains no obvious version: Inspect the SDK/package version, generated client, request logs, or vendor documentation.
• A request succeeds but the application fails: Compare response fields, null handling, coordinates, identifiers, and polling behavior.
• Only the primary repository is clean: Search Windows services, scheduled tasks, test tools, deployment variables, and third-party applications.
• The preferred SDK lacks a required capability: Reassess 3.2 or document a justified direct-preview REST dependency.
• No owner can be identified: Escalate the caller as an operational risk instead of marking it complete.

This mirrors another lesson from WindowsForum’s cloud-lifecycle reporting: retirement scope must be tied to the actual dependency. The Reserved VM Instance cutoff report distinguished affected legacy SKU purchasing and renewal rules, just as this migration must distinguish an Azure resource from the API version called by its consumers.

Frequently Asked Questions​

Will the Azure Computer Vision resource disappear on September 13, 2026?​

The stated impact is that calls to API versions 1.0, 2.0, 2.1, 3.0, and 3.1 will fail. Determine exposure from application requests, not from the resource name alone.

Is Computer Vision 3.2 the recommended replacement?​

Yes. Microsoft recommends the generally available Computer Vision 3.2 API for affected customers. It is usually the first target to evaluate when equivalent operations meet the workload’s needs.

Does the current Image Analysis SDK use a preview API?​

No. It calls the generally available 2023-10-01 REST API. Custom-model analysis or segmentation may require direct 2023-04-01-preview REST calls.

Should teams move directly to Image Analysis 4.0?​

Only after validating required operations, contracts, preview exposure, and the September 25, 2028 retirement risk. For many legacy callers, Computer Vision 3.2 remains the more controlled first migration.

---

References​

1. Primary source: learn.microsoft.com
   
   

   What's new in Azure Vision in Foundry Tools? - Foundry Tools | Microsoft Learn

   Stay up to date on recent releases and updates to Azure Vision in Foundry Tools.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure AD Graph API Retirement: Essential Migration Guide for 2025 | Windows Forum

   Microsoft’s looming retirement of the Azure AD Graph API is no longer a warning on the horizon—it’s now a fixed endpoint for IT departments, software...

   windowsforum.com

 

[ChatGPT]

Windows teams still running Computer Vision API v1.0 through v3.1 should treat September 13, 2026 as an application outage deadline, not a routine Azure housekeeping date: Microsoft says calls to those retired versions will fail after that day. The lowest-risk response is to move feature-compatible workflows to v3.2 now, but organizations with time to redesign should assess a task-specific move to Image Analysis 4.0 because Microsoft’s current migration guidance also schedules both v3.2 and v4.0 Image Analysis deployments for retirement on September 25, 2028.
Microsoft’s retirement notice makes the immediate scope clear: Computer Vision API v1.0, v2.0, v2.1, v3.0, and v3.1 are all in the shutdown group. The important operational detail is not whether a Windows application uses an old SDK package, a hand-written REST request, or a PowerShell wrapper. If its production call lands on one of those retired API versions, it becomes a failed call after the cutoff.
That puts Windows automation owners in a familiar but uncomfortable position. A legacy WinForms utility scanning incoming images to a network share, an IIS-hosted workflow, an unattended scheduled task, and an Azure-hosted line-of-business service may all share the same dependency while living under different owners, repositories, and deployment processes.

Find the hidden callers before choosing a destination​

Azure Advisor should be the first inventory pass, not the last. Microsoft says its Service Upgrade and Retirement recommendations can identify impacted Cognitive Service resources; in the Azure portal, go to Azure Advisor > Recommendations > Reliability, add the Recommendation Subcategory filter, choose Service Upgrade and Retirement, and inspect the retirement date, retiring feature, and impacted resources shown in each recommendation.
That resource-level view is valuable because it can establish which Azure Cognitive Services resources are involved. But it cannot prove that every Windows executable, scheduled task, or private integration has been updated. Advisor coverage is a discovery aid, and Microsoft notes that impacted-resource data is not comprehensive for every retirement recommendation. Treat it as the service inventory, then conduct an application inventory alongside it.
Start with these four checks, recording the owning team, executable or repository, Azure resource, region, auth method, business function, and migration choice for every result:

1. Search source control for version strings associated with the retiring API family, legacy Computer Vision client construction, endpoint configuration values, and direct HTTP requests. Include C#, PowerShell, Python, JavaScript, batch-driven curl calls, configuration files, deployment templates, and CI/CD variable definitions.
2. Search Windows servers and virtual desktops for configuration files and environment variables used by desktop automation. Old endpoints can persist in .config, JSON settings, registry values, encrypted credential stores, Task Scheduler arguments, and application-specific databases even after a repository has been modernized.
3. Audit Task Scheduler on automation hosts. Review both task actions and the scripts or executables they launch; image intake jobs frequently run under service accounts outside normal interactive testing and may only surface when the next overnight batch fails.
4. Trace the actual request path from a representative workload. Log the configured endpoint, API version, response status, and feature output in a nonproduction run. A code search finds likely dependencies; an observed request confirms the version that is truly in use.

The distinction matters because old endpoints often survive through configuration. A maintained application binary can still be directed to a retired version by a forgotten environment-specific setting, while a supposedly obsolete script may be processing the highest-value document queue in the business.
WindowsForum’s earlier coverage of the September shutdown correctly frames the immediate failure risk. The more difficult follow-through is assigning every discovered caller to either a continuity migration or a functional redesign before the September deadline arrives.

---

Choose v3.2 when preserving the current response matters most​

Computer Vision/Image Analysis v3.2 is Microsoft’s broad compatibility route for workloads built around the older feature family. Its listed capabilities include tags, objects, descriptions, brands, faces, image type, color, landmarks, celebrities, adult-content analysis, and smart cropping.
That makes v3.2 the practical bridge when a Windows workflow has downstream code that expects those outputs. Consider a document-routing utility that uses tags and descriptions, a moderation queue that needs adult-content analysis, or a photo cataloging tool that depends on color, landmark, celebrity, or brand metadata. Rebuilding that logic against a substantially different response model under deadline pressure is usually a higher-risk project than first restoring service through the closest available feature set.
The migration still needs testing. “Compatible” should mean the workflow delivers its required business outcome, not merely that an HTTP request returns success. Existing parsers can make silent assumptions about optional fields, array contents, confidence thresholds, image orientation, or the availability of a particular category. Run a controlled corpus of images through the existing implementation and v3.2, then compare the fields the application actually consumes.
For administrators, the v3.2 path is also easier to contain operationally. Preserve the current workflow, point a nonproduction instance at the supported deployment, validate the result contract, update secrets and endpoint configuration through the normal release process, and retain a deployment rollback to the prior application build. Do not confuse that rollback with a service rollback: after September 13, returning the endpoint setting to v1–v3.1 will not restore the retired service.

Treat Image Analysis 4.0 as a redesign decision, not a version bump​

Image Analysis 4.0 offers Read, captions, dense captions, tags, object detection, people detection, and smart cropping. That is a useful modern set for workloads focused on extracting text, describing scenes, locating objects, detecting people, or generating crops. It is not a feature-for-feature substitute for the v3.2 capability set.
The most consequential gap is that a 4.0 workload should not assume a replacement for every legacy output. Microsoft’s listed 4.0 features do not include faces, brands, image type, color, landmarks, celebrities, or adult-content analysis. “People detection” is also not interchangeable with face analysis: one identifies people as image subjects, while the legacy face-oriented requirement may involve a different data need entirely.
Descriptions and captions deserve their own review. V3.2 supports descriptions; 4.0 supports captions and dense captions, but output structure and application expectations may differ. Microsoft also notes that some caption capabilities are limited by region. A Windows service deployed in one Azure region may therefore not be portable simply by changing its endpoint configuration.
Choose 4.0 now when the workload’s real objective maps cleanly to its listed capabilities and the team can update its response handling, rules, tests, and operational documentation. A mailroom workflow that primarily needs OCR and scene or object information may be a good candidate. A product image pipeline that requires brand, landmark, celebrity, color, or adult-content signals should not be moved to 4.0 on the assumption that similarly named concepts will appear elsewhere.
This is where the 2028 date changes the planning conversation. Microsoft’s Image Analysis migration documentation says Image Analysis API deployments, including supported v3.2 and v4.0, retire on September 25, 2028. A v3.2 migration can therefore be the right resilience decision for 2026 while still being explicitly treated as a bridge with a second modernization milestone.

---

Test the contract, the identity, the region, and the bill​

A proper migration test should begin with production-like image samples, including low-quality scans, unusually large images, documents with sensitive content, and the categories that trigger downstream branching. Store representative responses from the existing implementation where possible, then compare only the fields that determine routing, approval, storage, alerts, or user-visible output.
Authentication deserves the same discipline. Confirm how the Windows workload obtains its credential, where it is stored, which identity or key is valid for the target resource, and whether the account running the scheduled task has access after the endpoint is changed. A test run launched from an administrator’s desktop does not validate a task running under a service identity at 2 a.m.
Regional validation is equally important. Confirm that the selected service region supports the capabilities the application needs, particularly if it relies on captions. Avoid a cutover plan that changes both the API generation and the geography at once unless there is no alternative; combining those changes makes an output difference harder to explain.
Finally, rerun representative volume through the proposed destination and inspect the resulting usage and cost before production cutover. Microsoft’s retirement guidance establishes the date and replacement paths, but it does not guarantee that an existing workload’s request pattern, selected features, or usage profile will behave identically after migration. Budget and capacity testing are part of the decision, not post-migration cleanup.

Frequently Asked Questions​

Do v1–v3.1 calls degrade gradually after September 13, 2026?​

No. Microsoft says calls to Computer Vision API v1.0, v2.0, v2.1, v3.0, and v3.1 will fail after September 13, 2026. Plan for a hard service dependency failure.

Is v3.2 the correct replacement for every legacy application?​

No. It is the broadest compatibility option for legacy features, but Microsoft also lists v3.2 for retirement on September 25, 2028. Use it when continuity and existing feature coverage outweigh the value of an immediate redesign.

Can Image Analysis 4.0 replace face, brand, celebrity, landmark, color, and adult-content workflows?​

Not based on Microsoft’s listed 4.0 feature set. Those workloads need a separate design review rather than a presumed API-version upgrade.

Is Azure Advisor enough to find every affected Windows workload?​

No. Azure Advisor can surface impacted Cognitive Service resources, but application-side searches, Task Scheduler reviews, endpoint tracing, and configuration audits are still required to identify every caller.
The immediate milestone is September 13, 2026, when legacy Computer Vision API calls stop working. The strategic milestone is September 25, 2028, which means every v3.2 migration should include an owner, a documented feature dependency list, and a funded plan for what replaces that bridge before it becomes the next retirement emergency.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Use Service Upgrade and Retirement recommendations - Azure Advisor | Microsoft Learn

   Use recommendations for retirement and upgrade of a service

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Computer Vision APIs 1.0–3.1 Fail September 13, 2026 | Windows Forum

   Microsoft will retire Azure Computer Vision API versions 1.0 through 3.1 on September 13, 2026, and calls to those versions will fail after that date. Most...

   windowsforum.com