Database Migration to the Cloud: A Step-by-Step Plan

A database migration to the cloud succeeds or fails on preparation, not on the transfer itself. The teams that finish on schedule map every dependency first, choose a strategy that fits the workload, rehearse with production-sized data, and build a tested way back before they switch traffic. This guide walks through each of those steps, with the checks we would want in place before any cutover.

Wvelabs

Build for what comes after migration

Wve Labs designs and builds custom software, cloud solutions, and ongoing product care for organizations developing digital products.

Explore Wve Labs

TL;DR

Treat migration as a lifecycle: assessment, preparation, data transfer, validation, then cutover. It is not a single event.
Pick one of three strategies, rehost, replatform or refactor, based on workload complexity and what you want from the cloud.
Run a full-scale test migration with real production volumes. Estimates built on small samples are unreliable.
Validate with row counts, hash-based sample comparisons and schema objects, not database size.
Build and test your rollback path before the primary migration starts. It is often harder than the migration.

Why migration is a lifecycle, not a weekend project
Phase 1: Assess what you are actually moving
Phase 2: Choose a migration strategy
Phase 3: Prepare the target environment
Phase 4: Transfer the data with minimal downtime
Phase 5: Test at production scale
Phase 6: Validate the data
Phase 7: Cut over and keep a way back
Our perspective
When you want a partner for the build around the database
Common mistakes to avoid
FAQ
Sources

Why migration is a lifecycle, not a weekend project

The most common misconception cloud architects describe is that migration is one event. Google's cloud architecture guidance describes a sequence: portfolio assessment, environment preparation, data transfer, validation, and only then the final cutover. Skipping the early phases, especially mapping the interdependencies between the database and everything that talks to it, is a leading reason timelines slip.

That has a practical consequence for how you plan. Budget the assessment and preparation phases as real work with owners and deliverables. If your project plan shows "migrate database" as a single line item, split it before you commit to a date.

Phase 1: Assess what you are actually moving

Before choosing a target, build an inventory. For each database, record:

Engine and version, including extensions, stored procedures, sequences and any vendor-specific features.
Size, growth rate and write volume. Write volume matters more than size for how you will replicate changes.
Consumers. Every application, report, ETL job, scheduled script and third-party integration that reads or writes.
Availability requirements. How much downtime the business can accept, and your Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Compliance constraints. If you handle regulated data in healthcare, insurance or financial services, note which controls your target environment must support before data moves.

The consumer list is where surprises hide. An undocumented nightly export or a reporting tool with a hard-coded connection string can break the day after cutover, even when the migration itself went cleanly.

Phase 2: Choose a migration strategy

AWS guidance frames the decision as rehost, replatform or refactor. In most database migrations any of the three can work. The guiding principle is how much benefit you want to get out of the move.

Strategy	What changes	Best when	Main trade-off
Rehost (lift and shift)	Same engine, moved to cloud infrastructure with minimal change	You need speed, or the workload is complex and risky to alter	Few cloud-native benefits, you keep much of the operational burden
Replatform	Same engine family, moved to a managed service with some optimization	You want less administration without rewriting the application	Some tuning and testing effort
Refactor	Different engine or re-architected data layer for cloud-native features	Licensing cost, scale or features justify the change	Highest effort, schema and code conversion, longer testing

The AWS guidance notes that heterogeneous migrations, where source and target engines differ, take more effort than homogeneous ones. The same material describes a Workload Qualification Framework: workloads in categories 1 and 2 are candidates for refactoring, while categories 4 and 5 are often better suited to rehost or replatform because of their complexity.

Homogeneous or heterogeneous

Moving PostgreSQL to a managed PostgreSQL service is homogeneous. Moving Oracle to PostgreSQL is heterogeneous. In the second case, AWS describes using DMS together with its Schema Conversion Tool to move a commercial database to an open-source one with minimal downtime. AWS also says AI-assisted schema conversion can reach up to 90% conversion rates in heterogeneous scenarios. Treat that as the best case: the remaining share of objects is where your engineers will spend their time, so inspect your own code (procedures, triggers, vendor functions) before you trust any percentage.

A decision shortcut

Hard deadline, such as a data center lease ending? Rehost first, optimize later.
Mostly standard SQL and a team that wants fewer patching and backup chores? Replatform to a managed service.
Paying heavy commercial licensing, or hitting a scaling ceiling? Evaluate refactor, but only with a conversion assessment in hand.

If the database sits behind a customer-facing web platform, remember that URL and endpoint changes can ripple outward. For site-level moves, a guide on mapping every URL before a site migration covers the search-visibility side that engineering plans often overlook.

Phase 3: Prepare the target environment

The database is useless if the application layer cannot reach it securely. Microsoft's guidance for migrating SQL Server to Azure SQL stresses that monitoring, alerting and security controls must be working on the target before cutover. Prepare:

Identity and access. Roles, service accounts, least-privilege permissions.
Network controls. Private connectivity, firewall rules, and routes from every consumer you inventoried.
Encryption. At rest and in transit, with key management decided in advance.
Observability. Dashboards and alerts for latency, connections, replication lag, storage and errors.
Backups and high availability. Configure them now and test them later.

A check that pays off: run the platform's pre-migration validation. Microsoft's PostgreSQL migration best practices recommend running it as the first step, because it surfaces unsupported extensions and permission gaps before they become mid-migration failures.

Phase 4: Transfer the data with minimal downtime

There are two broad patterns.

Offline (dump and restore). You stop writes, copy everything, and restart on the target. It is simple and predictable, and suits smaller databases or systems that can tolerate a maintenance window.

Online (snapshot plus change data capture). The service copies an initial full snapshot, then uses Change Data Capture (CDC) to replicate ongoing changes. AWS DMS and Google Database Migration Service work this way, which lets the source stay operational until the final cutover. Downtime shrinks to the moment you switch.

Offline and online database migration comparison

Online migrations have limits worth knowing. For Azure-style PostgreSQL flexible server tasks, Google's migration principles cite a maximum online task lifetime of 7 days, with a 72-hour cutover window after the initial copy completes. Check the equivalent limits for your chosen service and engine, because they shape how long you can run in parallel.

For very large datasets, network transfer can be too slow. Physical transfer appliances from the major cloud providers exist for that case, and you can combine a bulk load with CDC to catch up the delta.

Phase 5: Test at production scale

This is the step teams skip most often. AWS's database migration strategy guidance recommends a full-scale test migration using actual production data volumes. The reason is that duration depends on index counts, IOPS throughput and data bloat, none of which show up in a small sample.

A useful rehearsal produces:

A measured time-to-migrate you can put in the cutover plan.
Performance baselines on the target under realistic query load.
A list of failures and conversion gaps to fix.
A practiced runbook, with each step timed and assigned.

Run it more than once if the first run exposes problems. A rehearsal that surprises you is cheap. A cutover that surprises you is not.

Phase 6: Validate the data

Do not validate by comparing database size. Source databases often carry internal bloat and dead tuples that inflate the figure, and a freshly provisioned target will not have them. The Azure PostgreSQL guidance recommends validating with row counts, hash-based sample comparisons of documents, and checks of key schema objects such as sequences, extensions and procedures.

A practical validation checklist:

Row counts per table match after the final sync.
Checksums or hashes of sampled rows match between source and target.
Sequences and identity columns continue from the right values.
Stored procedures, views and triggers exist and return the same results on test inputs.
Application functional tests pass against the target.

Test the non-functional requirements too

Correct data is not enough. AWS's reliability guidance for migrations advises resilience testing, such as simulating failure of high-availability components, to confirm the new database actually meets your RTO and RPO. If you have never failed over the new database deliberately, you do not yet know whether it will.

Phase 7: Cut over and keep a way back

Cutover is the shortest phase and the one with the least room for improvisation. AWS's cutover guidance includes freezing ingestion on the source so it receives no new transactions, and taking a final backup. It also covers what to do if the new environment has already received transactions before you decide to go back.

A workable sequence:

Announce the window and schedule it for a low-traffic period.
Freeze writes on the source.
Let replication drain until lag reaches zero.
Run the validation checklist.
Switch application connections to the target.
Run smoke tests and watch dashboards closely.
Hold the source in read-only state until your agreed observation period passes, then decommission.

Define rollback triggers in advance

Decide before the night what counts as failure: error rate above a set threshold, latency beyond an agreed limit, a failed validation check. Writing triggers down removes debate at 2 a.m.

Then be honest about the rollback itself. Google's guidance points out that building a fallback from target back to source is often more complex than the original migration. If you cannot afford the downtime of a manual restore, build and test reverse replication before the primary migration begins.

Our perspective

We build mobile apps, web platforms and AI-enabled products, so we usually meet database migration from the application side. A team has a product that works, a database that is holding it back, and a worry that touching the data layer will break something customers can see. That worry is reasonable, and it is best answered by treating the database and the application as one system.

Three things we emphasize in our own work:

Start from the consumers, not the engine. The mobile clients, APIs and background jobs that depend on the database decide how much change is safe. Older app versions stay in users' hands for months, so schema and endpoint changes need to stay compatible with them.
Pair the migration with the product roadmap. If you are already modernizing a system or planning new AI features such as recommendations or LLM integration, the target architecture should anticipate them. Moving twice is more expensive than designing once.
Plan for life after cutover. Monitoring, performance tuning and release care continue after the data lands. Teams that stay close to the product after launch tend to catch regressions faster, and that is why we favor long-term working relationships over hand-offs.

If you prototyped on an AI app builder and now need a production-grade backend, the same logic applies: define the data model and migration path deliberately before real users and real data arrive.

— Brian

When you want a partner for the build around the database

A migration rarely stands alone. It usually comes with API and backend changes, cloud architecture, CI/CD pipelines and updates to the apps that sit on top. Wve Labs covers cloud architecture, backend development, DevOps, system modernization and mobile and web engineering under one team, and after launch our app and website maintenance service covers ongoing monitoring and updates. If you want to see the technologies we work with, our technology stack page lists them.

Common mistakes to avoid

Estimating instead of measuring. Always time a production-scale rehearsal.
Ignoring undocumented consumers. Scan connection logs for clients that are not in your inventory.
Validating by size. Use counts, hashes and schema checks.
Skipping the rollback build. A written plan is not a tested pipeline.
Going live without observability. If you cannot see latency and errors, you cannot call the migration healthy.
Decommissioning too early. Keep the source until the observation period ends.

FAQ

How do I migrate a database to the cloud with minimal downtime?

Use an online migration: take an initial snapshot, then replicate changes continuously with change data capture while the source stays live. Services such as AWS DMS and Google Database Migration Service support this approach. Downtime is then limited to the final switch, after you freeze writes and let replication catch up.

Which migration strategy should I choose?

Rehost is fastest and lowest risk, replatform trades modest effort for managed-service benefits, and refactor delivers the most change at the highest cost. Heterogeneous moves take more effort than homogeneous ones. Run a workload assessment first and let complexity, deadlines and long-term goals decide.

How long does a database migration take?

It depends on data volume, index counts, throughput and the strategy you chose, which is why estimates are unreliable. A rehearsal with production-sized data gives you a real figure. Plan the assessment and preparation phases as well, since they often take longer than the transfer.

How do I know the migration worked?

Compare row counts, hash samples of records and key schema objects between source and target, and run your application's functional tests. Do not rely on database size. Then test failover to confirm your RTO and RPO targets are met.