# Offline migration with mongodump/mongorestore
## Steps
1. Freeze writes on the source (or accept that post-dump writes are lost).
2. `mongodump --uri="[source]" --archive=dump.gz --gzip` from a host with source access.
3. Create the destination Atlas cluster and the database users there. Users do not migrate with the data; recreate them with the same names and roles.
4. `mongorestore --uri="[dest]" --archive=dump.gz --gzip`. Indexes are recreated from the dump metadata.
5. Verify counts per collection and the index list on the destination.
6. Point the app at Atlas and unfreeze.
## Rules
- This is a downtime migration: size the window from a timed trial run, not a guess.
- Large databases make huge archives; ensure disk space on the dump host and consider `--nsInclude` for partial migrations.
- `mongorestore` without `--drop` merges into existing data; with `--drop` it replaces. Choose deliberately per collection.
- Oplog replay (`--oplogReplay`) only helps for replica-set dumps taken with `--oplog`; for most Atlas landings, a clean frozen dump is simpler.
## Verify
Counts match, indexes match, the app smoke tests pass on Atlas, and no writes hit the old source after cutover (check its logs).