Atlas migration stalled — sound familiar?
- ▸ mongosync stalled with no error — Status endpoint returns "running" but nothing's moving; restart loses replication position, dual-write window has to be extended again, customer SLAs at risk.
- ▸ Atlas Live Migration timing out — Tool reports success but the read-from-source step hangs at >500GB; dataset size puts you outside the supported envelope but you don't want to rebuild the cutover playbook from scratch.
- ▸ 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 Migration Services
MongoDB Atlas migration via mongosync, Atlas Live Migration, or change-stream dual-write. Self-hosted → Atlas, cross-region, cross-cluster cuts with zero or near-zero downtime.
Migration Paths
Three migration paths we run
Self-hosted → Atlas (Live)
Atlas Live Migration for clusters under 500GB and single-shard; we handle IP-allowlist, Private Link, sync validation, cutover read-only window.
Self-hosted → Atlas (mongosync)
mongosync for larger clusters or sharded topologies; we configure source/target, monitor lag, manage restart-resume after network blips.
Self-hosted → Atlas (dual-write)
Application-level dual-write + change-stream catch-up; for the largest datasets or when downtime tolerance is zero. Most operationally complex but most flexible.
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
DocumentDB→Atlas via mongodump/restore or AWS DMS; we solve the wire-protocol-version compatibility (DocumentDB targets MongoDB 4.0, missing features must be remapped).
CosmosDB → Atlas
Azure CosmosDB Mongo API → Atlas via mongosync (if compatible) or custom CDC + dual-write; we audit the CosmosDB-specific dialect quirks first.
Cutover Phases
Cutover playbook — 5 phases
1. Pre-cutover
Network setup (VPC Peering / Private Link), IP allowlist, sync user creation, IAM roles, encryption key migration to customer KMS.
2. Initial sync
mongosync / Live Migration / dump-restore depending on dataset size; lag-zero achievement before cutover.
3. Validation
Schema validation, document-count match, sampled deep-equality check, application-level read tests against target.
4. Cutover
Application config switch, DNS update, source goes read-only, final sync, target accepts writes.
5. Post-cutover
Monitor for replication lag from source (if kept hot for rollback), de-commission source after rollback window, capture post-cutover metrics.
FAQ
Common questions
Ready to talk Atlas?
Book a 30-minute scoping call. Atlas-specialist DBA on the call, not L1.