# Post-cutover rebuilds: Atlas Search indexes, users and roles, time-series collections > Source-anchored research for Post-cutover rebuilds: Atlas Search indexes, users and roles, time-series collections. Run status: COMPLETED. Parent: [Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress)](https://llms-explorer.com/tree/migration-and-cutover-cost-live-migration-mongosync-dual-running-egress/) · 5 facets · 19 facts · page: https://llms-explorer.com/tree/post-cutover-rebuilds-atlas-search-indexes-users-and-roles-time-series-collections/ ## Definitions - Search readiness is a separate acceptance gate: Search indexing is asynchronous and eventually consistent, and migration guidance warns that indexes built mid-sync may lag after cutover. Therefore data-copy completion alone does not establish search-result completeness. (medium confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) ## How it works - Atlas live migration does not migrate Search indexes. PhysicsWallah independently reports rebuilding Atlas Search indexes after cutover because neither mongorestore nor mongosync recreated them automatically. Budget this as a separate feature-restoration step. (medium confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/atlas/live-migration/) - In an October 2024 MongoDB community migration discussion, responders recommend building destination Search indexes after cutover. They acknowledge building during migration is possible, but warn that Search can remain behind after migration completes because it is eventually consistent. This is dated operational guidance, not a rule that earlier index creation is impossible. (low confidence) (verified as of 2024-10-30) — [source](https://www.mongodb.com/community/forums/t/guidance-on-live-migration-of-clusters-with-enabled-search-nodes/301938) ## Problems, failure modes and limitations - The mongosync limitations snapshot lists time-series collections as unsupported. CloudSpinx independently tested mongosync 1.22.0 against MongoDB 8.0.34 Community replica sets and reports that a time-series collection caused /start to reject the migration. This is a migration-tool restriction, not a claim that Atlas cannot host time-series data. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md) - mongosync lists time-series collections as unsupported. This is a migration-path limitation, not evidence that time-series data is copied and merely needs an index rebuild after cutover. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md) - MongoDB Search cannot be used directly on time-series collections, according to the Search FAQ. Rebuilding a Search index is therefore not a supported way to restore Search functionality directly on a migrated time-series collection. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/search/faq.md) ## Comparisons and alternatives - MongoDB documents mongorestore support for time-series collections starting with MongoDB 5.0. CloudSpinx proposes excluding unsupported time-series data from mongosync and copying it separately during a stopped-write window; that proposal requires workload-specific rehearsal rather than assuming live-sync coverage. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/database-tools/mongorestore/mongorestore-behavior-access-usage.md) - MongoDB community guidance recommends building destination Search indexes after cutover. It also says building during migration is possible, so post-cutover construction is a recommendation rather than an absolute prohibition. PhysicsWallah reports following the post-cutover sequence in production. (medium confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/community/forums/t/guidance-on-live-migration-of-clusters-with-enabled-search-nodes/301938) - Time-series collections have a documented dump/restore path: mongorestore supports restoring them starting with MongoDB 5.0, and MongoDB supplies a worked mongodump/mongorestore example. This scopes the mongosync exclusion rather than implying time-series data cannot be migrated. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/database-tools/mongorestore/mongorestore-behavior-access-usage.md) - Migronaut's maintainer guide documents declaring Search index definitions, creating missing indexes, and using --wait-search to wait for queryability. It states that builds run asynchronously and that converge manages regular collections rather than time-series collections. This is product-specific tooling guidance, not an independently tested Atlas migration guarantee. (low confidence) (verified as of 2026-10-30) — [source](https://migronaut.vercel.app/guide/collections) - Databasezy's Atlas provider guide says its mongodump/mongorestore migration does not copy Atlas Search indexes or triggers. Its supported destination products and workflow differ from Atlas-to-Atlas live migration, so this evidence corroborates only that narrower omission. (low confidence) (verified as of 2026-10-30) — [source](https://docs.databasezy.com/migrate/providers/mongodb-atlas.html) ## Facts and statements - Atlas live migration does not migrate user or role data. Recreate application credentials and required roles before reconnecting applications; CloudSpinx observed both users and a custom role absent after a mongosync commit in its self-managed laboratory. (medium confidence) (verified as of 2026-10-26) — [source](https://www.mongodb.com/docs/atlas/live-migration/) - Search index creation and rebuilding consume resources and can affect cluster performance. MongoDB recommends expanding cluster capacity if a rebuild fails for insufficient disk space. Cost implication: retaining temporary capacity through Search readiness may be necessary; the sources establish no universal rebuild duration or dollar premium. (low confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - No-downtime indexing keeps an existing index serving while its replacement builds. That behavior does not establish immediate Search availability on a new migration destination whose Search indexes were never transferred. (medium confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - For M10+ dedicated clusters, Cloud Backup restores Search index definitions but does not restore Search index data. mongot performs initial synchronization for the restored definitions, and large indexes can delay restoration. Manual definition recreation is therefore not universal across migration methods. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-continuous.md) - Migronaut documents a practical readiness check for its own migration tooling: search indexes may remain PENDING or BUILDING after the operation returns; its converge --wait-search option waits until they are queryable. This is a tool-specific automation example, not an Atlas live-migration guarantee. (low confidence) (verified as of 2026-10-30) — [source](https://migronaut.vercel.app/guide/troubleshooting) - Atlas live migration and mongosync do not migrate Atlas Search indexes from source to destination; copying collection data therefore does not by itself recreate the application's Search indexes. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md) - mongosync does not synchronize users or roles and does not support a destination without provisioned users. Destination access must be provisioned separately; treating all user creation as a post-cutover task is unsafe. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md) - Cost-planning inference: budget separately for destination access provisioning, an alternative time-series migration procedure, and Search readiness after data transfer. Unsupported synchronization features and index rebuild work can add engineering effort and readiness time; the cited sources do not quantify an incremental price, minimum cluster tier for migration, or rebuild duration. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md)