Typical mistakes in a zero-downtime database migration

A safe migration starts with "what breaks around it", not with the copy command

When a company plans a database migration, attention goes to the database itself: schema, dump, replication, data volume. But in a live product the database never lives alone. Queues, integrations, background jobs, authorisation, reports and admin tools all pass through it — and those are the parts that fail first.

Where migrations break most often

• Cutover is not designed: nobody defined who stops writing to the old system and when the new one takes over.
• Background workers and integrations keep following old rules and create data drift.
• Tables were tested but roles, permissions and admin operations were not.
• Rollback exists on paper and was never rehearsed on a copy of production.

Why "we will do it at night" is not "we will do it without downtime"

A night migration reduces the number of users, not the business risk. If the application, integrations or document operations behave differently after the switch, downtime happens anyway. What matters is not the time of day but control over the window: a checklist, a tested recovery path and someone who can make the call to roll back.

What to verify before the migration

• Which business scenarios are critical and must pass immediately after the switch.
• Who is the system of record at each stage, and how write conflicts are prevented.
• How queues, cron jobs, admin operations and integrations behave during cutover.
• How long the rollback takes and what data has to be reconciled if it is used.

What separates a mature migration from a risky one

A mature migration is managed as a change in a business-critical system: with a checklist, a restore test, a role check, communication about the work window and clear ownership. A risky migration looks like a technical manoeuvre by one team that suddenly affects support, sales and finance.

What the business should get

Not "the database was moved", but confidence that real scenarios still work afterwards: orders, documents, roles, access, integrations and reports. That is what a migration without dangerous downtime actually means.