Data platform · SQL Server
SQL Server migration: version upgrades and cloud moves without a long outage
A SQL Server migration is usually one of three moves: an upgrade to a newer SQL Server version, the same engine moved to a cloud virtual machine, or a move to a managed service such as Azure SQL that changes what the instance can do. Interkey plans each one from Riyadh with an assessment first, a parallel run in which the old and new databases stay in step, and a cutover in gated steps with a rehearsed rollback, so the business does not stop for the move. Where Microsoft's native tools are the shorter route, we use them.
Orientation
At a glance
The whole engagement in one table, before the detail.
- What moves
- Schema, stored procedures and functions, SQL Server Agent jobs, logins and data, plus the application connections that point at them
- Common routes
- A version upgrade; SQL Server on a cloud virtual machine; or a managed service: Azure SQL, Amazon RDS for SQL Server or Cloud SQL for SQL Server
- How the outage is kept short
- Initial load, continuous replication, a parallel run, then a cutover in gated steps
- Where the data sits
- On your infrastructure in the Kingdom, or in a cloud region chosen per class of data
- How it is priced
- Per engagement, after the assessment
- Who supports it
- Interkey's data team, during the move and after it
Which SQL Server migration you are actually planning
Most requests that arrive as "SQL Server migration" turn out to be one of four pieces of work, and each carries a different risk. The assessment names which of these you are doing for each database, because one estate often needs more than one.
- A SQL Server upgrade. Same engine, newer version, on the same servers or on new ones. The data moves easily. The risk sits in queries and features that behave differently on the newer version.
- Rehosting. The same SQL Server moved onto a virtual machine in Azure, AWS or Google Cloud. You keep full control of the instance, and patching, backups and high availability stay your own work.
- A managed service. Azure SQL Database, Azure SQL Managed Instance, Amazon RDS for SQL Server or Cloud SQL for SQL Server. The provider runs more of the platform, and in exchange some instance-level features work differently or not at all. This is where a SQL Server migration to cloud needs the most checking.
- Leaving SQL Server. A move to another engine, usually to change the licensing position. The schema and stored code are rewritten, which makes it a different project; our page on SQL Server to PostgreSQL migration covers it.
Comparing the targets: what stays and what to check
| Target | What stays the same | What to check before you commit |
|---|---|---|
| Newer SQL Server version, side by side | The engine, the tools and the skills your DBAs already have | Deprecated features, query plans under the new compatibility level, and the old server kept as the way back |
| Newer SQL Server version, in place | Server names, storage and connection strings | There is no old server to return to, so a tested backup and restore is the rollback |
| SQL Server on a cloud virtual machine | Full control of the instance, close to how it runs on premises | Region, network latency to the applications that stay behind, and how licences are counted on that provider |
| Azure SQL Managed Instance | Most instance-level behaviour, with the platform run by Microsoft | Each feature the database uses, checked against Microsoft's current documentation for the service |
| Azure SQL Database | The database and its T-SQL, as a single database or in a pool | Anything that reaches outside one database: Agent jobs, cross-database queries, linked servers, file access |
| Amazon RDS or Cloud SQL for SQL Server | The SQL Server engine, with backups and patching handled by the provider | Which editions, versions and features the service supports, and in which regions |
No row in this table is a verdict. The answer comes from reading what your database actually uses, which is the first task of the assessment.
SQL Server upgrade: move the engine first, change the behaviour later
A version upgrade looks like the safe case, and usually is, provided two things are kept apart. The first is the engine version. The second is the database compatibility level, which governs much of how the query optimiser behaves. A database moved to a newer version can keep its older compatibility level for a while, so the engine moves first and the behaviour change follows once it has been tested. Microsoft's documentation lists which compatibility levels each version supports; we confirm yours in the assessment.
Read more
Before the upgrade we capture a baseline from production: the heaviest queries, their durations and their waits. After the upgrade, the same measurements on the new version show whether anything regressed, query by query, instead of by complaint. If you do not have that history yet, SQL Server monitoring with Redgate Monitor is how we usually collect it.
The same pass looks for features the target version marks as deprecated or removed, and for the things that live outside the database and are easy to forget: Agent jobs, linked servers, logins, certificates and maintenance plans.
Migrate SQL Server to Azure, AWS or Google Cloud from Saudi Arabia
A cloud move adds four questions that an upgrade does not ask.
- Where the data may live. Your data classification decides whether a database may be hosted outside the Kingdom at all. Google Cloud runs a region in Dammam (me-central2). AWS has announced a Saudi Region; until it appears in AWS's list of available Regions, a plan should not depend on it. For Azure and every other provider, check the current region list on the day you decide, not a roadmap slide. Our guide to data residency in Saudi Arabia sets out that decision.
- Which service. A managed service saves operations work and removes some control. A virtual machine keeps the control and the work. The table above is the starting point; the database's real feature use decides it.
- How the licence is counted. SQL Server licensing changes with the target: depending on the service, the licence is included in the provider's price or brought across from your own agreement under Microsoft's terms. Settle it with the provider and your Microsoft licensing contact before sizing, because it can change which target costs less.
- The network to what stays behind. Applications that stay on premises while the database moves will feel the network between them. Applications that make many small calls for each screen are the ones to test first.
SQL Server migration tools, and where iblync fits
For a like-for-like move, the native routes are often the shortest: backup and restore, log shipping, a replica promoted at cutover, or Microsoft's own migration tooling for Azure. When source and target are both SQL Server and a supported native path covers your versions and your downtime window, that path is usually cheaper and better supported, and we recommend it.
Read more
iblync, Interkey's own data migration and replication platform built in Saudi Arabia, fits where the native path runs short: a long parallel run while services move one at a time, a move between clouds or onto a different engine, a period in which both sides accept writes, or a downtime window too small for a full restore. iblync's published connector list includes SQL Server. It controls its own rate so replication does not compete with production, and when the target is unavailable, changes queue rather than fail. The version, edition and target pair your project needs are confirmed in the assessment; where a system is not yet covered, custom connectors are built.
Relatediblync
How Interkey runs a SQL Server migration
-
Assess.
Versions, editions, size, change rate, features in use, jobs and logins, the applications that connect, the downtime window and the residency position. The output is a written recommendation, and it can be to stay where you are.
-
Choose the route per database.
Upgrade, rehost, managed service or a different engine, with the reasons written down.
-
Build and test the target.
Schema, security, jobs and settings on the target, tested against a production-shaped copy and the captured baseline.
-
Load and replicate.
An initial load, then continuous replication with native tools or iblync, while production runs.
-
Run in parallel.
Both databases in step. Reads can move first, service by service, in steps that can be reversed.
-
Cut over through gates.
A final sync in an agreed window, row counts and checksums, a go or no-go from a named owner on your side, then writes move. The rollback is rehearsed beforehand.
-
Stabilise and hand over.
Tuning on the new version or service and a proven backup and restore, then handover to your DBAs or operation by Interkey.
Working with a data team in Riyadh
Interkey's data engineers work from Riyadh, on the Saudi working week, in Arabic and English. A cutover window is often a weekend night in Saudi time, and the people who planned it are the ones on the call. The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom when the data classification asks for it, and the assessment records where each database will live before any data moves. For the method behind this page, from assessment to handover, see our database migration services.
Relateddatabase migration services
What drives the cost and the timeline
Quotes are per engagement, after the assessment, and so is the schedule. The drivers are the number of databases and instances, their size and change rate, how many features the target handles differently, how many applications must be retested, the downtime window, the deployment model and residency, and who operates the platform afterwards. As a rough estimate, one database moving to a newer version on the same platform is measured in weeks, and an estate moving to a managed cloud service with application changes in months. The assessment replaces both estimates with a plan. Where iblync is used, it is priced by quotation, per source system, target system and data volume.
Questions buyers ask
Can SQL Server be migrated without stopping the business?
The long part runs while production stays live: an initial load, continuous replication and a parallel run. What remains is a short, planned window for the final sync and the switch of writes, sized in the assessment against what your applications can tolerate.
Should we upgrade SQL Server before moving it to the cloud, or do both at once?
One change at a time is easier to prove. Doing both in one step saves a cutover but makes any regression harder to trace. Where the managed service already runs a newer engine, the move is the upgrade, and the before-and-after baseline carries the weight.
Which is the right target: Azure SQL Database, Managed Instance or a virtual machine?
The one your database's feature use allows, at the operations cost you want. Instance-level dependencies such as Agent jobs and linked servers point to Managed Instance or a virtual machine; a self-contained database can suit Azure SQL Database. We read the database and put the reasons in writing.
Can our SQL Server data stay inside Saudi Arabia after the move?
Yes, if the target is your own infrastructure in the Kingdom or a cloud region inside it. Google Cloud runs a region in Dammam; for other providers, check the current region list when you decide. Your classification policy decides which databases may be hosted abroad.
How much does a SQL Server migration cost, and how long does it take?
Both are set by the assessment: the number of databases, their size, the features the target handles differently, the applications to retest and the downtime window. There is no published price list. iblync, where used, is quoted per source system, target system and data volume.
Who looks after the database once the migration is finished?
Your DBAs, after a documented handover, or Interkey from Riyadh under a written managed-services scope. Either way, monitoring is in place from the first day on the new platform.
Next
Read next
Next step
Plan a SQL Server migration
Tell us the SQL Server versions and editions, the rough data size, the target you have in mind and the downtime window the business will grant.
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