Data platform
Database migration, run like production depends on it
The migration is never the risky part people expect, and always the risky part people skip: not the data copy but the cutover night, the query rewrite nobody sized, the rollback that was a slide instead of a rehearsal. This guide is how Interkey runs enterprise database migrations from Riyadh, written plainly enough to steal.
Migration guide Published 5 min read
Scope
What this covers, and for whom
Written for the CTO, database architect or application owner planning a move
Relational estates (Oracle and SQL Server are the usual sources) moving to a distributed document platform, and NoSQL-to-NoSQL moves (MongoDB, Cassandra, Redis workloads consolidating onto Couchbase). The honesty that frames all of it: some assessed workloads should move to a tuned relational setup or stay put, and the process below is designed to surface that answer early, while it is still cheap to hear.
01Start here
The assessment: a small engagement that prevents a large mistake
Every migration Interkey runs starts with a bounded, paid assessment, and its deliverable is a decision, not a slideware architecture: the workload read honestly (access patterns, consistency and transaction requirements, volumes and growth), the modelling distance between the current schema and the target, the per-service impact list for the application team, the deployment model your residency position allows, and a costed comparison that includes staying put.
One outcome deserves naming because so few vendors will: the assessment can conclude “do not migrate”, and has. That outcome costs you the assessment and saves you the programme, which is the best trade available in enterprise IT.
02The programme
The migration sequence, with your side of it stated
Phases rather than dates, because honest durations come from the assessment, not a template. Each phase names what your team owns; migrations fail in the half that goes unstated.
-
Phase 01
Model the data for how it is read
The success-deciding step: documents designed from the application’s real access patterns, never a table-by-table transliteration, and the query and index design proven against production-shaped data. Your side: access to the people who know how the application actually behaves, not just its schema.
-
Phase 02
Size the application change and start it
Data access moves to the platform’s SDKs, queries are rewritten for the document model, transaction logic is re-examined against distributed semantics with their documented constraints respected rather than discovered. Your side: engineering capacity per the impact list, or Interkey’s engineers embedded to carry it.
-
Phase 03
Build the bridge and dual-run
Continuous data flow from the legacy system into the new platform, both live, results compared service by service. Reads move first, in increments that can be reversed; the legacy system remains the system of record until the evidence says otherwise. The bridge itself is usually Iblync, Interkey’s own replication platform, which is what makes the dual-run period something you can extend rather than something you have to survive. Your side: the comparison criteria, and the patience to honour them.
-
Phase 04
Rehearse the cutover, then perform it
The cutover is executed exactly once and rehearsed more than once, including the rollback, which is only real if it has actually been exercised. Agreed criteria decide go and no-go; a named person on your side holds the authority to call it, and calling rollback is defined in advance as a success of the process, not a failure of nerve.
-
Phase 05
Stabilise, tune, hand over or operate
Cluster sizing reviewed against real production load, indexes tuned against real queries, failover drilled, backup proven by an actual restore. Then the platform is either handed to your DBAs with documentation and training, or operated by Interkey from Riyadh on the Saudi working week.
03The night itself
Cutover night, drawn as a sequence of gates
Every step below has a pass condition agreed in advance; failing one routes to the rollback path, which has been rehearsed and takes minutes, not meetings.
-
Freeze and final sync
Writes paused or queued on the agreed window; the bridge drains the last deltas
-
Validation gates
Row and document counts, checksums on agreed samples, application health checks, pass conditions agreed before tonight
-
Reads switch
Traffic observes the new platform; error rates and latencies against thresholds, not vibes
-
The rollback decision point
The named owner holds the go/no-go with a rehearsed way back; past this gate, writes move
-
Writes switch and monitor
The new platform is the system of record; the legacy system stays warm until the numbers hold through a real peak
The structure to copy even if you never hire anyone: every arrow is a gate with a pre-agreed pass condition and a named decision-maker, and the rollback path is a first-class citizen of the plan, not an appendix.
04Budget honestly
What actually drives migration cost
Quotes are per engagement, and these are the variables that move them, useful for sanity-checking anyone’s number, including ours.
- Modelling distance: a normalised relational schema is a bigger journey than a document store
- Service count touching the data, which sizes the application-change workstream
- Data volume and the acceptable staleness window, which shape the bridge design
- Consistency and transaction requirements, which decide how conservative the cutover must be
- The deployment model: managed service versus self-managed in-Kingdom infrastructure
- Who carries the application changes: your engineers, Interkey’s, or a mix
- Operations after go-live: handover to your DBAs versus operated by Interkey
Considering a data platform migration? Review the workload and the migration constraints with Interkey’s engineering team, an assessment whose honest outcomes include “not yet” and “not at all”.
05Buyer 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.
Which source platforms do you migrate from?
Relational sources, Oracle and SQL Server most commonly, plus MongoDB, Cassandra and Redis consolidations. The discipline is identical regardless of source; what changes is the modelling distance and where the application impact lands, which the assessment sizes per service before anyone commits to anything.
What happens if we decide mid-assessment that we should not migrate?
Then the assessment worked. You receive the written analysis and the reasoning, usually with a tuning plan for the platform you keep, and you have spent a fraction of a programme budget to avoid the wrong programme. No migration vendor loves this answer, which is a good reason to insist any vendor put it in writing as a possible outcome before you engage them.
How long does an enterprise migration take?
The assessment produces the honest schedule from modelling distance, service count and your team’s capacity; a duration quoted before that analysis is a guess with a signature. The structural commitments that hold regardless: value ships in phases, reads move before writes, and the legacy system stays in service until evidence, not the plan, retires it.
Can the migration keep our data inside Saudi Arabia?
Yes: the bridge, the target cluster and the tooling can all run on in-Kingdom infrastructure, which is frequently why self-managed deployment is chosen in the first place. The residency question is settled in the assessment, before any data moves anywhere; the Couchbase page covers the deployment-model decision in detail.
From the insights library
Continue exploring the data platform
Iblync: the migration and replication platform
The Interkey product that runs the bridge and the dual-run period, with its capability model and benchmark figures.
ImplementationCouchbase implementation in Saudi Arabia
The target platform this practice implements, with the current-versus-target architecture and the wrong-fit table.
HubThe data platform practice
What triggers a platform change, the disqualification framework, and the residency layer above this guide.
Implementation guideKubernetes monitoring in Saudi Arabia
New data platforms increasingly land on cluster infrastructure; here is how that layer stays visible.
ServiceApplication modernisation around the data layer
A migration rarely stays isolated to the database; the application code that reads and writes it usually needs the same attention.
Next step
Put your workload through the assessment
Tell us the source database, the rough data volume and the window the business can tolerate — the assessment is scoped from exactly those three facts.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia