Production Database Migration or Modernization: A Comprehensive Planning Guide [Part 2]

3. Downtime Strategy Options

Your downtime strategy fundamentally shapes your migration approach and timeline.

Some Downtime (Planned Maintenance Window)

This traditional approach involves scheduling a maintenance window, typically several hours to a full day, during which services are completely or partially unavailable (e.g., read-only mode) while you migrate data and cut over to the new database.

Pros: Simplest to implement, lowest risk of data inconsistencies, easier validation, straightforward rollback if issues arise.

Cons: Service interruption impacts users, requires careful timing and communication, and may not be acceptable for globally distributed services.

Timeline: Shortest overall project timeline, but concentrated downtime during cutover.

Best for: Applications with naturally low-traffic periods or off-hours (e.g., insurance, banking), internal tools, or when business requirements permit scheduled maintenance.

For large databases or network-constrained environments, it's important to ensure that the migration window covers at least 1.5-2x actual data migration time to account for variability in data ingestion and minor deviations from the original plan, such as transient network or database issues.

Although most companies immediately discount this old-school approach because they expect the downtime period to be long, many modern databases, coupled with highly parallelized and scalable migration tooling, can easily make migrating many TBs and Billions of records a matter of hours rather than days.

Minimal Downtime (Quick Cutover)

Migrate the bulk of data, continuously sync the deltas (starting from the point in time right before the initial data copy to avoid losing data), then execute a brief cutover window (minutes to an hour) to sync final changes and switch traffic to the new database.

Pros: Significantly reduced user impact, most data migrated without affecting production, and maintains business continuity.

Cons: Requires CDC or careful change tracking, more complex orchestration, and higher stakes during the cutover window.

Timeline: Medium complexity; bulk migration can happen over days or even weeks while services run normally.

Best for: Services that can only tolerate brief interruptions during low-traffic periods.

It's worth noting that combining change data capture (CDC) with an initial data copy requires two distinct data processing paths for the migration. They need to be well coordinated and individually tested from the perspectives of data integrity and performance. The CDC mechanism should be fast enough to catch up with all changes within a reasonable, predictable timeframe and continue replicating them in near-real time. The initial data copy should be fast enough to reduce the catch-up period and give the CDC the best odds to succeed.

Some modern database migration tools implement the above already, but the burden of proper testing and evaluation always falls on the end user.

Zero Downtime (Dual Writes, Gradual Migration)

Implement dual writes via a dedicated Database Abstraction Layer (DAL) where all changes go to both old and new databases simultaneously, then gradually shift read traffic to the new database after validating data consistency. The bulk of data is backfilled in the background via a separate process.

Pros: No user-facing downtime, extensive validation possible before cutover, gradual rollout reduces risk.

Cons: Most complex implementation, requiring significant code changes; increased operational complexity and monitoring during transition; potential for data inconsistencies between systems; extended timeline with both systems running in parallel.

Timeline: Longest overall project timeline, but eliminates concentrated downtime.

Best for: Mission-critical services where any downtime is unacceptable, services with global user bases across time zones.

Key challenges specific to this approach:

• Consistency: Dual writes can cause data drift between the source and the destination unless each write has a transactional semantic and the writes order is strictly maintained for each record across both systems. Even if the business side is ok with some drift, no guarantees can be made here - the only practical approach is testing and measuring the drift.
• Race conditions: Unless the write workload is insert-only, the abstraction layer needs logic to prevent backfills from overwriting fresh data, and the destination write path should be able to handle possible conflicts.
• Data anomalies: Production data often contains "surprises" that only appear after the move unless the application code has been tested with the post-migration data. This is best done as part of the production dry-run.

Migration in Batches

For complex systems, consider migrating in phases ("blue-green" approach) rather than all at once.

Multi-tenant systems: Group tenants logically (by size, activity level, or business relationship) and migrate each group separately. This requires specialized middleware and feature flags to route requests to the appropriate database based on the tenant. Starting with smaller, lower-risk tenants allows you to refine your process before migrating to larger customers.

Multi-service systems: In a microservices architecture, identify independent groups of services and migrate them separately. Services with fewer dependencies make ideal starting points. This incremental approach reduces blast radius and allows learning from each migration. 

A variation of this approach is to split the migration into logically separate and independent groups of schemas/tables/collections.

4. Migration Approaches and Tools

Selecting the right tooling is critical for success as tools underpin the execution of any of the chosen approaches.

Vendor-Provided Tools

Cloud providers and database vendors often offer native migration services, such as MongoDB Atlas Migrations and Database Migration Services from Azure, AWS, and Google.  

These native tools integrate seamlessly with their respective cloud ecosystems and support a range of source and target database combinations.

Vendors like MongoDB offer specialized tooling like mongosync and MongoDB's Relational Migrator.

Pros: Free, easy to set up, vendor support.

Cons: The tools have a very limited scope and generally only cater to the lowest 50th percentile of workloads. Most of them are SaaS-based, require firewall exceptions, and move data over the public internet.

Best for: Workloads of average or below-average size and complexity, with little or no special requirements.

Specialized Third-Party Solutions

Tools like Adiom's Dsync, Oracle's Golden Gate, and Fivetran provide advanced capabilities for complex migrations. Dsync, for example, excels at NoSQL-to-RDBMS migrations with sophisticated transformation capabilities, modular extensions, and real-time CDC to minimize downtime.

Pros: Optimized tooling for repeatable and scalable execution of migrations with minimum or no downtime. Easy to operationalize. Specialized expertise and support.

Cons: Your company needs to onboard a new vendor unless the solution is available in Open Source or the tool provider has a partnership with the destination database provider (many of them are happy to credit the migration cost back or directly subsidize it).

Best for: Large-scale and mission-critical migrations. Complex transformations (especially RDBMS to NoSQL). Scenarios where specialized support and expertise add significant value.

Custom Scripts and Open-Source Tools

Apache Spark for data processing, Debezium for CDC from various databases, Kafka Connect for streaming data pipelines, and custom ETL scripts give you maximum flexibility. Modern AI tools like Copilot and Claude Code can help you to quickly create data pipeline migration scripts.

Pros: Full control of the process with no overhead of working with vendors.

Cons: Limited observability and scalability. Reliability and resumability are hard to implement without specialized expertise, dedicated design reviews, and testing. 

Best for: Straightforward one-way migrations for small datasets (10's of GBs). Can be used for larger and more complex migrations when your company has the necessary expertise and can readily allocate full-time resources to the project.

Selection Criteria

Choose tools based on your source and target database types, data volume, and transformation complexity, downtime tolerance, team expertise, budget, and whether you need ongoing support. In many cases, a hybrid approach combining vendor tools or scripts for smaller or less-critical databases or schemas, along with specialized tooling for large critical ones, yields the best results.

In the next post in the series, we will discuss migration planning, timelines, and common complications.