Cloud migrations that fail almost always fail before the migration begins. The technical work of moving workloads to the cloud is, in most cases, the most manageable part of the programme. What causes failures is the accumulation of unresolved assumptions, unmapped dependencies, unquantified costs, and unaddressed organisational issues that enter the migration in the planning phase and metastasise during execution.

This checklist is drawn from 40+ cloud migration engagements across Nigeria and West Africa. Use it before you commit to a go-live date.

Discovery and Assessment (Items 1–5)

1. Complete application inventory
Document every application you intend to migrate. For each one, capture: business owner, criticality, current infrastructure, average and peak resource usage, network dependencies, and licensing terms. This sounds obvious — and it is almost never done properly before migration.

2. Dependency mapping
Map every application-to-application dependency. Which systems talk to each other? What protocols do they use? What are the latency tolerances? Tools like AWS Migration Hub, Azure Migrate, or infrastructure scanning tools (Flexera, CloudPhysics) can automate much of this. Manual documentation catches what automated tools miss.

3. License audit
Some software licences — Oracle Database being the most notorious — have complex rules about cloud deployment that can make cloud licensing more expensive than on-premise. Microsoft products, SAP, and various UNIX operating systems all have cloud-specific licensing implications. Engage your vendors before migrating, not after.

4. Right-sizing analysis
Do not lift-and-shift without right-sizing. Collect 30–90 days of CPU, memory, and storage utilisation data from your current infrastructure. Most on-premise servers are provisioned at 2–3× their actual utilisation. Migrating an oversized on-premise server to an equivalently sized cloud instance will cost more, not less.

5. Total cost of ownership modelling
Build a 3-year TCO model before committing to cloud. Include: compute, storage, network egress, licences, migration costs, operational costs (cloud management tools, training), and the cost of any re-architecture needed to run efficiently in cloud. Compare against the total cost of extending your current on-premise environment.

Security and Compliance (Items 6–9)

6. Data classification
Identify which data can go to cloud, which requires specific geographic residency, and which must remain on-premise for regulatory reasons. NDPR, CBN guidelines, and sector-specific regulations (NAICOM for insurance, NITDA for government) all create data handling constraints.

7. Identity and access management design
Design your cloud IAM model before migration begins. How will on-premise Active Directory integrate with cloud identity? How will privileged access be managed? What is the break-glass procedure for emergency access? These decisions are much harder to change after 50 workloads have been migrated.

8. Network security architecture
Design VPC/VNet architecture, security group policies, and network segmentation before migrating any workloads. Retrofitting network security after migration is expensive and disruptive.

9. Incident response planning
Your incident response procedures will change when workloads move to cloud. Who calls the cloud provider during a major incident? What escalation paths exist? What forensic capabilities do you have in a cloud environment versus on-premise? Update your IR playbooks before go-live.

Operational Readiness (Items 10–13)

10. Monitoring and observability design
Design your observability stack before migration. How will you monitor cloud workloads? How will alerts integrate with your existing ITSM? Who is on-call for cloud infrastructure? Deploying workloads without monitoring is how you discover problems at 3am from angry users.

11. Backup and disaster recovery validation
Define and test your cloud backup strategy and RTO/RPO requirements before migrating. Just because your data is in cloud does not mean it is backed up — the default behaviour of most cloud services is no automatic backup.

12. Runbook documentation
Document operational procedures for your cloud environment before go-live: how to scale resources, how to respond to cost alerts, how to rotate credentials, how to run patch management. Do not leave this to be created reactively during an incident.

13. Team training
Identify which engineers need cloud training and complete it before migration — not during. AWS, Azure, and GCP all have structured certification programmes. At minimum, your infrastructure leads should hold associate-level certifications on your chosen platform before managing production cloud workloads.

Migration Execution (Items 14–15)

14. Pilot migration
Always run a pilot migration of a non-critical workload before committing to your migration wave schedule. The pilot will reveal assumptions that were wrong, tools that did not work as expected, and process gaps that need to be addressed. Discover these on a low-risk workload, not on a critical one.

15. Rollback plan
For every workload migrated, have a documented rollback procedure. How long will it take to revert if the cloud deployment has critical issues? Where is the data cutback point? Who has the authority to trigger a rollback? Test the rollback procedure before migration, not after.

Migration readiness is not a checklist you complete once — it is an ongoing assessment updated as each wave of migration progresses. Teams that treat it as a one-time exercise are the ones that get surprised mid-programme.