How to migrate SQL Server to cloud comes down to nine steps in a fixed order: inventory, dependencies and logins, a hosting model for each database, upgrade timing, the data move, tests, a cutover rehearsal, a rollback point, and patching and backups after the move. Every step closes with a test that shows the work is finished.
Last reviewed 2026-11-14 by Manish Sharma.
SQL Server is Microsoft’s database server, and it runs on Windows Server hosts. Also, a cutover is the switch from the old system to the new one. In addition, a rollback is the way back to the old system if the switch fails. The plan stays neutral between providers and states no prices, license terms, support dates or downtime figures. For the Windows Server hosts under those databases, use the host by host checks for the servers that carry your databases. Readers in India or the GCC who run databases or infrastructure can use it to order the move, and an IT head can see who signs each step off.
How to Migrate SQL Server to Cloud: Nine Steps at a Glance
In the table, every step has a likely owner and a test for finishing it. The owners are our suggestion, so replace the roles with the ones your firm has.
| Step | Suggested owner | Done when |
|---|---|---|
| 1. List instances and databases | The database lead lists them. | Every instance and database has a version, a size and an owner on the list. |
| 2. Map dependencies and logins | The database lead maps them, with the application owners. | Every application, job, linked server and login has an owner, and sign-in works from the target. |
| 3. Choose a hosting model | The infrastructure lead recommends, and the IT head decides. | Each database has a hosting model, with the reason on record. |
| 4. Decide on upgrade timing | The IT head decides, with the database lead. | The decision to upgrade during or after the move is written down. |
| 5. Move the data and keep it in sync | The database lead runs it. | Row counts and key totals on the target match the source. |
| 6. Test on the target | Each application owner tests their own system. | Every application passes its tests, and its owner signs it off. |
| 7. Rehearse the cutover | The database lead runs it, with a business owner. | A timed run fits the agreed window and leaves no open defect. |
| 8. Set the rollback point | The IT head decides, with the business owner. | The old instance stays readable, and the point of no return is named. |
| 9. Set patching and backups | The infrastructure lead runs it. | A patch owner is named, and a backup has been restored on the target. |
Before You Migrate SQL Server to Cloud: Scope, Owners and Hosts
Settle who does the work and signs off, and what the first version of the move covers, before step 1.
Name a database lead, an infrastructure lead, an owner for each application, a security lead for access, and a business owner who agrees the downtime window. Without a named business owner, however, nobody can say how long the databases may be offline.
The hosts move with the databases. The server a database runs on is built at Step 3, so there is no separate stage for hosts. The order inside the nine steps matters more than which comes first on paper.
The host that a database runs on is built at Step 3, and the plan has no separate host stage.
Some topics stay out. Other database engines and conversions between engines are different projects. License terms and prices are also out of scope, because they depend on contracts this plan does not see.
How to Migrate SQL Server to Cloud, Steps 1 to 4: Inventory, Logins, Hosting Model and Upgrade
Steps 1 to 4 turn a vague estate into a list of decisions. Then each decision is written down before any data moves.
Step 1: List Every Instance and Database
List every instance, and under each one every database, with its version, edition, size, owner and host. A short list built from memory misses the test database that one application still reads from.
If you need a method for the version list, how to take a version inventory covers it, and explains why the versions matter for support dates. To migrate SQL Server to cloud on a sound footing, keep those dates there and keep this plan to the order of work. If a bridge is needed for older versions, ask your supplier about Extended Security Updates.
Done when every database has a version, a size and an owner on the list.
Step 2: Map Dependencies and Logins
Then find everything that talks to each database: applications, linked servers, scheduled jobs, reports and file shares. Then list the logins and service accounts, because a missing login is the dependency found latest. Check that Active Directory sign-in works from the target.
Each dependency gets an owner. Done when every item has one and a test sign-in works from the target.
Step 3: Choose a Virtual Machine or a Managed Service per Database
Make this choice database by database, not once for the estate. Then use questions, and record the answers.
| Question | What to record |
|---|---|
| Does the database use features the target must support? | The feature list, checked against the documentation of each target. |
| Does it run agent jobs or linked servers? | Each job and link, with its owner. |
| Does the team need control of the operating system? | Yes or no, with the reason. |
| How large is the database? | Its size and its growth. |
| Who patches the host and the engine? | A named person or team. |
Microsoft Learn’s SQL Server data migration overview describes the Azure targets (virtual machines and two managed services) and the migration methods for each. For examples of managed services, see one managed service example on Azure and a second managed service example on AWS. The choice of cloud is a separate decision, and this plan does not make it. For that choice, see a factor by factor guide to picking a cloud for Windows databases.
Key Takeaway Choose the hosting model database by database, and record the reason for each.
Step 4: Decide to Upgrade During or After the Move
Decide whether the SQL Server version changes during the move or after it. Then ask three questions. Have the applications been tested against the newer version? Can the team handle two changes at once? Does the rollback plan still work after an upgrade, given that Microsoft’s backup documentation does not support restoring a backup from a newer version on an earlier version?
We recommend separating the two changes, unless a support date forces one of them. Write the decision down, with the reason.
How to Migrate SQL Server to Cloud, Steps 5 to 9: Data, Tests, Cutover, Rollback, Patching
Steps 5 to 9 move the data and make the switch safe. Each one relies on the decisions from the first four.
Step 5: Move the Data and Keep It in Sync
Choose between an offline move by backup and restore, and an online move by replication. The downtime the business accepts decides it. An offline move needs a longer window, while an online move keeps the target in sync until the cutover. Microsoft Learn’s database migration guide covers data sync and the cutover for one managed target.
When you migrate SQL Server to cloud with an online move, agree the window for the final sync before the first rehearsal. Then compare row counts and key totals on the target with the source, and file the comparison as evidence. Ask counsel which hosting rules cover your data.
Step 6: Test on the Target Before Anyone Switches
Run each application against the target with its owner. Then test the jobs, the reports and the logins. Then compare performance with a baseline taken on the source, so a slow query shows up before go-live. Each owner signs their application off.
Step 7: Rehearse the Cutover
Run the rehearsal on a copy, with a clock on every task. Then record who does what, in what order, and where the decision point sits. Repeat until one run fits inside the window and leaves no open defect. No set number of runs is promised here.
run the rehearsal on a copy.
put a clock on every task.
note who does what, in what order, and where the decision point sits.
run again until one run fits the window with no open defect.
Step 8: Set the Rollback Point Before You Cut Over
Keep the old instance untouched and readable. Name the point after which a rollback means losing data, so the decision at the cutover is clear. If writes land on the target, plan which way the data syncs back. Agree with the business owner how long the old system stays, and give the answer as a condition, not a figure.
Step 9: Set Patching and Backups After the Move
Name a patch owner and a schedule for the target. Take a backup and restore it on the target, because a backup that nobody has tested by restoring it is only a hope. Meanwhile, set monitoring and alerts, and keep an eye on cost. Retire the old hosts only after sign-off.
Take one backup and restore it on the target before sign-off, and keep the result with the step 9 record.
Key Takeaway A backup restored on the target is evidence, and a backup nobody has restored is only a hope.
Four Set-Up Mistakes When You Migrate SQL Server to Cloud
Teams new to this work repeat four mistakes, and each costs more the later it surfaces.
- Logins found at cutover. An application then fails at the first sign-in. Build the login list in Step 2.
- Upgrade and move in one jump with no test. Defects from the two changes then land together. Record the Step 4 decision.
- One rehearsal the night before. With a single run, a window that is too short shows up when changing it is hard.
- A backup that was not restored on the target. The first restore then happens during an incident.
What This Plan to Migrate SQL Server to Cloud Leaves Out
The scope here is the order of work. Other topics belong in other places:
- Scored checks before cutover: a separate topic.
- The choice of cloud: a separate topic.
- Licenses: the use case page answers the common questions.
- Prices: this plan gives none.
For other engines and general database moves, a separate use case applies. Bring in outside help if the dependency map is unclear, if the firm has no database lead, or if an upgrade and the move are planned as one. How Signisys moves SQL Server and its hosts as one project shows how we run such a project.
Signisys also provides cloud migration support for mixed server estates and platform engineering for the target environment. In a consultation we read your instances, dependencies and downtime window against the nine steps, and we make no promise about results. No charge, with a fixed scope.
How to Migrate SQL Server to Cloud: FAQ
Can the data move by backup and restore, or does it need continuous sync?
How long should the rollback point stay open?
Do the hosts move before or after the databases?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.