Microsoft will end support for Computer Vision API versions 1.0, 2.0, 2.1, 3.0, and 3.1 on September 13, 2026 — and unlike previous transitions, this isn’t a gradual deprecation. After that date, API calls will simply fail. That hard stop means every Windows tool, script, and automated workflow that relies on these legacy endpoints needs a rewrite or replacement before the deadline.

What’s Shutting Down — and Why It’s Urgent

The retirement covers the entire pre‑v3.2 Computer Vision API family. It doesn’t matter whether your application uses an old SDK, a hand‑crafted REST request, or a PowerShell wrapper — if the endpoint targets version 1.0, 2.0, 2.1, 3.0, or 3.1, the call will stop working on September 13, 2026. Microsoft’s retirement advisory, surfaced in Azure Advisor’s Service Upgrade and Retirement recommendations, lists the affected service as “Cognitive Service Computer Vision API v1.0, v2.0, v2.1, v3.0. v3.1” with a hard cutoff date.

The company has also flagged that Image Analysis API deployments — specifically versions 3.2 and 4.0 — will retire on September 25, 2028. That creates two deadlines: one imminent, and one that transforms today’s migration into a two‑stage journey.

The Real Risk: Your Unknown Callers

Many Windows‑based automation pipelines hide their API dependencies far from a central inventory. A legacy WinForms utility scanning images on a network share, an IIS‑hosted workflow, a scheduled task that runs nightly under a service account, or an Azure Function may all call the same old Computer Vision endpoint while living under different owners, repositories, and deployment processes.

This fragmentation makes it easy to overlook callers. The outage won’t be gradual — a job that worked on September 12 will throw errors the next morning. For IT admins and developers who manage unattended workloads, the impact could hit document routing, content moderation, photo cataloging, or invoice processing without warning.

Finding Where Your Apps Still Call the Old API

Azure Advisor is the first stop, not the last. In the portal, go to Advisor > Recommendations > Reliability, add the Recommendation Subcategory filter, and select Service Upgrade and Retirement. The recommendations list impacted Cognitive Services resources, providing a resource‑level view of what’s affected.

But that only shows which resources are involved — not which executables, scripts, or scheduled tasks consume them. Microsoft warns that impacted‑resource data is not exhaustive for every retirement recommendation. Treat Advisor as the service inventory; you still need an application‑level sweep.

Home in on these four areas:

  • Source control and codebases: Search for version strings like “v2.0”, “v2.1”, “v3.0”, or “v3.1” in C#, Python, PowerShell, JavaScript, batch files, CI/CD definitions, and deployment templates. Look for client construction calls, endpoint URLs containing the version, or direct HTTP references.
  • Configuration files and environment variables: Old endpoints often survive in .config files, JSON settings, registry keys, encrypted credential stores, Task Scheduler arguments, or application databases — even after the main repository is modernized.
  • Task Scheduler audits: Inspect both task actions and the scripts or executables they launch. Image‑processing jobs frequently run outside normal interactive testing and may only surface when the overnight batch fails.
  • Live request traces: In a non‑production run, log the actual endpoint, API version, and response status for a representative workload. A code search finds likely dependencies; an observed request confirms the version truly in use.

Record the owning team, executable or repository, Azure resource, region, authentication method, business function, and migration target for every discovered instance. The distinction matters: a maintained binary may still be directed to a retired version by a forgotten environment setting, while a supposedly obsolete script might be processing the highest‑value document queue in the business.

Choosing a Migration Destination: The Bridge vs. the Redesign

Microsoft offers two replacement destinations, each with a very different profile.

Image Analysis v3.2 — the broad compatibility bridge. Its feature list includes tags, objects, descriptions, brands, faces, image type, color, landmarks, celebrities, adult‑content analysis, and smart cropping. If your Windows workflow consumes outputs like color metadata, celebrity recognition, or brand detection, v3.2 is the most direct migration path. It preserves the response contract as closely as possible, minimizing code changes when the clock is ticking.

What v3.2 won’t do is buy you permanent peace. It retires on September 25, 2028, making it a bridge — not a final destination. That’s acceptable for teams who need to restore service quickly and plan a redesign later, but don’t treat it as the endpoint.

Image Analysis 4.0 — a forward‑looking but narrower option. This version serves workloads that focus on text extraction (Read), scene captioning, object detection, people detection, and smart cropping. It does not offer faces, brands, image type, color, landmarks, celebrities, or adult‑content analysis. “People detection” in 4.0 identifies people as image subjects — not the same as the face‑analysis data some legacy workflows expect. Caption capabilities also vary by region, so check availability before committing.

Choose 4.0 if your current workload’s objectives map cleanly to its listed features and your team can overhaul response parsing, rules, and tests. A mailroom workflow that needs OCR and object data might be a good fit. A product‑image pipeline that depends on brand, color, or adult‑content signals should not be moved to 4.0 under the assumption that similarly named fields will appear elsewhere.

Testing the Upgrade Without Breaking the Business

Migration testing must go beyond a simple “did it return 200 OK?”. Existing parsers often make silent assumptions about optional fields, confidence thresholds, image orientation, or the presence of particular categories. Run a controlled corpus of production‑like images — including low‑quality scans, oversized files, sensitive content, and the edge cases that trigger downstream branching — through both your legacy endpoint and the target version. Compare only the fields your application actually consumes.

Authentication also needs scrutiny. Confirm how the workload obtains its credential, where it is stored, which identity or key is valid for the target resource, and that the service account under which a scheduled task runs still has access after the endpoint change. A quick test from an administrator’s desktop does not validate a 2 a.m. task running under a managed identity.

Region matters. Verify that the chosen service region supports all the features your application needs, particularly if captions are involved. Avoid a cutover that changes both the API generation and the geography at the same time; combining those variables makes it far harder to explain any output differences.

Finally, run representative volume through the proposed destination and inspect the resulting usage and cost before production cutover. Microsoft’s guidance provides the deadline and the migration paths, but it does not guarantee that existing request patterns, selected features, or consumption will behave identically after the move.

The 2028 Countdown Has Already Started

Every migration to v3.2 should be recorded with an owner, a documented feature dependency list, and a funded plan for what replaces that bridge before September 25, 2028. The immediate focus is preventing an outage in 2026, but treating v3.2 as the final answer only shifts the crisis three years down the road. Image Analysis 4.0 offers a longer runway, but its narrower feature set means a direct jump may require a redesign today.

For Windows administrators and developers, the message is clear: start your inventory now. Find every hidden caller, test the replacement thoroughly, and don’t let a forgotten scheduled task take down a critical business process on September 14, 2026.