Rollback Strategy

Always plan for rollback before you start.

Problem	Rollback Option
Mapping error or missing data	Switch alias back to old index
Performance issues	Keep old cluster active for a few hours
Incomplete reindex	Restart _reindex from checkpoint
Failed upgrade	Restore snapshot into old version
Something wrong in CCR	you can re-enable following or reverse replication.

Keeping both environments (blue + green) online until validation ensures you can recover quickly.

Monitoring During Migration

Use _cat APIs or Kibana to monitor progress:

GET _cat/indices?v
GET _cat/nodes?v
GET _cat/recovery?v

Watch for:

• Shards not assigned or still initializing
• Disk space usage during reindex
• Cluster health (must stay green)

You can also throttle reindex speed:

POST _reindex
{
  "source": { "index": "my_index_v1" },
  "dest": { "index": "my_index_v2" },
  "max_docs": 100000,
  "script": { "source": "ctx._source.migrated = true" }
}

Common Mistakes to Avoid

Mistake	Problem	Better Approach
Reindexing without alias	Hard to switch safely	Always use aliases
Mixing versions in one cluster	May corrupt state	Use separate clusters
Deleting old index too soon	No rollback possible	Wait several days
Not testing queries	Wrong results after switch	Test both versions
Not taking snapshots	Irreversible loss	Always snapshot before upgrade

Conclusion

Blue-green deployment is the safest way to reindex or upgrade Elasticsearch without downtime.
It lets you prepare, test, and switch gradually, keeping your production system online all the time.

“Build green, test green, switch fast, sleep well.”

Follow this process:

1. Create a new index or cluster (green)
2. Reindex and test
3. Switch aliases or endpoints
4. Keep blue for rollback
5. Clean up when everything is stable

Your users won’t notice a thing, but your Elasticsearch will be faster, cleaner, and ready for the future.