Cloud migration · Data center migration
Data center migration in Saudi Arabia: from discovery to the last server switched off
A data center migration moves the applications, databases and infrastructure running in one facility to somewhere else: a partner cloud region, another site in the Kingdom, or a mix of both. It is finished when the old site is empty, not when the first application runs in the new one. Interkey, a Google Cloud partner and an AWS partner, plans and runs data center exit and consolidation programmes for organisations in Saudi Arabia, and moves the databases with iblync, its own platform, while production stays in service.
Orientation
At a glance
The whole page in one table, before the detail.
- What it is
- Moving every workload out of a data centre, then switching the site off
- Typical triggers
- A lease or colocation contract ending, hardware at end of life, consolidation of several sites
- Where workloads can land
- Google Cloud Dammam (me-central2), other partner cloud regions, or another site in the Kingdom
- Databases
- Moved with iblync: source in service, continuous replication, a planned cutover window
- Applications
- Decided one by one: leave, retire, rehost, replatform to containers, or rewrite
- What Interkey does
- Discovery, wave plan, landing zone, migration, cutover and decommissioning, from Riyadh
In short, for decision makers
- The date is usually fixed: a contract or hardware cycle sets it, and the plan works backwards from it.
- Classification comes first: each workload's data class decides whether it may sit in a cloud region or must stay in the Kingdom.
- Databases are the hard part: they need a cutover the business can live with.
- The cost most often missed: running both sites at once.
What a data center migration covers, and why it is more than a move
These programmes start for recurring reasons: a colocation or lease contract is ending, the hardware is due for replacement, or several sites are being consolidated into fewer. Some call it a data center relocation, some a DC exit, some a datacenter to cloud migration. The work is the same: find out what runs in the room, decide where each piece goes, move it in dependency order, and switch off what is left.
Read more
The estate is always larger than the diagram says. Forgotten servers and a monthly job feeding another system are found in discovery or on cutover night. Each workload gets one of the five answers on our cloud migration page, and "leave it where it is" stays a real answer.
Relatedcloud migration page
Data center migration scope: the workstreams and who owns them
| Workstream | What it covers | What Interkey does | What stays with your teams |
|---|---|---|---|
| Discovery | Servers, applications, databases, storage, network flows and owners | Builds the inventory and the dependency map | Naming owners and confirming what each system is for |
| Classification | The data class of each workload and where it may run | Records the constraint against each entry | The classification decision itself |
| Wave plan | Groups of workloads that move together, in dependency order | Proposes the waves and the cutover windows | Agreeing dates around the business calendar |
| Landing zone | Accounts, networking, identity, logging in the target | Designs and builds it before the first wave | Approving access and security standards |
| Databases | Moving data while the source stays in service | Runs the migration with iblync and the validation | The go or no-go call at cutover |
| Applications | Rehost, replatform to containers, or retire | Does the move and the fixes each route needs | User testing and sign-off |
| Decommissioning | Archiving, wiping and switching off the old estate | Plans the order and evidence per server | Disposal and contract closure |
A row with no owner is how a programme ends with two estates running, so the scope is written per row first.
Where the workloads can land in and around the Kingdom
Google Cloud runs a region in Dammam (me-central2), reached through the reseller route Google sets for organisations billed in Saudi Arabia; our Google Cloud page explains it. AWS has announced its first Region in the Kingdom and says it is on track to launch in December 2026. It was not in AWS's Region list on 2 November 2026; until it is, AWS's Middle East Regions are in Bahrain and the UAE, as our AWS page records. A wave plan that depends on a region opening on schedule names that risk.
Read more
Some workloads will go to another site in the Kingdom, and some stay on infrastructure you operate. Classification decides, under rules from Saudi authorities: the National Cybersecurity Authority (NCA) publishes cybersecurity controls, including for cloud computing, and the Saudi Data and AI Authority (SDAIA) oversees the Personal Data Protection Law. Which apply depends on your sector and data.
RelatedNational Cybersecurity Authority (NCA)Saudi Data and AI Authority (SDAIA)
Building the data center migration plan: discovery and waves
Discovery combines what tools see with what people know. Network flows show which machines talk to each other; owners explain why, and which month-end job would break if one moved alone. Every entry ends with a decision, a reason, a target and an owner.
Systems that call each other often move in the same wave, because splitting them adds latency and a link to secure and pay for. The first wave is real but recoverable. Systems with a hard constraint, such as a licence tied to hardware, are scheduled early. Our database migration checklist lists what to settle per database before its wave is fixed.
Relateddatabase migration checklist
Moving databases while the business keeps using them
A bulk export wants days of downtime; the business usually grants a few hours at a weekend. Zero downtime migration with iblync closes that gap: the source stays in service, the data is copied once with throttling, and continuous replication keeps both sides in step while validation runs. Reads can move first, service by service.
A short planned step remains: writes pause or queue while the last changes drain, checks such as row counts and checksums run, then reads and writes switch. We size that window in scoping instead of promising none, and the source stays until the numbers hold through a real peak, so switching back stays possible.
Applications: rehosted as they are, or moved to containers
A fixed exit date pushes many applications towards a rehost: the same application on new infrastructure. It is fast and low-risk, carries every inefficiency with it, and is followed by a right-sizing pass. Applications worth changing are replatformed, often to containers, starting from the application: local session state and hard-coded configuration are fixed before it runs as several instances. The Kubernetes migration page sets out that path.
How a data center migration project runs
-
Discover and classify.
Inventory, dependency map, data class and owner for every system in the room.
-
Decide per workload.
Leave, retire, rehost, replatform or rewrite, with the target and the reason recorded.
-
Build the landing zone.
Networking, identity, logging and the link between old and new sites, before the first wave.
-
Move in waves.
Applications and databases in dependency order, each wave with its own rehearsal and rollback plan.
-
Cut over and hold.
The agreed window, the validation gates, a named go or no-go owner, and the source kept until the numbers hold.
-
Decommission.
Data archived as retention requires, servers wiped and switched off, the site handed back.
What drives the cost and the timeline
Each programme is quoted from its own inventory. The factors that move the number most:
- The overlap. You pay for both sites while waves run; prompt decommissioning keeps it short.
- Data volume and change rate. They set the length of the load and the replication.
- Licensing. Check whether each per-server or per-core licence moves with its workload.
- Leaving again. Moving data out of a cloud costs more than moving it in.
- Business windows. Month-end, Ramadan and year-end close limit when a cutover can happen.
Read more
The timeline follows the same factors; we estimate it as a range after discovery, with its reasons. The team that scopes the programme runs it from Riyadh, in Arabic or English, on the Saudi working week, and can operate the new estate afterwards under a written managed-services scope. iblync, Interkey's own platform, is priced by quotation; cloud consumption is quoted through each provider's route in the Kingdom.
Questions buyers ask about data center migration
Our colocation contract in Riyadh ends next year. Is that enough time to empty the data centre?
It depends on how many systems are in the room, how many databases must move with production live, and how many cutover windows the business calendar allows. We give a range with its reasons after discovery, and name what would put the date at risk.
Can all our workloads stay inside Saudi Arabia after the data centre exit?
Yes, if that is what your classification requires. Google Cloud runs a region in Dammam, and workloads can also move to another site in the Kingdom. AWS has announced a Saudi Region; a plan should not depend on it until it is live.
Do we have to move everything to the cloud when we close a data centre?
No. Each workload gets its own decision: some go to a cloud region, some to another site in the Kingdom, some are retired, and some stay on infrastructure you operate.
How do you move a database that is used around the clock?
With iblync, the source keeps serving while data is loaded and replicated. A short final window is planned for the last changes and the switch, and its length is agreed with you in scoping.
How is a data center migration project priced in KSA?
By quotation, from the inventory: the number of systems, data volume, the routes chosen and the overlap period. iblync is quoted by source, target and volume, and cloud consumption is quoted separately.
Who looks after the new environment once the old data centre is switched off?
Your team, Interkey under a written managed-services scope, or both. That owner is named before the first wave, so the new estate has standards and a cost owner from day one.
Next
Related pages
Next step
Scope your data center exit
Tell us roughly how many servers and databases the site holds, when it must be empty, and which data must stay in the Kingdom.
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