Data platform

Database migration and replication: the decision checklist

Database migrations rarely fail on the copy. They fail on a decision nobody made — what counts as done, how much downtime was really acceptable, or what rollback means once the new system has taken writes. This checklist works through those decisions in the order they stop being reversible.

Decision checklist Published September 7, 2026 5 min read

Arrange a migration review Database migration services

01The real failure mode

Migrations fail on decisions, not on transfers

Copying data between database engines is a solved problem. Tooling exists, it works, and the copy is rarely where a migration comes apart.

What comes apart is the part nobody wrote down: whether a two-hour window was a target or a limit, what "the data matched" was actually checked against, and who decides — at 4am, with traffic on the new system — that this is going backwards. Each of those has a right answer, and each gets much more expensive the later it is settled.

02Decision one

What actually moves

The most common scope error is assuming the answer is "everything". It usually should not be.

A list of the schemas or databases in scope, and — explicitly — the ones that are not.
A decision on historical data: does it migrate, archive, or stay behind a read-only copy of the old system?
An inventory of what else connects: reporting tools, ETL jobs, that one spreadsheet with an ODBC connection, and the integration nobody has owned since its author left.
A decision on stored procedures, triggers and jobs — ported, rewritten, or retired. "Ported" is a bigger answer than it sounds.
The character set and collation the target will use, decided rather than defaulted, especially where Arabic text is involved.

03Decision two

The downtime budget decides the method

Acceptable downtime	What that permits	What it demands
A weekend	Backup, restore, verify, switch. The simplest thing that works, and it usually does	A tested restore time on production-sized data — not on a sample
A few hours	Bulk load plus a catch-up window, with writes stopped at the start of it	Rehearsal, because the catch-up is where the estimate is usually wrong
Minutes	Continuous replication with a short cutover: the target is already current when you switch	Replication running for days beforehand, monitored, with lag as a release gate
None	Dual writes or a full read/write split during transition	Application changes and a reconciliation strategy. This is a project, not a step in one

04Decision three

How you will prove the data arrived

Row counts are necessary and not sufficient. Every migration that went wrong quietly had matching row counts.

Row counts per table, compared — the floor, not the test.
Checksums or aggregate comparisons on the columns that carry money, identity or dates.
A named sample of real records, chosen before the migration, checked field by field afterwards by someone who knows what they should say.
An explicit check on the things engines disagree about: date and time zones, numeric precision, empty string versus NULL, and character encoding for Arabic text.
A business-level check: one report, run on both systems, producing the same total.
A decision on who signs off that validation passed, made before the night it matters.

Decision four

What rollback means

Rollback stops being possible the moment the new system takes a write

Before cutover, rollback is trivial: point back at the old system. After the new one has accepted a single write, it is no longer a rollback — it is a second migration, backwards, under pressure, with data that now exists in only one place.

So the decision is not "do we have a rollback plan". It is: what is the last moment we can still go back, what has to be true at that moment, and who is allowed to make the call. Written down, before the night. If the answer is "we cannot go back after 02:00", that is a fine answer — it is an unwritten one that hurts.

05Decision five

The rehearsal

A cutover rehearsed once on production-sized data is a different event from one attempted for the first time on the night.

Rehearsed on data of production size, not a subset — the timing is the thing being tested, and it does not scale linearly.
Timed at each step, with the numbers written down and compared against the window you have.
Run by the people who will run it on the night, at a realistic hour rather than a convenient one.
Including the validation, so the validation itself is timed and known to be feasible inside the window.
Including the rollback, at least once, so the last-safe-moment answer is measured rather than assumed.
With the application pointed at the target, because a migration nobody connected to is a copy, not a rehearsal.

06Decision six

Who does what on the night

Role	Owns	The failure when it is unassigned
Cutover lead	The sequence, the clock, and the call to proceed or stop	Everyone waits for someone else to decide, and the window closes
Database owner	The migration steps themselves and their verification	Steps get run twice, or skipped, because two people assumed the other had
Application owner	Repointing the application and confirming it works against the target	The database migrated fine and nothing can reach it
Validation owner	Running the agreed checks and stating pass or fail	Validation becomes "it looks fine", which is not a check
Business sign-off	Confirming the system is usable, from outside engineering	Technically successful, discovered broken on Monday morning

07Buyer questions

What buyers ask us

Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.

How long does a database migration take?

The copy is usually the shortest part and the easiest to estimate. What sets the calendar is the inventory of what connects to the database, the rewrite of anything engine-specific, and the rehearsals. A migration described as "a weekend" is usually a weekend of cutover after weeks of preparation, and the preparation is where the estimate should live.

Do we need replication, or is a backup and restore enough?

It is decided entirely by the downtime budget, which is why that is decision two above. If you can stop writes for a weekend, backup and restore is simpler and has fewer ways to go wrong. If the window is minutes, you need the target to be current before you switch, and that means replication running and monitored beforehand.

What usually goes wrong?

In our experience, three things, none of them the copy. Something connected to the database that nobody knew about. A data type that behaved differently on the target — dates, precision, or encoding, and for Arabic text usually encoding. And a catch-up window that took longer than the rehearsal suggested because the rehearsal ran on less data.

Can we migrate without any downtime at all?

Yes, and it is a bigger project than it sounds. Zero downtime means the application writes to both systems, or reads and writes are split during a transition, and either way it means application changes plus a strategy for reconciling divergence. It is the right answer when the business genuinely cannot stop; it is an expensive answer to a requirement nobody tested.

From the insights library

Read the checklist against your migration

Describe the source, the target and the window you think you have. The gap between the window you think you have and the one the rehearsal shows is usually the conversation.

Or directly

+966-11-2180999 info@interkey.com.sa

Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia

or Database migration services

Published by Interkey. Last updated 2026-09-07. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.