Transformation: self-managed MongoDB to MongoDB Atlas or Azure Cosmos DB for MongoDB (vCore)

#Choosing the target

If the app uses advanced or new MongoDB features, Atlas is the low-risk choice. If Azure-native integration and billing matter and the app uses common features, test vCore against your workload.

#1. Inventory and compatibility

db.adminCommand({ listDatabases: 1 })
db.getCollectionInfos()                         // capped, time series, views, validators
db.orders.getIndexes()
db.serverStatus().version

• Text indexes, geospatial indexes, time series and capped collections, transactions, change streams: check each on the target.
• Run the app's integration tests against a small target cluster early.

#2. Size the target

Use working set (indexes plus hot data) to choose RAM, and the source's peak ops/sec and storage growth for tier and disk. Atlas tiers (M30, M40...) and Cosmos vCore tiers both scale up later without migration.

#3. Migrate

#Online to Atlas

• mongosync (cluster-to-cluster sync) or Atlas Live Migration (pull-based in the Atlas UI): initial sync, then continuous sync until you cut over.
• Requirements include a source user with the right roles, network access from Atlas to the source (or a migration host), and supported source versions. Check the current docs.

mongosync --cluster0 "mongodb://user:pwd@src1:27017,src2:27017/?replicaSet=rs0" \
          --cluster1 "mongodb+srv://user:pwd@cluster0.abcd.mongodb.net" &
curl localhost:27182/api/v1/start -XPOST --data '{"source":"cluster0","destination":"cluster1"}'
curl localhost:27182/api/v1/progress -XGET

#Online / offline to Cosmos DB vCore

Use Microsoft's current migration tooling for MongoDB to Cosmos DB vCore (online and offline modes), or offline dump/restore. The tooling has changed over time; follow the current Azure documentation for your source version.

#Offline (any target)

mongodump --uri "mongodb://user:pwd@src1:27017/?replicaSet=rs0" --gzip --archive=/mnt/dump/all.gz
mongorestore --uri "<target connection string>" --gzip --archive=/mnt/dump/all.gz --numParallelCollections=4

Use --oplog / --oplogReplay for a consistent snapshot of a replica set during the dump.

#4. Validate

• Document counts per collection; sample documents compared by _id.
• Indexes present (and built) on the target.
• App tests, especially aggregation pipelines and transactions.
• Performance: run the top queries (from the source's profiler / slow query log) and check explain() on the target.

#5. Cut-over

1. Stop writes (app maintenance or revoke write roles).
2. Wait for sync lag 0 (online tools show it), then commit/cut over in the tool.
3. Switch connection strings (Atlas uses mongodb+srv://, TLS on by default; vCore has its own connection string format).
4. Keep the source read-only for the rollback window.

Tip

Update drivers before migrating. Older drivers may not support the target's TLS, +srv connection strings or server version.

#Checklist

• Target chosen after compatibility testing
• Sized from working set and peak load
• Migration rehearsed with sync lag measured
• Counts, indexes and app tests validated
• Drivers updated; connection strings switched