Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress)

Published reference · snapshot 2026-10-20 · skill mongodb-operations-expert/references/migration-and-cutover-cost-live-migration-mongosync-dual-running-egress.md · viability 3.25 / 5 (research)

↓ Facts as markdown all context files

Source-anchored research for Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress). Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

Atlas Live Migration is a free MongoDB-hosted service, and MongoDB charges nothing for data transferred into an Atlas cluster. The tool and the inbound traffic add no Atlas line item. (high confidence) (verified as of 2026-10-14) [source]

Structure and components

Exit waivers do not fund a partial move or a dual-run. Google's program bars migrating only part of a service; AWS scopes its waiver to all data off AWS or off one AWS service; Azure scopes its waiver to customers leaving Azure. A team that keeps part of its estate on the old cloud should assume list egress rates apply to the data it moves. (medium confidence) (verified as of 2026-10-20) [source]
Google's exit process runs in stages: an Exit Notice, then 14 days for agent assignment and review, then a 30-day Initiation Period to start the move, then a Migration Period of at least 30 days (longer if Google or the customer asks for more time). A Completion Notice follows within 180 days, and termination takes effect at the next month end at least 30 days later. The program is per service, and moving only part of a given service is not permitted. (low confidence) (verified as of 2025-09-11) [source]
A migration bill has these parts. This list is derived from the sources; it is not a published formula. Destination hours at the elevated tier through initial sync, lag drain, cutover and any hold. Source environment hours until the rollback window closes. Any staging cluster from a rehearsal. The mongosync host for standalone runs. Egress billed by the source provider. Application downtime. Exit-program credits offset only the egress part. The CMA's customer research found switches usually run two sets of services at once and keep the old one for a while in case of problems. (medium confidence) [source]

How it works

Moving data into Atlas incurs no ingress fee: Atlas does not charge for incoming data transfer to an Atlas cluster, and AWS states there is no charge for inbound data transfer across all services in all Regions. The metered leg is the sender's egress, billed by the source's provider, or by Atlas when the source is an Atlas cluster. (high confidence) (verified as of 2026-10-20) [source]
Atlas starts an extendable 120-hour (5-day) timer when it detects that source and destination are nearly in sync. When the timer expires, Atlas stops synchronizing and the user must retry the migration. The timer starts after the initial copy, so dual-running lasts the initial-copy time plus up to 120 hours, or more if the user extends the sync. (high confidence) (verified as of 2026-10-20) [source]
In a mongosync cutover, application downtime runs from stopping writes on the source until the application can write to the destination after /progress reports canWrite: true. Start only when canCommit is true and lag.overallLagSeconds is near 0. If the embedded verifier is on, also require both verification documents to show lagTimeSeconds near 0 in the 'stream hashing' phase. If lag is not near 0 when cutover starts, the cutover can take a long time. With default settings mongosync blocks source writes once the user requests commit, and the user must first wait for open source transactions to commit or abort. (high confidence) [source]
Google Cloud's free exit transfer (announced 11 January 2024) covers internet transfers off a Google Cloud service when the customer leaves that service completely, and only for products listed in Google's data-portability terms. Steps: submit an Exit Notice; Google assigns a billing-support agent within 14 days; the customer starts migrating within a 30-day Initiation Period; the Migration Period lasts at least 30 days; the customer sends a Completion Notice within 180 days after the Migration Period; the credit appears on the final invoice; the agreement for that service ends after at least 30 more days. (high confidence) (verified as of 2026-10-20) [source]
The EU Data Act (Regulation (EU) 2023/2854) defines 'switching charges' to include data egress charges (Art. 2(35)-(36)); standard service fees and early termination penalties are outside the definition. From 12 January 2027, providers of data processing services may not impose any switching charges. From 11 January 2024 until 12 January 2027 they may impose only reduced charges that do not exceed their costs directly linked to the switching process (Art. 29(1)-(3)). (high confidence) (verified as of 2026-10-20) [source]
A pull live migration is a bounded dual-running window. The source keeps taking writes while the destination, which is write-blocked, syncs. When the clusters are nearly in sync, Atlas starts an extendable cutover timer. When the timer expires, Atlas stops syncing from the source. (high confidence) [source]
AWS pays for leaving as credits, not as zero-rated traffic. AWS offers free data transfer out to the internet when a customer moves all data off AWS from all eligible payer accounts, or all data off one AWS service. The customer goes through AWS Support, and AWS applies extra scrutiny when the same account asks more than once. (high confidence) (verified as of 2026-10-08) [source]
Google credits the egress on the customer's final invoice. The credit covers the workloads and production data on Google Cloud when the customer submitted the Exit Notice. The customer must submit the Exit Notice before any migration it expects a credit for. Free transfer covers internet transfers for the products on Google's data-portability list. (high confidence) (verified as of 2025-09-11) [source]
AWS and Google size the credit on the data stored when the request is made, so the credit covers moving each byte once. A migration that moves data more than once can exceed it, for example re-seeding, or a forward sync plus a reverse sync kept for rollback. That example is an inference from the CMA's reasoning. The CMA judged AWS and Google credits insufficient for temporary multi-cloud use during a switch. Microsoft told the CMA its program covers multi-cloud egress inside the 60-day window for a total switch. (medium confidence) (verified as of 2025-07-31) [source]
Respect the write rules or lose data. Atlas blocks writes on the destination when a live migration starts. Other clients must not write to the destination while mongosync runs. A write to the source during commit can cause data loss. (high confidence) [source]
A reversible rollback window lengthens the dual-running bill. Both clusters stay in service, and reverse sync replicates every post-cutover write on the destination back to the old source. When the destination is Atlas, that flow is outbound transfer, which Atlas bills (Atlas charges outbound but not inbound). This cost is derived from the reverse-sync and Atlas pricing docs; neither states it. (medium confidence) (verified as of 2026-10-14) [source]
The Atlas Live Migrate (Pull) procedure does not describe a reverse sync. A 2021 customer request asks for a fallback sync because there is no way to sync data in reverse after a Live Migrate cutover. MongoDB's comparison page lists reverse sync as a row that differs between Atlas Live Migration and standalone mongosync. Treat rollback from a managed pull migration as unavailable until MongoDB confirms otherwise. (low confidence) (verified as of 2026-10-20) [source]
Documents updated very frequently (hot documents) cause replication lag that delays a low-lag commit. mongosync 1.18 added --hotDocIDs to copy named hot documents at the commit stage. The option is not retained on a reverse sync, so restart mongosync with hot document IDs for the reverse direction. (high confidence) (verified as of 2026-10-20) [source]

Measurements and reference values

The mongosync destination needs disk for the logical data plus the destination oplog entries the initial sync writes. The mongosync FAQ example: migrating 10 GB of data needs 10 GB for the data and another 10 GB for insert oplog entries. From mongosync 1.22, /start estimates on-disk size, applies a 1.25x safety factor, and returns InsufficientDestinationDiskSpace if the destination lacks room. skipDiskSpaceCheck: true turns the check off. The check is best effort only. (high confidence) (verified as of 2026-10-20) [source]
MongoDB says the vast majority of Atlas customers spend less than 10% of their budget on data transfer (Atlas docs), and that data transfer fees are under 10% of the bill for most customers (AWS pricing page). These are vendor statements about steady-state spend, not about migrations. (medium confidence) (verified as of 2026-10-20) [source]
AWS gives credits for free data transfer out to the internet when a customer moves all of its data off AWS, or all of its data off one AWS service, across its eligible payer accounts. The customer asks AWS Support and does not have to close the account. AWS's page was updated on 10/8/26 to give non-EU customers 180 days to finish, and on 9/30/25 to drop the requirement of more than 100 GB/month of transfer. AWS says it applies additional scrutiny when the same account applies repeatedly. (high confidence) (verified as of 2026-10-08) [source]
Azure gives free internet egress to customers leaving Azure for another cloud or on-premises: the first 100 GB per month is free in all regions, and larger moves claim credits through Azure Support. When Microsoft announced the waiver in March 2024, press reports said the move had to finish within 60 days and that credits apply only after all Azure subscriptions on the account are cancelled. The current Azure pricing page does not repeat those two terms. (medium confidence) (verified as of 2026-10-20) [source]
Estimate egress as gigabytes moved times the sending provider's per-GB rate. Arithmetic example, not a quoted figure: 10 TB (10,240 GB) out of Atlas on AWS at the $0.09-$0.16/GB internet list range is about $920-$1,640 before any waiver. mongosync's default network compression lowers wire bytes, and change-stream traffic during the overlap adds to them. (low confidence) (verified as of 2026-10-20) [source]
MongoDB's worked example of a forced serverless-to-dedicated migration (50 GB, AWS us-east-1, help-center article dated 1 July 2025) bills a migration M50 cluster at $2.00/h for 24 h ($48.00), interim M40 and M30 clusters ($27.12 and $15.12), and data transfer at $0.01/GB (up to $5.00), total $95.24. It shows that Atlas bills a temporary oversized cluster by the hour and that auto-scaling through interim tiers adds line items. (low confidence) (verified as of 2025-07-01) [source]
mongosync protects small destinations: for migrations of 64 GB or less into destinations with 4 or fewer vCPUs, the collection copy issues fewer concurrent writes. Setting an explicit load level turns this off, and the user can change the load level during a sync. On Atlas destinations mongosync runs 12 createIndexes commands at once, capped by maxNumActiveUserIndexBuilds. Raising that value speeds index builds but raises destination CPU and can trigger unintended Atlas auto-scaling events. (high confidence) (verified as of 2026-10-20) [source]
The destination needs disk for the migrated data plus the insert oplog entries written during the initial sync. The docs example: a 10 GB migration needs at least 10 GB for data and another 10 GB for oplog entries. Budget roughly double the logical data size while the sync runs. (high confidence) [source]
Since mongosync 1.22, /start checks destination disk space. It estimates the on-disk size of the selected collections and indexes and applies a 1.25x safety factor. If space is short, /start returns InsufficientDestinationDiskSpace and the migration does not start. The skipDiskSpaceCheck option bypasses the check. (low confidence) (verified as of 2026-10-20) [source]
For data sets under about 300 GB that can tolerate extended downtime, MongoDB recommends mongodump and mongorestore. It recommends mongoexport and mongoimport only when index handling is not a concern. These options trade cutover tooling for downtime. (low confidence) (verified as of 2026-10-20) [source]

Problems, failure modes and limitations

mongosync supports one-time migrations only. The destination cannot serve application reads or writes until commit succeeds and canWrite is true. MongoDB states that disaster recovery, analytics, and similar use cases are not supported workflows, so mongosync cannot keep a standing standby copy during a long dual-run. (high confidence) [source]
Atlas Live Migration (pull) is the managed wrapper around mongosync: it needs little setup, the destination must be in Atlas, and the source may be on-premises or in Atlas. MongoDB recommends it for source clusters of 5 TB or less or up to 3 shards. It recommends standalone mongosync above those thresholds, and whenever the user must use VNet peering or Private Link, cannot allow a third party to reach the source, or will not import the source into Cloud Manager or Ops Manager. Standalone mongosync adds tunable parameters, pause and resume, detailed progress, direct logs, filtered sync, and a destination that may be on-premises, but the user hosts it. (high confidence) (verified as of 2026-10-20) [source]
Pull live migration needs a publicly reachable source and cannot use VPC peering or private endpoints as the migration data path; both stay usable for application connectivity. The destination cannot be a Free or Flex cluster. Clusters on 'Latest Version With Auto Upgrades' are unsupported. MongoDB Search (Atlas Search) indexes are not migrated. Push live migration supports VPC peering or private endpoints between the migration host and Atlas, with private endpoints only within a single cloud provider and region. (high confidence) (verified as of 2026-10-20) [source]
mongomirror reached end of life on 31 July 2025 and works only with MongoDB 6.0 and below; MongoDB says mongosync replaces it. mongomirror does not import users or roles, does not copy the config database, cannot move time-series data, and needs TTL indexes dropped and rebuilt. The Atlas architecture page still lists mongomirror as a manual migration tool without the end-of-life note. (medium confidence) (verified as of 2026-10-20) [source]
mongosync makes two round trips to the destination for each source operation, so latency between mongosync and the destination slows the sync. It uses majority reads and writes, so replica-set nodes spread across regions slow it further. It can run on hardware separate from either cluster, and it enables network compression by default when both clusters share a compressor. (high confidence) [source]
Size the source oplog window to cover the whole migration: raise the minimum oplog window when storage auto-scaling is on, or the fixed oplog size when it is off. If operations that mongosync has not applied roll off the source oplog, the sync fails. If a source outage or pause outlasts the oplog window, mongosync cannot resume, and the user must restart from the beginning, which removes all migrated data from the destination. (high confidence) [source]
The embedded verifier is on by default in mongosync (since 1.9) and keeps its state in memory. The limitations page sizes it at about 10 GB plus 500 MB per 1 million documents; the start-up disclaimer says about 0.5 GB per 1 million documents and that verification fails if memory is insufficient. Verification cannot resume after a pause or restart. Atlas Live Migration verifies by default and then needs a large destination oplog; the 'Verify data post-migration' switch turns it off. (medium confidence) (verified as of 2026-10-20) [source]
MongoDB's architecture page limits mongodump with mongorestore to data sets under about 300 GB that can tolerate extended downtime, and limits mongoexport with mongoimport to small data sets with no index concerns. These are the fallback paths when live migration cannot be used. (low confidence) [source]
mongosync does not check that a deployment meets its limitations; running it in the presence of a limitation 'could lead to undefined behavior on the destination cluster', and the limits apply for the whole migration, including pauses. Operations that break or slow a sync include DDL on the source, movePrimary, moveChunk, moveRange, reshardCollection, shard-key refinement, rolling index builds, writes by other clients to the destination, and a balancer that is enabled after start. (high confidence) (verified as of 2026-10-20) [source]
For sharded migrations without namespace filtering, mongosync needs the balancers stopped. Since version 1.17 it disables them during initialization and waits 15 minutes for in-flight chunk migrations, and it fails if a balancer is enabled later. Atlas Live Migration stops the balancers on both clusters for the whole procedure and restarts them at the end; if it cannot restart one, a banner tells the user to restart it manually. mongosync does not preserve chunk distribution, so the user rebalances the destination after cutover. (high confidence) (verified as of 2026-10-20) [source]
mongosync returns 'Invalid URI option, read concern must be majority' or 'Invalid URI option, write concern must be majority' when a connection string sets a non-majority concern. After a fatal error the user deletes all migrated data on the destination, including the __mdb_internal_mongosync database, and starts a new migration. Log lines that contain 'error' or 'failure', and duplicate key errors, are normal and do not mean the sync is failing. (medium confidence) [source]
Before MongoDB 8.0.20, a replace operation that adds a field named $v makes mongosync exit with an unrecoverable fatal error during change event application, and resuming fails with the same error. The fix is to restart the sync from scratch after deleting mongosync's metadata database on the destination, or to upgrade the source to 8.0.20 or later. (low confidence) (verified as of 2026-10-20) [source]
If an Atlas cutover has run for at least 12 hours, Atlas emails the user to check the migration or contact support. If live migration cannot recover automatically from network interruptions or elections on either cluster, the user restarts it from the beginning, which repeats the initial copy and extends the dual-running period. (high confidence) [source]
Atlas Live Migration is mongosync hosted by MongoDB. MongoDB advises it for source clusters up to 5 TB and 3 shards. Above either limit it advises standalone mongosync, which adds tunable parameters, pause and resume, detailed progress tracking and direct log access, at the price of hosting mongosync yourself. (high confidence) (verified as of 2026-10-20) [source]
An undersized destination slows the sync. The collection copy phase can exhaust a small destination's CPU or memory. For migrations of 64 GB or less into destinations with 4 or fewer vCPUs, mongosync issues fewer concurrent writes; larger migrations use the default concurrency. Slow-operation warnings point to CPU, memory or network strain, and the FAQ says to upgrade underprovisioned clusters. (medium confidence) (verified as of 2026-10-20) [source]
The embedded verifier holds its state in memory: about 10 GB plus 500 MB per 1 million documents. It cannot resume. If mongosync stops or pauses, verification restarts from the beginning. (low confidence) (verified as of 2026-10-20) [source]
Atlas live migration turns the embedded verifier on by default only up to 5 TB and 3 shards. The verifier needs a large destination oplog. If you cannot allocate one, turn verification off in the Atlas UI and verify with another method. (high confidence) (verified as of 2026-10-14) [source]
Do not run mongosync as a standing replica for disaster recovery, analytics or other continuous use. It is built for one-time migrations. The destination cannot take application traffic until commit has run and canWrite is true. Any dual-running window with mongosync is temporary. (high confidence) [source]
Cutover downtime runs from stopping source writes until canWrite is true on the destination. The steps: confirm lag is near zero, stop writes, wait for open transactions to end, call commit, poll /progress for canWrite, verify, then repoint applications. Since mongosync 1.21, canCommit is false and /commit returns an error when mongosync or the embedded verifier lags more than 30 seconds. If lag is not near zero when cutover starts, the cutover can take a long time. (high confidence) (verified as of 2026-10-20) [source]
Track mongosync lag against the source oplog window for the whole sync. Compare db.getReplicationInfo().timeDiff with lag.overallLagSeconds from /progress. If lag nears the window, widen the oplog window or add CPU or memory to the mongosync host. If unapplied operations roll off the source oplog, the sync fails and mongosync exits. Large data sets and long pauses are the main risk. (high confidence) [source]
Reverse sync is the rollback path for standalone mongosync. Plan it at /start with reversible=true, which cannot change later. Reverse also needs the COMMITTED state, the same shard count and major version on both clusters, no legacy-format unique indexes on the source, and no destination oplog rollover between canWrite=true and /reverse. You must commit the reverse sync, or the original source stays unusable. Filtered sync and pre-6.0 sources cannot reverse, and dropping mongosync's metadata databases ends the option. (high confidence) (verified as of 2026-10-20) [source]
A managed pull migration tries to survive elections and network interruptions but can fail. If it cannot recover on its own, you restart from the beginning. Standalone mongosync keeps its restart state on the destination, so restarting it with the same parameters resumes the sync, and since 1.18 it retries network or availability errors for up to 30 minutes. A restart from zero extends the time you pay for both environments. (high confidence) (verified as of 2026-10-20) [source]
Pull live migration validates before moving data. It supports specific source and destination version pairs (sources from 5.0 to 8.0), rejects clusters on Latest Version With Auto Upgrades, cannot target Free or Flex clusters, needs an empty destination or the clear-data option, and fails if the source holds the mongosync_reserved_for_internal_use database. (medium confidence) (verified as of 2026-10-14) [source]
MongoDB's settings to contain cost and risk during a live migration: disable auto-scaling on the destination to avoid unexpected resizes, set a large fixed destination oplog for the duration, and expect Atlas to pause cloud backups on the target until cutover completes. After cutover, ask MongoDB Support to help right-size the destination to minimize cost. (medium confidence) (verified as of 2026-10-14) [source]
Application-level dual writing is the alternative to database-level sync, and it has its own cost. Stripe's four phases are dual write, read from the new store, write only to the new store, then remove old data. Stripe's backfill was costly because finding records through production queries was slow, so it moved discovery to offline jobs on database snapshots, and it used GitHub's Scientist to compare old and new reads. Haptik warns that running two change streams at once for zero downtime risks duplicate operations, race conditions and complex conflict resolution. (medium confidence) [source]

Comparisons and alternatives

For parallel use of two providers, Art. 34(2) of the EU Data Act lets a provider charge data egress only to pass on egress costs incurred, without exceeding them. Recital 99 says egress for in-parallel use can be an ongoing activity, unlike the one-off egress of switching. Google points European customers to a separate Data Transfer Essentials offer for parallel use. (medium confidence) (verified as of 2026-10-20) [source]
mongosync does not sync users or roles, system.* collections, Atlas Search indexes, or Persistent Query Settings. It does not support time-series collections, clustered collections with expireAfterSeconds, Queryable Encryption, client-side field-level encryption, global clusters, or sync from a sharded cluster to a replica set. Each gap needs separate work after or instead of the sync, such as recreating users and roles and rebuilding search indexes on the destination. (high confidence) (verified as of 2026-10-20) [source]
Vendor statements that egress is a minor part of switching cost are unmeasured for database migrations. Bloomberg reported Google's position that switching fees are about 2% of the total cost of migrating to a new provider. AWS said about 90% of its customers already pay nothing for data transfer out because of the 100 GB/month free allowance. Gartner's Lydia Leong said the cost of the move is trivial compared with the ongoing cost of storing data. None of these sources measured a database-cluster migration. (medium confidence) [source]

Facts and statements

Atlas Live Migration carries no tool fee: the Atlas data-transfer docs call it 'the free Atlas Live Migration Service'. MongoDB's migration guidance frames the cost the user controls as destination-cluster sizing: temporary scaling during the sync, then resizing to the right tier after cutover. (medium confidence) (verified as of 2026-10-20) [source]
For the migration window, MongoDB recommends a destination Atlas tier at least two tiers above the source, at least an M40, and an M80 with 6000 IOPS disks or higher for large data sets. It tells users to disable auto-scaling on the destination during the migration and to set a large fixed oplog size or minimum oplog window there. Users may raise the destination tier temporarily and resize after cutover. (high confidence) (verified as of 2026-10-20) [source]
While a live migration runs, Atlas pauses both scheduled and on-demand cloud backup snapshots of the target cluster. Atlas resumes them automatically after the cutover step. The destination takes no new Atlas snapshots during the overlap. (high confidence) [source]
mongosync copies unique indexes as non-unique indexes and restores uniqueness at commit. /progress returns canWrite: true once the indexes are set to prepareUnique, but the state reaches COMMITTED only after mongosync converts them to unique indexes. On large collections the conversion is resource intensive, so the gap between canWrite: true and COMMITTED can be long. Applications can write in the gap, but index builds wait and write latency can rise. (medium confidence) [source]
MongoDB suggests running the live-migration procedure twice. A first partial run stops before the cutover step and creates an up-to-date Atlas staging cluster for application tests. A second run performs the production cutover. The staging cluster is an extra Atlas cluster, so budget its run-rate for as long as it exists. (medium confidence) [source]
Atlas docs list data transfer prices by provider (checked 2026-10-20). AWS clusters: same region $0.00-$0.01/GB, different region $0.02-$0.15/GB, out to internet $0.09-$0.16/GB. Azure clusters: internet data transfer $0.087-$0.181/GB. Google Cloud clusters: internet $0.12-$0.23/GB, between regions $0.02-$0.15/GB. The Atlas-on-AWS pricing page shows the base figures $0.01 same region, $0.02 cross-region, $0.09 internet. Ranges depend on region. Atlas charges no incoming transfer and charges no outgoing transfer on Free and Flex tiers. (high confidence) (verified as of 2026-10-20) [source]
In a push live migration the user provisions, secures, and runs the migration host, and Cloud Manager must monitor the source cluster. MongoDB's push page requires source and destination at MongoDB 6.0.17 or later. AWS Prescriptive Guidance still says 6.0.8 or later for guided pull or push migration. (medium confidence) (verified as of 2026-10-20) [source]
Budget a migration overlap from these documented terms: source run-rate, plus destination run-rate at least two tiers above the source, for the initial copy plus up to 120 hours of sync and the cutover window; destination disk for data plus sync oplog; a migration host for push or standalone mongosync; source-side egress; and a staging cluster if the user rehearses. MongoDB publishes no copy throughput and no downtime figure, so the duration term must come from a test run. (medium confidence) [source]
A migration started with reversible: true can be reversed after commit, which keeps the old cluster usable as a rollback target. Reversal needs the same number of shards and the same major version on both clusters and no filtered sync, and the user must not drop the mongosync metadata databases. The rollback window is therefore an extra dual-running period. (medium confidence) [source]
Changing the region or cloud provider of an existing Atlas cluster runs as an in-place rolling migration: Atlas replaces one node at a time, secondaries first, then the primary, using initial sync, and an election takes about five seconds on average. Each new node's initial sync adds load to the primary. The cluster cost estimate excludes data transfer, and the docs do not say whether the sync is billed as transfer. (low confidence) [source]
Relocating only the application tier to another cloud while the Atlas cluster stays put turns in-region traffic into billed internet transfer. One user reported an Atlas bill rising from about $250 to $850 a month, all of it on the line 'Data Transfer: Atlas AWS Internet Transfer', after moving an app from Heroku to Railway, which runs on Google Cloud (thread dated 2 May 2024). Atlas docs say queries from on-premises, across cloud providers, or between continents incur the greatest data transfer costs. (medium confidence) [source]
If mongosync crashes during commit with default write blocking, source writes can stay blocked. Run db.adminCommand({ setUserWriteBlockMode: 1, global: false }) on the source to unblock them. If mongosync disabled a balancer and then failed before commit, run balancerStart manually unless the user will run mongosync again. (high confidence) [source]
Atlas bills outbound and inter-region data transfer per GB by provider, and tabulates the charges daily. The Atlas docs list AWS at $0.00 to $0.01 same region, $0.02 to $0.15 different region, and $0.09 to $0.16 out to the internet. They list Azure data transfer at $0.087 to $0.181 and Google Cloud internet or Interconnect transfer at $0.12 to $0.23. (low confidence) (verified as of 2026-10-14) [source]
MongoDB recommends a destination Atlas tier at least two tiers above the source for the whole migration. It advises at least M40 for speed, and M80 with 6000 IOPS disks or higher for large data sets. It allows a temporary size increase and tells you to right-size after cutover. (high confidence) (verified as of 2026-10-14) [source]
Atlas bills a dedicated cluster per hour by tier, and Atlas migration guidance is temporary scaling followed by resizing. The cost of the oversized destination therefore grows with how long the sync, cutover and any hold period last. (medium confidence) [source]
Current Atlas docs set the cutover timer at 120 hours (5 days), extendable. If you take no action before it ends, Atlas cancels the migration and you start again. (low confidence) (verified as of 2026-10-14) [source]
AWS changed the move window on 2026-10-08. Eligible customers outside the EU now have 180 days to finish the move and must tell AWS Support at once if they need longer. EU customers follow the AWS EU Data Act Addendum (Section 2.3). The CMA's July 2025 appendix recorded a 60-day window. (medium confidence) (verified as of 2026-10-08) [source]
Azure pays an invoice-level credit only after four customer steps: a support request that states the start date and data estimate; moving the data within 60 days of that date; cancelling all subscriptions on the account; and a second request for the credit. The credit covers at most 60 calendar days of egress (180 days for UK billing addresses moving data out of UK datacenters). ExpressRoute, VPN, Front Door and CDN traffic is excluded, and Azure may change the policy. (high confidence) (verified as of 2026-07-25) [source]
Do not budget the exit programs as zero-rated transfer. Google and Azure pay after the move: Google puts the credit on the final invoice, and Azure issues it only after the data is out and every subscription is cancelled. The customer carries the egress bill until then and has no certainty over the credit value. (high confidence) (verified as of 2026-07-25) [source]
File the exit notice before moving data. Google requires the Exit Notice before any migration the customer expects a credit for. Azure requires advance notice through a support request. The CMA found AWS requests ineligible where the migration was already underway or notice came late. (high confidence) (verified as of 2025-09-11) [source]
Regulation (EU) 2023/2854 (the Data Act) Article 29 ends switching charges on 12 January 2027. Until then, from 11 January 2024, providers may charge only reduced switching charges, capped at the provider's costs directly linked to the switch. Article 2(36) defines switching charges to include data egress charges. (high confidence) [source]
Article 34(2) of the Data Act still lets a provider charge data egress charges, at cost and no more, while a customer uses its service in parallel with another provider's service. After 12 January 2027 a one-way switch carries no switching charges, but egress during dual running stays billable at cost. (high confidence) [source]
Google Data Transfer Essentials (EU and UK customers, launched 2025-09-10) meters qualifying multicloud traffic at zero charge and bills other traffic at normal rates. It targets in-parallel processing of one organization's workloads across providers, and customers opt in by specifying the multicloud traffic. Google's exit page points European customers to it for partial moves. (high confidence) (verified as of 2025-09-10) [source]
Pull live migration needs the source reachable from MongoDB's live migration servers, so you must allow their IP ranges through the source firewall. It does not support VPC peering or private endpoints for the migration path. If you need private networking, or will not open the source to a third party, MongoDB recommends standalone mongosync. (high confidence) (verified as of 2026-10-14) [source]
Standalone mongosync can run on its own hardware, apart from the cluster hosts. Adding CPU or memory to that host raises the copy rate. The destination should have more CPU, memory and disk I/O than the source so it can absorb mongosync writes. (high confidence) [source]
mongomirror reached end of life on 2025-07-31 and is no longer usable for migrations into Atlas. MongoDB names mongosync as its replacement. Direct migration into Atlas with mongosync supports source clusters at version 5.0 and above. (high confidence) [source]
Cutover in a managed pull migration is manual. You stop writes to the source, stop the application instances, point them at the Atlas cluster, and restart them. Atlas reports the application downtime after success. MongoDB tells you to run the three-step cutover quickly to keep downtime minimal. (high confidence) [source]
On large collections, converting prepareUnique indexes to unique indexes during commit can be resource intensive. That can leave a long gap between canWrite=true and COMMITTED. Writes may see extra latency in the gap, and operations that need exclusive locks, such as index builds, wait until the conversion finishes. (low confidence) (verified as of 2026-10-20) [source]
A live migration does not carry everything across. Atlas migrates no users or roles, and neither migration path syncs MongoDB Search (Atlas Search) indexes. mongosync does not replicate system.* collections, and it rejects time-series collections, serverless clusters, Queryable Encryption and client-side field-level encryption. Persistent Query Settings need a manual move. Budget time to recreate these after cutover. (high confidence) (verified as of 2026-10-20) [source]
Destination indexes can end up larger than source indexes. mongosync builds indexes before the copy by default and copies in _id order. The fixes cost time or load: buildIndexes=never means you build indexes by hand afterward, buildIndexes=beforeDataCopy can lengthen the migration, and a rolling initial sync or compact after migration adds load. (medium confidence) (verified as of 2026-10-20) [source]
Sources older than 6.0 add constraints. No DDL may run on the source during the migration (collMod, create, createIndexes, drop, rename and similar, including collections created implicitly by inserts). Reverse is unavailable. Sharded 5.0 sources need cleanupOrphaned on every shard's primary first. (medium confidence) (verified as of 2026-10-20) [source]
Pick the destination region for low latency to the application servers, ideally the same cloud region. Atlas bills the most for queries from on-premises, across cloud providers or between continents, so a distant destination adds recurring transfer cost after cutover. (high confidence) (verified as of 2026-10-14) [source]
Rehearse on a staging cluster. Run the live migration up to the cutover step to get a current Atlas-backed staging cluster for testing with the target driver version, then run the full migration into a separate Atlas cluster for production. This adds one more destination cluster to the bill. (low confidence) [source]
Haptik moved a multi-terabyte MongoDB replica set across clouds without mongosync. It seeded from a hidden secondary (priority 0, votes 0) cloned as a VM, captured changes with change streams into a delta store, and replayed the delta in a short maintenance window. Reverse streaming kept the old cluster usable for rollback. It named oplog rollover during the VM transfer and heavy CDC bandwidth as the main risks. The article gives no egress cost figures. (low confidence) (verified as of 2025-10-09) [source]

Children

Application-level dual-write migration pattern (frontier)
Atlas Live Migration pull versus push versus standalone mongosync selection (frontier)
Atlas Search index rebuild after migration (frontier)
Cloud exit-credit programs and EU Data Act in-parallel egress (frontier)
Cross-cloud application-tier placement and Atlas internet egress (frontier)
Destination right-sizing after cutover (frontier)
Destination temporary scaling and post-cutover right-sizing (frontier)
EU Data Act switching charges and in-parallel egress (frontier)
Embedded verifier and post-migration data verification cost (frontier)
Hyperscaler exit-egress waiver programs (AWS, Google Cloud, Azure) (frontier)
Oplog sizing and embedded-verifier memory for migrations (frontier)
Post-cutover rebuilds: Atlas Search indexes, users and roles, time-series collections (frontier)
Relational-to-MongoDB migration cost (Relational Migrator) (frontier)
Reverse sync and rollback-window economics (frontier)
Standalone mongosync hosting and sizing (frontier)
mongosync reversible sync and the rollback window (frontier)

Frontier under this node: Application-level dual-write migration pattern, Atlas Live Migration pull versus push versus standalone mongosync selection, Atlas Search index rebuild after migration, Cloud exit-credit programs and EU Data Act in-parallel egress, Cross-cloud application-tier placement and Atlas internet egress, Destination right-sizing after cutover, Destination temporary scaling and post-cutover right-sizing, EU Data Act switching charges and in-parallel egress, Embedded verifier and post-migration data verification cost, Hyperscaler exit-egress waiver programs (AWS, Google Cloud, Azure), Oplog sizing and embedded-verifier memory for migrations, Post-cutover rebuilds: Atlas Search indexes, users and roles, time-series collections, Relational-to-MongoDB migration cost (Relational Migrator), Reverse sync and rollback-window economics, Standalone mongosync hosting and sizing, mongosync reversible sync and the rollback window

← the whole tree · 3D view· how to read this page