The Cloud Migration Checklist Every SMB Needs Before They Start

Cloud migration is one of those projects that looks straightforward on paper and turns into a nightmare in practice — if you haven't done the groundwork first.

After working on dozens of SMB migrations, the pattern is consistent: the businesses that succeed prepared properly. The ones that struggled were in too much of a hurry to skip the boring bits.

Here's the checklist I use with every client before we touch a single workload.

1. Cloud Readiness Assessment

Before you decide which cloud or how to migrate, you need to know whether you're actually ready.

What to assess:

• Skills: Does your team have the knowledge to operate in a cloud environment? This isn't a blocker, but it shapes your plan.
• Applications: Are your core applications cloud-compatible? Legacy software with hard-coded server names or local file dependencies will need extra work.
• Network: Is your internet connectivity robust enough? Cloud shifts your dependency from local infrastructure to your internet connection.
• Compliance: Do you operate under any regulatory frameworks (ISO 27001, SOC 2, industry-specific)? Cloud providers offer compliance support — but you need to map your obligations.

Red flag to watch for: If you don't have an accurate inventory of your current infrastructure, stop here. You can't migrate what you can't see.

2. Workload Classification

Not all workloads should be migrated the same way. The industry uses the "6 Rs" framework:

| Strategy | What it means | When to use it | |---|---|---| | Rehost ("lift and shift") | Move as-is to cloud VMs | Quick migration, legacy apps | | Replatform | Minor optimisations (e.g. managed DB) | Good ROI with low effort | | Refactor | Re-architect for cloud-native | Max cloud benefit, higher effort | | Retire | Decommission the workload | It's not needed anymore | | Retain | Keep on-premises | Regulatory or latency reasons | | Repurchase | Switch to SaaS | Replace with cloud-native product |

For most SMBs, the sweet spot is a mix of rehost and replatform — move quickly, then optimise.

3. Data Migration Planning

Data is the hardest part of any migration. A few principles:

• Inventory your data first. Where is it? How much? What's the retention requirement?
• Classify sensitivity. Customer PII, financial records, and IP need different handling.
• Plan for downtime. Some data can be migrated live. Other data requires a maintenance window.
• Test your restore. Migrating data is useless if you can't restore it. Test your restore procedure before you cut over.

Practical tip: Use a staged migration. Move non-critical data first, run in parallel, validate, then cut over critical systems.

4. Security Baseline

Cloud security operates on a shared responsibility model — the provider secures the infrastructure, you secure what you put on it.

Before you migrate, establish:

• Identity and Access Management (IAM): Who can access what? Principle of least privilege from day one.
• MFA everywhere: No exceptions, especially for admin accounts.
• Encryption in transit and at rest: Most cloud providers enable this by default — verify it.
• Logging and monitoring: Set up CloudTrail (AWS), Azure Monitor, or equivalent. You need an audit trail.
• Network segmentation: Don't put everything in one flat network. Use VPCs, subnets, and security groups.

5. Cost Modelling

Cloud costs surprise businesses constantly. The mistake is comparing cloud costs to on-premises hardware costs — you need to compare total cost of ownership.

What to include in your TCO:

• Compute (instances/VMs)
• Storage (block, object, database)
• Networking (data transfer costs — these bite people)
• Licences (some on-prem licences don't transfer; others offer cloud benefits)
• Operations (your team's time managing the environment)
• Savings opportunities (reserved instances, auto-scaling, right-sizing)

Use the provider's cost calculators. AWS has the Pricing Calculator, Azure has the TCO Calculator. They're not perfect but they're a good starting point.

6. Rollback Planning

This is the one step most businesses skip — and the one they regret.

Before you cut over:

• Document your rollback procedure for every workload
• Test your rollback in a staging environment
• Define your rollback trigger: "If X happens, we roll back within Y hours"
• Ensure your on-premises environment stays intact until you've validated the cloud environment

The rule: Never decommission on-premises infrastructure until you've run successfully in cloud for at least 30 days.

---

The Bottom Line

A cloud migration isn't an IT project — it's a business transformation. The checklist above isn't exhaustive, but covering these six areas will dramatically reduce your risk and improve your outcomes.

If you're not sure where to start, that's exactly what a discovery conversation is for.