Show:
mongodump
mongosync
Live Migration
mongomirror
AWS DMS
mongoexport

MongoDB Migration Toolkit

Six tools compared: mongodump, mongosync, Atlas Live Migration, mongomirror, AWS DMS, and mongoexport — internal mechanisms, version compatibility, platform support, pros/cons, caveats, and a decision guide.

Tool Overview

Active

mongodump / restore

v100.14.0 · Dec 2025

Offline binary export/import. Snapshot-based. Classic tool for backups and small-to-medium migrations.

Active

mongosync

v1.19 · Jan 2026 · aka Cluster-to-Cluster Sync

Live cluster-to-cluster sync with continuous CDC. Primary tool for zero-downtime migrations. Officially branded as MongoDB Cluster-to-Cluster Sync.

Active

Atlas Live Migration

Atlas-hosted mongosync

MongoDB-managed migration service. Same engine as mongosync, operated via Atlas UI. Best for ≤5 TB.

EOL

mongomirror

v0.13.2 · EOL Jul 2025

Legacy live migration. Oplog-based tailing. Replaced by mongosync. No new updates.

Active

AWS DMS

v3.6.1 · May 2025

AWS Database Migration Service. MongoDB as source/target. Oplog-based CDC via replication instance.

Active

mongoexport / import

v100.14.0 · Dec 2025

JSON/CSV export & import. Human-readable format. Same package as mongodump. Best for small datasets or cross-format transfers.

Host Resource Requirements

Self-hosted tools run on your infrastructure. Managed services (Atlas Live Migration, AWS DMS) handle provisioning for you.

RequirementmongodumpmongosyncLive MigratemongomirrorAWS DMSmongoexport
Deployment ModelSelf-hosted binarySelf-hosted binaryAtlas-managedSelf-hosted binaryAWS-managed replication instanceSelf-hosted binary
CPU (minimum)1–2 cores8 CPUs minimumN/A — Atlas provisions2–4 cores (per shard)N/A — select instance class (dms.r5.large+ recommended)1 core
RAM (minimum)1–2 GB24 GB minimumN/A4–8 GBN/A — instance class dependent (8–32 GB typical)1 GB
Disk / Storage≥ source data size (BSON files written to disk; less with --gzip)Minimal — streams data, doesn't store. Verifier uses ~0.5 GB per 1M source docs.N/AMinimal — streams dataN/A — but larger instance = larger storage for task logs & sort buffers≥ source data size (JSON/CSV larger than BSON)
NetworkNot critical (file-based)High bandwidth essential — streams all data over network. Low-latency link to both source and dest.Atlas manages connectivity; you provide VPC peering / PrivateLinkHigh bandwidth to Atlas destinationWithin AWS VPC; cross-region adds latencyNot critical (file-based)
Architecture64-bit (x86_64, ARM)64-bit (x86_64, ARM)N/A64-bit (x86_64, ARM, ppc64le, s390x)N/A64-bit (x86_64, ARM)
Scaling GuidanceAdd --numParallelCollections (default 4) for faster dump. More CPU/RAM helps parallelism.Single binary handles all. More CPU helps change stream processing and index builds.Atlas auto-scales. ≤5 TB / ≤3 shards.One instance per replica set migration.Choose larger instance class (dms.r5.xlarge, 2xlarge) for high-throughput CDC.Single-threaded per collection. Script parallel runs for multiple collections.
mongosync is the most resource-hungry. MongoDB officially recommends a minimum of 8 CPUs and 24 GB RAM for the host running mongosync. The embedded verifier (enabled by default since v1.9) uses ~0.5 GB RAM per 1 million source documents. For mongodump, the bottleneck is disk space — you need enough room to store the full BSON export.

Resilience & Failure Recovery

What happens when things go wrong — and how each tool recovers. Covers self-hosted tools and managed services.

mongodump / restore

ON FAILURE

No resume. An interrupted mongodump produces a partial dump — some collections complete, others missing or truncated. mongorestore on a partial dump will insert whatever is there but the dataset is incomplete.

RECOVERY

Delete partial output and re-run. For huge datasets, dump individual databases/collections separately so a failure only requires re-dumping one piece.

RESILIENCE TIPS
Run on a machine with stable power/network
Use --archive | gzip > backup.gz to pipe directly — avoids running out of disk mid-dump
Split large migrations: --db per run
Script a checksum validation after dump completes

mongosync

ON FAILURE

Built-in 30-minute retry window (v1.18+). Transient network/cluster errors are retried automatically. If mongosync process crashes, state is persisted on the destination cluster in mongosync_reserved_for_internal_use database.

RECOVERY

Resume via API: Restart the mongosync binary and call POST /api/v1/resume. It picks up from where it left off using state on the destination. Takes ~2 min to re-enter RUNNING state. No data loss, no re-copy.

RESILIENCE TIPS
Run mongosync under systemd with Restart=on-failure
Monitor /api/v1/progress — watch estimatedOplogTimeRemaining
Size source oplog generously (2–3x expected copy duration)
Script health checks: if process exits, auto-restart + call /resume
Set up alerts on the warnings field in progress API (v1.19)

mongomirror

ON FAILURE

No resume, no retry. If mongomirror crashes or loses connection, the migration stops. If the oplog rolls over before you restart, you must start from scratch — drop destination data and re-run.

RECOVERY

Restart mongomirror with same arguments. If initial sync had completed and oplog hasn't rolled over, it resumes tailing. Otherwise: clean destination, re-run from scratch.

RESILIENCE TIPS
Do not use for new migrations — EOL
If stuck on legacy: large oplog, stable host, fast network
Avoid renameCollection or $out during migration
Do not restart the primary during initial sync

Atlas Live Migration

ON FAILURE

Atlas manages retries internally using the same mongosync engine. Transient errors are retried automatically. However, you have zero visibility into retry logic — no logs, no retry count, no timeout configuration.

RECOVERY

If migration fails: Atlas shows a failure banner in the UI. There is no resume — you must restart the migration from scratch via the Atlas UI. Destination data from the failed attempt must be cleaned up (Atlas handles this on restart).

RESILIENCE TIPS
Verify network connectivity (VPC peering / PrivateLink) before starting — this is the #1 failure cause
Test with a small migration first to validate the network path end-to-end
Monitor progress in the Atlas UI — stalled percentage = likely network issue
No pause/resume — a failure means starting over
No direct log access — dependent on MongoDB support for debugging
No configurable retry window or timeout tuning

AWS DMS

ON FAILURE

Multi-AZ failover available. If the replication instance fails, Multi-AZ automatically provisions a standby and fails over. For CDC tasks, DMS stores a checkpoint — but if the source oplog rolls over before recovery, the CDC stream is broken and a full-load restart is required.

RECOVERY

Stop and restart the task. CDC tasks resume from the last checkpoint. Full-load tasks restart from scratch. Use cdc-start-position to manually set oplog resume point if needed. Table statistics in the console show per-collection progress.

RESILIENCE TIPS
Enable Multi-AZ on the replication instance for automatic failover
Set up CloudWatch alarms on CDCLatencyTarget and CDCIncomingChanges
Use DMS data validation task to verify row counts and data integrity post-migration
Size the replication instance generously — dms.r5.xlarge+ for production workloads
Oplog rollover during extended outage = full-load restart
No DDL replay — schema changes during recovery may cause task errors

mongoexport / import

ON FAILURE

No resume. An interrupted mongoexport produces a truncated JSON/CSV file. mongoimport on a truncated file will fail on the malformed last line but import everything before it.

RECOVERY

Delete partial output and re-run. For mongoimport, use --mode=upsert to safely re-import without duplicates. One collection at a time, so failures are scoped.

RESILIENCE TIPS
Export one collection per command — failures are isolated
Use --query to break large collections into chunks
Pipe through gzip to reduce disk usage
No parallelism — script it yourself

How Each Tool Works Internally

The migration mechanism — oplog, change streams, or query cursor — determines capabilities and limitations.

mongodump / mongorestore

Query Cursor + Oplog (optional)
1
mongodump reads documents via standard query cursors (find({}) scan). Each collection serialized to BSON files. Metadata stored as JSON sidecar files.
2
Optional --oplog captures oplog entries during dump for point-in-time consistency. Without it, the dump is not consistent if writes are happening.
3
mongorestore reads BSON and inserts into target. Indexes rebuilt after data. --oplogReplay replays captured entries for point-in-time.
⚠ Not live. Source must be quiesced or --oplog used. Transfer is via files, not network streaming.

mongosync

Change Streams (CDC)
1
Opens a change stream on source and records resume token — marks the CDC start point.
2
Collection copy: Bulk-copies all docs from source to destination. Parallelized across collections. Indexes batched in parallel (v1.19+).
3
CDC phase: Replays change stream events (inserts, updates, deletes, DDL). Continues until you call commit via API.
4
Commit / cutover: Final changes applied, source caught up. Switch connection string. Downtime: seconds to minutes.
Uses change streams (not raw oplog) — works across different topologies. Source oplog must survive initial copy duration.

Atlas Live Migration

Hosted mongosync
1
Click "Migrate" in Atlas UI. Atlas provisions a mongosync instance and connects to your source (needs VPC peering or public IP).
2
Same mechanism as mongosync: Change stream → collection copy → CDC. Monitor via Atlas dashboard.
3
Cutover: Atlas shows "Ready to cut over". Finalize migration, last changes applied, destination promoted.
Same engine, zero management. Limited to ≤5 TB / ≤3 shards. No tunable params, no pause/resume, no direct logs.

mongomirror

Direct Oplog Tailing
1
Initial sync: Copies all collections from source to Atlas destination via standard queries.
2
Oplog tailing: Directly tails local.oplog.rs. Replays oplog entries on destination in real-time.
3
Cutover: When caught up, stop source writes and switch connection string. Manual coordination.
⚠ EOL July 2025. No pause/resume, no filtering, no MongoDB 7.0+ support. Use mongosync.

AWS DMS

Query Scan + Oplog (CDC)
1
Replication instance provisioned in AWS. Source + target endpoints configured. Requires replica set for CDC.
2
Full-load: Reads via MongoDB queries. Transforms to document mode (single _doc JSON column) or table mode (flattened).
3
CDC: Tails oplog on source. Applies inserts/updates/deletes through replication instance. Does not replicate DDL.
Extra network hop. Document mode preserves schema; table mode flattens it. Schema changes require a new task.

mongoexport / mongoimport

Query Cursor → JSON/CSV
1
mongoexport queries documents via standard cursor (find). Outputs one document per line as Extended JSON or CSV. No BSON — human-readable text format.
2
Transfer files via scp, S3, or any file transfer. JSON files are larger than BSON equivalents.
3
mongoimport reads JSON/CSV and inserts into target. Supports --mode=upsert for idempotent re-imports. No index migration — manual rebuild required.
⚠ Not live. One collection at a time. Extended JSON can lose some BSON type fidelity (Decimal128, dates). Use mongodump for full-fidelity binary transfer.

Feature Matrix

Toggle tools in the filter bar to focus your comparison.

CapabilitymongodumpmongosyncLive MigratemongomirrorAWS DMSmongoexport
MechanismQuery cursor + oplogChange streamsChange streams (hosted)Direct oplog tailingQuery scan + oplogQuery cursor → JSON/CSV
Zero-Downtime✗ Offline✗ Offline
Continuous CDC✗ Snapshot✓ Until commit✓ Until cutover✓ Until stop✓ Ongoing✗ Snapshot
Collection Filtering--db --collection --queryincludeNamespaces + regex✓ Inherits mongosync✗ Full cluster✓ Table mappings--db --collection --query
Sharded Clusters✓ Per-shard or mongos✓ Full (mismatched OK)✓ ≤3 shards✗ Replica sets only△ Limited✓ Via mongos
Pause / Resume✓ API✓ Task stop/start
Index Migration✓ Metadata + rebuild✓ Parallel batched✗ Manual✗ Manual
Queryable Encryption
DirectionAny → AnyAny → AnyAny → AtlasAny → AtlasAny → Any (AWS)Any → Any
Multi-Cloud✓ Portable files✓ Cross-cloud△ Dest = Atlas△ Dest = Atlas✗ AWS only✓ Portable files
Compression--gzip / --archive✓ Wire✓ Auto✓ Wire△ Depends✗ Pipe to gzip
Monitoring✗ Stdout/progress API✓ Atlas UI△ Stdout✓ CloudWatch✗ Stdout
Managed Service✗ Self-run✗ Self-run✓ Atlas✗ Self-run✓ AWS✗ Self-run

Platform & Target Support

Which source → destination combinations each tool supports.

PlatformmongodumpmongosyncLive MigratemongomirrorAWS DMSmongoexport
MongoDB EA / Community✓ Source & Target✓ Source & Target✓ Source only✓ Source only✓ Source & Target✓ Source & Target
MongoDB Atlas✓ Source & Target✓ Source & Target✓ Dest (required)✓ Dest (required)✓ Source & Target✓ Source & Target
Amazon DocumentDB✗ Not real MongoDB✗ No change streams✓ Via DMS endpoint△ Partial API compat
Cosmos DB (vCore)△ mongodump works; restore limited✗ No change stream compat△ vCore as source✗ No DMS endpoint△ Export works; import limited
Cosmos DB (RU)△ Partial API compat✗ Wire protocol gaps△ Partial
Self-managed replica set✓ Any (inc. standalone)✓ Replica sets & sharded✓ Source✓ Source (RS only)✓ Source (RS for CDC)✓ Any (inc. standalone)
Key takeaway: DocumentDB and Cosmos DB are not MongoDB — wire protocol gaps mean most native tools fail. AWS DMS is the only tool with a native DocumentDB endpoint.

MongoDB Version Support

VersionmongodumpmongosyncLive MigratemongomirrorAWS DMSmongoexport
4.2
4.4✗ (dropped v1.19)
5.0✓ Source
6.0✓ ≥6.0.17△ Max
7.0✓ ≥7.0.13
8.0✗ EOL
Key constraint: mongosync v1.19 requires source 6.0.17+ or 7.0.13+. mongodump and mongoexport have the broadest support (4.2–8.0). AWS DMS supports 3.6+ as source.

Collection & Database-Level Migration

Not every migration is a full cluster copy. Here's how each tool handles selective migration.

mongodump

--db myDatabase
--collection orders
--query '{"status":"active"}'
--excludeCollection logs

Filter by db, collection, or query predicate.

mongosync

includeNamespaces: [{
  "database": "prod",
  "collections": ["orders"]
}]

Regex since v1.1/v1.6. Immutable after sync starts.

Atlas Live Migration

Inherits mongosync filtering. Configured via Atlas UI during setup.

mongomirror

No filtering.

Full cluster only. Key reason it was replaced.

AWS DMS

"rule-action": "include",
"table-name": "%orders%"

Wildcard table mapping rules + transformations.

mongoexport

--db myDatabase
--collection orders
--query '{"status":"active"}'
--type json|csv

One collection at a time. Filter by query. CSV requires --fields.

Pros & Cons

mongodump / restore

PROS
Broadest version support (4.2–8.0)
Works anywhere — no network dep
Granular filtering (--query)
Simple — one binary, no infra
Portable BSON backup artifact
CONS
Offline — requires downtime
Slow for large datasets
No CDC — snapshot only
Index rebuild on restore is expensive

mongosync

PROS
Zero-downtime live migration
Change-stream-based — topology agnostic
Pause/resume via API
Namespace filtering with regex
Parallel index builds (v1.19)
Progress API with ETA
CONS
Requires MongoDB 6.0+ source
No standalone support
Self-hosted — you manage it
Oplog must survive initial copy

Atlas Live Migration

PROS
Fully managed — zero infra
Atlas UI monitoring
Zero-downtime
Network connectivity wizards
CONS
Destination must be Atlas
Limited ≤5 TB / ≤3 shards
No pause/resume
No tunable parameters
No direct log access

mongomirror

PROS
Simple oplog-based — battle-tested
Low resource footprint
CONS
EOL — no updates since Jul 2025
Max MongoDB 6.0
No collection filtering
No sharded cluster support
No pause/resume
Destination must be Atlas

AWS DMS

PROS
Broadest source versions (3.6+)
Fully managed AWS service
CDC via oplog
Table mapping filtering
CloudWatch monitoring
CONS
No index migration
Cannot handle DDL during CDC
AWS-only infra
Document mode loses schema fidelity
Extra network hop

mongoexport / import

PROS
Human-readable JSON/CSV output
Works with non-MongoDB targets
Broadest version support (4.2–8.0)
Granular --query filtering
Upsert mode for idempotent imports
CONS
Offline — requires downtime
Loses BSON type fidelity (dates, Decimal128)
No index migration
One collection at a time
JSON files larger than BSON
No parallelism built-in

Caveats & Gotchas

What catches people in production.

mongodump — Oplog window risk. Without --oplog, dump is inconsistent during writes. With it, oplog must not roll over before dump completes. Large DBs = high risk.
mongodump — BSON metadata is version-sensitive. Metadata files may not be compatible across major versions. Data BSON is safe; metadata restoration may fail silently.
mongosync — Oplog must survive initial copy. If oplog rolls over during collection copy, sync fails. Size your oplog for the expected copy duration.
mongosync — Filters are immutable. includeNamespaces / excludeNamespaces cannot be changed after sync starts. Must restart entirely.
Live Migration — Network is the #1 blocker. Atlas must reach your source. VPC peering / PrivateLink / public IP required. Setup often takes longer than migration.
Live Migration — No debugging tools. No direct mongosync log access. Dependent on Atlas support for troubleshooting.
mongomirror — EOL = no security patches. Vulnerabilities after Jul 2025 won't be fixed. Security risk in production.
mongomirror — Silent failures on 7.0+. Connection errors or silent data inconsistencies. Never tested against these versions.
AWS DMS — No DDL replication. create, rename, drop collection not replicated. Schema changes during migration require a new task.
AWS DMS — Document mode vs table mode. Document mode: single JSON column (no SQL). Table mode: flattened (loses arrays/nesting). Neither ideal for Mongo-to-Mongo.
mongoexport — BSON type loss. Extended JSON preserves most types, but Decimal128, dates, and binary may not round-trip perfectly. Always validate after import. Use mongodump for full-fidelity Mongo-to-Mongo.
mongoexport — No --oplog equivalent. Unlike mongodump, there is no way to capture ongoing writes during export. The dataset is only consistent if writes are paused.

Release Timeline

Jan 2026
mongosync v1.19 — Parallel index builds, dropped MongoDB 4.4 source
Dec 2025
mongodump v100.14.0 — MongoDB 8.2 support, security fixes
Nov 2025
mongosync v1.18 — Hot document ID handling, 30-min retry
Jul 2025
mongomirror EOL — No further updates or support
May 2025
AWS DMS v3.6.1 — MongoDB 7.0/8.0 support
2023
mongosync v1.1 — Namespace filtering added
2022
mongosync v1.0 GA — Replaces mongomirror
2020
mongodump v100.0.0 — Decoupled from server binary

Which Tool Should You Use?

Start at the top. Follow the branches.

Can you afford downtime?
↓ Yes
Dataset size?
↓ Small / need JSON
mongoexport / importHuman-readable. One collection at a time.
↓ Medium / Large
mongodump / restoreBinary BSON. Full fidelity. Any version 4.2+.
↓ No — zero-downtime
Source is MongoDB 6.0+?
↓ Yes
Destination is Atlas?
↓ Yes, ≤5 TB
Atlas Live MigrationFully managed. No infra.
↓ Any / >5 TB
mongosyncSelf-hosted. Full control.
↓ No — 4.x / 5.x
Upgrade source, or:
AWS DMS3.6+ support. No indexes, no DDL.
Do not use mongomirror. EOL since July 2025. No security patches, no 7.0+ support. Complete any in-progress migrations and switch to mongosync.

Worthy Mentions

Not covered in depth here, but worth knowing about if you're evaluating the full landscape.

Azure Database Migration Service

Azure's equivalent of AWS DMS. Supports MongoDB as a source via the MongoDB API for migrating to Cosmos DB vCore. Less relevant for Mongo-to-Mongo-Atlas, but the go-to path if your destination is Azure.

Debezium (MongoDB Connector) + Kafka

Open-source CDC via change streams, streamed through Kafka. Not a migration "tool" per se, but some teams build custom migration pipelines with it — especially when they need to transform data in-flight or fan out to multiple destinations.

MongoDB Relational Migrator

Purpose-built for migrating from relational databases (Oracle, SQL Server, PostgreSQL, MySQL) to MongoDB. Not for Mongo-to-Mongo migrations. Includes schema analysis, mapping rules, code conversion, and CDC sync.

References & Documentation