iblync · Cloud migration
Cloud database migration in Saudi Arabia, with production still running
A cloud database migration moves a production database from your own servers, or from another cloud, into a managed or self-run database in a cloud region, without losing data and without taking the business offline for days. For Saudi organisations two questions come first: which region the data may land in, and whether the cloud provider's own migration service is enough. iblync, Interkey's own migration and replication platform, is for the moves where it is not.
In short, for executives
- The decision that comes first: where the data may live. Some data classes may sit abroad, some need an in-Kingdom region, some stay on your own systems.
- Regions in the Kingdom: Google Cloud runs a region in Dammam. AWS has announced a Saudi Region; plan around what is live on the day you buy.
- The tool: when source and target are the same engine, the cloud provider's own migration service is often the simplest path. When engines differ or both systems must stay live and in step, iblync is built for that.
- The risk: rarely the copy. It is the cutover, an unrehearsed rollback, and data passing through somewhere nobody approved.
- What Interkey does: assessment, the migration with iblync, cutover, and support from Riyadh afterwards. Priced by quotation.
At a glance
| Question | Answer |
|---|---|
| What moves | Relational and NoSQL databases, from your data centre or another cloud, into a cloud region |
| Target clouds | AWS, Microsoft Azure and Google Cloud, managed database services or databases you run on cloud servers |
| In-Kingdom regions | Google Cloud Dammam (me-central2) is live; the AWS Saudi Region is announced; check each provider's list when you buy |
| Pattern | Throttled initial load, continuous replication, parallel running, then a planned cutover with rollback |
| Where iblync runs | Confirmed per engagement, with whether any data leaves your environment |
| Commercial model | By quotation: source systems, target systems and data volume |
What a cloud database migration has to cover
Copying tables into a cloud database is the easy part. A cloud database migration that holds up in production settles five things before the first byte moves:
- The target region, chosen from the data's classification, not from a price list.
- The target service, a managed database or the same engine on cloud servers.
- The data model, because a move to a different engine means transformation, and that is real work.
- The downtime the business will grant, usually a few hours at a weekend, not the days a bulk export wants.
- The proof: counts, checksums and application checks that show the move is complete.
Read more
Typical starting points are a data-centre exit with a fixed date, a move from a region abroad into the Kingdom, a change of engine during the move, or a cloud reporting copy that must stay in step with an on-premise system. Our cloud migration practice decides which applications should move at all; this page covers the databases underneath them.
Relatedcloud migration practice
Moving databases into cloud regions in the Kingdom
The region map is changing, so read this as dated. Google Cloud runs a region in Dammam (me-central2); our Google Cloud in Saudi Arabia page explains access. AWS has announced a Saudi Region and says it is on track to launch in December 2026; it was not in AWS's Region list on 2 November 2026 (see AWS in Saudi Arabia). For Azure, check Microsoft's region list when you buy.
Read more
A live region does not mean every service is live in it, so check that the managed database and version you need are offered there. And a plan that depends on a region opening on schedule carries a risk it does not control: classify the data now and keep the source in service until the region is ready. Moving twice, first to a nearby region, is possible; write it into the plan.
The cloud provider's own service, or a vendor-neutral tool
AWS, Azure and Google Cloud each offer their own database migration service, and for many moves it is the right choice. Check these points first.
| Question to check | Provider's own service usually fits when | A vendor-neutral tool such as iblync fits when |
|---|---|---|
| Source and target engines | Both are the same engine, or a pairing the provider documents and supports | The engines differ, for example a relational source and a NoSQL target, and transformation is real work |
| Where the target lives | The target is that provider's managed database | The target is on another cloud, on your own servers, or in more than one place |
| After the move | The source is switched off once the move is done | Both systems stay live and in step for a long period, or in both directions |
| Effect on production | The source can take the extra load of the copy | Throttling and queueing are needed so the move does not compete with production |
| A second migration | This is a one-off | More databases follow, and configured workflows make each one cheaper than the last |
The rule on our iblync product page applies here: when a supported native path exists between the two systems, it is usually cheaper and better supported, and we will say so.
How iblync moves a database into the cloud
iblync follows the pattern Interkey uses when production must keep running:
- Initial load. The bulk of the data is moved once, throttled so it does not compete with production.
- Continuous replication. Later changes are applied to the cloud target continuously, and queue instead of failing if the target is unavailable.
- Parallel running. Both databases stay live and in step for as long as validation requires. Reads can move first, service by service.
- Cutover. In an agreed window the last changes drain, checks run, then reads and writes switch. The source stays until the numbers hold through a real peak.
Read more
iblync's own site states that an interrupted migration resumes where it stopped and that validation uses checksums and row counts. Listed sources include MySQL, PostgreSQL, SQL Server and IBM DB2. Our zero downtime migration page sets out what stays live in each phase.
Relatedzero downtime migration page
Migrate a database to AWS, Azure or Google Cloud
The method stays the same; the details change. To migrate a database to AWS, ask which managed engine and version you need, whether your chosen region offers it, and how the network path from your data centre is set up. An Azure database migration raises the same questions against Microsoft's services and regions. A GCP database migration into Dammam adds one: confirming your account has access to the region.
A programme can use both tools: the provider's service for like-for-like moves, and iblync for moves between engines or systems that must stay in step.
Data residency during the migration, not only after it
Residency is usually discussed for the target. The move itself needs the same scrutiny: data passes through a replication engine, sometimes a staging area, and often logs and monitoring. Each has a location, and each should be approved as deliberately as the target region.
In Saudi Arabia the frameworks that shape the answer include the Personal Data Protection Law, overseen by the Saudi Data and AI Authority (SDAIA), and the cloud controls of the National Cybersecurity Authority (NCA), alongside any rules of your own sector regulator. We do not restate what they require; read the authorities' own texts with your compliance owner, because obligations depend on your sector and your data classes.
Read more
What we can do is keep the path inside the boundary you set. Where the replication engine runs, next to the source or in the target region, is confirmed per engagement before any data moves. Interkey works from Riyadh, with Arabic-speaking engineers from scoping to support. Our observability data residency guide applies the same reasoning to monitoring data.
RelatedSaudi Data and AI Authority (SDAIA)National Cybersecurity Authority (NCA)observability data residency guide
What drives the cost and the timeline
iblync is priced by quotation, against the source systems, the target systems and the data volume. There is no published price list. The provider bills the target database separately.
The timeline depends on your estate more than on the tool: how far the data models differ, how many applications use the database, how much data changes during the move, the network path into the region, and how long you want parallel running. We give an estimated range after the assessment, with its reasons.
How Interkey runs a cloud database migration
-
Assess.
Databases, versions, volumes, change rates, data classes and the downtime window. The answer can be "do not move this one".
-
Choose region and path.
The target region and service per database, and for each one, the provider's own service or iblync.
-
Design and prove the target.
Schema, queries and indexes tested against production-shaped data in the cloud region.
-
Load and replicate.
Throttled initial load, then continuous replication with queueing, inside the agreed residency boundary.
-
Run in parallel, then cut over.
Reads first, then writes, behind pass conditions agreed in advance and a rehearsed rollback.
-
Stabilise and support.
Tuning under real load, then handover or support from Riyadh.
Questions buyers ask
Which cloud regions inside Saudi Arabia can we migrate a database into?
Google Cloud runs a region in Dammam. AWS has announced a Saudi Region, on track for December 2026 by AWS's account; it was not in its Region list on 2 November 2026. Check each list, and your database service, when you buy.
Should we use the cloud provider's migration service or iblync?
For a like-for-like move into that provider's managed database, its own service is often simpler. iblync fits when engines differ, when both systems must stay in step, or when the target is elsewhere.
Does our data leave the Kingdom while the database is being migrated?
Only if the plan routes it out. The replication engine, staging area and logs each have a location, agreed with your security team first. iblync can run inside the Kingdom.
How long does a cloud database migration take for a Saudi organisation?
It depends on how far the data models differ, how many applications use the database, how much data changes during the move and how long you want parallel running. We give an estimated range after the assessment, with the reasons behind it.
How is a cloud database migration with iblync priced?
By quotation, against the source systems, target systems and data volume in scope. The cloud provider bills the target database separately. There is no published price list.
Can the on-premise database keep running after we move to the cloud?
Yes. Replication keeps both in step for as long as you need, and the source stays after cutover until the numbers hold through a real peak, so switching back stays possible.
Next
Read next
Next step
Scope a cloud database migration
Tell us the source databases and versions, the cloud and region you are considering, a rough data volume, and the downtime window the business will grant. The reply comes from the team that would run the migration.
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