▸ mongosync progress needs intervention - The runbook needs version-aware status checks, pause and resume decisions, network recovery steps, and escalation criteria instead of an unplanned restart.
▸ The source exceeds the managed path - A source above 5 TB or more than three shards needs standalone mongosync or another supported pattern rather than an Atlas Live Migration assumption.
▸ Network setup blocking migration - VPC Peering vs Private Link decision pending, IP allowlist needs re-cut per environment, source-cluster firewall hasn't been audited for outbound Atlas connectivity.

JusDB MongoDB Atlas specialists own the call - sizing, migration, optimization, ongoing managed. Book an Atlas scoping call →

MongoDB Atlas Specialty

MongoDB Atlas Migration Services

In short: A MongoDB Atlas migration selects a supported transfer method from the source version, topology, size, change rate, and downtime target. The runbook covers compatibility, networking, initial sync, validation, a write-stopped final cutover, post-cutover monitoring, and an explicit rollback data strategy.

Atlas Live Migration is the managed path for eligible sources; standalone mongosync adds operational control for larger or more complex supported topologies. Neither removes the need for application and rollback validation.

Schedule Atlas scoping call Generic MongoDB consulting

Migration Paths

Three migration paths we run

Self-hosted → Atlas (Live)

Use Atlas Live Migration for an otherwise eligible source of 5 TB or less, or three shards or fewer. Validate source access, supported versions and topology, initial sync, application connectivity, and the final write-stopped cutover.

Self-hosted → Atlas (mongosync)

Use standalone mongosync for a supported source above 5 TB or more than three shards, or when its documented operational controls are required. The runbook covers status, pause and resume, validation, commit, and reverse-sync capability where supported.

Self-hosted → Atlas (dual-write)

Use application-assisted dual writes only when the business case justifies its conflict handling, idempotency, consistency, observability, and rollback complexity. It is not a default zero-downtime promise.

Atlas → Atlas (cross-region)

Cross-region migration via Global Cluster reshape or new cluster + mongosync; common driver: GDPR data-residency or AWS region exit.

DocumentDB → Atlas

Treat Amazon DocumentDB as a distinct MongoDB-compatible source. Inventory API and feature differences first, then select a supported offline or change-data-capture path and validate application behavior on Atlas.

CosmosDB → Atlas

Treat the Azure Cosmos DB API for MongoDB as a distinct source. Assess API-version behavior and feature gaps before selecting export/import, supported CDC tooling, or an application-assisted migration.

Cutover Phases

Cutover playbook - 5 phases

Before sync

1. Pre-cutover

Network setup (VPC Peering / Private Link), IP allowlist, sync user creation, IAM roles, encryption key migration to customer KMS.

Measured from the source

2. Initial sync

mongosync / Live Migration / dump-restore depending on dataset size; lag-zero achievement before cutover.

Before cutover approval

3. Validation

Schema validation, document-count match, sampled deep-equality check, application-level read tests against target.

Maintenance window

4. Cutover

Application config switch, DNS update, source goes read-only, final sync, target accepts writes.

Until exit criteria pass

5. Post-cutover

Monitor Atlas and application behavior, reconcile data, preserve the source according to the agreed recovery strategy, and decommission it only after acceptance and rollback exit criteria pass.

FAQ

MongoDB Atlas migration FAQ

Can an Atlas migration have minimal downtime?

Continuous synchronization can reduce the cutover window, but Atlas Live Migration and mongosync normally require source writes to stop while final lag clears and applications switch connection strings. A dual-write design may reduce the pause, but it introduces consistency, conflict, and rollback risks and must be validated for the application.

When should I use Atlas Live Migration instead of standalone mongosync?

MongoDB currently directs eligible migrations of 5 TB or less, or three shards or fewer, to Atlas Live Migration. For a source above 5 TB or more than three shards, use standalone mongosync or another supported migration pattern. Version, topology, authentication, network, and namespace limits still need to be checked before selecting either tool.

How long does a typical Atlas migration take?

Duration depends on source topology and version, data size, change rate, indexes, network throughput, validation depth, application release process, and the cutover window. We estimate initial sync and catch-up from measured data and change rates, then state assumptions and decision gates in the runbook.

Do you handle the network setup (PrivateLink, VPC Peering)?

Yes. We validate source reachability, IP access lists, DNS, TLS, and application connectivity. Private endpoints or VPC peering may be appropriate for application traffic, but Atlas pull migrations do not use those links for the migration data path; that path must meet the current Live Migration network requirements separately.

Can the source be kept for rollback?

The source can be preserved after cutover, but preserving it is not the same as a lossless rollback. Once Atlas accepts new writes, Live Migration does not automatically reverse-sync them. A rollback needs a pre-agreed data strategy: a supported reverse-sync workflow where applicable, validated dual writes, a back-migration, or acceptance of a defined recovery point and write pause.

Can a migration be paused or resumed?

Standalone mongosync provides documented pause and resume controls for supported workflows, which can help coordinate operational windows without discarding migration progress. Atlas Live Migration is a managed workflow with different controls. Tool version, migration state, and supported actions are confirmed in the runbook; restarting a process is not treated as the default recovery action.

What's the pricing?

Pricing is scoped from source and destination topology, versions, data and change volume, network work, compatibility gaps, validation depth, downtime target, application changes, and rollback requirements. The proposal documents assumptions, responsibilities, milestones, and acceptance criteria.

Technical review and primary sources

MongoDB Atlas migration sources

Review scope: Hosted Live Migration, standalone mongosync, supported topologies, validation, cutover, and restartable migration operations. Guidance is checked against primary documentation; deployment targets and performance outcomes remain workload- and contract-specific.

Review owner: JusDB Database Reliability Engineering team. Last reviewed: 16 July 2026.