Cloud Migration Checklist: What to Plan Before Moving to AWS, Azure or GCP

Cloud migration is rarely difficult because of the act of moving a server or database. The real difficulty is knowing what should move, how it should move, what it depends on, what it will cost afterward, and what happens if something goes wrong.

A successful migration therefore starts well before the first workload is transferred.

Whether you are moving from an on-premises data center, another cloud provider, or a hybrid environment, the planning process is broadly the same. You need a clear inventory of your environment, an understanding of application dependencies, a target architecture, a migration strategy, security controls, cost estimates, and a tested rollback plan.

AWS, Azure, and Google Cloud all provide their own migration frameworks and assessment tools, but the underlying planning principles are similar. AWS emphasizes readiness assessment and the 7 migration strategies, Azure’s Cloud Adoption Framework separates strategy, planning, readiness, and adoption, while Google Cloud Migration Center supports discovery, assessment, planning, and migration activities.

Here is the checklist to work through before moving your first production workload.

Cloud Migration Checklist at a Glance

Area	What to Confirm Before Migration
Business objectives	Why are you migrating and what outcome defines success?
Application inventory	Do you know what applications, servers, databases, and services you have?
Dependencies	Do you know which systems communicate with each other?
Workload assessment	Which workloads should move first, later, be modernized, or retired?
Cloud selection	Why AWS, Azure, or GCP for the workload?
Migration strategy	Rehost, replatform, refactor, relocate, repurchase, retain, or retire?
Target architecture	What will the environment look like after migration?
Networking	How will users, applications, offices, and existing systems connect?
Security	Are identity, access, encryption, logging, and security controls defined?
Data	How will data be transferred, validated, protected, and synchronized?
Cost	What will the new environment actually cost?
Operations	Who will monitor, manage, patch, back up, and support it?
Testing	Have performance, security, functionality, and failover been tested?
Cutover	Is there a detailed migration and rollback plan?
Post-migration	How will you optimize and validate the environment afterward?

1. Define Why You Are Migrating

Do not start with “We want to move to AWS” or “We are moving everything to Azure.”

Start with the business reason.

Common objectives include:

• Reducing data-center costs
• Exiting an aging data center
• Improving application availability
• Increasing scalability
• Supporting business expansion
• Modernizing legacy applications
• Improving disaster recovery
• Reducing infrastructure management
• Preparing for analytics or AI workloads
• Consolidating multiple environments

The reason matters because it affects almost every later decision.

If the objective is simply to exit a data center quickly, rehosting may make sense for some workloads.

If the objective is to reduce long-term operational costs, simply copying existing virtual machines into the cloud may not be enough.

If the objective is application modernization, you may need to redesign databases, application architecture, deployment processes, or infrastructure.

Write down the expected business outcomes before designing the technical migration.

For example:

“Move 80% of infrastructure out of the data center within 12 months while maintaining application availability and reducing infrastructure operating costs.”

That is much more useful than:

“Move everything to the cloud.”

2. Build a Complete Inventory of Your Current Environment

You cannot migrate what you cannot see.

Create an inventory of your current infrastructure before deciding how anything should be moved.

At minimum, document:

• Physical servers
• Virtual machines
• Operating systems
• Databases
• Storage
• Applications
• Network devices
• Load balancers
• Firewalls
• DNS
• IP addresses
• Backup systems
• Monitoring systems
• Scheduled jobs
• Third-party integrations
• External APIs
• Development and test environments

For each workload, capture basic information such as:

Information	Example
Application	Customer portal
Server	4 vCPU / 16 GB RAM
OS	Ubuntu
Database	PostgreSQL
Storage	800 GB
Average CPU	35%
Peak CPU	78%
Users	5,000/day
Availability requirement	99.9%
Business criticality	High
Dependencies	API, database, payment gateway
Current cost	₹X/month
Target cloud	AWS
Migration approach	Replatform

This inventory becomes the foundation for architecture, cost estimation, migration sequencing, and risk assessment.

3. Map Application Dependencies

One of the most common migration mistakes is treating applications as isolated servers.

They are not.

A typical business application may depend on:

Application → Web Server → API → Database → Storage → Authentication → External API

There may also be dependencies on:

• DNS
• Active Directory
• SMTP
• File shares
• Payment gateways
• ERP systems
• Monitoring
• Backup systems
• On-premises databases
• Third-party SaaS applications

Moving one component without understanding these relationships can break the application even when the migrated server itself is functioning correctly.

Create a dependency map for critical workloads.

Before migration, you should be able to answer:

• What does this application depend on?
• What depends on this application?
• Where does its data reside?
• Which systems must remain on-premises?
• Does it require low-latency connectivity?
• Does it communicate across regions?
• Does it send or receive sensitive data?

Microsoft’s Azure migration guidance similarly emphasizes gaining visibility into workload components, dependencies, architecture, performance, security, code, and databases before migration.

4. Classify Every Workload

Not every workload should receive the same migration treatment.

A useful classification is:

Workload Type	Typical Action
Stable legacy application	Rehost or replatform
Business-critical application	Migrate carefully with extensive testing
Outdated application	Consider modernization
Low-value application	Retire if no longer required
SaaS-replaceable application	Repurchase
Highly customized application	Assess for refactoring
Temporary workload	Consider whether migration is worthwhile
Data-intensive workload	Analyze storage and network requirements carefully

This is where the familiar “7 Rs” migration framework becomes useful: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor/Re-architect. AWS documents these as the seven migration strategies for workloads moving to AWS.

The important point is that “move” is not a strategy by itself.

For each workload, decide what you are actually trying to achieve.

5. Decide Whether AWS, Azure or GCP Is the Right Target

Cloud selection should happen at the workload and business level, not simply because one provider is popular.

Consider:

• Existing technology investments
• Application compatibility
• Database requirements
• Geographic availability
• Compliance requirements
• Existing cloud skills
• Licensing
• Networking
• Security tooling
• Managed services
• AI and analytics requirements
• Expected workload growth
• Pricing model
• Long-term operational requirements

For example, an organization heavily invested in Microsoft technologies may find Azure operationally attractive, while an analytics-heavy environment may place greater emphasis on Google Cloud’s data and AI capabilities.

The decision should ultimately be based on workload requirements rather than brand preference.

6. Design the Target Cloud Architecture Before Migration

Do not migrate first and design later.

Define the target environment before moving production workloads.

At a minimum, document:

• Cloud accounts/subscriptions/projects
• Regions
• Virtual networks
• Subnets
• Routing
• Firewalls
• Identity and access
• Compute
• Databases
• Storage
• Load balancing
• DNS
• Monitoring
• Backup
• Disaster recovery
• Logging
• Security controls

You should also decide how environments will be separated.

For example:

Organization

│

├── Production

│   ├── Network

│   ├── Compute

│   ├── Database

│   └── Security

│

├── Staging

│

├── Development

│

└── Shared Services

    ├── Monitoring

    ├── Logging

    └── Identity

AWS, Azure, and Google Cloud use different organizational models and terminology, so the exact implementation will vary. The architectural principle remains the same: establish a controlled foundation before workloads arrive.

Microsoft’s Cloud Adoption Framework, for example, places a “Ready” stage before migration so that the cloud environment and landing zone are prepared for workloads.

7. Plan Networking and Connectivity

Networking is one of the areas most likely to create migration problems.

Determine how the cloud environment will communicate with:

• Existing data centers
• Branch offices
• Remote employees
• Customers
• Third-party services
• Other cloud environments
• Internet-facing applications

Decide whether you need:

• Site-to-site VPN
• Dedicated connectivity
• Private endpoints
• NAT
• Load balancers
• Firewall services
• Private DNS
• Network segmentation
• Cross-region connectivity

Also document the IP address plan before migration.

A poorly planned network can result in overlapping CIDRs, unexpected routing behavior, excessive data-transfer costs, or applications that cannot communicate after cutover.

8. Build the Security Model Before Moving Data

Security should not be added after migration.

Define the security baseline before production workloads arrive.

Your checklist should cover:

• Identity and access management
• Least-privilege permissions
• Multi-factor authentication
• Privileged access
• Network segmentation
• Encryption at rest
• Encryption in transit
• Secrets management
• Security logging
• Vulnerability management
• Endpoint protection
• Backup protection
• Security monitoring
• Incident response

Also determine who owns security after migration.

Moving infrastructure to AWS, Azure, or GCP does not eliminate the organization’s responsibility for securing its workloads.

The target environment should have clearly defined security controls before the first production cutover.

9. Assess Data Before You Move It

Data migration deserves its own plan.

For each database and storage system, determine:

• Data volume
• Data type
• Growth rate
• Source location
• Target location
• Required downtime
• Replication requirements
• Encryption requirements
• Retention requirements
• Backup requirements
• Validation method

Then decide how the data will actually move.

Possible approaches include:

• Offline transfer
• Online replication
• Database migration services
• Storage transfer services
• Backup restoration
• Application-level synchronization

The right method depends heavily on data size, network capacity, business downtime requirements, and application architecture.

Do not assume that moving the application is the hard part. For many environments, moving and validating the data is the more sensitive operation.

10. Estimate the Real Cloud Cost

A migration can reduce infrastructure costs, but simply moving existing infrastructure to cloud pricing does not guarantee savings.

Estimate the full operating cost.

Include:

• Compute
• Storage
• Database
• Backup
• Network traffic
• Data transfer
• Load balancing
• Monitoring
• Security services
• Support
• Software licensing
• Managed services
• Disaster recovery
• Third-party tools

Also account for usage patterns.

A server that costs a fixed amount in a data center may have a very different cost profile in the cloud depending on whether it runs continuously, scales dynamically, or is frequently stopped.

Create at least three estimates:

Scenario	Purpose
Baseline	Expected normal usage
Growth	Expected business growth
Peak	High-demand scenario

Do not base the migration business case only on the provider’s calculator estimate.

Compare the expected cloud TCO with the current cost of running the environment.

11. Choose the Migration Sequence

Moving everything at once creates unnecessary risk.

Instead, create migration waves.

A simple structure might look like:

Wave 0 → Discovery and assessment

Wave 1 → Low-risk applications

Wave 2 → Supporting services

Wave 3 → Medium-criticality applications

Wave 4 → Business-critical systems

Wave 5 → Optimization and modernization

Your first workload should generally be useful for learning without creating unacceptable business risk.

For each wave, define:

• Applications included
• Dependencies
• Migration date
• Migration owner
• Expected downtime
• Testing requirements
• Communication plan
• Rollback procedure
• Success criteria

Microsoft’s migration planning guidance specifically recommends defining workload sequencing, data-transfer paths, and rollback strategies as part of migration planning.

12. Define Success Criteria Before the Migration

“Server successfully moved” is not a meaningful business success criterion.

Define measurable outcomes.

For example:

• Application response time remains below X seconds
• No critical functionality is lost
• Database consistency is confirmed
• No critical security findings remain
• Recovery objectives are achieved
• User acceptance testing passes
• Cloud cost remains within the approved range
• Monitoring is operational
• Backup completes successfully

This gives the migration team a clear definition of “done.”

13. Build a Proper Testing Plan

Testing should happen before production cutover.

At minimum, test:

Functional testing

Does the application actually work?

Performance testing

Does it handle expected traffic?

Integration testing

Can it communicate with dependent systems?

Security testing

Are authentication, authorization, encryption, and network controls working?

Disaster recovery testing

Can the workload actually be recovered?

Data validation

Is the migrated data complete and consistent?

A successful server boot does not mean a successful migration.

14. Prepare a Rollback Plan

Every production migration needs an answer to one question:

“What happens if we discover a critical problem after cutover?”

Your rollback plan should define:

• Rollback decision criteria
• Who can authorize rollback
• Maximum acceptable downtime
• How traffic will be redirected
• How databases will be synchronized
• How users will be informed
• How the original environment will be restored
• How data created after cutover will be handled

Do not create a rollback plan that exists only on paper.

Test it where practical.

15. Prepare Operations Before Going Live

The migration is not finished when traffic reaches the new cloud environment.

The operations team needs to be ready to manage it.

Before go-live, confirm:

• Monitoring is active
• Alerts are configured
• Logs are centralized
• Backups are running
• Recovery procedures are documented
• Access permissions are assigned
• Incident procedures are defined
• Patch management is established
• Cost monitoring is active
• Support ownership is clear

Google Cloud’s Migration Center, for example, supports discovery, assessment, planning, and migration activities rather than treating migration as a single transfer event.

16. Decide What Happens to the Old Environment

One frequently overlooked part of migration planning is the source environment.

After a workload moves, decide whether the old infrastructure will be:

• Decommissioned
• Kept temporarily for rollback
• Repurposed
• Reduced to a minimal footprint
• Retained for compliance or archival purposes

Do not immediately shut everything down after a successful cutover.

Keep the required rollback capability until the migration has been validated and the agreed stabilization period has passed.

At the same time, avoid leaving unused infrastructure running indefinitely. That creates unnecessary costs and operational risk.

The Pre-Migration Checklist

Before approving a production migration, verify that these questions have clear answers.

Business

• Is the reason for migration documented?
• Are the expected business outcomes defined?
• Is the migration budget approved?
• Are business owners identified?

Discovery

• Is the infrastructure inventory complete?
• Are applications classified by business criticality?
• Are application dependencies documented?
• Are performance requirements known?
• Are licensing requirements understood?

Architecture

• Is the target cloud selected?
• Is the target region selected?
• Is the target architecture documented?
• Is the landing zone ready?
• Is the network architecture defined?
• Is the identity model defined?

Security

• Are IAM roles and permissions defined?
• Is MFA enabled where required?
• Is encryption configured?
• Are secrets protected?
• Are security logs enabled?
• Are compliance requirements addressed?

Data

• Is the data inventory complete?
• Is the migration method selected?
• Is data replication required?
• Is data validation defined?
• Is the backup strategy confirmed?

Cost

• Is the cloud TCO estimated?
• Are network and data-transfer costs included?
• Are licensing costs included?
• Are backup and disaster recovery costs included?
• Are growth and peak scenarios modeled?

Migration

• Is a migration strategy selected for every workload?
• Are workloads assigned to migration waves?
• Is a migration owner assigned?
• Is downtime defined?
• Is a rollback procedure documented?
• Has the migration been tested?

Operations

• Is monitoring ready?
• Is logging ready?
• Are backups working?
• Are alerts configured?
• Is operational ownership clear?
• Is post-migration support defined?

AWS vs Azure vs GCP: What Changes in the Checklist?

The planning principles remain similar, but implementation differs between providers.

Area	AWS	Azure	GCP
Migration planning	AWS Cloud Adoption Framework	Azure Cloud Adoption Framework	Google Cloud Migration Center
Organization model	Organizations / accounts	Tenant / management groups / subscriptions	Organization / folders / projects
Network model	VPC	Virtual Network	VPC
Identity	IAM	Microsoft Entra ID / Azure RBAC	Cloud IAM
Migration tooling	AWS migration and modernization tools	Azure Migrate	Migration Center
Migration strategy	7 Rs	Workload-specific migration strategies	Migration and modernization pathways
Key planning concern	Account structure, workloads, networking and operating model	Landing zones, governance and Microsoft ecosystem integration	Projects, networking, data and modernization

AWS recommends assessing organizational readiness across areas such as business, people, process, platform, operations, and security. Azure’s framework similarly starts with strategy and planning before preparing the environment and migrating workloads. Google Cloud’s Migration Center provides a unified platform for discovering assets, estimating cloud spend, assessing workloads, and planning migration.

The provider-specific tools can help with the process, but they do not replace your own migration strategy.

A Practical 90-Day Pre-Migration Approach

For a medium-sized environment, the planning phase can be organized into three stages.

Days 1–30: Discover

Focus on understanding the existing environment.

Complete:

• Infrastructure inventory
• Application inventory
• Dependency mapping
• Performance analysis
• Data assessment
• Security assessment
• Licensing review
• Current-cost analysis

The output should be a clear picture of what you have today.

Days 31–60: Design

Move from discovery to decisions.

Complete:

• Cloud provider selection
• Target architecture
• Network design
• Security architecture
• Identity model
• Migration strategy for each workload
• Migration waves
• Cloud TCO
• Testing strategy
• Rollback strategy

The output should be an approved migration roadmap.

Days 61–90: Validate

Before production migration:

• Build the landing zone
• Establish connectivity
• Configure security controls
• Migrate a pilot workload
• Test applications
• Test data
• Validate performance
• Test monitoring
• Validate backup and recovery
• Document the production cutover

The objective is not simply to prove that migration is technically possible.

It is to prove that the organization is ready to operate the workload after migration.

The Most Important Rule: Do Not Treat Migration as a Copy-and-Paste Exercise

A cloud migration is an opportunity to make deliberate decisions about your infrastructure.

Before moving each workload, ask five questions:

1. Does this application still need to exist?
2. Does it need to move to the cloud?
3. If it moves, should it be rehosted, replatformed, or modernized?
4. What will it cost to operate after migration?
5. What could go wrong during and after the move?

These questions prevent one of the most expensive migration mistakes: taking an inefficient on-premises environment and reproducing the same inefficiencies in the cloud.

The goal is not to move servers.

The goal is to move workloads into an environment that is more scalable, secure, manageable, resilient, and economically sustainable.

A well-planned migration therefore follows a simple sequence:

Discover → Assess → Design → Prioritize → Test → Migrate → Validate → Optimize

AWS, Azure, and Google Cloud each provide frameworks and tooling to support these stages. The actual success of the migration, however, depends on how well the organization understands its workloads and prepares for the environment it is moving into.

The best migration plan is not the one that moves the most infrastructure the fastest. It is the one that knows exactly what is being moved, why it is being moved, what the target state should look like, and how the business will operate once the migration is complete.