# Migrating MongoDB Between Servers: Dump, Restore, Replica

> Migrating MongoDB to a new server: mongodump export, mongorestore import and a replica-based move with no downtime.

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](https://www.zevshost.net/en/kb/migratsia-failov-rsync-scp/):

```
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](https://www.zevshost.net/en/kb/perenesti-bazu-dannykh/), and the final site checklist is in the article [post-migration site checklist](https://www.zevshost.net/en/kb/migratsia-proverka-posle/).

---

Source: https://www.zevshost.net/en/kb/migratsia-mongodb/