How to switch managed database providers without downtime: a migration playbook

TL;DR: four phases: discovery (read-only, 2-3 weeks), design (target architecture + rollback plan), parallel-run migration (replicate, verify, cut over in minutes), and Day-2 handover (SLAs, runbooks, monitoring in your accounts). Downtime is a planning decision.

Switching managed database providers sounds like open-heart surgery, which is exactly why bad providers retain unhappy customers for years.

In practice, a provider switch is a well-understood engineering project with known phases, known risks, and known mitigations. This playbook describes the process we use at Maxima Consulting, engine-agnostic, from the first assessment to Day-2 operations.

Phase 1: discovery (weeks 1-3, zero risk)

Everything in this phase is read-only. No credentials with write access, no changes, and it can run while your current contract is still active, without the incumbent knowing or needing to know.

What gets inventoried:

• every database engine and version,
• topology (replicas, shards, clusters),
• data volumes and growth rates,
• dependency map (which applications touch which databases, through what),
• backup and restore reality (not the policy, the last tested restore),
• compliance constraints (data residency, encryption requirements, audit obligations),
• the full cost baseline including the line items your current provider bills separately.

You get a written assessment with a risk register and a go/no-go recommendation. Sometimes the honest recommendation is "renegotiate, don't migrate." A provider that never says that is selling migrations, not outcomes.

Phase 2: design (weeks 2-4, overlaps discovery)

The target architecture answers four questions.

1. Where does each workload run (your cloud accounts, by default, so you keep ownership and visibility)?
2. What replaces each proprietary dependency (most have open-source equivalents; each one gets mapped before anything moves)?
3. What does the rollback plan look like at each stage (every phase has a tested way back, which is what makes the cutover boring)?
4. And what do Day-2 operations look like (monitoring, alerting, escalation paths, SLA)?

This is also where the SLA gets negotiated properly: response times, restore times, and what evidence you will see monthly. If you learned anything from your current provider, encode it here.

Phase 3: migration (weeks 4-10, parallel run)

The core principle: the old and new environments run in parallel, with continuous replication, until the new one has proven itself.

1. Provision the target environment in your accounts, configured to the design, with monitoring live from day one.
2. Replicate data continuously from source to target. The method is engine-specific. For PostgreSQL, logical replication streams changes to a target running the new version until lag reaches zero. For MySQL, an initial dump (mysqldump or Percona XtraBackup) followed by binlog replication catches the target up to the source. For Apache Cassandra, the distributed model changes the shape of the job: you add the target as new datacenters to the ring, let it stream and rebuild, and cut over once consistency is confirmed.
3. Verify with checksums and row counts, then run production-shadow load against the target: real query patterns, real volumes. On the relational side, the discipline that prevents silent data loss is MD5/SHA checksum verification on every critical table, not just row counts, plus a replication-lag alert below five seconds before you schedule the cutover.
4. Rehearse the cutover at least once, including the rollback. Measure the actual cutover window; it is typically minutes.
5. Cut over in a planned window: freeze writes, drain replication lag to zero, switch connection strings or DNS, unfreeze. For most topologies the write-freeze is minutes but exact windows vary by engine and topology.
6. Keep the rollback path warm for an agreed observation period (usually two to four weeks) before decommissioning the source.

Phase 4: Day-2 handover (from cutover onward)

The migration is not the product. The operation is. \

Day-2 means: 24/7/365 monitoring with follow-the-sun coverage, proactive tuning and capacity management, patching and upgrade cycles agreed in advance, tested restores on schedule with evidence you can see, and a monthly review that includes recommendations, not just uptime reports.

At Maxima Consulting this runs under a 99.99% uptime SLA, enforced end to end, from SRE teams in Kraków and Pune, across the relational engines and Apache Cassandra alike. Maxima Consulting is a managed cloud operator and engineering partner that runs Day 0, 1 and Day-2 operations for software vendors and enterprises. Replatforming itself is one of our standing migration and modernization services.

The three mistakes that cause migration horror stories

Big-bang cutovers. 

Moving everything in one weekend with no parallel run. If anything surprises you, and something always does, there is no way back. Parallel-run migrations turn surprises into log entries instead of incidents.

Migrating the mess. 

Copying an unhealthy environment as-is preserves every problem you were trying to escape. Discovery exists to decide what gets fixed in transit (versions, topology, security posture) and what gets moved untouched.

Skipping the restore test. 

A migration is the one moment you are guaranteed to have a complete, verified copy of everything. Test the restore before cutover. If your new provider does not insist on this, that is sign number one all over again.

FAQ

How much downtime should we expect? 

For replication-based migrations, the write-freeze during cutover is typically minutes; read traffic can continue throughout. Environments with unusual topologies or very old engine versions may need longer windows, which discovery identifies upfront.

Can we switch providers while under contract with the current one? 

Yes. Discovery and design are read-only and independent. Many clients time the cutover to land at contract renewal so nothing overlaps.

Who talks to the old provider? 

You control that. Nothing in phases 1-2 requires the incumbent's cooperation. During migration, standard data-export and access requests are usually sufficient, and they are obligations in most contracts.

What does a switch cost? 

Migration is typically priced as a fixed project after discovery, so there is a number before there is a commitment. The relevant comparison is against the annual cost of staying: overspend, incidents, and engineering time lost to the current provider.

What happens to our backups and history? 

Historical backups are exported or retained per your compliance requirements before decommissioning. Restore evidence for the new environment is produced before cutover, not after.