Microsoft has set an August 31, 2026, end-of-support date for the Azure AI Document Intelligence v2.0 cloud API and v2.1 container releases. After that date, these services will no longer be available, and any application still using them will break.

The timeline is more nuanced than a single deadline, though. The v2.1 cloud API remains supported until September 15, 2027, while v3.0 retires on March 30, 2029. The current generally available release, v4.0 (REST API version 2024-11-30), has no announced retirement date and is recommended by Microsoft for all new development and migrations.

This article unpacks exactly what is changing, how it affects your organization, and the concrete steps you need to take now to avoid production outages.

Which Versions Are Retiring – and When

The retirement dates are easy to misread because Microsoft’s product naming overlaps. Here’s what you need to know:

  • Azure AI Document Intelligence v2.0 cloud API – End of support: August 31, 2026. This is the classic “Form Recognizer” cloud endpoint.
  • Document Intelligence v2.1 container – Same deadline: August 31, 2026. Containerized deployments of v2.1 must be replaced before this date.
  • Document Intelligence v2.1 cloud API – End of support: September 15, 2027. The cloud-hosted v2.1 API has an extra year.
  • Document Intelligence v3.0 (2022-08-31) – Retires on March 30, 2029.
  • Document Intelligence v3.1 (2023-07-31) and v4.0 (2024-11-30) – No announced end dates; both are generally available.

Microsoft’s own documentation confirms these dates and urges developers to “use Azure Document Intelligence 2024-11-30 v4.0 for all new development” and migrate existing workloads to v4.0 before the relevant retirement dates.

A common mistake is treating every v2.x implementation as though it shares the same deadline. In practice, a service calling the cloud-hosted v2.1 API has until September 2027, while a v2.1 container deployment must be addressed by August 2026. Classify each workload by deployment type and API contract before assigning a target date.

Why This Matters to Your Business

If your organization uses any version of Azure AI Document Intelligence (formerly Form Recognizer), the clock is ticking. The service processes invoices, receipts, identity documents, contracts, and custom forms for thousands of businesses. When an endpoint stops responding, the impact cascades:

  • Automated invoice processing pipelines fail.
  • Customer-facing document uploads return errors.
  • Scheduled batch jobs that extract data from PDFs and images stall.
  • Downstream analytics, search indexes, and RAG (retrieval‑augmented generation) systems stop receiving fresh data.

Even if you think you have no v2.0 traffic, the migration pressure is real. Azure Advisor’s retirement alerts may not flag every caller. Microsoft acknowledges that retirement coverage is not comprehensive, and the “impacted resources” field for the v2.0 retirement is listed as unavailable or pending. A clean Advisor pane does not prove that your organization is safe.

The most dangerous v2.0 caller is unlikely to be the primary application already listed in an Azure migration plan. It’s more likely to be an old PowerShell‑driven workflow, a vendor‑maintained connector, a low‑code integration, or an infrequent batch job whose API version never appeared in an inventory.

How We Got Here: From Form Recognizer to Document Intelligence

Azure AI Document Intelligence started life as “Form Recognizer,” a cognitive service for extracting text, key‑value pairs, and tables from documents. Over time, Microsoft expanded its capabilities and rebranded the service. The version lineage shows steady evolution:

  • v2.0 (classic) – The original cloud API and container, now facing retirement.
  • v2.1 – Introduced incremental improvements and prebuilt models for invoices and receipts.
  • v3.0 (2022-08-31) – A major overhaul with new SDKs, a unified REST API surface, and improved layout and custom neural models.
  • v3.1 (2023-07-31) – Built on v3.0, added features like query fields, barcode extraction, and better language support.
  • v4.0 (2024-11-30) – The current GA release, aligning with Microsoft’s “Content Understanding” strategy and providing the strongest foundation for modern document AI workloads.

Microsoft’s guidance is clear: jump to v4.0. The older you stay, the sooner you face another forced migration.

What to Do Now: A Practical Migration Guide

Step 1: Find Every v2.0 and v2.1 Caller

You cannot fix what you cannot see. Start with an exhaustive inventory.

Search your code repositories, infrastructure‑as‑code manifests, CI/CD variables, runbooks, integration‑platform exports, and secret‑management metadata for:

  • api-version=2.0
  • References to v2.0 or the old “Form Recognizer” name in configuration files
  • api-version=2023-07-31, api-version=2022-08-31, and api-version=2024-11-30 to identify applications that have already moved onto newer contracts

Don’t stop at source code. Inspect environment variables, application settings, API gateway policies, workflow connectors, and low‑code platform configurations. The API version may be injected outside the main repository.

Step 2: Correlate Code with Actual Traffic

Because a single Document Intelligence resource can receive requests from many applications using different API versions, resource ownership doesn’t equal call‑site ownership. Correlate your static inventory with outbound request telemetry. Review application, proxy, gateway, or network logs for the actual API version strings being sent. Group the findings by caller identity, source application, API version, model, and environment.

Also, examine a long enough time window to capture monthly finance runs, quarterly compliance jobs, archival imports, and other low‑frequency processes. Many teams miss the document‑processing scripts that run once a month and then fall silent.

Step 3: Map Both the Submission and the Polling Path

Document processing is asynchronous. An application may submit a document through one component and poll for the result through another. Both stages must be inventoried, along with any queue messages or stored operation locations passed between them.

Step 4: Choose Your Migration Destination

Microsoft recommends v4.0, and for most workloads, that’s the right choice. Moving directly to v4.0 avoids the double‑migration trap: updating to v3.1 now, then repeating the work for v4.0 later.

The current v4.0 SDKs—released in December 2024 for .NET, Java, JavaScript, and Python—target REST API version 2024-11-30 by default. They give you a supported destination aligned with Microsoft’s long‑term roadmap.

Direct‑to‑v4.0 is the stronger move when:

  • Your application can tolerate a coordinated integration release.
  • You can update the API contract, client library, model selection, polling logic, and result normalization in one tested change.
  • You have the engineering capacity to validate downstream consumers end‑to‑end.

When is a v3.1 bridge defensible? Only when your organization must first remove v2.0 response assumptions but cannot safely combine that remediation with a new SDK and broader downstream validation before August 2026. For example, a central platform team that owns the Azure client while multiple business teams own their own result parsers might move the central integration to v3.1 to isolate the immediate retirement risk. However, this approach must come with an explicit exit plan: an owner, a v4.0 migration milestone, test coverage preserved from the first transition, and controls preventing new services from adopting v3.1 merely because it is available.

Remember: the absence of a v3.1 retirement date is not a promise of indefinite support. Microsoft’s published guidance still points migrations and new development toward v4.0.

Step 5: Test Beyond Compilation

A successful build proves very little about an asynchronous document‑processing workflow. Before switching production traffic, run the new v4.0 path in a test environment with documents that cover poor scans, multipage files, empty fields, repeated tables, unexpected layouts, and the largest inputs your workload normally accepts.

Compare normalized business output rather than raw JSON. The goal is to preserve the data contract your application relies on, not to force the new service response into a byte‑for‑byte imitation of v2.0.

Operational testing should include:

  • Authentication failures
  • Throttling scenarios
  • Polling timeouts and abandoned operations
  • Malformed documents
  • Retry behavior

Instrument the new path so you can separate submission failures from polling failures and downstream transformation errors.

Step 6: Plan Your Rollback—and Your Second Migration

Reverting to v2.0 after August 31, 2026, will not be a durable recovery strategy. Your rollback plan should restore the previous application release while routing it through a compatible adapter or retaining the new Azure‑facing integration behind a stable internal contract.

If you chose the v3.1 bridge, schedule the second migration date now. The bridge should never become permanent technical debt.

What to Watch Next

  • v2.1 cloud API retirement (September 2027) – Even if you clear the v2.0 deadline, you still have a v2.1 cloud deadline on the horizon. Classify those workloads now and start planning.
  • v3.0 retirement (March 2029) – This one is further out, but if you have any v3.0 applications, aim to move them directly to v4.0 within the next year rather than waiting until the last minute.
  • Azure Advisor improvements – Microsoft may expand coverage of retirement alerts over time. Monitor the Document Intelligence documentation for updates.
  • Content Understanding convergence – Microsoft is merging Document Intelligence into its broader “Content Understanding” strategy, which adds LLM‑powered analyzers for unstructured content. As that matures, v4.0 will gain capabilities that make it an even more compelling migration target.

The August 2026 deadline is an inventory test as much as a code change. Start now by finding every hidden caller, classifying each workload by deployment type and API contract, and committing to v4.0 as your primary destination—except where a tightly scoped v3.1 bridge truly reduces near‑term risk.