Cloud migrations fail in predictable ways. Applications that depended on something no one documented. Costs that came in higher than the business case. Cutovers that took the business down. Data that did not all make it. Most of these failures are avoidable with a thorough checklist and the discipline to follow it.
This checklist is built for mid-sized companies: enough systems to make migration complex, not enough staff to dedicate a large team to it. Work through it in order.
Phase 1: Assessment
Inventory Everything
- Every application, with owner, business function, and criticality
- Every server, virtual machine, and database, with specifications and utilization
- Every integration between systems, documented or not
- Every external dependency: vendors, APIs, file transfers, scheduled jobs
- Every license and its cloud eligibility
- Network topology, including firewall rules and VPNs
Most organizations find undocumented dependencies at this stage. Better now than during cutover.
Classify Applications
For each application, decide the migration approach:
Rehost. Move as-is to cloud infrastructure. Fastest, least benefit.
Replatform. Minor changes to take advantage of cloud services, like moving to a managed database. Moderate effort, meaningful benefit.
Refactor. Significant rearchitecture for cloud-native operation. High effort, highest benefit.
Replace. Retire the application in favor of a SaaS alternative.
Retire. Decommission applications no one uses.
Retain. Keep on-premises for now, with a documented reason.
Assess Data
- Volume and growth rate for each data store
- Sensitivity and compliance requirements
- Dependencies between data stores
- Backup and recovery requirements
- Transfer method and time estimate
Build the Business Case
- Current infrastructure cost, including hardware, facilities, licenses, and staff time
- Projected cloud cost, based on actual sizing rather than list prices
- Migration cost, including consulting, tooling, and internal time
- Expected benefits beyond cost: agility, scalability, resilience, security
- Timeline and risk
Be conservative on cloud cost. Most first estimates are low.
Phase 2: Planning
Choose the Platform
AWS, Azure, Google Cloud, or a combination. Base the decision on existing skills, existing vendor relationships, application requirements, and regional needs. A Microsoft-centric organization often lands on Azure. Organizations with specific data or AI needs may lean toward Google Cloud. AWS has the broadest service catalog.
Design the Target Architecture
- Account and subscription structure
- Network design, including connectivity to on-premises during transition
- Identity and access management
- Security controls, monitoring, and logging
- Backup and disaster recovery
- Cost management and tagging strategy
Get this right before migrating anything. Retrofitting architecture is expensive.
Sequence the Migration
Group applications into waves. Start with low-risk, low-dependency systems to build confidence and process. Move to complex, critical systems once the team has experience.
Plan Each Wave
- Applications and data in scope
- Migration approach for each
- Dependencies that must move together
- Testing plan
- Cutover plan with rollback
- Communication plan
- Success criteria
Prepare the Team
- Assign roles: migration lead, application owners, infrastructure, security, testing
- Identify skill gaps and address them with training or partners
- Establish decision-making authority for issues during migration
Address Compliance
- Data residency requirements
- Regulatory controls that must be maintained
- Audit trail for the migration itself
- Vendor agreements and shared responsibility
Phase 3: Execution
Build the Foundation First
Deploy the target architecture: networking, identity, security, monitoring, and cost controls. Validate it before any application moves.
Migrate Wave One
- Replicate data to the target environment
- Deploy application in the cloud
- Test functionality, performance, and integration
- Run in parallel with on-premises if possible
- Validate against success criteria
- Cut over
- Monitor closely for the first days
- Document what was learned
Iterate
Apply lessons from each wave to the next. Adjust sequencing if dependencies emerge. Do not rush later waves because early ones went well.
Manage Cutover Carefully
- Schedule during low-usage windows
- Communicate to users in advance
- Have rollback ready and tested
- Staff the cutover with people who can fix problems
- Verify data integrity immediately after
Phase 4: Post-Migration
Validate
- All applications functioning
- All integrations working
- All data present and correct
- Performance meeting expectations
- Security controls active
- Backups running and tested
Optimize
- Right-size resources based on actual usage
- Apply reserved instances or savings plans where usage is stable
- Eliminate resources that were provisioned for migration and are no longer needed
- Review cost against the business case
Decommission
- Shut down on-premises systems that have been migrated
- Cancel licenses and contracts no longer needed
- Dispose of hardware
- Update documentation and diagrams
Operate
- Establish cloud operations processes
- Set up cost monitoring and alerts
- Train staff on the new environment
- Schedule regular reviews of security, cost, and performance
Common Mistakes
Skipping the inventory. Undocumented dependencies are the most common cause of cutover failure.
Rehosting everything. Fast, but it moves problems to the cloud and rarely reduces cost.
Underestimating data transfer. Large datasets take longer to move than expected, and bandwidth costs add up.
Migrating before securing. Cloud environments without proper identity, network, and monitoring controls are exposed from day one.
No rollback plan. If cutover fails and there is no way back, the business is down.
Ignoring cost after migration. Cloud costs drift upward without active management.
Losing institutional knowledge. If a partner did the migration and left, no one on staff understands the environment.
When to Bring in a Migration Partner
Most mid-sized companies use a partner for at least part of the migration. The right partner brings tooling, experience with the platform, and a process that has been refined across multiple migrations. They also reduce the risk of the common mistakes above.
Our guide to the best cloud migration consulting companies covers firms with mid-market experience. Xcelacore provides cloud migration consulting and execution across AWS, Azure, and Google Cloud, with a focus on migrations that leave the internal team capable of running the environment afterward.
