On this page · 10 sections
Summary. The Azure AI Document Intelligence v2.0 cloud API and the v2.1 container both reach end of support on August 31, 2026. Microsoft's official retirement notice states that "the Azure AI Document Intelligence v2.0 API will be retired on 31 August 2026," after which those surfaces stop being supported. The target is Azure Document Intelligence v4.0, the 2024-11-30 generally available release. This is not a version bump you can rush the night before: the analyze response renames boundingBox to polygon, endpoints move to a single documentModels operation, custom models trained on preview versions must be retrained, and v4.0 containers do not yet cover every prebuilt model. Two dates soften the picture: the v2.1 cloud REST API runs until September 15, 2027, and the v3.0 REST API until March 30, 2029. Costs are unchanged on v4.0, with the Read model at about $1.50 per 1,000 pages, Layout and prebuilt models near $10, and custom extraction near $30 as of 2026. This checklist covers what breaks, the endpoint and response changes, when to retrain, and the wider Azure retirement wave landing the same month.
The naming is its own trap. Form Recognizer became Document Intelligence, and the SDK package changed from azure-ai-formrecognizer to azure-ai-documentintelligence. Old code that imports the former keeps compiling against a library that targets a retiring API, so a clean build is not proof you are safe.
What is ending, and what has more time
Not every "v2" is on the same clock, and getting this wrong is how teams either panic early or miss the real deadline. Map each deployment to its own line before you plan anything.
| Version | What it is | End of support |
|---|---|---|
| v2.0 cloud API | Classic Form Recognizer cloud endpoint | August 31, 2026 |
| v2.1 container | On-premises or disconnected container | August 31, 2026 |
| v2.1 cloud REST API | Cloud endpoint | September 15, 2027 |
| v3.0 REST API (2022-08-31) | First redesigned GA | March 30, 2029 |
| v4.0 (2024-11-30) | Current GA, migration target | Supported |
The split that matters: a cloud application calling the v2.1 REST API has until September 15, 2027, but a Kubernetes cluster or Docker host running a v2.1 container is named separately on the lifecycle page and ends on August 31, 2026. Inventory cloud calls and container deployments apart, because a single "we use v2.1" answer hides two very different deadlines.
The endpoint and response changes that break code
Starting with v3.0, the REST API was redesigned, and v4.0 continues that shape. Three changes catch existing v2.x code.
First, the analyze response changed. The migration guide is explicit: the boundingBox property is renamed to polygon in every instance. Any parser that reads boundingBox returns nothing on v4.0.
Second, the endpoints moved. v2.0 and v2.1 used per-model paths under /formrecognizer/v2.0 and /formrecognizer/v2.1. v4.0 combines layout, prebuilt, and custom analysis into one documentModels operation addressed by modelId.
| Operation | v2.0 / v2.1 path | v4.0 path |
|---|---|---|
| Layout | /layout/analyze |
/documentModels/prebuilt-layout:analyze |
| Receipt | /prebuilt/receipt/analyze |
/documentModels/prebuilt-receipt:analyze |
| Invoice | /prebuilt/invoice/analyze (v2.1) |
/documentModels/prebuilt-invoice:analyze |
| ID document | /prebuilt/idDocument/analyze (v2.1) |
/documentModels/prebuilt-idDocument:analyze |
| Custom | /custom/{modelId}/analyze |
/documentModels/{modelId}:analyze |
Third, parameters and the result shape changed. The includeTextDetails parameter is no longer supported, and the full output is always returned in a more compact form. The analyze result is refactored so pages, tables, keyValuePairs, styles, and documents are top-level properties rather than nested under pages. The call pattern itself is familiar: submit an analyze request, read the Operation-Location header, then poll the result URL at a minimum one-second interval.
The request body is straightforward in v4.0. Send a URL or base64 content:
{ "urlSource": "https://example.com/invoice.pdf" }
{ "base64Source": "{base64EncodedContent}" }
For code-level changes, Microsoft ships language-specific SDK migration guides on GitHub for the Python SDK, plus .NET, Java, and JavaScript. The common move is replacing azure-ai-formrecognizer with azure-ai-documentintelligence and updating method names and response handling.
Custom models: plan a retrain, not a copy
This is the part teams underestimate. Custom extraction and classification models trained on a preview API version are tied to that preview version's lifecycle and base model. When the preview version retires, those custom models retire with it. Microsoft's guidance is direct: as part of migration, retrain the model using the latest GA API version.
Even on GA, custom models carry an expirationDateTime, because they build on a large base model that Microsoft updates for quality. When a base model is retired, the custom model expires and needs a retrain. Two model-object changes also matter on migration: modelName is now description, and a new buildMode property takes template for custom form models or neural for custom neural models. Neural builds are quota-limited per subscription per region each month, so a big-bang retrain of many models needs scheduling, not a single afternoon.
Costs after you move
Migrating does not change the price list; it changes the API around it. As of 2026 on Azure, the Read model is about $1.50 per 1,000 pages, Layout and prebuilt models such as invoice and receipt about $10 per 1,000 pages, and custom extraction about $30 per 1,000 pages, per the Azure pricing page. Commitment tiers can cut Read toward $0.45 per 1,000 pages at volume, and neural model training is billed at $3 per hour after the first 10 free hours each month. Premium add-ons (high-resolution OCR, formulas, font styles) carry extra cost, so a v4.0 move is a good moment to check whether add-ons requested by default are actually used.
This is part of a wider Azure retirement wave
Document Intelligence is not retiring alone. A cluster of Azure services reaches end of support within about five weeks, so a single dependency audit is cheaper than four separate fire drills.
| Service | Retires | Move to |
|---|---|---|
| Document Intelligence v2.0 API + v2.1 container | August 31, 2026 | v4.0 (2024-11-30) |
| Azure OpenAI Assistants API | August 26, 2026 | Foundry Agent Service |
| Computer Vision API v1.0 to v3.1 | September 13, 2026 | Image Analysis 4.0 |
| Azure Functions 1.0 | September 14, 2026 | Functions 4.x |
| Azure API for FHIR | September 30, 2026 | Azure Health Data Services |
If your document pipeline also calls Computer Vision for image analysis or runs on a Functions 1.0 host, those break within two weeks of the Document Intelligence date. The Azure OpenAI Assistants API migration to Foundry Agent Service shares the same window and the same lesson: inventory first, then migrate on the nearest deadline. For teams tracking Azure spend and lifecycle together, the Azure reserved VM instances retirement and migration work belongs on the same board, and the broader cloud FinOps playbook for Indian teams frames the cost side.
A migration checklist that finishes on time
- Inventory every caller of Document Intelligence, and tag each as v2.0 cloud, v2.1 cloud, or v2.1 container. The container and v2.0 cloud paths end August 31, 2026; v2.1 cloud has until September 15, 2027.
- List every custom model and its training API version. Anything trained on a preview version needs a retrain on the 2024-11-30 GA API.
- Update the SDK from
azure-ai-formrecognizertoazure-ai-documentintelligenceand switch endpoints to thedocumentModelsoperations.
- Fix parsers for the renamed
polygonproperty and the refactored top-levelpages,tables, anddocumentsresults; removeincludeTextDetails.
- For containers, move Read and Layout to v4.0, and keep ID Document, Receipt, and Invoice on v3.1 where v4.0 containers do not yet cover them.
- Retrain and revalidate custom models against a labelled test set, then cut over well before August 31, 2026, keeping the old path only until accuracy is confirmed.
The real cost here is usually the retrain and the parser rewrite, not the endpoint swap. Scope the custom models first, because their accuracy has to be re-proven, not just re-pointed.
India-specific considerations
The August 31, 2026 deadline is the same worldwide. For Indian teams, two points carry weight. Map which Azure region hosts each Document Intelligence resource, because document workloads often move invoices, KYC records, and health forms that fall under the Digital Personal Data Protection Act, 2023. Financial-services and healthcare documents raise the stakes on where extracted personal data lands and who can read it, so treat this migration as a data-handling review, not only a code change. The DPDP engineering playbook for Indian startups covers the handling side, and regulated teams weighing Azure controls can compare notes with model control decisions on Azure.
FAQ
How eCorpIT can help
eCorpIT migrates Azure document pipelines as scoped projects: inventory v2.0, v2.1 cloud, and container callers separately, rewrite endpoints and response parsers for v4.0, and retrain custom models against a labelled test set so accuracy is proven before cutover. Our senior engineering teams are ISO 27001:2022 certified and design document workflows aligned with DPDP Act 2023 requirements, which matters when invoices, KYC, and health records carry personal data. If you run Form Recognizer or Document Intelligence workloads that must move before August 31, 2026, talk to us and we will scope the retrain and rewrite to the time you have. See also our document AI and intelligent document processing work for BFSI.
References
- Microsoft Learn — Document Intelligence v4.0 migration guide
- Windows Forum — Document Intelligence v2.1 containers end August 31, 2026
- Microsoft Learn — What's new in Document Intelligence
- Microsoft Azure — Azure AI Document Intelligence pricing
- DocuOCR — Azure Document Intelligence pricing 2026
- Windows News — Azure Computer Vision v1.0 to v3.1 retire September 13, 2026
- Windows Forum — Azure API for FHIR retires September 30, 2026
- Microsoft Learn — Azure API for FHIR to Azure Health Data Services migration
_Last updated: August 2, 2026._