Cloud Migration Checklist for Growing Businesses
The discovery, design and operational steps SMBs skip during cloud migration - and end up paying for in cost, performance and downtime later.
Cloud migrations rarely fail outright. They quietly underdeliver. The business ends up with infrastructure that costs more than the on-prem environment it replaced, performs worse for the workloads that mattered, and is harder to change because no one wrote anything down. The work that prevents this is unglamorous and almost always skipped: discovery, dependency mapping, cost modelling and infrastructure-as-code from day one.
This is the checklist we use when planning Azure or AWS migrations for SMBs in Ottawa and the GTA. It assumes you are moving real workloads, not a few file shares, and that you want the result to be operable by your team after we leave.
Before you move: discovery and dependency mapping
You cannot migrate what you do not understand. Spend the first two to four weeks building a real inventory: every server, every application, every shared dependency, every scheduled job, every print queue, every line-of-business integration nobody has touched in five years.
The output is a dependency map - which application talks to which database, which jobs run when, which services share authentication. This is the single most valuable artifact in any migration. It is also the one most likely to surface a forgotten Access database holding together a critical workflow.
- Inventory: hostnames, OS versions, CPU/memory, disk usage, network throughput.
- Application owners: name a person responsible for each line-of-business app.
- Integration points: APIs, SFTP, scheduled exports, on-prem connectors.
- Identity dependencies: AD groups, service accounts, RBAC assignments.
- Compliance scope: which workloads must stay in Canada.
Cost modelling - real cost, not list price
Azure and AWS list prices are the start of a conversation, not the end. Reserved instances, savings plans, spot capacity, egress charges, snapshot storage, log ingestion and managed-service premiums all bend the bill in real ways. Model your top ten workloads with realistic 24-month utilization, not the always-on default. Build in a 15-20% contingency.
Compare the modelled cloud cost to your fully-loaded on-prem cost - including hardware refresh, power, cooling, maintenance contracts and the staff hours spent on patching and capacity. Lift-and-shift often looks more expensive than on-prem until you add those back in.
Pick the right region - and stay there
For Canadian SMBs with any data residency obligations (PIPEDA, provincial health information, federal-adjacent contracts), default to Canadian regions: Azure Canada Central, AWS ca-central-1. Test latency from your user locations before committing. Multi-region is a future problem; pick one region, do it well, then expand only when the business case is real.
Design identity, networking and backup before you migrate
- Identity: how will cloud workloads authenticate - Entra ID, IAM Roles, federated identities?
- Networking: hub-and-spoke or flat VNet? VPN, ExpressRoute or public endpoints? Private endpoints for storage?
- Backup: who runs it, where, with what RPO/RTO? Cloud-native (Azure Backup, AWS Backup) or third-party?
- Monitoring: what gets logged, where do logs go, who looks at them?
- Naming and tagging: standards in writing before anything gets deployed.
Use Infrastructure-as-Code from day one
Even for small environments. Terraform is the SMB default; Bicep is fine if you are all-in on Azure. The first time you need to rebuild an environment, recover from a region outage, or spin up a staging copy, the difference between IaC and "someone clicked it together two years ago" is the difference between an afternoon and a quarter.
Click-ops environments are technical debt the moment they are created. Pay the small upfront cost; thank yourself in eighteen months.
Migrate in waves, not big-bang
Group workloads by dependency cluster. Migrate the simplest, lowest-risk cluster first - typically internal tools or test environments. Validate, learn, then move the next wave. Big-bang migrations exist mostly so they can fail spectacularly. The wave approach also lets you reuse landing-zone work and IaC modules across waves, which compounds.
After the move: FinOps, observability, optimization
Cloud bills creep. Without active cost discipline, most SMBs we audit have 20 to 30 percent waste within twelve months - oversized VMs, orphaned disks, idle dev environments running 24/7, log retention nobody reviewed. Build a simple monthly FinOps review into whoever owns the environment. Tag everything by application and cost centre; the tags pay for themselves the first time finance asks who is spending what.
Set up real observability - logs, metrics and traces - before you need it. Production failures discovered by customers cost more than the entire observability stack you would have built to prevent them.
Bottom line
A good SMB cloud migration is boring. It is well-scoped, well-documented, runs in waves, lands in the right Canadian region, costs roughly what was modelled, and leaves behind infrastructure your team can operate without us. If yours is starting to feel exciting, that is usually a sign the discovery phase ended too early.