Azure Document Intelligence Studio returns "Form Recognizer Not Found" after subscription migration

Question

Azure Document Intelligence Studio returns "Form Recognizer Not Found" after subscription migration

Sarabjeet Singh 0

We recently moved an Azure AI Document Intelligence (formerly Form Recognizer) resource to a new Azure subscription.

Resource Details

Resource Name: PII

Subscription ID: PII

Resource Group: HublixDocuments

Region: UK South

Kind: FormRecognizer

Status: Active

Current Behavior

The Document Intelligence resource is active and functioning correctly.

The following operations work successfully:

Analyze Document using the .NET SDK
Analyze Document using the REST API
Existing custom extraction models continue to process documents successfully
Resource is visible in Azure Portal
Resource is selectable within Document Intelligence Studio

However, when attempting to open Document Intelligence Studio (either from the Azure Portal or directly from https://documentintelligence.ai.azure.com), Studio immediately displays the following error:

Name:Form Recognizer Not Found

Message: The form recognizer could not be found.

HTTP Status:404

Investigation

Using the browser Developer Tools (Network tab), we observed that Document Intelligence Studio is issuing requests to:

https://contentunderstanding.ai.azure.com/documentintelligence/api/my/cache/subscriptions/68083a6e-fcad-4190-b5f4-c68379b5883d/resourceGroups/HublixDocument/formRecognizers/Hublix-IDP-001

This request references the OLD Azure resource location:

Old Subscription ID:PII

Old Resource Group:PII

However, the resource now exists at:

Subscription ID:PII

Resource Group:PII

Expected Behavior

Document Intelligence Studio should discover and use the current resource location instead of attempting to access the previous subscription/resource group.

Question

It appears that Document Intelligence Studio retains stale metadata or cached project information after the resource was moved to a different Azure subscription.

Could the engineering team please advise:

Is there a server-side cache or project metadata that needs to be refreshed?
Can the existing Studio project references be updated to point to the current subscription/resource group?
Is there a supported procedure for migrating Document Intelligence Studio projects after an Azure resource move?
If this is a known limitation, is there a recommended workaround that preserves existing custom extraction projects?

Additional Information

Resource is Active.
User has Owner permissions.
Public network access is enabled.
SDK and REST API continue to work correctly.
Only Document Intelligence Studio fails with 404 "Form Recognizer Not Found."

Thanmayi Godithi 11,555 Reputation points Microsoft External Staff Moderator

2026-07-29T10:21:26.2+00:00
Hi Sarabjeet Singh ,

Thank you for the detailed investigation — capturing the Studio request in the browser Network tab was exactly the right step, and it confirms the cause.

Document Intelligence Studio custom projects store the ARM resource ID of the bound Document Intelligence resource at the time the project is created. That reference isn't re-resolved afterwards, so once the resource is moved to a different subscription or resource group, the project keeps requesting the original path — which no longer exists. Hence the 404 Form Recognizer Not Found.

This is precisely why your SDK and REST calls continue to work: they address the resource by endpoint, not by ARM resource ID. Only Studio is affected.

The official troubleshooting table documents this exact scenario:

Scenario: You receive the error message Form Recognizer Not Found when you open a custom project. Cause: Your Document Intelligence resource, which is bound to the custom project, was deleted or moved to another resource group. Resolution: There are two ways to resolve this problem: • Re-create the Document Intelligence resource under the same subscription and resource group with the same name. • Re-create a custom project with the migrated Document Intelligence resource and specify the same storage account.

Source: Get started: Document Intelligence Studio — Troubleshooting

Answering your four questions directly

Is there a server-side cache or project metadata that needs refreshing?

No. This isn't a transient cache that expires — the resource ID is persisted as part of the project definition. Signing out of Studio, clearing browser site data, or re-selecting the subscription will not resolve it.

Can existing Studio project references be updated to point to the current subscription/resource group?

No. There is no documented or supported method to edit a saved Studio project's bound ARM resource ID, via the portal, CLI, or API.

Is there a supported procedure for migrating Studio projects after a resource move?

There is no project-migration path. The two documented resolutions above are the supported options.

Recommended workaround that preserves existing custom extraction projects

Your trained models are safe. They live with the resource and remain callable through your working endpoint — as you've already confirmed via SDK and REST. What's broken is the Studio project wrapper, not the models themselves. There's no urgency to retrain anything currently deployed.

Practical path forward:

Create a new custom extraction project in Studio, selecting the moved resource and pointing at the same storage account and container. Your labelled data (.labels.json and .ocr.json files) lives in blob storage rather than inside the project, so the new project picks up your existing labelling work — you aren't starting over. Build and train a custom extraction model

Verify role assignments after the move, since these don't always survive a subscription change. For custom projects you need Cognitive Services User on the Document Intelligence resource and Storage Blob Data Contributor on the storage account. To let Studio configure CORS for you, Storage Account Contributor is also needed. Create Document Intelligence Studio custom projects — Azure role assignments

Check CORS on the storage account. Allowed origins must include https://documentintelligence.ai.azure.com, with all eight allowed methods, * for allowed and exposed headers, and a max age of 120 seconds or more. Same doc as above.

Optionally, use project sharing. If you can still generate a project token from the original project, you can import it into the replacement — though note this shares the project reference and won't itself rewrite the stale resource ID. Project sharing using Document Intelligence Studio

One important thing to check

If your storage account stayed in the old subscription while the Document Intelligence resource moved, verify that separately. A resource move doesn't carry storage data with it, and this has caused follow-on failures for others in similar migrations.

If, after creating a new project against the moved resource, Studio still requests the old resource ID, that would go beyond the documented behaviour and would warrant a Microsoft Support case for engineering to inspect server-side state.

I hope this helps — please let me know how you get on.

1 answer

Your answer

Answer 1

Your SDK and REST tests confirm that the moved Document Intelligence resource and its existing models are healthy. The 404 occurs because the Studio project is still requesting the old subscription and resource-group path, rather than because the service endpoint is unavailable.

Sign out of Studio, clear the site data for Document Intelligence Studio, sign back into the correct directory, and explicitly select the new subscription and resource. If the old resource ID remains, create a new custom extraction project against the moved resource and the existing training-data container. Where available, export/share the original project and import its project token into the replacement project. Verify Cognitive Services User access on the Document Intelligence resource, storage data access, and the required Studio CORS origin. Existing deployed model IDs should remain callable through the working endpoint. Microsoft does not document a supported way to directly edit a saved Studio project’s ARM resource ID, so persistent stale server-side references require a Microsoft Support case.