Embedding Migration: Reversible Index Cutover

Changing the model that embeds a user's question while leaving the stored document vectors untouched can produce valid requests and poor search results. Matching vector lengths do not make two models interchangeable. The query and document representations must belong to the intended embedding space.

Azure AI Search's vector index guide describes that relationship and requires field dimensions to match the generated vectors. Treat the embedding configuration, preprocessing rules and destination index as one release unit.

Write down the current retrieval configuration

Before building a replacement, capture the model identifier, requested dimensions, similarity metric, text normalisation, chunking version, vector field name and query settings. Include any prefixes or instruction formats required by the chosen embedding model.

Also record what is outside the vector itself: document keys, source versions, access metadata, effective dates, deletion flags and the text returned with a hit. A migration that improves relevance while losing the permission filter is a failed migration.

Save a representative query set and its expected evidence. The model output regression note explains the value of a stable baseline. For retrieval, the baseline must include document identities and ranks, not only the final assistant prose.

Build a second index from a defined source snapshot

Create a new destination with a distinct name. Keep the old one serving production while the replacement is populated. Microsoft explicitly recommends testing production schema changes side by side.

Record the source snapshot or ingestion watermark. Without one, a document added halfway through the rebuild can be absent from both the count comparison and the migration report. Use a replayable change log or another supported synchronisation method to capture additions, edits and deletions that occur during the build.

Validate the ingest manifest. Check source counts, expected chunk counts, failed records, duplicate keys and missing metadata. Different chunking can legitimately change the count, so reconcile by source version as well as by total rows.

Do not mix old and new vectors in the same field as a gradual update strategy unless the retrieval design explicitly handles separate representations. A request can succeed syntactically while comparing incompatible data.

Compare evidence quality before switching users

Run the same questions against both configurations. Each query must use the embedding model paired with its destination. Compare the presence of required evidence, duplicate results, no-answer behaviour, latency and cost.

Inspect difficult cases individually: short product codes, acronyms, near-identical policy versions, multi-language content and questions requiring an exception. An average gain can hide a serious regression for one business-critical document family.

Keep generation fixed during this comparison. Otherwise a more capable answer model may conceal weaker retrieval. Save the actual chunks passed to generation so a reviewer can distinguish an index improvement from better guessing.

Switch a configuration bundle

An Azure index alias can point an application at a different index without changing each index-name reference. It does not update your separate embedding client or every ingestion target. Microsoft also notes that an indexer cannot use an alias as its targetIndexName.

The release should therefore select a bundle: index target, query embedding model, preprocessing version and relevant query settings. If the platform cannot switch them together, route through a versioned application configuration that can. Prevent requests using half of each version during the transition.

For a staged rollout, send a small authorised cohort to the new bundle while keeping the rest on the old one. If shadow queries are used, confirm that the extra processing is permitted for the data and budget. Shadow results should not overwrite live answers or create side effects.

Keep the old route current enough to use

A return path is only useful if the old index still contains the changes users expect. Decide how long both indexes receive updates, who checks synchronisation and when the old pipeline can stop.

Before retiring it, practise returning one test request to the previous bundle. Confirm that the query model changes with the index, that caches do not return answers from the wrong corpus version, and that removed documents remain removed.

Set a retention deadline for the old index to avoid paying for it indefinitely. Delete it only after the agreed observation period and after preserving the configuration and source material needed for a later rebuild. That decision should follow the evaluation record, outstanding failures and actual workload behaviour, rather than the date the new model was announced.

References

• Microsoft, Create a vector index in Azure AI Search. Accessed 17 October 2026.
• Microsoft, Update or rebuild an index. Accessed 17 October 2026.
• Microsoft, Create an index alias. Accessed 17 October 2026.