Migrations You Can Watch, Verify and Prove
mongosync-ui turns MongoDB’s API-only migration workflow into one guided interface. Configure, measure, sync, verify and commit from a single screen, with real progress the whole way through.
Runs inside your infrastructure | Attaches to a run already in progress | Manages the official mongosync binary | macOS and Linux
Runs where your data already is
mongosync-ui is a single executable that runs inside the customer’s own network, with no agents to deploy and no service to stand up. It handles credentials the way an operator would want them handled: passed only where they are needed, written owner-only, redacted from anything it stores.
One Binary, No Infrastructure
A single executable with the web UI embedded. No agents, no server to stand up, and no database of its own to maintain or secure.
Credentials Passed, Not Stored
Connection strings go only to mongosync, in files written owner-only. mongosync’s control API binds to localhost by default.
Inside Your Own Network
Runs on a laptop or a jump host with reach into both clusters. Available for macOS and Linux, with a Windows build subject to mongosync’s own platform support.
Nothing Sensitive Written Down
Passwords are redacted in the stored session history, and webhook URLs are held in memory only, never written to disk.
One binary. One interface. The whole migration.
A single-binary web application that wraps mongosync’s API-only workflow in a guided, observable, auditable process. Same engine, same guarantees, with the operational visibility a production cutover deserves.
Configure, measure, start, monitor, verify and commit a migration from one place.
It downloads mongosync itself and verifies it by SHA-256. There is nothing else to install.
It supervises its own mongosync process, or attaches to one already running elsewhere.
A laptop or a jump host on the customer's network. Connection strings never leave it.
Built and developed by the original author, not an abandoned side project.
MongoDB Inc.’s mongosync is the official tool for cluster-to-cluster migration. It is powerful, and it is a command-line binary driven by an HTTP API. Everything around the copy itself, the setup, the tracking, the proof, is left to whoever is running it.
How It Works
1. Configure
Set the run up once, correctly
Source and destination connection strings, verification mode, and mongosync’s tuning options, all grouped and explained on one screen rather than assembled as command-line flags. Fields validate as you fill them, so a malformed connection string or an unreachable host surfaces here, not forty minutes into a run.
Let it manage the binary. mongosync-ui downloads mongosync, verifies it by SHA-256 and supervises the process itself. Nothing to install and nothing to keep in sync.
Or attach to one already running. Point it at a mongosync instance on a jump host or anywhere else on the network, including one that started before mongosync-ui was in the picture, and drive it from there.
2. Measure
Find out what you are actually moving
Before a single document moves, mongosync-ui queries the source cluster directly and reports the size of the job: bytes, documents and collections in scope, read from the cluster rather than estimated from it.
Narrow the scope and the measurement follows. Pick specific databases, add collection filters, and the totals update live as you cut things out, so you can see what each exclusion is worth before you commit to it. That figure then does real work for the rest of the run: it becomes the denominator behind the progress bar, which is why the progress you see later is progress against something measured rather than against mongosync’s own pre-start guess.
3. Sync
Watch it run instead of wondering
The initial copy and the live change events run together, and both are visible. Copy progress reads against the measured total, with collections finished and remaining, index-build strategy and progress, and warnings surfaced as they occur rather than buried in a log you have to go looking for.
Alongside it, the replication side: change events applied to the destination, replication lag with a catch-up estimate, and how much oplog window you have left. The raw mongosync log is in the interface too, for the moments when you want to see exactly what the binary is saying. Pause, resume and reverse are available throughout.
Slack and Microsoft Teams notifications carry launch, control, verification and failure events out to the team, so an overnight run does not need somebody sitting with it.
4. Verify
Prove the destination matches, while it copies
Verification is not something you run afterwards and hope for. It progresses alongside the copy, comparing documents and source bytes while the migration is still moving, so problems surface during the window rather than after you have closed it.
You choose the mode at setup: no verification, mongosync’s embedded verifier, or the standalone MongoDB Labs migration_verifier. Whichever you pick, mismatches are reported individually, by namespace and document, so you can look at what actually differs. Nothing gets flattened into a single pass or fail that leaves you no better informed than before you asked.
5. Commit
Cut over when the run says you can
The commit control stays locked until the copy is complete and the destination has caught up, and while it is locked it tells you which condition is outstanding. There is no way to cut over early by accident, and no need to decide from a terminal whether now is the moment.
Until commit, the run is reversible. After it, the session closes into a permanent record: timeline, outcome, bytes copied, documents and collections verified, indexes built, with passwords redacted from the stored connection strings. That record is what you hand to a client, or hold up in the post-mortem, when someone asks what moved and whether it checked out.
Point it at a migration already in flight
You do not have to start a migration in mongosync-ui to get the benefit of it. If mongosync is already running, on a jump host, in a container, in a terminal session somebody opened days ago, mongosync-ui attaches to it and takes over the visibility.
The longest runs are the blind ones
Large migrations do not run for an afternoon. A multi-terabyte cluster can copy for days, sometimes for weeks, and for all of that time the only way to check on it is to poll the control API and read the JSON that comes back. The runs that most need watching are exactly the ones nobody can see.
Attach, and it appears
Give mongosync-ui the address of the running mongosync control API and press Attach. The migration shows up in the same monitor every other run uses: copy progress, replication lag with a catch-up estimate, the remaining oplog window, index builds, warnings as they occur, and the raw mongosync log alongside them. Nothing restarts, nothing is copied twice, and the run continues exactly as it was.
Read and control, not read-only
Attaching gives you the controls, not just the view, so the run can be managed from the interface instead of from the API. If a standalone migration_verifier is running against the same migration, point mongosync-ui at that as well and its progress arrives on the same screen. The migration stays where it is; only your view of it changes.
Know the size of the job first
Before a single document moves, mongosync-ui queries the source cluster directly and reports exactly what the run will move.
- Bytes, documents and collections in scope, read straight from the source cluster.
- Pick databases or add collection filters, and the measurement updates live as you narrow it.
- The measured size becomes the progress bar’s denominator, replacing mongosync’s own unreliable pre-start estimate.
- A defensible answer to how big this is and how long it will take, before you commit to a maintenance window.
Full visibility, live
Progress
- Copy progress against a measured total
- Collections finished and estimated remaining
- Index-build strategy and progress
- Warnings surfaced as they occur
Replication Health
- Change events applied to the destination
- Replication lag and catch-up estimate
- Remaining oplog window
- The raw mongosync log, in the UI
Verification and proof
Verification is a decision made at setup, not an afterthought, and its results are part of the migration record.
- Disabled, mongosync’s embedded verifier, or the standalone MongoDB Labs migration_verifier.
- Document comparison and source-byte comparison progress while the migration is still moving.
- Namespace and document mismatches are reported individually, never summarized into a single pass or fail.
- Commit stays locked, with the reason shown, until the copy completes and the destination catches up.
- Timeline, outcome, bytes copied, documents and collections verified, indexes built.
A full migration, start to finish
Video Demo
Let’s deliver impact
Cluster migrations stall for the same reasons every time: nobody can say how big the job is before the window opens, nobody can see where the run has got to once it starts, and nobody can prove afterwards that the destination matches the source. mongosync-ui is built for the people who carry that risk.
Consulting and delivery teams who migrate clusters for clients and have to commit to a window, hit it, and hand over a record of what moved. Platform and database teams moving production clusters in-house, at night, who would rather watch a run than poll an API in a second terminal.
MongoDB partners need a supported tool behind their migration practice rather than a stack of shell scripts that only one engineer understands. In every case, the value is the same: the copy stays mongosync’s, and the certainty around it becomes yours.
Is this a replacement for mongosync?
1Is it affiliated with MongoDB, Inc.?
2Where does it run?
3Do I need to install mongosync first?
4Which operating systems are supported?
5Can it migrate sharded clusters?
6How is verification handled?
7Can a migration be reversed?
8Can I use it on a migration that is already running?
9© Fabio Cionini