Reindex API Version Conflicts: Reconciling Old-Index Writes Before Alias Cutover

Answer

For a small Elasticsearch application, the safest reconciliation strategy is a final-delta reindex with a brief write pause. Run the bulk copy asynchronously, then briefly pause or queue incoming writes, execute a second delta reindex to capture the write window, verify that no conflicts remain, and finally perform the atomic alias swap. Continuous dual writes add ordering and partial-failure risk that outweighs their benefit at this scale.

Why conflicts=proceed is not reconciliation

Setting conflicts=proceed allows the Reindex API to continue past version conflicts, but it does not copy the conflicting source updates. A nonzero version_conflicts count in the task response means those writes were skipped, not reconciled. Treat it as pending work, not success.

Recommended sequence

1. Pre-create the destination index with the intended settings and mappings. The Reindex API copies documents only; it does not copy index configuration.
2. Keep the client alias on the old index during the copy. Do not add the new index to the alias before cutover, because a multi-index alias requires a single write index and partial data can leak into reads.
3. Run the bulk reindex asynchronously with wait_for_completion=false and a conservative requests_per_second to protect the small cluster. Use conflicts=proceed so the job does not abort on concurrent updates.
4. Briefly pause or queue writes for the final delta. If writes must never fail, an external queue is required; a short pause is still a brief unavailability window.
5. Run the delta reindex without a timestamp filter unless every write path reliably updates an updated_at field. A full delta is safer for small datasets.
6. Swap the alias atomically in a single _aliases request that removes the old index and adds the new one with is_write_index: true.

Verification before cutover

Refresh the destination index, then compare GET /<old>/_count and GET /<new>/_count. For a small dataset, scroll both sides and compare _id, _routing, and _source or stable hashes rather than relying on counts alone. The delta is complete only when counts and content match and the task response reports version_conflicts: 0 with no failures. Do not rely on _version equality unless your reindex path preserves versions.

Confirm the destination configuration with GET /<new>/_mapping and GET /<new>/_settings, and verify alias state with GET /_alias/<alias> before and after the swap: exactly one index, with is_write_index on the new index after cutover.

Monitoring the reindex task

Save the task ID returned by the asynchronous reindex and poll GET /_tasks/<task_id>?detailed=true until completed is true. Check response.total, created, updated, version_conflicts, failures, and the batch count. Never cut over while the task is running or after failures. If version_conflicts is nonzero after the write pause, run another delta.

One missing diagnostic detail

Can your application tolerate a short write pause or queue during the final delta? If writes must never fail, the recommendation changes to an external queue or idempotent ordered dual-write design, which is more complex but removes the unavailability window.

Version note: Mapping types were removed in Elasticsearch 8, and remote-reindex allow/whitelist setting names differ across 7.x and 8.x. Confirm exact parameter names against your deployed version before relying on them.