Insights

The document service that retires on Monday

Braintree Insights | 28 August 2026

The document service that retires on Monday

Microsoft’s lifecycle table lists the Azure AI Document Intelligence v2.0 API, and the v2.1 container, retiring on 31 August 2026. That is the first working day after this article publishes. The product’s own What’s new page carries an Important box of retirement dates that names v2.1 in 2027 and v3.0 in 2029, and does not name the version that retires on Monday.

What changed

Microsoft’s lifecycle page Ending Support in 2026, last updated on 19 August 2026, lists two items against a retirement date of 31 August 2026: the Azure AI Document Intelligence (formerly known as Azure Form Recognizer) v2.0 API, and the Azure Document Intelligence v2.1 Container. Microsoft’s guidance for the affected versions is stated on the product’s What’s new page: to avoid production disruption, use Azure Document Intelligence 2024-11-30 v4.0 for all new development, and migrate existing workloads to Azure Document Intelligence 2024-11-30 v4.0 before these retirement dates.

The risk is easy to miss because nothing about this service is visible under its own name. Document Intelligence is almost never something a business bought deliberately; it is the component that reads the invoice, the identity document or the bank statement inside a process somebody built years ago, and the person who built it has frequently moved on. A retirement date lands on the API, not on the workflow, so the calendar entry that matters belongs to a team that may not know the calendar entry exists.

What the term means in plain language

Azure AI Document Intelligence, formerly Azure Form Recognizer, is a managed service that extracts structured fields from unstructured documents. An application sends it a PDF or an image of an invoice, an identity document, a receipt or a bank statement, and the service returns typed fields rather than raw text. It is most often consumed as a REST API from inside another system, which is why organisations rarely refer to it by name. The service has moved through several API generations: v2.0 and v2.1 under the Form Recognizer name, v3.0 and v3.1, and the current v4.0, whose REST API version string is 2024-11-30.

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

Microsoft’s lifecycle table lists the Azure AI Document Intelligence v2.0 API, and the v2.1 container, retiring on 31 August 2026. That is the first working day after this article publishes. The product’s own What’s new page carries an Important box of retirement dates that names v2.1 in 2027 and v3.0 in 2029, and does not name the version that retires on Monday.

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

The decision this forces is not whether to migrate; Microsoft has set the date and the date is Monday. The decision is whether anyone in the organisation currently knows where the service is called from, and that is a different question with a different owner. Two observations are worth holding separately. The first is verifiable: the lifecycle table carries the 31 August date for v2.0, and the Important box on the product’s own What’s new page carries end-of-support dates for v2.1 on 15 September 2027 and for v3.0 on 30 March 2029, without naming v2.0. Its version banner marks v3.0 and v2.1 as retiring and lists no v2.0 entry at all. The second is Braintree’s reading rather than Microsoft’s wording: a team that had bookmarked the product page as the place to watch for lifecycle news would have been reading two dates years away while the nearer one sat on a different page. Neither observation says Microsoft failed to publish the retirement, because it did. What it says is that the page a developer keeps and the page that carries the date are not the same page, and that is worth ten minutes of searching today rather than a support call on Monday.

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 a search rather than with the Azure portal, because the portal shows you where the resource is provisioned and not where it is called from. Search code repositories, Logic App definitions and Power Automate flow exports for the service hostname pattern ending in cognitiveservices.azure.com together with the path segments formrecognizer and documentintelligence, and for the api-version query parameter on those calls. A v2.0 call carries an api-version of 2.0 or a v2.0 path segment; the current release carries 2024-11-30. Where the call is made through a client library rather than raw REST, check the package version instead: Microsoft’s December 2024 GA release notes state that the .NET, Java, JavaScript and Python client libraries target REST API 2024-11-30 (GA) by default, so a current library is already on the supported version and an old pinned library is the thing to look for. Treat the migration as a behaviour change and not only a version change. The field names, the response shape and the model identifiers differ between generations, and custom models trained against an older API generation are the most likely thing to need attention, so re-test extraction against a representative document set rather than against a single sample. One thing this article deliberately does not tell you is what happens mechanically to a v2.0 request after the date, because no Microsoft page consulted for this article states it. Microsoft’s own framing is that migration avoids production disruption, and that is the phrase worth carrying into the conversation rather than a guess about error codes.

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: Whoever owns the integrations rather than the Azure subscription: the application or automation lead responsible for the workflow that reads documents, with the platform owner who holds the Azure AI Services resource.

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 your codebase, your Logic Apps and your Power Automate flows for calls to the Document Intelligence or Form Recognizer endpoint and read the API version in each one. Where a v2.0 call is found, move it to the 2024-11-30 v4.0 release, which the current client libraries already target by default, and re-test the extraction against real documents rather than assuming a version bump is transparent. Keep the search output whether or not it finds anything.

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 dated search results across code repositories, Logic Apps and Power Automate flows showing which integrations call Document Intelligence and at which API version, together with the Azure AI Services resource list showing where the service is provisioned. Where a migration was made, retain the before and after extraction comparison on a representative document set.

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

What exactly retires on 31 August 2026?

Microsoft’s lifecycle page Ending Support in 2026 lists the Azure AI Document Intelligence (formerly known as Azure Form Recognizer) v2.0 API and the Azure Document Intelligence v2.1 Container against that date.

What happens to an application still calling v2.0 on the day?

No Microsoft page consulted for this article states the mechanical behaviour after the retirement date. Microsoft’s guidance is framed as avoiding production disruption by migrating beforehand. Rather than infer a specific failure mode, treat the date as the point after which the version is unsupported and plan on that basis.

Which version should we move to?

Microsoft states that Azure Document Intelligence 2024-11-30 v4.0 should be used for all new development and for migrating existing workloads. The current .NET, Java, JavaScript and Python client libraries target that REST API version by default.

Is v2.1 affected as well?

The container form of v2.1 is listed against the same 31 August 2026 date. The v2.1 REST API is listed separately on the product’s What’s new page as reaching end of support on 15 September 2027.

We do not think we use this service. How do we confirm that?

Check the Azure AI Services resources in each subscription for a Document Intelligence or Form Recognizer resource, and search your code and automation for calls to the endpoint. An absence of provisioned resources is a stronger answer than an absence of recollection, and the search output is worth keeping either way.

Why is this a Friday story rather than a news announcement?

It is a deadline rather than an announcement. The retirement was published well before this week and the reason it earns a slot today is that 31 August is the next working day, so today is the last working day on which anything can be checked.

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.

Related Posts

Microsoft Entra Tenant Governance brings multiple Microsoft tenants...
Microsoft's security round-up published on 27 August 2026...

The cost of delay is rising as AI...