Cloud Migration Checklist: What to Do Before, During and After

Cloud migration fails in predictable ways. Costs come in higher than the business case promised, a cutover breaks something nobody knew was connected, or the organisation ends up running a data centre in someone else's building with none of the elasticity it was paying for.

All three are avoidable. What follows is a checklist organised by phase, with attention to the steps most commonly skipped.

Before: assessment and planning

Define why you are doing this

"Move to the cloud" is not a goal. Write down the specific outcomes you expect and how you will measure them - exiting a data centre by a fixed date, reducing provisioning time from weeks to minutes, meeting a compliance requirement, supporting a traffic pattern your current hosting cannot handle, or improving disaster recovery objectives.

These goals determine every subsequent decision. A data centre exit deadline pushes you toward fast rehosting. A scalability goal justifies re-architecture. Without stated goals you cannot make trade-off decisions or judge whether the project succeeded.

Build a complete inventory

For every application and server, record the technology stack and versions, resource utilisation over a representative period, licensing terms and whether they permit cloud deployment, data volumes and sensitivity classification, compliance obligations, business criticality, and acceptable downtime.

Utilisation data matters more than specifications. Servers are routinely provisioned for a peak that never arrives; migrating a 32-core machine that averages 4 percent CPU means paying cloud rates for idle capacity. Measure actual usage over at least a month, including month-end and any seasonal peaks.

Map dependencies exhaustively

This is where migrations are won or lost. Use automated discovery tooling to capture network traffic between systems, then validate against the people who operate them. You are looking for:

• Application-to-application and application-to-database calls
• Scheduled jobs and batch processes, including ones on servers nobody owns
• Shared file locations and network drives
• Hardcoded IP addresses and hostnames
• Licences tied to specific hardware or MAC addresses
• Integrations with external partners and third parties
• Reporting tools and spreadsheets connecting directly to production databases

That final category is consistently underestimated. Business users build direct database connections that become load-bearing and appear in no architecture diagram.

Model the target cost properly

Build a cost model based on measured utilisation and right-sized instances, not on current hardware specifications. Include compute, storage by tier, data transfer - particularly egress, which surprises people - managed service fees, backup and disaster recovery, licences, and the monitoring and security tooling you will need.

Then model the savings levers explicitly: reserved or committed-use discounts for steady workloads, autoscaling for variable load, and shutting down development and test environments outside working hours. Non-production environments running 24/7 are one of the largest sources of avoidable cloud spend.

Choose a pattern per application

Do not apply one strategy to everything. Per application, decide between retiring it, rehosting it as-is, replatforming with targeted changes such as a managed database, re-architecting it for cloud-native operation, or replacing it with a SaaS product.

Rehosting is fast and satisfies deadlines but captures little benefit. Re-architecting captures the benefit but costs significantly more. A common and sensible approach is to rehost the long tail to hit a deadline, and re-architect the small number of applications where elasticity or resilience genuinely matters.

During: foundations and migration

Establish the landing zone first

Before migrating anything, build the environment properly:

• Account and subscription structure separating production, non-production and shared services
• Network design - address ranges that do not collide with on-premise, segmentation, and connectivity back to your data centre
• Identity and access management with least-privilege roles, federated to your existing directory, and no shared credentials
• Encryption at rest and in transit, with a defined key management approach
• Logging and monitoring centralised from day one, including audit logs
• Tagging standards for cost allocation - retrofitting tags across hundreds of resources is miserable
• Infrastructure as code so environments are reproducible rather than hand-built

Skipping this to move faster is a false economy. Retrofitting network segmentation or tagging conventions after the fact costs multiples of doing it upfront.

Understand the shared responsibility model

The provider secures the infrastructure. You remain responsible for your data, your access controls, your configuration and your application security. Most cloud security incidents are misconfigurations by the customer - publicly readable storage buckets, over-permissive roles, management interfaces exposed to the internet.

Deploy automated configuration checking early so misconfigurations are caught continuously rather than during an annual review.

Migrate in waves

Sequence deliberately. Start with a genuinely low-risk workload - a development environment or an internal tool with tolerant users - to exercise your tooling, runbooks and team. Then move progressively more critical systems as confidence builds.

Group applications that are tightly coupled into the same wave. Splitting a chatty application and its database across the internet introduces latency that can make an application unusable even though both components are "migrated".

Reserve the most critical, most integrated systems for late waves, when your team has real operational experience.

Plan data migration and cutover mechanics

For each system decide the approach: a backup and restore during a maintenance window for small datasets with tolerable downtime, continuous replication with a short final cutover for anything where downtime is expensive, or physical transfer appliances for very large volumes where network transfer would take weeks.

Every cutover needs a written runbook with the sequence of steps, who does what, validation checks that prove success, a defined rollback trigger and procedure, and a communication plan. Rehearse it against non-production. A rollback plan you have never tested is a hope, not a plan.

Validate before declaring success

Confirm functionality against real business scenarios, not just that the service responds. Check performance against the pre-migration baseline - users notice latency regressions immediately. Verify data integrity with row counts and reconciliation against source. Confirm every integration, including partner connections and scheduled jobs. Test that backups actually restore.

After: the phase people skip

Migration completion is not the end; it is when cost and performance optimisation becomes possible with real data.

• Right-size continuously. Initial sizing is a guess. Review utilisation after a few weeks of production traffic and adjust.
• Buy commitments once demand is known. Reserved instances and savings plans offer substantial discounts, but only commit after you understand your steady-state baseline.
• Implement autoscaling where load genuinely varies, rather than provisioning for peak permanently.
• Schedule non-production shutdowns. Development and test environments rarely need to run overnight or at weekends.
• Apply storage lifecycle policies to move ageing data to cheaper tiers automatically.
• Review egress patterns. Unexpected data transfer charges usually indicate an architectural problem worth fixing.
• Assign cost ownership. Cloud spend without an accountable owner per workload drifts upward indefinitely.
• Decommission the old environment. Paying for both indefinitely quietly destroys the business case. Set a date, verify nothing still depends on it, and switch it off.

Finally, invest in your team. Cloud operations differ from data centre operations - different tooling, different failure modes, different cost dynamics. A migration completed by contractors and handed to a team that was never trained produces an environment nobody can safely change.

If you want an assessment of your own portfolio before committing to a plan, see our cloud computing services or get in touch.