Skip to main content
Menu

Cosmos DB to MongoDB

Live migration from Cosmos DB to MongoDB Atlas

Use Dsync to move from Cosmos DB to MongoDB Atlas while the application keeps serving traffic. Realize the benefits of Atlas in minutes rather than months.

Book a free assessmentTry Dsync

What actually changes between Cosmos DB and MongoDB Atlas

Cosmos DB for MongoDB is wire-compatible with MongoDB, not identical to it. The differences that matter for a migration are in the plumbing rather than the query language: change streams exist per collection with no database-level stream, they carry no timestamps, and they do not emit delete events. Provisioned throughput is metered in request units, so a bulk read that would be routine against a replica set can throttle the source or blow through the RU budget, and the practical ceiling on parallel change streams is in the low tens before performance degrades.

A migration therefore has three jobs that a plain copy does not: partition the initial copy so it moves fast without starving production traffic, keep one change stream per collection in step with that copy so writes during the migration land exactly once, and find deletes some other way because the stream will not tell you about them. Dsync does all three in one process — the deletes by periodically scanning the source index and applying the difference — reading Cosmos DB directly and writing to Atlas with no broker, staging bucket or SaaS tier in between, and it exposes throughput, lag and per-namespace progress in a CLI and a web UI while it runs.

On the Atlas side the work is mostly preparation: recreate indexes deliberately rather than by inference (Cosmos DB's automatic indexing hides which ones the application actually relies on), decide the cluster tier from measured working-set size rather than RU history, and review anything that depended on Cosmos-specific behavior such as TTL semantics or the 429 back-off your drivers learned to tolerate. The cutover itself is a DNS or connection-string change once verification shows the two sides match, and the same tool run in reverse is the fallback if you need to return.

Why Cosmos DB to MongoDB is harder than it looks

The usual approach

  • Dump and restore is slow and fragile, and needs prolonged downtime
  • Azure Data Factory and general ETL tools are not optimized for migration
  • Kafka-based DIY takes weeks to months of setup, orchestration and custom code
  • Cosmos DB's MongoDB API has behavioral differences that surface late
  • Atlas Live Migrate and mongomirror do not accept Cosmos DB as a source

With Dsync

  • The application keeps writing to Cosmos DB until the moment you cut over
  • Initial copy is partitioned on _id ranges and read in parallel at a load level you choose, checkpointed so an interruption resumes
  • Change streams are coordinated per collection with the snapshot, so nothing written mid-copy is lost
  • Deletes, which Cosmos DB's change stream never emits, are detected by a periodic index scan
  • Verification is a flag, and back-out is the same command run in reverse

How the migration runs

dsync $COSMOS $ATLAS
  1. 01

    Parallelized, resumable initial copy

    • 10–100× faster than scripts
    • Resumes from checkpoint
    • Progress via CLI or web UI
  2. 02

    Real-time incremental sync and CDC

    • 1000+ ops/sec on active workloads
    • Automatic resume after interruption
    • Seamless handover from the copy
  3. 03

    Verified cutover

    • No downtime out of the box
    • Embedded integrity checks
    • Back out by reversing direction

See it running

What a migration actually looks like

Not a mockup. The command line, the web UI and the integrity check, from a real run.

The dsync command-line interface during a migration, showing per-collection progress and throughput.
Command line — progress, throughput and lag per namespace, live.
The dsync web interface showing a running migration with source, destination and status.
Web UI — the same run, for people who are not in a terminal.
The dsync data integrity check comparing record counts and contents between source and destination.
Integrity check — evidence the two sides agree, before you cut over.

Proof

“We utilized dsync to handle the migration of two production databases from Cosmos DB to MongoDB. The tool was incredibly efficient, allowing us to bypass the manual overhead of writing custom migration logic. It delivered exactly what was promised: speed, reliability, and risk elimination. I highly recommend it to any team looking to streamline their data synchronization.”
Senior EngineerMultinational retail and finance company

Cosmos DB to MongoDB migration questions

Does this work for both Cosmos DB APIs?

Yes. Dsync reads Cosmos DB for MongoDB (RU and vCore) and Cosmos DB for NoSQL as sources. The mechanics differ — the MongoDB API uses change streams, the NoSQL API uses the change feed — but the migration runs the same way and lands in MongoDB Atlas or any MongoDB-compatible destination.

How much downtime should we plan for?

None for the copy and the catch-up phase; the application keeps writing to Cosmos DB throughout. The cutover is the time it takes to point the application at Atlas, typically a connection-string change and a restart. Teams that cannot pause writes at all keep both sides in sync and flip traffic gradually.

Cosmos DB's change stream does not include deletes. How are they handled?

Dsync has a Cosmos-specific mode that periodically scans the source index and removes on Atlas whatever has disappeared from Cosmos DB, so deletes made during the migration are applied before cutover. If the application can soft-delete during the migration window that is simpler still, but it is not required.

How long does the initial copy take?

It depends on data size, document shape and how much RU headroom the source has. The copy is partitioned on _id ranges and reads in parallel, and it resumes from its last checkpoint if interrupted, so a 100 GB collection is hours rather than days and a failure does not mean starting over. We give an estimate on the assessment call from your actual collection sizes.

Will the migration throttle production traffic on Cosmos DB?

You control it. Dsync's load level sets how many reader and writer threads it uses, from Low to Beast, and a write rate limit on the destination throttles the source through back-pressure. Most teams run the copy at a level that keeps 429s off the application and let it take longer; the change stream keeps everything written in the meantime.

What if we need to go back to Cosmos DB after cutting over?

Run the same command with the reverse flag. Dsync starts a change-data-capture flow with Atlas as the source and Cosmos DB as the destination, skipping the initial copy, so writes made after cutover flow back. That is why we recommend keeping the Cosmos DB account for a defined period rather than deleting it at cutover.

More on Cosmos DB to MongoDB

Free migration assessment

Tell us your Cosmos DB setup and target, and we will map the path.

We reply within one business day. Your details are handled per our privacy policy.