MongoDB is moved in two ways: a quick offline transfer with mongodump and mongorestore for smaller databases, and a temporary replica for larger databases where a long write pause is unacceptable.
Which migration method to choose
A dump works well for databases up to 20-30 GB, when a few minutes of downtime is not critical. For larger production databases or systems with no maintenance window, add the new server to a replica set instead — the switch then takes seconds rather than the time needed for a full copy.
| Method | Database size | Downtime | Complexity |
|---|---|---|---|
| mongodump / mongorestore | up to 30 GB | minutes | low |
| Replica set (replicaof) | any | seconds | medium |
Moving with mongodump and mongorestore
On the old server, take a dump of the database in binary BSON format — it is more compact and transfers faster than a text export:
mongodump --host localhost --port 27017 --db shop --out /backup/mongo_dump
Archive the directory and transfer it to the new server with rsync, as described in the article moving site files:
tar -czf mongo_dump.tar.gz /backup/mongo_dump
rsync -avz mongo_dump.tar.gz user@newserver:/backup/
On the new server, unpack the archive and restore the database:
tar -xzf mongo_dump.tar.gz
mongorestore --host localhost --port 27017 --db shop /backup/mongo_dump/shop
The --drop flag before restoring removes existing collections with the same name, if the new server already has test data.
Moving without downtime using a replica set
Add the new server as a member of the existing replica set — MongoDB copies the data itself through initial sync and then keeps it up to date:
rs.add("newserver.example:27017")
Wait for the new node to reach the SECONDARY state with rs.status() — the stateStr field should change from STARTUP2 to SECONDARY. Then switch the primary role:
rs.stepDown()
The old server becomes secondary and the new one becomes primary, with no write downtime. Once clients have fully switched to the new address, remove the old node from the replica set with rs.remove("oldserver.example:27017").
Configuring the application connection to the new server
In the connection string, specify the new host, or, if a replica set is used, the full list of members — the MongoDB driver finds the current primary on its own:
mongodb://appuser:password@newserver.example:27017,server2.example:27017/shop?replicaSet=rs0
Check authentication: if authorization is enabled on the new server for the first time, create a user with the needed roles before switching the application, otherwise it loses access to the database right after the move.
db.createUser({ user: "appuser", pwd: "new_password", roles: [{ role: "readWrite", db: "shop" }] })
Checking the data after the move
Compare the document count in key collections on the old and new server — a mismatch points to an incomplete sync or a restore error:
db.orders.countDocuments()
db.users.countDocuments()
Check the indexes with db.orders.getIndexes() — mongorestore restores indexes automatically, but a manual export via mongoexport requires recreating them.
MongoDB migration checklist
- The right method is chosen: a dump for a small database, a replica set for production with no downtime.
- The dump was taken in BSON format and transferred without archive damage.
- The new replica set node reached the SECONDARY state before the switch.
- The application connection string is updated, authorization is set up in advance.
- The document count and indexes are checked against the old server.
- The old node is removed from the replica set only after clients fully switch over.
General principles for checking data after moving any database are covered in the article moving a MySQL database, and the final site checklist is in the article post-migration site checklist.