How to migrate a database to the cloud comes down to ten steps in a fixed order: an inventory, a move type, a managed target, a method, network and access, a rehearsal, a cutover plan with a rollback point, the cutover, backups and alerts, and retiring the old servers. Every step ends with a test.
Last reviewed 2026-11-14 by Manish Sharma.
A database holds a firm’s records for the applications that read and write them. A managed cloud database is one where the provider handles tasks such as backups and software patching, and the firm keeps its application tuning and query performance (see the Amazon RDS user guide). Change sync means copying later changes to the target until the switch (see the AWS explainer on database migration). Also, this guide stays engine-neutral and names no prices, figures or dates. For why firms move at all, read the first article linked in the section on scope.
How to Migrate a Database to the Cloud: Ten Steps at a Glance
Each row shows the step, a lead and a pass test. The leads are our recommendation, so rename them to fit your firm.
| Step | Lead | Pass test |
|---|---|---|
| 1. Inventory | The database lead keeps the register. | Every database has an owner and a list of connected applications. |
| 2. Move type | The database lead picks one per database. | A move type sits beside every database. |
| 3. Managed target | The infrastructure manager chooses it. | Each database has a target, a size and confirmed features. |
| 4. Method | The database lead and the application owner agree it. | A method and a stop time are agreed per database. |
| 5. Network and access | The network owner builds it. | The target takes a test connection, and nobody shares a login. |
| 6. Rehearsal | The database lead runs it. | The rehearsal ran end to end, and the timings are written down. |
| 7. Cutover plan | The business sponsor owns it. | A one-page plan names who says go or no-go. |
| 8. Cutover window | The database lead runs it with the sponsor. | Applications write to the target, and the sponsor signed the go. |
| 9. Backups and alerts | The operations lead sets them. | A trial restore worked, and an alert reached a person. |
| 10. Retire old servers | The infrastructure manager closes them. | The register shows each old server retired and who signed. |
Before You Migrate a Database to the Cloud: Scope, Owners and Move Types
Decide first whether the plan covers one database or the whole estate. Then name a database lead, an application owner, a network owner and a business sponsor. A CIO signs the plan.
Decide whether the plan covers one database or the whole estate before step 1.
Meanwhile, for one database there are three move types: the same engine on a managed service, the same engine on a cloud virtual machine, or a change of engine. That is our sorting, not a standard count. The AWS explainer sorts moves by whether the engines match and by offline or online method, so other published models group them differently, and none is the standard.
If you are weighing the move, what running a database yourself asks of a team explains why firms leave.
How to Migrate a Database to the Cloud, Steps 1 to 5: Inventory, Move Type, Target, Method and Network
Steps 1 to 5 settle what moves, where it goes and how. Data stays put until step 5 is done. Overall, cloud database migration, in plain terms, is the whole sequence below.
How to Migrate a Database to the Cloud, Step 1: Inventory Every Database
To begin with, record each database in one register: name, owner, engine and version, size, features in use, connected applications and the jobs that call it. Applications and jobs are where surprises hide. List them with care.
Key Takeaway Applications and jobs are where surprises hide. The inventory lists them.
Done when every database has an owner and a list of connected applications.
Step 2: Pick the Move Type per Database
To begin with, rank the databases by risk and by the downtime the business accepts. Then pick a move type for each. A change of engine adds code and data conversion work, so it goes later in the order.
Done when one move type sits beside every database.
Step 3: Choose the Managed Target and Size It
Match the engine and version to what the provider lists as supported, since feature support varies by engine version and region. Then confirm the features the database uses exist on the target. Base the size on measured use rather than the old server’s specification. Keep a note of what your team still owns. Amazon RDS is one example of a managed service, and this guide does not compare services.
Confirm that the features the database uses exist on the target before you size it.
Done when each database has a target, a size and a list of confirmed features.
How to Migrate a Database to the Cloud, Step 4: Choose the Method, Offline Copy or Change Sync
An offline copy stops writes, copies the data and starts the target. It suits a database that can be down for the copy. Full load plus change sync copies everything, then applies later changes until the switch (see AWS DMS ongoing replication). It suits a database that must stay available during the transfer. The target can lag the source, so plan the stop point. Instead of the tool, the downtime limit from step 2 drives the choice. Overall, that limit is the core of any database migration strategy.
Done when a method and a stop time are agreed per database.
Step 5: Set Network and Access Before Data Moves
To begin with, build a private path between the old network and the cloud account. Then set firewall rules and routing. Also create identities and keys for the move itself, switch on encryption on the target, and limit access to the move team.
Done when the target accepts a test connection from the old network and from the application, and nobody shares a login.
Migrate a Database to the Cloud, Steps 6 to 10: Rehearsal, Cutover, Rollback and After the Move
Steps 6 to 10 test the move, switch over with a way back and close the old estate. This is how to migrate a database to the cloud with a rollback point agreed beforehand.
Step 6: Rehearse the Move on a Copy
Run the full method on a copy. Then time each stage, compare row counts and samples, and point a test copy of the application at the target. Pre-cutover scoring is set out in a pass or fail list to clear before the cutover date.
Done when the rehearsal ran end to end and the timings are written down.
How to Migrate a Database to the Cloud, Step 7: Set the Cutover Plan and the Rollback Point
To begin with, write the order of actions for the day and who does each one. Also mark the point after which the old database stops taking writes, and the point after which going back costs data. Keep the old database read-only and intact until the sponsor signs off.
Key Takeaway Keep the old database read-only until the sponsor signs off. A rollback then stays possible.
Done when a one-page plan names the person who says go or no-go.
Step 8: Run the Cutover Window
Pause writes and let change sync finish. Compare the two sides, then switch the connection strings and watch the first transactions. At the agreed time, the sponsor decides go or rollback.
stop writes and let change sync finish.
check the two sides.
change the connection strings and watch the first transactions.
Done when applications write to the target and the sponsor signed the go.
Step 9: Set Backups, Alerts and Right-Sizing After the Move
Set the backup schedule and retention on the target, and then run a trial restore. Set alerts on the signals your team will act on, such as seeing what a system is doing in plain terms. Finally, review the size after the first full business cycle.
Done when a trial restore worked and an alert reached a person.
How to Migrate a Database to the Cloud, Step 10: Retire the Old Servers
Keep the old database read-only for an agreed period. Then take a last backup and store it. Also remove access and network paths, close licenses and support contracts through procurement, and update the register. A data platform for analytics is a separate project.
Done when the register shows each old server retired and who signed.
Four Move Mistakes When You Migrate a Database to the Cloud
Four mistakes recur on database moves, but each is cheaper to catch early.
- Sizing the target from the old server. Measured use tells you more. Size in step 3.
- Picking the method before the downtime limit. The tool then drives the plan. Fix the limit in step 2.
- Skipping a timed rehearsal. The cutover window then has no basis. Time it in step 6.
- Switching the old database off on cutover day. A rollback is then impossible. Instead, hold it read-only through step 10.
What This Plan to Migrate a Database to the Cloud Leaves Out
However, this plan covers the order of work for one move. These subjects sit elsewhere:
- Scored checks and migration testing: a separate topic.
- Managed or self-managed choice: set out in how to weigh a provider run database against one your team runs.
- Running a database yourself: the article linked in the section on scope.
- SQL Server with Windows hosts: a separate topic. See the SQL Server version of this plan, with its Windows hosts.
- Engine conversion tools and syntax: not covered.
Application moves carry wider hazards, and wider risks to plan for when moving applications covers them. Bring in help if no one owns a database, when the downtime limit is unclear, or when nobody has run a cutover. How Signisys moves databases to managed services describes that work.
Signisys supports this through our solution for moving workloads to AWS and Azure and platform engineering support for the move. A consultation reads your databases and downtime limits next to the ten steps, with no result promised. No charge, with a fixed scope.
How to Migrate a Database to the Cloud: FAQ
Should every database move in one wave?
Who signs off the cutover?
How long should the old database stay available after the move?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.