Embedding Model Migration
The process of moving a corpus to a new embedding model, which requires re-embedding everything because vectors from different models are not comparable.
Vectors from different models occupy different spaces. A query embedded with model B cannot be compared against a corpus embedded with model A — the results are not merely worse, they are meaningless.
So changing the embedding model means re-embedding the entire corpus, and for a large corpus that is a significant cost in compute, time and, if using a hosted model, tokens.
The migration pattern that avoids downtime: build the new index alongside the old, embedding in batches; run both in parallel and compare retrieval quality on an evaluation set; switch queries atomically once satisfied; retain the old index until confident.
What makes it survivable is designing for it from the start: store the source text alongside the vectors, so re-embedding does not require re-extracting from original documents; record which model and version produced each vector; and keep the embedding step as a distinct pipeline stage rather than inlined into ingestion.
Two related constraints worth knowing: dimensionality affects storage and query cost roughly linearly, and some models support truncation to fewer dimensions with graceful degradation; and embeddings are not anonymous — text can be partially reconstructed from them, so a vector store holding embeddings of personal data is holding personal data.