Atlassian Labs has released AOSC (Automatic Online Schema Change), an open-source OpenSearch plugin that migrates a live index to a new target with different mappings, settings, or shard count without downtime. It backfills existing documents, replays writes and deletes that arrive during the copy, and swaps an alias after a brief write-block cutover window, requiring only simple retry logic from applications. Shard-count changes are safe for same-count or power-of-two growth, since OpenSearch's operation history does not track routing keys for deletes, making shrinking or non-power-of-two growth unsafe with custom routing. The plugin is Apache 2.0 licensed and available on GitHub, with same-cluster scope only and a required alias for cutover to work.
Table of contents
Reshaping a live index with today’s toolsWhat AOSC doesHow a migration runsThe cutover windowMonitoring a migrationScaling shard countOperational safeguardsWhere AOSC does not fitTry itResourcesGet involvedAuthorsQuestions this post answers
How can I change the number of primary shards in an OpenSearch index without downtime?
The open-source AOSC plugin migrates a live OpenSearch index to a pre-created target index with a different shard count while the source keeps serving writes. It backfills existing documents, replays writes that arrive during the copy, then applies a brief write block to the source before swapping an alias to the target, so applications only need retry logic. Track new tools like AOSC for zero-downtime schema changes by following OpenSearch releases on daily.dev.
Why can changing shard count in OpenSearch cause deleted documents to reappear or persist?
OpenSearch's operation history records a deleted document's _id but not its routing key, so when a migration target has a different shard count, a replayed delete can miss the document it was meant to remove. This is tracked as OpenSearch issue 20907. The AOSC plugin works around it by only allowing same shard count or power-of-two growth, where the shard split is deterministic and a routing-less delete can be fanned out across a fixed block of target shards; shrinking or non-power-of-two growth with custom routing is blocked unless explicitly forced. Engineers planning OpenSearch shard changes can follow routing edge cases like this via daily.dev.
What are the limitations of using OpenSearch's _reindex API to migrate a live index?
The _reindex API only copies a point-in-time snapshot of the source index and does not track or replay writes that land after it starts, so on a busy index the reconciliation of concurrent writes becomes a separate problem the developer must solve. It is a reasonable option only when the source index can be made quiet or there is already a separate mechanism to reconcile in-flight writes. Compare live-migration tradeoffs like this for OpenSearch and other databases on daily.dev.