MongoDB Migration: Upgrades, Atlas Moves and Backups

A MongoDB migration is one of three projects: a version upgrade on the same cluster, a move from self-managed MongoDB to Atlas, or a move between self-managed clusters, data centers or clouds. Each has its own tool and its own failure points. All three start the same way, with a backup you have restored at least once. The procedures below follow MongoDB's documentation, checked on 9 October 2026.

MongoDB documents three backup methods for self-managed deployments, and they trade off differently:

• mongodump and mongorestore. A logical export. MongoDB describes these tools as suited to small deployments. On a replica set, run mongodump --oplog so writes made during the dump are captured, then restore with mongorestore --oplogReplay. That gives you the state at the moment the dump finished, not an arbitrary point in time. Indexes are rebuilt on restore, which is slow on large collections.
• Filesystem snapshots. LVM, EBS or your storage array's snapshots. Journaling must be on and the journal must sit on the same volume as the data files. For a sharded cluster, stop the balancer and snapshot every shard and a config server at about the same moment, which is harder than it sounds.
• Ops Manager, Cloud Manager or Atlas backups. Ops Manager (with Enterprise Advanced) and Cloud Manager read the oplog continuously and offer point-in-time recovery, including consistent sharded cluster snapshots. Cloud Manager backup requires MongoDB Enterprise Server. Atlas has scheduled snapshots and continuous cloud backup.

For a migration, the backup that matters is the one you can restore within your outage window. Restore it to a separate host, start the application against it, and record how long it took. That copy is also the right place to rehearse the migration itself. Our MongoDB backup guide compares the methods in detail.

MongoDB does not skip major versions. To reach 8.0 you must be on 7.0, and to reach 9.0 you must be on 8.0 (or 8.3). A cluster on 4.4 therefore goes 4.4, 5.0, 6.0, 7.0, 8.0, and on to 9.0 if that is the target. Each step has the same shape:

1. Confirm every member reports the current featureCompatibilityVersion (FCV) and that none is in ROLLBACK or RECOVERING.
2. Replace binaries on secondaries one at a time, run rs.stepDown() on the primary, then upgrade it. On a sharded cluster, stop the balancer, upgrade the config servers, then the shards, then the mongos routers, and re-enable the balancer.
3. Run the application on the new binaries for a burn-in period. While FCV stays on the old version, a downgrade is simpler.
4. Raise FCV on the primary or through mongos, then start the next step.

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand( { setFeatureCompatibilityVersion: "8.0", confirm: true } )

Upgrade the drivers before the servers. MongoDB says deployments running incompatible drivers can see unexpected or undefined behavior, and the driver compatibility tables list which driver release supports which server. Check the hardware too: from 5.0, MongoDB on x86_64 needs a CPU that exposes the AVX instruction set, so older hosts and some hypervisor CPU profiles stop at 4.4.

mongomirror, the tool behind the older Atlas live migration, reached end of life on 31 July 2025. Atlas live migration now runs on mongosync and comes in two forms: pull, where an Atlas-hosted migration server connects to your source, and push, for sources monitored by Cloud Manager. If your firewall cannot allow the migration servers in, MongoDB documents running mongosync yourself.

The documented paths start from a 5.0, 6.0, 7.0 or 8.0 source and land on a 7.0 or 8.0 Atlas cluster. A 4.4 or older source has to be upgraded to at least 5.0 first, or moved with mongodump and mongorestore during an outage. Standalone sources must be converted to a replica set. Clusters on rapid releases such as 8.1 or 8.2 are not supported, and you must not change FCV while the migration runs.

Cutover is the only downtime. Atlas copies data and then tails changes until you stop writes to the source, repoint the application and restart it.

Three approaches cover most moves between data centers or cloud providers:

• mongosync (Cluster-to-Cluster Sync). Copies collections, then applies changes from the source until you call commit. Sources can run 5.0 through 8.0 and destinations 7.0 or 8.0, so it can upgrade and relocate at once. It does not sync a sharded cluster into a replica set, and pre-6.0 sources cannot have DDL operations during the sync.
• Replica set member swap. Add members in the new location, let them complete initial sync, step the primary over to a new member, then remove the old ones. No extra tooling, and the application only sees an election, but source and destination must run the same version and reach each other over the network.
• mongodump and mongorestore. Simple and version tolerant, but writes must stop for the whole copy. Practical for small databases and acceptable maintenance windows.

• Inventory every cluster: version, FCV, topology, storage size and the drivers that connect to it.
• Take a backup and complete a timed restore test.
• Read the compatibility changes for every major version you will cross, not only the last one.
• Upgrade drivers and test the application against the target version in staging.
• Measure the oplog window with db.getReplicationInfo() and compare it with the expected copy time.
• Confirm disk space on the destination for data, indexes and oplog growth during the initial copy.
• Agree the cutover steps, the rollback point and who decides to roll back.

• Oplog window too short. mongosync and live migration apply source changes after the initial copy. If unapplied operations roll off the source oplog, the sync fails and has to start again. Raise the oplog size with oplogSizeMB before starting a large copy.
• Index builds. Rebuilding indexes after mongorestore can take longer than the data load. mongosync does not support rolling index builds during migration, so pause index changes until it finishes.
• FCV forgotten. A cluster upgraded binary by binary but left on the old FCV is not ready for the next step, because each upgrade requires FCV to match the current version. Running setFeatureCompatibilityVersion during an initial sync also restarts that sync.
• Driver too old. The server upgrade goes cleanly, then the application fails on connect or behaves unexpectedly. Driver upgrades belong at the start of the plan.
• Hardware without AVX. 5.0 and later binaries fail to start on hosts that do not expose AVX.

Most migration risk sits in the rehearsal and the cutover, not the tooling. AceMQ provides MongoDB support during the migration, from backup testing through cutover, for self-managed and Atlas deployments. If you are still choosing between vendor and independent coverage, see MongoDB support options. MongoDB is often one of several databases in the plan, and database support covers the rest under one contract.

Some teams cannot leave 4.2 to 6.0 quickly, because of AVX hardware, certified drivers or a long upgrade chain. OSSeva, AceMQ's extended support platform, ships patched builds of self-managed MongoDB 4.2 to 6.0 so the cluster stays covered while the migration runs. Other end-of-life support options are listed separately.

• MongoDB — Upgrade a Replica Set to 8.0
• MongoDB — Upgrade a Sharded Cluster to 8.0
• MongoDB — Upgrade a Replica Set to 9.0
• MongoDB — Backup Methods for a Self-Managed Deployment
• MongoDB — Back Up and Restore with MongoDB Tools
• MongoDB Atlas — Restore Your Cluster
• MongoDB Atlas — Migrate or Import Data
• MongoDB Atlas — Live Migrate (Pull) a Cluster into Atlas
• MongoDB Atlas — Changelog (mongomirror end of life)
• MongoDB — mongosync server version compatibility
• MongoDB — mongosync limitations
• MongoDB — mongosync oplog sizing
• MongoDB — Replace a Self-Managed Replica Set Member
• MongoDB — Production Notes (AVX requirement)
• MongoDB — Driver compatibility
• OSSeva — MongoDB extended support