Cloud migration planning

How to plan and execute a cloud migration

Migrating your IT infrastructure, data, and applications to the cloud is best treated as a structured business and technology transformation—not simply moving servers from a data center to a cloud provider.

A successful migration balances business continuity, security, cost, performance, and modernization. The key is to understand your current environment, choose the right migration strategy for each workload, move in controlled phases, and validate results before retiring legacy systems.

The cloud migration lifecycle

Detailed steps and deliverables

1. Assess your current IT environment

Start by establishing exactly what you have today and what the business expects from the migration.

• Infrastructure: Servers, virtual machines, storage, networks, firewalls, and data centers.
• Applications: Business-critical systems, legacy applications, integrations, licensing, and third-party dependencies.
• Data: Databases, file shares, data volumes, sensitivity, retention requirements, and data quality.
• Business requirements: Availability, performance, recovery time, recovery point, and acceptable downtime.
• Financial baseline: Current infrastructure costs, licensing, staffing, maintenance, and data center expenses.

Deliverable: A complete asset inventory, dependency map, risk register, and initial cloud cost and readiness assessment. Discovery and dependency mapping are essential inputs to migration planning.docs.cloud.google.com+1

2. Define the cloud strategy and target architecture

Determine what you want to achieve and select an appropriate destination.

Key decisions include:

• Cloud model: Public, private, hybrid, or multicloud.
• Provider: Compare services from AWS, Microsoft Azure, Google Cloud, or other providers against your requirements.
• Architecture: Design networking, compute, storage, databases, identity, and application hosting.
• Business priorities: Decide whether the main objective is cost reduction, scalability, resilience, faster delivery, or modernization.
• Compliance: Address data residency, privacy, regulatory requirements, and auditability.
• Economics: Estimate total cost of ownership, migration costs, ongoing cloud consumption, and expected return on investment.

Deliverable: An approved cloud strategy, target architecture, business case, and migration roadmap.

3. Select a migration approach for each application

Not every workload should be moved in the same way. Use the appropriate migration strategy for each system.

These approaches are commonly known as the 7 Rs of cloud migration.docs.aws.amazon.com+1

Deliverable: A workload-by-workload migration strategy, including cost estimates, dependencies, complexity, owners, and priorities.

4. Build a secure cloud foundation

Before moving production systems, establish a standardized cloud environment, often called a landing zone.

Include:

• Identity and access management, multifactor authentication, and least-privilege access.
• Network segmentation, private connectivity, DNS, firewalls, and routing.
• Encryption for data at rest and in transit, plus secure key management.
• Centralized logging, monitoring, alerting, and audit trails.
• Governance policies, tagging, resource ownership, and spending limits.
• Infrastructure as code and automated deployment pipelines.
• Backup, disaster recovery, incident response, and security monitoring.

Deliverable: A tested, governed, secure cloud foundation ready to host workloads. Cloud adoption frameworks emphasize building this foundation before scaling migrations.learn.microsoft.com+1

5. Plan data migration and application dependencies

This phase deserves particular attention because moving data and interconnected applications introduces risks that a simple server migration may not address.

For data migration:

• Select the transfer method based on data volume, sensitivity, bandwidth, and downtime tolerance.
• Choose between offline transfer, bulk transfer, replication, and database-specific migration tools.
• Establish encryption, access controls, data mapping, and transformation rules.
• Define how you will validate record counts, checksums, consistency, and completeness.
• Plan synchronization of changes made during the migration.

For application migration:

• Map dependencies among applications, databases, authentication services, and external systems.
• Identify incompatible operating systems, runtimes, database versions, and licensing.
• Document configuration changes, integration endpoints, and secrets management.
• Define cutover windows, rollback procedures, and business communication plans.

Deliverable: A detailed migration runbook covering data transfer, sequencing, validation, downtime, and rollback.github.com+1

6. Execute migration in controlled waves

Avoid moving the entire environment at once unless there is a compelling, carefully validated reason.

• 

Wave 1 — Pilot

Move a low-risk application or development environment. Test tooling, networking, security, deployment, and operational procedures.

---

• 

Wave 2 — Initial production workloads

Migrate relatively independent, well-understood systems. Refine estimates and resolve issues before increasing volume.

---

• 

Wave 3 — Complex and business-critical workloads

Migrate tightly coupled applications, large databases, and critical services with additional testing, approvals, and recovery safeguards.

For each wave, use a consistent sequence:

1. Prepare and configure the destination.
2. Replicate or transfer data.
3. Test the workload in the cloud.
4. Approve the production cutover.
5. Switch traffic or users to the cloud environment.
6. Monitor closely and execute rollback if acceptance criteria are not met.

Deliverable: Migrated workloads with documented cutover outcomes, approvals, and operational ownership.

7. Validate, stabilize, and optimize

Migration is not complete merely because an application starts successfully.

Validate the following:

Resolve defects and stabilize production workloads before declaring a migration wave complete. Then optimize compute sizing, storage tiers, database services, autoscaling, and reserved or committed-use pricing where appropriate.

Deliverable: Signed-off test results, stable workloads, and an optimization backlog.

8. Decommission legacy systems and establish cloud operations

Once the migrated workloads are stable and the business has formally accepted them:

• Retire old servers, storage, network connections, and unused software licenses.
• Verify that backups, retention requirements, legal holds, and archival obligations are satisfied.
• Remove obsolete accounts, credentials, firewall rules, and access permissions.
• Update asset inventories, architecture diagrams, and disaster recovery documentation.
• Establish ongoing cloud cost management, patching, capacity planning, security reviews, and service ownership.

Keep the source environment available until the agreed acceptance and rollback conditions have been met. Do not decommission the original systems prematurely.

Deliverable: An updated IT estate, reduced legacy operating costs, and an ongoing cloud management model.github.com+1

---

Project governance: how to keep the migration on track

Assign clear ownership across the major workstreams.

Track progress with measurable KPIs, such as:

• Percentage of workloads migrated and formally accepted.
• Number of critical defects and unresolved security findings.
• Application availability and performance against baseline.
• Data reconciliation failures.
• Actual versus planned migration costs and downtime.
• Cloud operating costs versus the approved budget.
• Legacy infrastructure successfully retired.

Suggested high-level timeline

The actual duration depends on the size and complexity of your environment. For an illustrative medium-sized project, planning might look like this:

Illustrative only. Workstreams overlap, and complex enterprise migrations can take many months or longer.

Recommended next step

Start with a cloud migration assessment and discovery phase before committing to a detailed schedule or budget. This provides the evidence needed to determine scope, migration order, technical risks, and realistic costs.

For practical implementation guidance, consult these official resources:

• AWS Prescriptive Guidance —Assess, mobilize, and migrate
• Microsoft Cloud Adoption Framework —Plan, prepare, migrate, govern, and manage
• Google Cloud Migration Center —Discovery, assessment, and migration planning

The most important principle: migrate in business-aligned waves, establish security and governance early, validate every workload before acceptance, and measure success by business outcomes—not simply by the number of servers moved.

Cloud migration roadmap: From planning to full adoption

Moving your IT infrastructure, data, and applications to the cloud is best managed as a phased transformation program—not simply a project to move servers. A successful roadmap combines business planning, technical preparation, security, controlled migration, and ongoing optimization.

A practical approach is to use six phases: assess, strategize, prepare, pilot, migrate, and optimize. This aligns with major cloud-provider guidance, which emphasizes readiness assessment, building a secure cloud foundation, migrating in waves, and modernizing workloads over time.docs.aws.amazon.com+2

The six phases at a glance

1. Assess your current environment

   Inventory assets, dependencies, risks, and business needs.

2. Define your cloud strategy and business case

   Choose the target architecture, migration approach, budget, and success measures.

3. Build the cloud foundation

   Establish networking, identity, security, governance, and operational processes.

4. Run a pilot migration

   Test the approach on a small number of representative workloads.

5. Migrate infrastructure, data, and applications

   Execute prioritized migration waves with validation and rollback plans.

6. Optimize, modernize, and decommission

   Control costs, improve reliability, modernize services, and retire legacy systems.

Phase 1 — Assess your current IT environment

• 

Goal: Understand what you have, what it supports, and what it will take to move it.

Key activities:

• Inventory servers, virtual machines, storage, networks, databases, applications, licenses, and integrations.
• Map dependencies between applications, databases, identity services, and external systems.
• Review performance, capacity, availability, security, compliance, and disaster recovery requirements.
• Identify technical debt, unsupported software, and applications that may not be suitable for cloud migration.
• Establish current infrastructure and operating costs.

Deliverables: Current-state architecture, application and data inventory, dependency map, risk register, cloud-readiness assessment, and initial cost baseline.

Exit criterion: You know what needs to move, its business importance, and the major risks and constraints.docs.aws.amazon.com+1

Phase 2 — Define the cloud strategy and business case

Goal: Decide what to migrate, where to migrate it, and why.

Key activities:

• Choose a cloud model: public, private, hybrid, or multicloud.
• Evaluate providers such as Amazon Web Services, Microsoft Azure, and Google Cloud.
• Define target architectures for infrastructure, data platforms, applications, and connectivity.
• Estimate total cost of ownership (TCO), including migration labor, cloud consumption, licenses, network traffic, support, backup, and security.
• Prioritize workloads based on business value, technical complexity, dependencies, and risk.
• Define measurable success criteria, funding, owners, and decision-making authority.

For each application, select an appropriate migration strategy:

These are commonly known as the migration “6 Rs,” although terminology varies by provider.docs.aws.amazon.com+2

Deliverables: Approved cloud strategy, business case, target-state architecture, prioritized workload portfolio, budget, and high-level migration roadmap.

Phase 3 — Build the cloud foundation

Goal: Make the destination secure, reliable, and operationally ready before moving critical production systems.

• 

Key activities:

• Establish a cloud landing zone with account or subscription structure and resource organization.
• Configure network connectivity, routing, DNS, firewalls, and segmentation.
• Implement identity and access management, multifactor authentication, least privilege, and secrets management.
• Establish encryption, logging, monitoring, alerting, vulnerability management, and security policies.
• Configure infrastructure-as-code, automated deployment pipelines, backup, disaster recovery, and recovery testing.
• Define support processes, incident response, cost allocation, tagging, and cloud operating responsibilities.
• Train teams and close skills gaps.

Deliverables: Production-ready landing zone, security and governance controls, operational runbooks, connectivity, monitoring, and tested recovery procedures.

Exit criterion: The cloud environment can support the first production workloads with the required security and operational controls. Microsoft and Google both emphasize foundational architecture, identity, networking, security, and governance as essential parts of cloud readiness.learn.microsoft.com+1

Phase 4 — Run a pilot migration

Goal: Validate your methods before scaling up.

Choose a small set of representative workloads, ideally including a relatively simple application and its associated database or data flow. Avoid starting with the most business-critical system.

Key activities:

1. Document the migration procedure, owners, dependencies, and maintenance window.
2. Move the selected infrastructure, data, and application components.
3. Test functionality, performance, integrations, security, backup, and recovery.
4. Measure actual migration effort, downtime, and cloud operating costs against estimates.
5. Test cutover and rollback procedures.
6. Document lessons learned and improve the migration playbook.

Deliverables: Validated migration patterns, tested cutover and rollback plans, updated cost estimates, and an improved migration runbook.

Exit criterion: The pilot works in production or a representative production-like environment, meets agreed service levels, and can be supported by your operations team.docs.aws.amazon.com+3

Phase 5 — Migrate infrastructure, data, and applications in waves

Goal: Execute the migration in manageable groups, with business continuity and data integrity as priorities.

Organize workloads into migration waves based on dependencies, complexity, risk, and business priorities. Start with low-risk workloads, then progress toward more complex and critical systems.

Example migration-wave sequence

Wave 1 — Low-risk workloads

Development and test environments, standalone applications, and noncritical file services.

---

Wave 2 — Shared platforms and data

Databases, shared storage, reporting services, and applications with manageable dependencies.

---

Wave 3 — Integrated business applications

Enterprise applications, interconnected systems, and applications with more complex data flows.

---

Wave 4 — Critical systems and final cutovers

High-availability applications, remaining critical databases, and systems requiring carefully coordinated transitions.

For every wave, follow a repeatable execution process:

• Prepare: Confirm dependencies, capacity, access, migration tooling, backups, and stakeholder approvals.
• Replicate or transfer: Move servers, storage, databases, and files using an appropriate migration method.
• Validate: Reconcile data, test application behavior, verify integrations, and check security and performance.
• Cut over: Coordinate DNS, routing, connection strings, identity, and traffic changes.
• Stabilize: Monitor errors, latency, resource utilization, and business transactions.
• Roll back if necessary: Execute predefined recovery steps if critical acceptance criteria fail.

For data migrations, decide in advance whether you can tolerate downtime or need ongoing replication and a controlled final synchronization. Establish data ownership, retention, residency, encryption, and reconciliation requirements before transferring sensitive datasets.

Deliverables: Migrated and accepted workloads, test evidence, updated asset records, cutover reports, and documented exceptions.

Google's migration guidance specifically recommends dependency-aware waves, detailed execution plans, post-migration testing, and workload-specific rollback procedures.docs.cloud.google.com+1

Phase 6 — Optimize, modernize, and decommission

Goal: Turn a successful migration into a sustainable cloud operating model.

Key activities:

• Right-size compute, storage, and database resources using actual utilization.
• Review cloud bills, budgets, idle resources, licensing, and data-transfer charges.
• Improve performance, resilience, autoscaling, observability, and disaster recovery.
• Modernize selected workloads using managed databases, containers, serverless services, or SaaS where justified.
• Review access permissions, vulnerabilities, compliance, and recovery readiness continuously.
• Decommission legacy servers, storage, network circuits, and licenses only after formal acceptance and retention checks.
• Update documentation, asset inventories, support procedures, and ownership records.

Deliverables: Optimized cloud estate, documented operating model, verified legacy-system retirement, and continuous improvement backlog.

Exit criterion: Applications meet agreed service levels, the cloud environment is supportable and secure, costs are controlled, and retired infrastructure no longer creates unnecessary expense or risk.docs.aws.amazon.com+3

---

How long should the roadmap take?

The following is an illustrative planning baseline, not a provider commitment. Actual duration depends on workload count, complexity, compliance, data volume, and available staff.

Phases overlap deliberately. A small migration may take weeks to a few months; a large enterprise migration can take a year or longer.

Governance: Workstreams to run throughout the program

Don't treat security, costs, or operations as final-stage tasks. Assign clear owners and track these workstreams from the beginning.

Useful program-level KPIs include migration completion rate, critical defects, service availability, data reconciliation results, downtime per cutover, cost variance, security findings, and the number of legacy systems successfully retired.

Recommended next step

Start with a discovery and assessment engagement, then produce a prioritized application portfolio and a migration-wave plan before committing to a detailed delivery schedule.

To tailor this roadmap to your organization, the most useful starting point is understanding your current environment.

Build a tailored migration plan

Share a few basics to turn the roadmap into a sequenced plan with milestones, workstreams, and deliverables. You can leave any selection as-is.

1. Organization size

Small — fewer than 250 employees

Mid-sized — 250–2,000 employees

Enterprise — more than 2,000 employees

---

2. Current environment

On-premises data center

Hybrid on-premises and cloud

Moving from one cloud provider to another

---

3. Target environment

Single public cloud

Hybrid cloud

Multicloud

Not decided yet

---

4. Primary business objective

Reduce costs or exit a data center

Improve scalability and agility

Improve security, resilience, or compliance

Modernize applications and data platforms

---

5. Migration scope

Infrastructure only

Infrastructure and applications

Infrastructure, applications, and databases

Entire IT estate, including end-user services

[Generate tailored roadmap]

Further reading

• AWS — Phases of a large migration
• Microsoft — Plan your migration
• Google Cloud — Migration planning
• Google Cloud — Execute your migration

Cloud migration roadmap: from planning to production

A successful cloud migration is best treated as a business transformation program, not simply a move of servers from one environment to another. Your roadmap should cover application discovery, business priorities, security, cloud architecture, migration execution, and post-migration optimization.

A practical approach is to organize the project into six phases, with clear deliverables and approval gates at each stage. This aligns with the migration frameworks published by AWS, Microsoft Azure, and Google Cloud.docs.aws.amazon.com+2

1. The roadmap at a glance

Phase 1 — Assess and define the strategy

Weeks 1–3 · Establish the business case

Inventory applications, infrastructure, data, dependencies, compliance requirements, and migration goals.

Deliverable: Approved scope, business case, and baseline assessment.

---

Phase 2 — Design and prepare the cloud foundation

Weeks 3–7 · Build the landing zone

Design networking, identity, security, governance, logging, backup, disaster recovery, and cost controls.

Deliverable: Secure, tested cloud environment ready for workloads.

---

Phase 3 — Plan workloads and migration waves

Weeks 5–8 · Sequence the move

Select a migration method for each application, map dependencies, assign owners, and define cutover and rollback plans.

Deliverable: Prioritized migration backlog and approved wave plan.

---

Phase 4 — Run a pilot migration

Weeks 8–10 · Validate the approach

Move a small, lower-risk workload. Test performance, security, integrations, backup restoration, monitoring, and recovery.

Deliverable: Validated runbook and go/no-go decision.

---

Phase 5 — Execute production migrations

Weeks 10 onward · Migrate in controlled waves

Move applications and data in dependency-aware batches, validate each wave, and use approved cutover and rollback procedures.

Deliverable: Production workloads operating in the cloud.

---

Phase 6 — Stabilize, optimize, and decommission

After each migration wave

Tune performance and costs, transfer operational ownership, verify resilience, and retire source infrastructure when safe.

Deliverable: Accepted service, measured benefits, and approved retirement.

Illustrative timeline for an initial migration program, not a fixed schedule. Phases can overlap, and total duration depends on workload count, complexity, regulatory needs, and downtime constraints.cloud.google.com+2

2. Essential activities in each phase

Phase 1: Assess the current environment

Before selecting cloud services or setting dates, establish what you have and why you are moving.

• Define business outcomes: cost reduction, data-center exit, scalability, resilience, faster releases, or modernization.
• Build a complete inventory: applications, virtual machines, databases, storage, integrations, network connections, licenses, and owners.
• Map dependencies: determine which applications, databases, authentication services, and external systems must move together.
• Assess readiness: identify legacy systems, unsupported software, skills gaps, technical debt, and compliance constraints.
• Build the financial case: estimate migration costs, ongoing cloud spend, dual-running costs, licensing changes, and potential savings.

Choose measurable success criteria early—for example, availability targets, acceptable downtime, performance thresholds, migration completion dates, and cost variance.

Reference: AWS migration strategy and readiness guidance.docs.aws.amazon.com+1

Phase 2: Build the cloud foundation

Create a standardized, secure environment before moving business-critical applications.

Exit gate: The platform team and security stakeholders approve the foundation, and recovery and operational procedures have been tested.

Reference: AWS migration mobilization guidance.docs.aws.amazon.com+2

Phase 3: Choose a migration strategy for each workload

Not every application should be migrated in the same way. Classify workloads individually.

For each application, record its chosen strategy, dependencies, business criticality, data migration approach, estimated effort, target architecture, testing requirements, and rollback plan.docs.aws.amazon.com+5

Phase 4: Pilot and prove the process

Choose a representative, relatively low-risk workload that still tests the migration process meaningfully.

Validate:

• Application functionality and integration with dependent services.
• Data completeness, consistency, and integrity.
• Performance against agreed baselines.
• Security controls and compliance requirements.
• Backup restoration and disaster recovery.
• Monitoring, alerting, support escalation, and cost visibility.
• Cutover duration, business communications, and rollback procedures.

Document what worked, what failed, how long each activity took, and what must change before scaling up.

Exit gate: Business, technical, security, and operations owners agree that the pilot meets acceptance criteria.cloud.google.com+3

Phase 5: Migrate production in waves

Organize workloads into batches based on dependency, risk, complexity, and business impact—not just the number of servers.

A typical sequence is:

1. Development, test, and other non-production workloads.
2. Independent, lower-risk production applications.
3. Applications with shared databases or interconnected services.
4. Business-critical systems with stringent availability requirements.
5. Remaining complex workloads requiring modernization or special treatment.

For every wave, complete a readiness review, confirm data synchronization, freeze changes where needed, validate backups, execute the cutover, run smoke and business acceptance tests, and monitor the workload closely.

Define rollback triggers and decision authority before cutover. Keep the source environment available until the new service is accepted and the agreed rollback window has passed.

Reference: Microsoft guidance on sequencing, data migration, and rollback.docs.aws.amazon.com+2

Phase 6: Optimize and hand over

Migration is not complete just because the application starts successfully in the cloud.

• Compare actual costs against the business case and forecast.
• Right-size compute, storage, and database capacity.
• Review performance, availability, and security telemetry.
• Tune autoscaling and resource scheduling where appropriate.
• Validate backup retention, recovery objectives, and operational ownership.
• Update architecture diagrams, asset inventories, runbooks, and support documentation.
• Decommission legacy systems only after data retention, dependencies, audit, and business sign-offs are complete.

Track benefits over time; defer major modernization work when combining it with migration would add unacceptable risk, but identify worthwhile improvements explicitly.cloud.google.com+1

3. Project governance and team structure

Establish clear accountability from the start. A migration program often stalls not because of technology, but because application ownership, security decisions, dependencies, and business approvals are unclear.

Run a weekly program review, maintain a shared risk and dependency register, and require explicit approval at each major gate. For larger programs, use dedicated workstreams with a single integrated plan.docs.aws.amazon.com+1

4. Track progress with measurable KPIs

Agree on a small set of metrics before migration starts, then report them consistently.

Schedule and delivery

Percentage of workloads migrated versus planned, milestone adherence, and migration throughput per wave.

---

Reliability and security

Service availability, failed migrations, critical security findings, recovery test results, and rollback frequency.

---

Cost and business value

Actual versus forecast spend, total cost of ownership, cost per workload, and realized savings against baseline.

---

Quality and readiness

Acceptance-test pass rate, data validation results, workload-owner sign-offs, and operational handover completion.

Set target values based on your business requirements and existing service baselines rather than adopting arbitrary industry-wide targets.

5. A practical kickoff checklist

Migration readiness tracker

/

[Copy checklist] [Reset]

6. Recommended next step

Turn this roadmap into a project plan tailored to your actual environment. The three most important inputs are your cloud destination, migration scope, and deadline.

Customize your migration roadmap

Choose what you know so far; you can refine the details later.

Target cloud

Amazon Web Services (AWS)

Microsoft Azure

Google Cloud

Multi-cloud

Not decided yet

---

Current environment

On-premises / data center

Another public cloud

Hybrid environment

---

Migration scope

Under 20 applications

20–100 applications

100+ applications

Entire data center / complex estate

---

Target timeline

Under 3 months

3–6 months

6–12 months

12+ months / flexible

---

Primary business priority

Speed / fixed exit deadline

Cost reduction

Modernization

Security, compliance, and resilience

Balanced approach

[Build my detailed roadmap]