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

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

1. 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.

2. 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.

3. 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.

4. 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.

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.