Cloud Migration Checklist for Small and Mid-Sized Businesses

Large enterprises run cloud migrations with dedicated programme teams. Small and mid-sized businesses usually have one or two technical people, a tight budget and no appetite for a weekend of downtime. A clear cloud migration checklist makes up for the missing headcount: it stops important steps from being forgotten and gives everyone, technical or not, a shared view of progress. The list below is organised into five phases. Copy it into a spreadsheet or task tracker and add an owner and date to each line.

Phase 1 of the cloud migration checklist: discovery and inventory

You cannot move what you have not listed. Most surprises during a migration come from something nobody knew was running.

List every server, virtual machine and hosting account, including the operating system and version.
List every application, its users, and whether it is business-critical, important or nice-to-have.
Record dependencies: which database each app uses, file shares, scheduled jobs (cron), outbound email, third-party APIs and licence servers.
Note every domain name, who the registrar is, and where DNS is hosted.
Gather SSL/TLS certificates and their expiry dates. Our SSL checker shows issuer and expiry for any public site.
Measure current resource usage (CPU, memory, disk, bandwidth) over at least two weeks, including a month-end or other busy period.
Find hard-coded IP addresses in configuration files and firewall rules; these break silently when servers move.

On Linux servers, a few commands give a quick picture of what is actually running and listening:

systemctl list-units --type=service --state=running
ss -tulpn
crontab -l; ls /etc/cron.d/
df -h

Phase 2: Planning and design

With the inventory done, decide what happens to each item and what the target environment looks like.

Choose a migration approach per application: rehost, replatform, replace with SaaS, refactor, retire or keep.
Pick a cloud provider and region. Consider where your customers are, data residency rules that apply to you, and the skills your team already has.
Design the network: private subnets for databases, public access only for web and load balancer endpoints, and VPN or private connectivity back to the office if needed.
Define identity and access: individual accounts for every administrator, multi-factor authentication on the root or owner account, and least-privilege roles.
Set budget alerts in the provider console before you launch anything.
Decide on backup policy (frequency, retention, and where copies live) for the new environment.
Agree on a maintenance window and a communication plan for staff and customers.
Write a rollback plan: what triggers it, who decides, and the exact steps to point traffic back.

Phase 3: Build and test

Build the new environment alongside the old one. Nothing should be switched off until the new side has been proven.

Provision servers or managed services, ideally from scripts or templates so the setup can be rebuilt.
Apply security baselines: closed ports by default, SSH key authentication, automatic security updates where appropriate.
Copy a recent snapshot of data and restore it in the new environment.
Test the application using a hosts-file override, so you can browse the new server by its real domain name without changing public DNS.
Run through key business tasks: log in, place an order, generate an invoice, send an email, run a report.
Check that open ports match your design with a port checker; only the ports you intend to expose should answer.
Load-test anything customer-facing if traffic is significant.
Time a full data sync so you know how long the final cutover will take.

A hosts-file test entry looks like this (on Linux and macOS in /etc/hosts; on Windows in C:\Windows\System32\drivers\etc\hosts):

203.0.113.25   www.example.com example.com

Phase 4: Cutover

The cutover is the moment traffic moves to the new environment. Preparation makes it short and boring, which is exactly what you want.

One to two days before: lower the TTL on DNS records you will change to 300 seconds.
At the start of the window: put the old application into maintenance or read-only mode so data stops changing.
Final sync: copy the last changes of databases and files.
Switch DNS or load balancer targets to the new environment.
Smoke test the same business tasks from Phase 3, this time through public DNS.
Watch propagation with a DNS propagation checker and keep the old server running until it completes.
Go or roll back: make the call at a pre-agreed time rather than drifting.

Phase 5: After the move

Migration is not finished when the site loads. The first few weeks decide whether the move actually delivers its benefits.

Confirm monitoring and alerting are live for uptime, disk space, CPU and certificate expiry.
Run and verify the first backup, then do a test restore.
Check email deliverability if mail is sent from the new servers (SPF, DKIM and reverse DNS).
Review the first full month's bill against your estimate; right-size anything that is idle.
Raise DNS TTLs back to normal values.
Update documentation: architecture diagram, credentials store, runbooks.
Decommission old servers only after a final backup and an agreed waiting period; cancel their contracts so you stop paying for them.

Common pitfalls for smaller teams

Underestimating data transfer time

Copying hundreds of gigabytes over an office connection can take days. Start an initial bulk copy early and only transfer the changes at cutover, using tools such as rsync for files or database replication.

Leaving everything on default settings

Cloud defaults are designed to get you started, not to be secure or cheap. Storage buckets, security groups and instance sizes all deserve a deliberate review.

No single owner

Even in a small company, one person should own the checklist and make the go or no-go call. Shared ownership tends to mean nobody notices the item that slipped.

Key takeaways

Inventory first: servers, apps, dependencies, domains, certificates and real resource usage.
Build and test the new environment in parallel; never migrate by switching off the old one first.
Lower DNS TTLs in advance, freeze data during cutover, and keep a tested rollback plan.
Finish properly: monitoring, verified backups, cost review and decommissioning.

Cloud articles