# Run old and new indexes with a clear activation point

A replacement index needs a source checkpoint, a catch-up plan and compatible answer caches. Switching a query alias is only one step.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define the snapshot you are building

A full rebuild can take long enough for the source collection to change underneath it. Record the source checkpoint or snapshot boundary used to start the new index. Then decide how changes after that boundary will be applied.

If the source supports a consistent snapshot and change feed, retain enough history to catch up before activation. If it does not, use a reconciliation process that can detect differences and repeat safely. The choice depends on the source's guarantees, not just the indexing service.

Include deletions and permission changes in catch-up work. A new index containing every recently added document can still be unsafe if it missed withdrawals during the rebuild.

## Make the two generations distinguishable

Give each index generation an explicit identifier and record it with retrieval results. Keep passage identifiers and source revisions meaningful within that generation. This helps explain differences during comparison and prevents an answer cache from treating two incompatible evidence sets as equivalent.

Run representative queries against both generations using the same user permissions. Compare evidence quality, current revisions and exclusion behaviour. A raw document count is useful for reconciliation but does not establish that the right passages are being served.

Check operational capacity while both indexes exist. Rebuild traffic, embeddings and duplicated storage can affect the live service. Throttle background work if it compromises the query path users already depend on.

## Establish a readiness gate

Before activation, require the new index to reach the agreed source checkpoint and pass targeted update, deletion and access probes. Document any remaining lag and whether it is acceptable for the collection.

An alias or application configuration can provide a clear activation point, depending on the platform. Verify the actual switching semantics. Do not assume that every in-flight request, cache and worker changes generation at exactly the same instant.

Decide how cached answers behave at the switch. They can be invalidated, partitioned by generation or revalidated against source dependencies. Reusing them without a compatibility rule can make the new index appear stale even when its data is correct.

## Keep rollback current enough to use

Retaining the old index is only useful if it remains compatible with the application's source and permission requirements. Continue updates during the observation period or define a catch-up step before rollback. An old index frozen before recent withdrawals may be a poor recovery target.

Test a rollback with a document changed after activation. Confirm the reader receives the permitted revision and that stored answers still resolve their evidence. Retire the old generation after the observation window and reconciliation checks, recording what happens to historical citations that refer to it.

## Sources

- [Microsoft Learn: index updates and rebuilds](https://learn.microsoft.com/en-us/azure/search/search-howto-reindex)
- [Microsoft Learn: changed and deleted source blobs](https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-changed-deleted)