--- title: Migrating 47 TB in Under 48 Hours | daily.dev description: A large enterprise migrated 47 TB of data across 7,000+ collections from a 27-node MongoDB-compatible cluster to a 3-node Azure DocumentDB cluster in under 48... canonical: https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Migrating 47 TB in Under 48 Hours | daily.dev og:description: A large enterprise migrated 47 TB of data across 7,000+ collections from a 27-node MongoDB-compatible cluster to a 3-node Azure DocumentDB cluster in under 48... og:url: https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7 og:image: https://api.daily.dev/og/posts/1P8C1LkR7.png og:image:alt: Migrating 47 TB in Under 48 Hours og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Migrating 47 TB in Under 48 Hours **[DevBlogs](https://daily.dev/sources/devblogs)** · 7 min read · 18 upvotes · 2 comments ## Summary A large enterprise migrated 47 TB of data across 7,000+ collections from a 27-node MongoDB-compatible cluster to a 3-node Azure DocumentDB cluster in under 48 hours. The migration succeeded through disciplined sequencing: assessing scope to skip irrelevant collections, deferring high-availability and cross-region replication until after bulk ingestion to avoid WAL pressure, building non-unique indexes post-load to prevent resource contention, redesigning the target topology to match the actual workload rather than mirroring the source, and splitting the work into four balanced parallel jobs with continuous monitoring and throttling. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do you avoid disk pressure and WAL log buildup during a large MongoDB migration to Azure DocumentDB? Defer high availability and cross-region replication until after the bulk data load completes. Enabling HA and cross-region replicas during heavy ingestion causes write-ahead log accumulation and rising disk pressure, which can lead to storage filling up mid-migration. Loading bulk data first, then re-enabling HA and replicas afterward, keeps the ingestion phase focused purely on data movement. _daily.dev surfaces migration playbooks like this for teams sequencing large database cutovers._ ### Should you build database indexes before or after a large bulk data migration? Build non-unique indexes after the bulk load finishes, not during ingestion. Building indexes while rapid writes are occurring causes CPU and disk utilization spikes because the system handles heavy write traffic and expensive index construction simultaneously. Running index builds in blocking mode post-ingestion, while pausing CDC online sync, keeps the migration predictable and avoids resource contention. _Engineers planning cutovers can track sequencing lessons like this on daily.dev before their next migration._ ### Should a database migration target mirror the source cluster's sharding topology? No, the target should be designed around the actual workload rather than copying the source topology. In one migration, a 27-node, 9-shard MongoDB-compatible source (sharded on _id) was consolidated into a 3-node, 16 TB Azure DocumentDB cluster with collections kept un-sharded, since queries performed better that way and no single collection was too large for one node. _Teams weighing sharded versus un-sharded targets can find real-world tradeoffs like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@dcorto** · 0 upvotes > that is fast ## Similar posts on daily.dev - [5 Billion Records, 10 Terabytes, Four Weeks: A Real Data Migration Playbook](https://daily.dev/posts/5-billion-records-10-terabytes-four-weeks-a-real-data-migration-playbook-finv6kwcs) · Wix Engineering · 0 upvotes · 1 comments - [Stripe's Zero-Downtime Data Movement Platform Migrates Petabytes with Millisecond Traffic Switches](https://daily.dev/posts/stripe-s-zero-downtime-data-movement-platform-migrates-petabytes-with-millisecond-traffic-switches-e0msys40v) · InfoQ · 44 upvotes · 0 comments - [Moving Mountains of Data off S3](https://daily.dev/posts/moving-mountains-of-data-off-s3-j5lh5ktov) · 37signals Dev · 1 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#mongodb](https://daily.dev/tags/mongodb), [#distributed-systems](https://daily.dev/tags/distributed-systems), [#data-engineering](https://daily.dev/tags/data-engineering) [View this post on daily.dev](https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Migrating 47 TB in Under 48 Hours","url":"https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7"},"datePublished":"2026-07-14T04:09:07.498Z","dateModified":"2026-09-14T06:12:35.860Z","description":"A large enterprise migrated 47 TB of data across 7,000+ collections from a 27-node MongoDB-compatible cluster to a 3-node Azure DocumentDB cluster in under 48...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1eb28c7cf9afddce7814051b4f2a12b0?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1eb28c7cf9afddce7814051b4f2a12b0?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DevBlogs","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DevBlogs","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/8f68b453325f482ebeb73fb780092713","url":"https://daily.dev/sources/devblogs"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":18},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"database,mongodb,distributed-systems,data-engineering","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DevBlogs","item":"https://daily.dev/sources/devblogs"},{"@type":"ListItem","position":3,"name":"Migrating 47 TB in Under 48 Hours"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7","comment":[{"@type":"Comment","text":"that is fast","datePublished":"2026-07-18T16:20:49.530Z","url":"https://daily.dev/posts/1P8C1LkR7#c-YDnyeYHl4","author":{"@type":"Person","name":"David C.","url":"https://daily.dev/dcorto","image":"https://media.daily.dev/image/upload/s--EPnTZZFw--/f_auto/v1784418453/avatars/avatar_tT4BuvxaHeTxyE5fH41si?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/migrating-47-tb-in-under-48-hours-1p8c1lkr7#faq","mainEntity":[{"@type":"Question","name":"How do you avoid disk pressure and WAL log buildup during a large MongoDB migration to Azure DocumentDB?","acceptedAnswer":{"@type":"Answer","text":"Defer high availability and cross-region replication until after the bulk data load completes. Enabling HA and cross-region replicas during heavy ingestion causes write-ahead log accumulation and rising disk pressure, which can lead to storage filling up mid-migration. Loading bulk data first, then re-enabling HA and replicas afterward, keeps the ingestion phase focused purely on data movement. daily.dev surfaces migration playbooks like this for teams sequencing large database cutovers."}},{"@type":"Question","name":"Should you build database indexes before or after a large bulk data migration?","acceptedAnswer":{"@type":"Answer","text":"Build non-unique indexes after the bulk load finishes, not during ingestion. Building indexes while rapid writes are occurring causes CPU and disk utilization spikes because the system handles heavy write traffic and expensive index construction simultaneously. Running index builds in blocking mode post-ingestion, while pausing CDC online sync, keeps the migration predictable and avoids resource contention. Engineers planning cutovers can track sequencing lessons like this on daily.dev before their next migration."}},{"@type":"Question","name":"Should a database migration target mirror the source cluster's sharding topology?","acceptedAnswer":{"@type":"Answer","text":"No, the target should be designed around the actual workload rather than copying the source topology. In one migration, a 27-node, 9-shard MongoDB-compatible source (sharded on _id) was consolidated into a 3-node, 16 TB Azure DocumentDB cluster with collections kept un-sharded, since queries performed better that way and no single collection was too large for one node. Teams weighing sharded versus un-sharded targets can find real-world tradeoffs like this on daily.dev."}}]} ```