What changed

Microsoft’s lifecycle listing for 2026 records Computer Vision API versions 1.0, 2.0, 2.1, 3.0 and 3.1 reaching end of support on 13 September 2026. That is the near-term deadline and it is the one an application team has to plan against. Versions 3.2 and 4.0 are not in that list, which is why the obvious response is to move onto one of them. The migration documentation is where that response falls apart. Microsoft states that the Image Analysis API will be retired on 25 September 2028, that calls to the service fail after that date, and defines its own scope explicitly as the Computer Vision Image Analysis REST API at the imageanalysis endpoint covering supported versions 3.2 and 4.0. The retirement applies to all deployment types, including cloud APIs, connected containers and disconnected containers, so an on-premises or air-gapped deployment is not exempt.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

Computer Vision is the Azure service that reads information out of images: extracting text through optical character recognition, tagging objects, generating captions, detecting people and producing image embeddings for search. It has shipped in several API versions over the years, and applications typically pin one of them in the endpoint URL. Image Analysis is the name of the newer unified API surface, reached at the imageanalysis endpoint, which brought several of those capabilities into a single call.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Computer Vision API versions 1.0, 2.0, 2.1, 3.0 and 3.1 reach end of support on 13 September 2026. The two versions that survive that date, 3.2 and Image Analysis 4.0, are themselves already announced for retirement in September 2028, and Microsoft’s migration guidance routes off the product rather than to a newer version of it.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

Two retirements are in play and they point in different directions. The September 2026 date forces a move off versions 1.0 to 3.1. The September 2028 date means that moving to 3.2 or 4.0 buys roughly two years and then requires the same work again. That is a genuine choice rather than an obvious error, because a team with a hard deadline in three weeks may legitimately choose the smallest change now and plan the real migration separately. What makes it a decision rather than an accident is doing it knowingly. Microsoft’s own migration guidance does not offer a newer Image Analysis version as the destination. It routes by scenario, off the product: optical character recognition and Read capabilities go to Azure Document Intelligence, which provides support for OCR text in images through its Read model; face scenarios go to the Face API, which Microsoft describes as offering full support for all face scenarios under the Image Analysis API plus recognition scenarios such as person identification; and image embedding scenarios go to models in Microsoft Foundry, with Cohere Embed named for multilingual multimodal embeddings and SigLIP also listed. A single application calling one API can therefore end up with three different destinations, which is why this is an application-architecture decision rather than a platform upgrade. Microsoft’s own preparation checklist for the move is to assess current usage and dependencies, identify the business scenarios and technical requirements, evaluate alternatives on capability, integration, cost and support, plan the model migration steps, test in a staging environment, and update production workflows and retrain stakeholders. That is not three weeks of work, which is precisely why the inventory has to start now even if the migration cannot finish by 13 September.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Start with discovery, because it is cheap and it bounds everything else. Search source, configuration and infrastructure definitions for the Computer Vision endpoint host and for version segments in the request path, and check container image tags and any disconnected container deployments separately, since those do not appear in application source. For each call site, record the API version and the capability being used. Then map capability to destination: text extraction to Document Intelligence and its Read model, face detection or attributes to the Face API, embeddings to a Foundry embedding model. Where a call uses several capabilities in one request, which was one of the reasons Image Analysis 4.0 existed, expect it to split into more than one call against more than one service, and treat that as a design change with its own testing rather than a substitution. Test against production-representative images rather than samples, because OCR accuracy and object detection behaviour differ between engines and the difference shows up on real documents, not clean ones. Keep the before-and-after output for a fixed sample set as the evidence that the migration preserved the result.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The owner of the application that calls the API, with the development lead.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Search the codebase and any container deployments for Computer Vision endpoints and version strings, list which retiring version each call uses, and record what each call is actually for, reading text, detecting faces or generating embeddings, because the replacement differs by scenario.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The list of call sites with their endpoint and API version, the scenario each one serves, and the chosen destination service per scenario with the date the decision was taken.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

Which versions retire on 13 September 2026?

Microsoft’s lifecycle listing for 2026 names Computer Vision API versions 1.0, 2.0, 2.1, 3.0 and 3.1.

Are versions 3.2 and 4.0 affected by that date?

They are not in the 13 September 2026 listing. They are covered by a separate announced retirement of the Image Analysis API on 25 September 2028, which Microsoft’s migration guide scopes explicitly to the imageanalysis endpoint and supported versions 3.2 and 4.0.

So should we move to 4.0 now?

That is a judgement call rather than a rule. It is the smallest change available before the September deadline and it is supported until 2028, but it is a second migration rather than a final destination. Braintree’s recommendation is to take it only as a deliberate, recorded holding position, not as the default.

Where does Microsoft say to go instead?

By scenario. Microsoft’s migration guidance sends OCR and Read capabilities to Azure Document Intelligence, face scenarios to the Face API, and image embedding scenarios to models in Microsoft Foundry, naming Cohere Embed and SigLIP.

Does this affect containers as well as the cloud API?

Yes. Microsoft states the Image Analysis retirement applies to all deployment types, including cloud APIs, connected containers and disconnected containers.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.