Introduction
A step-by-step guide to help you open, configure, and run a Live Migration in NoSqlStudio — the screen that moves data into MongoDB from another source (for example a Cosmos DB account) with minimal downtime. Follow from Step 1 to the end, in order. Each step tells you what to do and what you will see.
How to read this manual
Each step has:
- Do — the exact action (open the screen, set a source, run the assessment).
- See — what should happen on screen. This is your “pass / fail”.
- Why — extra context, only when it helps (skip it if you're in a hurry).
Before you start
Concept
What a live (online) migration is
A live migration moves your data while the source database keeps serving traffic. Instead of a one-shot dump-and-restore — where you stop writes, export, import, and only then switch over — Live Migration does a full bulk copy and then keeps the target in sync with ongoing writes (CDC) until you cut over. That keeps downtime down to the brief cutover window rather than the whole copy.
Heads-up
Rehearse before you migrate for real
A real cutover redirects a production application to a new database. Run this whole walkthrough against test data and a throwaway target first, so the steps and your “See” checks are familiar before anything matters.
You will need:
- 1An active connection in NoSqlStudio — Live Migration runs on top of a live connection, so connect first.
- 2A reachable source (for example a Cosmos DB account, or another MongoDB) and a target MongoDB deployment (self-hosted or Atlas) you can write to.
- 3Enough access on both sides: read on the source, and write on the target database you are migrating into.
Estimated time for the full walkthrough: ~15 minutes.
Open & connect
Get a connection open and bring up the Live Migration screen.
Connect to a deployment
Connect NoSqlStudio to an active deployment using your connection string — for example mongodb+srv://<user>:<password>@<cluster-host>/.
The connection opens and appears in the sidebar.
Live Migration is part of the Schema & Data DataOps tools, and every one of them needs an active connection to work.
Open Live Migration
From the Home screen open the Schema & Data card, or use the menu Tools ▸ Schema & Data ▸ Live Migration (keyboard shortcut Ctrl+Alt+Y).
The 🚚 Live Migration screen opens on its own — unlike Copy, Compare and Data Mask, it is not part of the Data Operations container; it is its own dedicated screen.
Concept
Why a screen of its own
Copy, Compare and Mask are one-pass operations that live together in a tabbed Data Operations container. A migration is a longer-running, multi-phase job — assess → bulk → CDC sync → cutover — so it gets a screen of its own to show progress through each phase.
Configure source & target
Choose the source
In the source configuration, pick where the data comes from — for example a Cosmos DB connection.
The source is set and Live Migration shows it as the origin of the migration.
Live Migration is built for moving data into MongoDB from another system; Cosmos DB is a common source, but the same flow applies to any supported origin.
Choose the target
In the target configuration, pick the MongoDB deployment you are migrating into — your self-hosted cluster or an Atlas cluster.
The target is set, and you now have both ends — source and target — wired up.
Concept
Picking the scope
Before running anything, be deliberate about what you are migrating — the whole instance, a single database, or specific collections. A narrow, well-understood scope is easier to assess, faster to copy, and simpler to verify after cutover.
Assess
Run the assessment
With source and target configured, run the assessment — the first phase of the flow.
Live Migration produces a report of what will migrate and any compatibility findings between the source and the target.
Read the findings
Review the assessment before moving on: it tells you which databases and collections are in scope and surfaces anything that might need attention on the way into MongoDB.
Concept
Why you assess first
Assessment is a dry run of understanding: it inventories what is going to move and flags incompatibilities before you copy a single byte. Finding a problem in the report is cheap; finding it halfway through a multi-gigabyte bulk load is not.
Bulk load
Start the bulk copy
Start the bulk phase to copy the existing data from the source into the target.
Live progress appears as the bulk copy runs — you can watch it advance through the data.
Watch it complete
The bulk phase works through the in-scope data and reports its progress to completion.
Concept
What bulk means
Bulk is the initial full copy — a point-in-time snapshot of everything currently in scope, moved into the target. It is the heavy lifting of the migration. Writes that land on the source while (and after) bulk runs are handled by the next phase, not by this one.
CDC sync
Keep the target in step with the source while the application is still writing.
Watch the CDC sync
After bulk completes, watch the CDC sync phase as it streams ongoing changes from the source onto the target.
The target stays in sync with the source: inserts, updates and deletes that keep happening on the source are continuously applied to the target, and the lag between them trends toward zero.
Concept
What CDC is
CDC — change data capture — watches the source's stream of changes and replays them onto the target. Bulk gives you a snapshot; CDC keeps that snapshot fresh, so the application can stay live on the source the whole time the copy and catch-up are happening.
Keep the source reachable
Cutover
Cut over once lag is ~zero
When CDC lag is at or near zero, orchestrate the cutover — the final phase — to switch the application over to the target.
The migration completes the cutover and the target becomes the database your application now uses.
Concept
Minimizing downtime
Cutover is the only moment that needs a real pause. Because bulk and CDC have already done the work, the source and target are nearly identical when you cut over — so the downtime is just the short switchover window, not the whole copy. That is the entire point of an online migration.
Verify the result
After cutover, verify the target matches the source with Compare Databases (Ctrl+Alt+Shift+C) — select the two sides and review the structural diff.
Compare reports the differences (ideally none of substance) so you can confirm the migration landed everything you expected.
A migration is only done when you can prove the target is right. Compare gives you that evidence instead of a gut feeling.
Cleanup (when you're done)
Stop or close the migration when the cutover is complete (or to abandon a rehearsal run), then close the Live Migration screen.
The migration job ends and the screen closes cleanly.
Heads-up
A real cutover is a production change — it repoints a live application at a new database. Rehearse the whole flow on test data first, and only run the production cutover once every “See” in this manual matched on your dry run.
Summary of what you validated
| Stage | Feature |
|---|---|
| 1 | Open Live Migration on its own screen (Ctrl+Alt+Y) over an active connection |
| 2 | Configure the source (e.g. Cosmos DB) and the MongoDB/Atlas target, and pick a scope |
| 3 | Run the assessment and read its compatibility findings before copying |
| 4 | Start the bulk load and watch the initial full copy progress |
| 5 | Watch CDC sync keep the target current with ongoing writes on the source |
| 6 | Orchestrate the cutover at ~zero lag and verify with Compare Databases |