Coping anlazsers and training data

Question

Hello,

We have 2 subscriptions and i want to move an analyser with a label data between them.

From what i checked in the docs Copy Custom Analyzer is a good option to move the field schema and settings, but what about a label data? When I execute POST {endpoint}/contentunderstanding/analyzers/{analyzerId}:copy?api-version=2025-11-01 the labeledData stays pointing to the original location (which the new analyzer do not have access to). Can i just copy it to a new storage account and patch the analyzer to use it?

Answer 1

The behavior is expected: analyzer copy transfers the analyzer configuration, but labeledData is a knowledge-source reference, so it continues to point at the original blob container. Copy the training-data tree to storage accessible from the target subscription, preserving the prefix, file-list JSONL, label or annotation files, and referenced document paths. Then GET the copied analyzer and use its definition to create or replace the target analyzer with a knowledgeSources entry containing kind labeledData, the new containerUrl, prefix, and fileListPath. Do not use PATCH for this: in the 2025-11-01 API, PATCH supports only description and tags, not knowledgeSources. Use PUT on the target analyzer, with allowReplace when replacement is intended, wait for the operation to succeed, then GET the analyzer and run a representative test. Ensure the target resource or credential can access the new storage. If replacement is unsuitable, create a new analyzer ID and switch consumers after validation.

Answer 2

For people looking for a solution, this is how we achieved it in the end.

High-Level Approach

The migration runs in six phases:

1. Setup — Validate configuration, resolve output directory, verify Azure CLI login (if needed).
2. List & Select — Call GET /contentunderstanding/labelingProjects on the source to enumerate projects.
3. Serialise to disk — For each selected project:
   • Save project metadata (project.json).
   • Fetch and save the schema via GET .../labelingProjects/{projectId}/schema (schema.json).
   • Enumerate and download all blobs under labelingProjects/{projectId}/ from the source storage account using Azure CLI, preserving the original directory structure (the sa is in the project.json file)
4. Recreate projects in target — PUT .../labelingProjects/{projectId} with the project body (kind, displayName, description, tags, target container URL). If the project already exists, prompt to update or skip.
5. Apply schema & upload blobs — Post a schema:edit operation containing clearFieldSchema, editAnalyzerProperties, and initFieldSchema. Then az storage blob upload-batch to push training-set blobs into the target container, preserving paths.
6. Summary — Output a results table and write migration-summary.json with per-project status and any errors.

The only thing left at this point is just create analyzers based on the serialised project data via PUT .../contentunderstanding/analyzers/{{analyzerId}}?allowReplace=true