Quest1
Case Study · Healthcare · Legacy System Modernization

Migrating a 45 TB MongoDB Cluster to Atlas Without Rewriting 25 Applications

A Fortune 100 health insurance provider migrated a 45 TB on-premises MongoDB cluster to MongoDB Atlas with zero read downtime. Twenty-five Java applications moved onto the new cluster without code rewrites, and the platform team kept the validation stack Quest1 built during the engagement.

$ cat case-study/details.yaml
Industry
Healthcare
Service
Legacy System Modernization
Partner
MongoDB
$ read /case-study/01-the-problem.md

The Problem.

The client runs a claims management platform on a 45 TB on-premises MongoDB cluster, with roughly 25 Java applications reading and writing against it. The self-managed cluster had hit its operational ceiling on three fronts at once. Scale had outrun the self-managed model, with storage, memory, and auto-scaling becoming full-time operational burdens on the platform team. Shard key design had accumulated tech debt over the life of the cluster, so query paths that used to be fast weren't anymore, and further tuning had reached its natural limits. And the application layer was tightly coupled to the database's specifics — LDAP-based authentication, hardcoded connection strings, and cluster-specific configuration lived directly in the 25 applications, which made a migration that required touching all 25 a nonstarter.

The engagement needed to compress three things into a single delivery window. It had to move 45 TB of production data to Atlas with minimal downtime. It had to migrate 25 applications onto the new cluster without rewriting any of them. And it had to validate the whole thing rigorously enough for the client's platform team to sign the cutover.

$ read /case-study/02-what-we-built.md

What we built.

Quest1 delivered the migration across six components. Each one was built to leave a reusable asset with the platform team after cutover.

Large-scale database migration with continuous sync.
The 45 TB source cluster was migrated to Atlas using Mongo Sync. Continuous synchronization between source and destination through the migration window supported a controlled cutover with minimal write downtime; writes stayed with the source until the destination was ready to take over.
A shared Java MongoDB connection library.
Instead of modifying each of the 25 applications to point at Atlas, we built a single Java library the applications consume. The library owns connection management centrally, reads its configuration from HashiCorp Vault at runtime, and supports environment-based switching between the on-premises cluster and Atlas, including a rollback path back to on-premises. Applications changed once (to consume the library); the migration itself was a Vault configuration change.
A configurable regression testing framework.
Built on Gatling, the framework runs API validations against both environments in parallel. Each test is defined by four config files (endpoint, auth, requests.txt, responses.txt); the framework sends the configured requests, captures actual responses, compares them against expected outputs, and generates mismatch reports. Manual API validation across 25 applications became a config-driven, reproducible run.
A performance benchmarking automation suite.
JMeter scripts covering every application API, executed against both the on-premises cluster and Atlas, producing directly comparable measurements on response time, database latency, and throughput. Before this engagement, the client had no automation to measure or verify migration performance; every check was manual. The suite gave the platform team a repeatable, scripted way to prove parity before cutover and to re-validate any future capacity or infrastructure change.
An automated payload generator.
Maintaining regression and performance test data by hand across 25 applications wasn't going to work. We built a Java utility that queries MongoDB directly, pulls production-like records, and populates request templates dynamically, producing matching request/expected-response pairs. The output is reusable across both the Gatling regression framework and the JMeter performance suite.
A MongoDB View validation framework.
Certain application screens read from MongoDB Views directly rather than through an API layer, so conventional API testing didn't cover them. We built a lightweight Spring Boot application that executes queries against the Views, measures execution latency on both environments, and generates comparison reports.

The stack: MongoDB Atlas, Mongo Sync for the migration, Java and Spring Boot for the connection library and validation utilities, HashiCorp Vault for configuration and secrets, Gatling for regression, JMeter for performance.

$ read /case-study/03-the-impact.md

The Impact.

The client is on MongoDB Atlas at full 45 TB scale. The 25 dependent applications run unchanged against the shared connection library. The operational burden of the self-managed cluster (storage capacity planning, memory tuning, scaling operations) moved off the platform team and onto Atlas as a managed service. Shard key design and query patterns were revisited as part of the migration.

The cutover itself was the shortest window the platform had ever run for a change of this scope. Read traffic saw zero downtime through the entire migration. Lower environments cut over in fifteen minutes each. The production write window was estimated at two to four hours, held open only for the final source-to-destination synchronization. Rollback stayed available through the connection library across the whole window.

The migration also left the client with a capability they hadn't had before: automated, scriptable verification of database performance. Prior to this engagement, they had no automation to measure response time, throughput, or query latency across a migration or infrastructure change. The JMeter benchmarking suite and the Gatling regression framework closed that gap permanently. The platform team can now run comparable performance and functional validation on any future capacity change, cluster upgrade, or version bump without rebuilding the validation from scratch.

  • A shared Java MongoDB connection library, Vault-configured, environment-aware, rollback-capable. Any future migration or configuration change can flow through it without touching application code.
  • A configurable Gatling regression framework the platform team can rerun against future releases or environment changes, replacing what used to be manual validation.
  • A JMeter performance benchmarking suite parameterized across the full API surface. Before Quest1, the client had no automation of this kind; the suite is now theirs for future capacity or cluster-change validation.
  • An automated payload generator that keeps the regression and performance test data in sync with production shapes.
  • A View validation framework for the direct-database screens that don't sit behind an API.
$ cat metrics.summary
production data migrated to Atlas
45 TB
migrated through the shared connection library
25 applications
cutover was a Vault configuration change
0 rewrites
$ ls case-studies/related/

Related case studies.

A Product Advisory Practice for Ditto: Supporting Enterprise Adoption from First Integration to Production

An ongoing partner practice between Quest1 and Ditto, the edge-native sync platform for resilient, offline-first mobile and IoT operations. Quest1 engineers work as an extension of Ditto's team on the hard customer questions that don't fit the support-ticket queue, from mid-integration architecture reviews to production escalations where the fault line between platform and application needs to be found. Alongside that customer-facing work, the practice ships tooling directly into Ditto's own product surface, closing the gaps that show up across multiple customers at once.

read case study →

From Months to Days: A Self-Service Migration Pipeline Between Two SaaS Products

How a practice-management software provider serving the elective medical industry rebuilt customer migration between two of its products — replacing months of engineering-led work with a self-serve, AWS-native pipeline that the service team runs in days, with two-hour turnarounds in sight.

read case study →