Database moves and upgrades without long outages
Move PostgreSQL, MySQL or SQL Server to managed or self-hosted targets, or upgrade major versions, using replication and a near-zero-downtime cutover with a tested rollback.
Overview
Databases are where migrations go wrong. An unsupported extension, a sequence that was not synced, or a query plan that changed after a major version upgrade can turn a planned hour into a lost weekend. Most teams also put off upgrades until the provider forces them, which leaves little time to test.
We move and upgrade databases using logical replication or change data capture, so the new database stays in sync while you test against it. Cutover is a short, rehearsed switch with a written rollback path. We check extensions, collations, sequences and query performance before the real cutover, not after.
Signs you need this
- Your cloud provider has announced extended support charges for your database version
- Nobody has tried a restore of the main database recently
- The last upgrade attempt was rolled back and the reason was never written down
- The planned maintenance window is far shorter than a dump and restore would take
What you get
- Compatibility report
- Extensions, data types, collations, stored procedures and driver versions checked against the target, with fixes listed.
- Replication setup
- Logical replication, AWS DMS or Debezium configured from source to target, with lag monitoring during the sync.
- Performance comparison
- Your slowest and most frequent queries run against both databases so plan changes are found before cutover.
- Rehearsed cutover
- At least one full rehearsal on a copy of production, timed step by step, before the real switch.
- Rollback path
- Reverse replication or a frozen source kept ready, with the exact steps and the decision point for using it.
- Post-migration checks
- Row counts, checksums, sequence values and application smoke tests run and recorded after cutover.
How the work runs
- 1
Assessment
1 to 2 weeks
Review schema, extensions, size, write rate and application drivers. Pick the migration method and target configuration.
- 2
Sync and test
2 to 4 weeks
Build the target, start replication, and let your team test the application against the new database in a staging setup.
- 3
Rehearsal
1 to 2 weeks
Run the full cutover on a production copy, time it, fix surprises and update the runbook.
- 4
Cutover and watch
1 to 2 weeks
Perform the real switch in the agreed window, keep the rollback ready, and watch performance until the old database is retired.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- The application runs on the target database or new major version
- Row counts and checksums match between source and target at cutover
- Query plans for your critical queries have been compared and fixed where needed
- A tested backup and restore procedure exists for the new database
Tools we work with
- PostgreSQL
- MySQL
- Microsoft SQL Server
- Amazon RDS
- Amazon Aurora
- Google Cloud SQL
- Azure Database for PostgreSQL
- AWS DMS
- Debezium
- pgBackRest
- pg_upgrade
- Patroni
From our work
North American clients, delivered by the OpsBreak team
Database migrations planned around a tested rollback
Production databases moved with a tested rollback path
Questions buyers ask
- How long will the application be down?
- With replication, the outage is the time to stop writes, let the target catch up and switch connections. The rehearsal tells us that time before we agree the window with you.
- What if something goes wrong after cutover?
- The rollback path stays ready for an agreed period. If a serious issue appears, we switch back using the written steps rather than improvising.
- Do you need access to production data?
- We need database admin access to source and target to configure replication. We do not export data to our own systems, and all work happens in your environment.
- Can you upgrade in place instead?
- Sometimes pg_upgrade or a provider in-place upgrade is the simpler choice for smaller databases. We recommend whichever method fits your size, write rate and downtime limit.
Talk to us about database migration and upgrades.
Tell us what you run and where. We reply within one business day with questions or a quote.