Migrate MongoDB to MongoDB
Certified — live-tested pathSame-engine MongoDB migrations are how you move between hosts, clouds, or versions — and they still fail in the boring ways: half-copied tables, stale sequences, missing indexes. DBShifts moves the schema and every row, defers constraints for speed, reseeds counters, and proves the result with row counts and checksums.
Free tier · no credit card
How the migration works
Connect
Point DBShifts at your source and target. Credentials stay encrypted; SSH tunnels supported for private databases.
Analyze
Automatic schema introspection produces a migration plan: what converts automatically, what migrates with warnings, what needs human review.
Migrate
Schema is created on the target, data transfers in parallel batches with constraints deferred, indexes rebuilt after load.
Validate
Per-table row counts, type-aware checksums on both sides, FK integrity — plus a fidelity report listing anything lossy.
You cannot skip a major version
MongoDB upgrades one major version at a time, and each step has to complete before the next begins. Moving from 4.4 to 7.0 is four upgrades, not one, and the constraint is enforced rather than advisory — the server refuses to start against data files it considers too old.
Between each step sits the feature compatibility version. Raising FCV is what actually enables the new version's behaviour and, importantly, what makes the step hard to reverse: once FCV is raised, downgrading requires bringing it back down first, and that can fail if any feature introduced at the new level is already in use. Leave FCV at the old value until the upgrade has been observed under real load, then raise it.
The oplog window is the real time limit
A live migration replays changes from the oplog, which is a capped collection. If the initial data copy takes longer than the oplog holds, the replay has nowhere to resume from and the sync has to start over — on a large dataset, that can happen repeatedly without ever converging.
So the oplog should be sized against the copy duration before starting, not after the first failure. The same applies to change-stream resume tokens, which become invalid once the entry they point at has aged out. This is the constraint that makes same-engine MongoDB moves fail, and it has nothing to do with schema or types, which is why it is easy to omit from a plan built around conversion.
Index builds are the other thing that goes wrong
Indexes are not part of the data copy; they are rebuilt on the target. On a large collection that build is expensive, and doing it while the initial sync is still running competes for the same I/O.
The order that works is data first, indexes after the bulk load, unique indexes last so that a duplicate surfaces as a build failure you can inspect rather than as a rejected insert in the middle of the copy. Verify the index list matches the source before cutover — a missing index is invisible until production traffic arrives and then is the whole incident.
MongoDB → MongoDB conversion notes
Engine-specific rules baked into the conversion and transfer pipeline — verified by live certification of this exact pair.
- Schema is inferred by sampling documents — null values don't poison type inference (a nullable int stays an int column).
- Decimal128 maps to exact DECIMAL on SQL targets, never a float round-trip.
- Nested documents and arrays land as JSON/JSONB columns with data preserved byte-for-byte.
- _id becomes the primary key; ObjectId converts to its 24-character hex form.
Frequently asked questions
Is MongoDB to MongoDB migration production-ready in DBShifts?
Yes — MongoDB to MongoDB is a certified pair. It passed DBShifts's live certification suite (schema conversion, data transfer, row counts, type-aware checksums over an edge-case fixture) and is battle-tested in production use.
How does DBShifts verify the MongoDB to MongoDB migration was correct?
Three layers: per-table row counts on both sides, an order-independent type-aware checksum of row data (canonicalized so engine representation differences don't false-alarm), and FK integrity checks on the target. Rows that fail to insert are quarantined with the exact error — never silently dropped — and can be fixed and retried from the UI.
What happens to MongoDB types that MongoDB doesn't have?
They convert by deterministic rules with a recorded decision: a native equivalent where one exists, a portable fallback (TEXT/JSON/DECIMAL) where one doesn't. Every lossy conversion appears in the migration plan before you run and in the fidelity report after. You can override any mapping per column.
Can I keep MongoDB and MongoDB in sync after the initial migration?
Yes. DBShifts supports incremental sync (UPSERT-based delta transfers on a sync key) and, for supported sources, real-time change data capture so the target stays current until you cut over.
Do I need to write any SQL or scripts for MongoDB to MongoDB?
No. Connect both databases, review the generated migration plan (what's automatic, what migrates with warnings, what needs manual review — typically triggers and stored procedures), and run. Procedural code is transpiled best-effort and queued for human review rather than auto-applied.
What changes in a same-engine MongoDB migration?
Structurally nothing changes — types map one-to-one. The risks are operational: half-copied tables, sequences left pointing at 1, and indexes that never got rebuilt. DBShifts reseeds counters to MAX(id)+1, defers then rebuilds constraints and indexes, and proves the copy with row counts and checksums.
Go deeper
Related migration paths
Ready to move MongoDB to MongoDB?
Set up in under two minutes. Validation and rollback included.
Start Free Migration