Cloud Migration Plan: Assessment, Strategy and Cutover

Migrations fail less often because of technology than because of surprises: an undocumented dependency, a database that takes three times longer to copy than expected, or a DNS record nobody remembered. A good cloud migration plan exists to turn those surprises into known tasks before cutover weekend. This guide covers the three stages that matter most: assessment, strategy and cutover.

The approach applies whether you are moving from an on-premises data center, from colocation, or from one cloud provider to another.

Stage 1: Assessment #

Assessment answers two questions: what exactly are we moving, and how does it all connect? Skipping it is the single most common cause of failed or delayed migrations.

Build an inventory

List every server, database, storage share, scheduled job, certificate and external integration in scope. For each, record:

Owner (a person, not just a team).
Operating system and version, CPU, memory and disk, plus actual utilization.
Data volume and daily change rate, which drives how long replication takes.
Business criticality and acceptable downtime.
Licensing constraints, especially for Windows Server, SQL Server and Oracle.
Compliance requirements such as data residency.

Discovery tools help. AWS Application Discovery Service and AWS Migration Hub, Azure Migrate, and Google Cloud Migration Center can collect inventory and utilization data from existing environments. Spreadsheets work too for smaller estates, as long as they are kept current.

Map dependencies

Applications talk to databases, file shares, identity systems, license servers, SMTP relays and third-party APIs. Map these connections using network flow data, firewall rules, configuration files and interviews with owners. Pay particular attention to hard-coded IP addresses and hostnames, since those break silently after a move.

Group tightly coupled components into move groups that must migrate together. Splitting a chatty application from its database across a data center link can make it unusably slow during the transition.

Set success criteria

Agree in writing what “done” means: performance baselines to match, a maximum acceptable downtime, a target cost range, and security controls that must be in place. Capture current performance metrics now, because you cannot prove the new environment is as fast without a baseline.

Stage 2: Strategy #

Not every workload should move the same way. The widely used “7 Rs” framework, popularized by AWS, gives a vocabulary for deciding per application.

Strategy	What it means	Good fit when
Retire	Switch it off	Nobody uses it, or another system already covers it
Retain	Leave it where it is for now	Recently upgraded, hard constraints, or low value in moving
Rehost	Lift and shift the VM as is	Speed matters most, such as a data center exit deadline
Relocate	Move a virtualization platform wholesale	Running VMware and using a cloud VMware service
Replatform	Small changes for managed services	Moving a self-managed database to a managed one
Repurchase	Replace with SaaS	A commodity function such as email or CRM
Refactor	Re-architect for cloud-native services	The application needs major change for scale or agility anyway

A common and sensible pattern is to rehost or replatform first to meet a deadline, then refactor the most valuable systems once they are running in the cloud. Trying to refactor everything during the move multiplies risk.

Plan waves

Sequence move groups into waves. Start with low-risk, well-understood workloads to prove the process and tooling, then move toward critical systems. Each wave should end with a short retrospective so the runbook improves before the high-stakes moves.

Prepare the landing zone

Before the first workload moves, the target environment needs a foundation:

Account structure: separate accounts, subscriptions or projects for production and non-production.
Identity: SSO for staff, MFA, least-privilege roles and audit logging enabled.
Networking: VPC or VNet address ranges that do not overlap with on-premises networks, subnets, routing and firewall rules. Our guide to VPCs, subnets and load balancers covers the design basics.
Connectivity: site-to-site VPN or a dedicated interconnect to the source environment for replication traffic.
Observability: metrics, logs and alerts ready before workloads arrive, not after.
Cost controls: tagging standards and budget alerts.
Quotas: check service quotas for vCPUs, IP addresses and storage in the target region, and request increases through the provider’s official process well ahead of each wave.

Choose data migration methods

Data usually dictates the timeline. Options include:

Continuous server replication with tools such as AWS Application Migration Service or Azure Migrate, which keep a target copy in sync until cutover.
Database replication with native tools (for example PostgreSQL logical replication or SQL Server log shipping) or services such as AWS Database Migration Service and Google Cloud Database Migration Service.
Bulk file transfer over the network with tools such as rsync or provider transfer services, or offline transfer appliances for very large datasets.

Choosing the right target storage type matters as much as the copy method. Our explainer on object, block and file storage helps match each dataset to the right service.

Stage 3: Cutover #

Cutover is the moment traffic moves to the new environment. The goal is to make it boring: rehearsed, scripted and reversible.

Rehearse

Run at least one full rehearsal per critical move group using a copy of production data. Time every step. Rehearsals routinely reveal missing firewall rules, forgotten cron jobs and slow steps that would have blown the downtime window.

A sample cutover runbook

Several days before: lower DNS TTLs on affected records so changes propagate quickly. Confirm backups of the source environment are current.
Go or no-go meeting: confirm replication is in sync, rehearsal issues are resolved, and the rollback owner is available.
Freeze: put the application into maintenance mode or stop writes at the source.
Final sync: let replication catch up, then verify row counts, checksums or application-level checks.
Switch: update DNS, load balancer targets or connection strings.
Validate: run smoke tests and check key business transactions end to end.
Open traffic: lift maintenance mode and watch dashboards closely.
Decision point: at a pre-agreed time, confirm success or trigger rollback.

Always have a rollback plan

Define in advance what conditions trigger rollback, who decides, and how long rollback remains possible. Keep the source environment intact and read-only until the new environment has run cleanly for an agreed period. If writes occur in the new environment before rollback, you need a plan for reconciling that data.

After the move #

Migration is not finished at cutover. Plan for a stabilization period:

Compare performance against the baseline captured during assessment.
Right-size instances once real utilization data is available, since lift-and-shift sizing is often generous.
Confirm backups run and a restore works in the new environment.
Review the first full month’s bill against the estimate.
Decommission the source systems deliberately, including licenses, contracts and DNS records.

Monitoring is critical during this period. Our guide to infrastructure monitoring basics covers what to watch and alert on.

For provider-specific tooling and prescriptive guidance, see the AWS documentation, the Microsoft Azure documentation (including the Cloud Adoption Framework) and the Google Cloud documentation. Our AWS platform overview and Microsoft Azure overview summarize how each target platform is organized.

Frequently asked questions #

What should a cloud migration plan include?

At minimum: an inventory with owners, a dependency map, a strategy per application, a wave schedule, a prepared landing zone, data migration methods, a rehearsed cutover runbook and a rollback plan.

Is lift and shift a bad idea?

No. Rehosting is often the fastest, lowest-risk way to meet a deadline. The trade-off is that you may miss out on managed-service benefits until you optimize later, so plan a follow-up phase for right-sizing and modernization.

How much downtime does a migration require?

It depends on data volume, change rate and replication method. With continuous replication, many workloads can cut over in minutes to a few hours. Rehearsals give you a measured figure rather than a guess.

Why lower DNS TTLs before cutover?

Resolvers cache DNS records for the TTL period. Lowering it days in advance means that when you change the record, clients pick up the new address quickly, and a rollback also propagates quickly.

Planning a Cloud Migration: Assessment, Strategy and Cutover