Azure Form Recognizer vs Document Intelligence: What Changed, What Broke, and What It Costs

Last updated August 10, 2026. API versions, retirement dates and endpoint paths below were read from Microsoft Learn on that date. Rates were read from Microsoft's Azure Retail Prices API, region East US.

Azure Form Recognizer and Azure AI Document Intelligence are the same service. Microsoft renamed it in July 2023, and the rename by itself changed nothing: same endpoints, same models, same prices. What actually changed your code was a separate event, the v3.0 API redesign, which moved every operation under a single documentModels route, renamed the boundingBox property to polygon, and replaced FormRecognizerClient with DocumentAnalysisClient. Those two events get conflated constantly, which is why so much advice about "migrating off Form Recognizer" is confusing. This article separates them.

Is Azure Form Recognizer the same as Azure AI Document Intelligence?

Yes. Microsoft announced the rename in July 2023, and Microsoft Learn now files the product under "Azure Document Intelligence in Foundry Tools", with article titles that read "(formerly Azure AI Form Recognizer)". There is no separate Form Recognizer service to migrate away from and nothing was deprecated because of the name.

The reason the old name persists is that Microsoft only changed it in the documentation and the portal. Everywhere an engineer or an accountant actually looks, the old name survived:

That last row is the one worth checking on your own account. Microsoft's price feed still returns a live legacy product called Form Recognizer whose custom-pages meter bills $50 per 1,000 pages, against $30 per 1,000 under the current Azure Document Intelligence name. We wrote up the full rate card, including the commitment tiers and the meters that have no volume break, on the Azure Form Recognizer pricing reference.

What actually changed in the v3.0 API redesign

This is the change that matters, and it landed before the rename. Starting with v3.0, Microsoft consolidated what had been a scatter of per-model routes into one pair of operations. In v2.1 you called a different path for layout, for invoices, for receipts and for each custom model. From v3.0 onward, everything is a model ID under documentModels.

The call pattern itself did not change. You still POST the document, read the Operation-Location header, and poll it with a GET until the status turns to succeeded. Microsoft recommends a minimum of one second between polls.

The one genuinely breaking change: boundingBox became polygon

Microsoft flags exactly one breaking change in the analyze response, and it is easy to miss because it does not throw an error, it just returns a shape your parser does not recognize. In the 2023-07-31 release, the boundingBox property was renamed to polygon in every instance. If you have code walking coordinates to draw overlays or to work out which field sits where on the page, that code reads undefined after the upgrade and usually fails silently.

The response got restructured, not just renamed

In v2.1 most results hung off individual pages. From v3.0 the analyze result promotes them to top-level arrays: pages, tables, keyValuePairs, entities, styles and documents. This is a real improvement, because a table spanning three pages is finally one object with bounding regions across all three rather than three fragments you have to stitch together. It is also a rewrite of any code that walked the old structure.

A few smaller changes catch people out during the same upgrade:

• The includeTextDetails parameter is gone. The new response is more compact and the full output is always returned.
• modelName was renamed to description, and modelId became a property you can set to a human readable name.
• A new buildMode property takes template for the classic custom form models or neural for custom neural models.
• Compose model is now limited to a single level of nesting.
• authorizeCopy is now a POST rather than a GET.
• Input is supplied as urlSource for a public URL or base64Source for inline content.

The change nobody budgets for: custom models now expire

This is the single most operationally disruptive difference, and it has nothing to do with syntax. Microsoft introduced an expiration date on every custom extraction and classification model, because those models are built on a large base model that gets updated and eventually retired. A GET on the model now returns an expirationDateTime alongside the API version it was trained with. When a custom model expires, you retrain it against the current base model. There is no automatic migration.

The sharper version of the same rule applies to preview API versions. Microsoft states that custom models trained using a preview API version are tied to that preview version's lifecycle, so when the preview retires, the models trained on it retire with it. If you built a proof of concept on a preview API and it quietly became production, that is a dependency with a fuse on it. Retrain on the current GA version as part of any migration.

There is also a build quota worth knowing about before you plan a retraining sprint: the number of custom neural models each subscription can build per region per month is capped, and a GET on /info now returns your used count, your quota and the reset date.

When does Azure Form Recognizer v2.1 stop working?

Microsoft has published two dates, and they are further out than most people assume:

If your code still imports FormRecognizerClient or FormTrainingClient, you are on a v2.x client and you are inside the first window. Version 3.0 replaced both classes with DocumentAnalysisClient and DocumentModelAdministrationClient. Microsoft's guidance is to go straight to v4.0 for new development rather than stepping through v3.x.

What v4.0 added that is worth the migration

Moving from v2.1 to v4.0 is a real piece of work, so it helps to know what you get beyond staying supported. The additions that change what is possible, rather than just improving quality:

• A batch API covering all models, including read, layout, prebuilt and custom, with list and delete operations on batch jobs. Note that it buys throughput, not a discount: Azure prices every batch meter identically to its synchronous twin.
• Searchable PDF output from the read model, with image formats and Chinese, Japanese and Korean support.
• New prebuilt models including US bank statement, pay stub, check, mortgage documents and a unified US tax model covering W-2, 1098, 1099 and 1040.
• Custom classification improvements, including incremental training so you can add classes without starting over, and a 25,000-page training limit.
• Office and HTML support widened, though with a caveat: embedded images in Office and HTML files are no longer supported, and if you request add-on features on those file types you get an empty array back rather than an error.
• Currency normalization, mapping a symbol like $ to an ISO 4217 code like USD in the field output.

One deprecation to plan around

The general document model, prebuilt-document, was deprecated. To pull key-value pairs now you call prebuilt-layout with the keyValuePairs feature enabled via the features query parameter. Some of those features are billed as add-ons at $6 per 1,000 pages, so a like-for-like migration can quietly raise your per-page cost if you turn several on.

Does the rename change what I pay?

No. The rates are attached to the meters, not to the product name, and the Standard tier rates are the same on either side of the rename: $1.50 per 1,000 pages for Read, $10 for Layout or any prebuilt model, $30 for custom extraction and $3 for the document classifier. Read is the only meter with a genuine pay-as-you-go volume break, dropping to $0.60 per 1,000 above a million pages a month.

The one place the name does appear to matter is that legacy billing product. Microsoft's price feed still carries a Form Recognizer product with a custom-pages meter at $50 per 1,000, effective since August 2021, against $30 under the current name, effective June 2024. We verified that in East US, West US 2 and North Europe. It does not tell you which meter your own subscription bills on, so the practical advice is narrow: open the invoice, find the line item and read the meter name rather than the product heading. At 100,000 custom pages a month the difference between the two is $2,000.

Should you migrate now or wait?

If you are on v2.1, start planning rather than starting work. September 2027 is far enough away that a rushed migration is worse than a scheduled one, but the code changes are not cosmetic: new client classes, new routes, a restructured response, and the polygon rename that fails quietly. Budget for reparsing, not just for a package upgrade.

If you are on a preview API version, treat that as urgent regardless of the dates above, because your custom models retire with the preview they were trained on.

If you are choosing between Azure and its competitors while you are in there anyway, the entry rate will not decide it. Azure, AWS Textract and Google Document AI all charge exactly $1.50 per 1,000 pages for plain OCR. The gaps show up on structured work, where Azure's Layout is $10 against Textract's $15 for tables, and on capabilities that simply do not exist elsewhere, like Azure's $3 document classifier. The cross-vendor OCR pricing per 1,000 pages reference normalizes all of them to the same unit, and the Azure Document Intelligence limits page covers the file size and page ceilings that tend to decide architecture more than price does.

The part the API version does not solve

Worth saying plainly, because a migration is a good moment to ask it: none of this changes what the service gives you. Both versions return JSON. Neither one queues your documents, decides which model each one needs, holds back the ones that failed validation, gives a non-engineer a screen to fix a misread total, or pushes finished rows into an accounting system. That surrounding pipeline is where most of the real budget goes, and it is the reason teams processing a few thousand documents a month often find a finished product cheaper than a $1.50 API plus the engineering around it.

It also tends to be where the data stops. Once documents are parsed into structured fields, the text usually lands in a store nobody can query in plain language, and teams end up rebuilding a way to find answers across everything the company has written down as a second project. Worth scoping that before the extraction work finishes rather than after.

If you want to see what structured output looks like on your own paperwork before committing to either API version, upload a document at the top of this page and read the fields that come back. For the full rate card behind the numbers quoted here, see the Azure Form Recognizer pricing reference, and for the current-name companion, Azure Document Intelligence pricing.