Atlas Live Migration pull versus push versus standalone mongosync selection
Parent: Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Atlas Live Migration pull versus push versus standalone mongosync selection. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- Pull is the managed option: Atlas provisions the migration server and connects to the source. For a self-managed source, its firewall must admit the Atlas migration servers; MongoDB recommends pull especially for deployments not monitored by Cloud Manager or Ops Manager. (high confidence) (verified as of 2026-10-31) [source]
- Standalone mongosync means a self-hosted migration utility, not permission to migrate a standalone mongod directly: both managed procedure pages instruct converting a standalone source to a replica set first. (high confidence) (verified as of 2026-10-31) [source]
How it works
- Standalone mongosync requires self-hosted infrastructure but permits either Atlas or on-premises source and destination clusters. It is the appropriate candidate when the destination must remain outside Atlas. (low confidence) (verified as of 2026-10-31) [source]
- For a partial database or collection move, standalone mongosync supports includeNamespaces and excludeNamespaces. RightTouch selected it because Atlas Live Migration lacked collection filtering and non-migrating collections had to remain active. (medium confidence) (verified as of 2026-10-31) [source]
- MongoDB recommends standalone mongosync for larger or more operationally demanding migrations because it offers tunable parameters, pause/resume, progress tracking, and direct logs. Its comparison page phrases the managed-service sizing guidance as source clusters at most 5 TB or at most 3 shards; this wording is guidance, not evidence of a hard combined eligibility cap. (low confidence) (verified as of 2026-10-31) [source]
- Standalone mongosync is also MongoDB's recommended approach when required private network connectivity or a prohibition on third-party source access prevents managed pull, and importing the source into Cloud Manager or Ops Manager is undesirable. (low confidence) (verified as of 2026-10-31) [source]
- Pull does not use VPC peering or private endpoints as its migration data path. Those configurations can still serve application connectivity; Atlas-to-Atlas pull migration uses the Atlas-managed backbone. MongoDB recommends standalone mongosync when private networking or restrictions on third-party source connections rule out the managed approach. (high confidence) (verified as of 2026-10-31) [source]
- Choose standalone mongosync when only selected databases or collections should move: filtered sync accepts namespace filters. RightTouch selected it for a partial-collection migration after finding that Atlas Live Migration operated on the whole cluster. (high confidence) (verified as of 2026-10-31) [source]
Comparisons and alternatives
- Atlas Live Migration uses mongosync underneath; choosing standalone mongosync changes who hosts and controls the migration process rather than selecting an unrelated copying engine. (high confidence) (verified as of 2026-10-31) [source]
- Use the current procedure-specific version matrix rather than AWS's broad statement that both ends running 6.0.8 or later can use guided migration. The current pull page enumerates particular source/destination version paths, including 5.0 to 7.0, and warns against minor-version deployments using Latest Version With Auto Upgrades. (high confidence) (verified as of 2026-10-31) [source]
Facts and statements
- Atlas Live Migration copies existing data, follows subsequent source changes, and keeps applications on the source until cutover. Cutover requires stopping source writes and redirecting applications to Atlas. (medium confidence) (verified as of 2026-10-31) [source]
- Choose the documented push workflow for a source monitored by Cloud Manager. The operator provisions, secures, and runs a migration host with a dedicated MongoDB Agent; the workflow uses mongosync underneath and links Cloud Manager to Atlas with a link-token. (low confidence) (verified as of 2026-10-31) [source]
- Pull does not use customer VPC peering or private endpoints as its migration data path. Push documentation instead permits configuring peering or a private endpoint between its migration host and the destination, subject to provider and region requirements. Application connectivity and migration connectivity must be evaluated separately. (medium confidence) (verified as of 2026-10-31) [source]
- Changing from Atlas Live Migration to standalone mongosync does not automatically solve MongoDB minor-version incompatibility: the pull procedure explicitly says both tools do not support minor versions and excludes clusters using Latest Version With Auto Upgrades. (low confidence) (verified as of 2026-10-31) [source]
- In its reported lab, CloudSpinx ran mongosync 1.22.0 against MongoDB 9.0.4 and received ClusterValidation refusals for a 9.0 source or destination. This is version-specific first-hand evidence for checking the exact binary and cluster pairing before choosing standalone mongosync. (low confidence) (verified as of 2026-10-31) [source]
- In its Atlas-to-Atlas partial migration, RightTouch operated mongosync on a temporary Google Cloud VM and added application write-hold and connection-switch logic. Standalone operation therefore solved the filtering requirement while adding infrastructure and application cutover work in this case. (low confidence) [source]
- The documented push workflow requires a source monitored by Cloud Manager, a provisioned migration host running a dedicated MongoDB Agent, and a link-token connecting Cloud Manager to Atlas. Its API references to Ops Manager must not be treated as proof that this particular workflow supports Ops Manager directly. (low confidence) (verified as of 2026-10-31) [source]
- Standalone mongosync requires operator-provided infrastructure. It offers tunable parameters, pause/resume, detailed progress, and direct logs; RightTouch's implementation illustrates the additional work of provisioning a VM and securing credentials and cluster connections. (high confidence) (verified as of 2026-10-31) [source]
- MongoDB's comparison guide recommends managed Live Migration for sources described as no more than 5 TB or 3 shards and recommends standalone mongosync above those thresholds. This is selection guidance, not evidence of a hard managed-service capacity ceiling; the pull procedure separately documents verifier defaults for larger migrations. (high confidence) (verified as of 2026-10-31) [source]
- Managed Live Migration requires an Atlas destination. Standalone mongosync can use either Atlas or on-premises clusters for both source and destination. (low confidence) (verified as of 2026-10-31) [source]
Children
- Migration network path validation (frontier)
- Mongosync namespace filtering (frontier)
- Source and destination version compatibility (frontier)
Frontier under this node: Migration network path validation, Mongosync namespace filtering, Source and destination version compatibility