- Acceptable downtime
- A weekend
- What that permits
- Backup, restore, verify, switch. The simplest thing that works, and it usually does
- What it demands
- A tested restore time on production-sized data — not on a sample
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 5 min read
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
- A few hours
- What that permits
- Bulk load plus a catch-up window, with writes stopped at the start of it
- What it demands
- Rehearsal, because the catch-up is where the estimate is usually wrong
- Acceptable downtime
- Minutes
- What that permits
- Continuous replication with a short cutover: the target is already current when you switch
- What it demands
- Replication running for days beforehand, monitored, with lag as a release gate
- Acceptable downtime
- None
- What that permits
- Dual writes or a full read/write split during transition
- What it demands
- 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
- Cutover lead
- Owns
- The sequence, the clock, and the call to proceed or stop
- The failure when it is unassigned
- Everyone waits for someone else to decide, and the window closes
- Role
- Database owner
- Owns
- The migration steps themselves and their verification
- The failure when it is unassigned
- Steps get run twice, or skipped, because two people assumed the other had
- Role
- Application owner
- Owns
- Repointing the application and confirming it works against the target
- The failure when it is unassigned
- The database migrated fine and nothing can reach it
- Role
- Validation owner
- Owns
- Running the agreed checks and stating pass or fail
- The failure when it is unassigned
- Validation becomes "it looks fine", which is not a check
- Role
- Business sign-off
- Owns
- Confirming the system is usable, from outside engineering
- The failure when it is unassigned
- 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
More on data platform work
Service
Database migration services in Riyadh
How Interkey runs the work this checklist describes, including who does what.
Productiblync data migration and replication
Interkey's own tooling for the replication half of decision two.
ServiceDatabase DevOps
What keeps schema changes safe after the migration, when the same risks arrive weekly instead of once.
Continue exploring
Next step
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 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia