A cloud migration checklist for small and mid-size businesses covers six areas: knowing what you run today, choosing the right approach for each workload, planning security and access, estimating running costs, testing the move with a rollback plan, and monitoring afterwards. Doing these in order prevents most surprises, outages and bills.
Key takeaways
- Inventory everything first; you cannot move what you have not found.
- Not every system should move the same way. Decide per workload whether to move as is, adjust, rebuild or retire.
- Plan security, backups and access before the move, not after.
- Cloud costs are usage-based, so set budgets, tags and alerts from day one.
- Migrate in stages, test thoroughly and keep a rollback plan until the new setup is proven.
Before you start: why migrate at all?
Be clear about your reason, since it shapes every choice. Common reasons include replacing ageing hardware, improving availability, supporting growth or remote teams, strengthening backups and disaster recovery, or reducing the effort of maintaining servers. Cost savings are possible, but not automatic. A badly planned move can cost more than staying put. Write down your top two goals and what success looks like.
Phase 1: Discover and assess
Build an inventory
List every application, server, database, file store, scheduled job and integration. For each, note the owner, purpose, technology, dependencies, how many people use it and how critical it is. Include the invisible items: a spreadsheet macro, a cron job or an old script that someone relies on.
Map dependencies
Find out which systems talk to which. Moving an application without its database or an internal service it calls is a classic cause of failure.
Classify by criticality
Sort workloads by how damaging an outage would be. Start your migration with a low-risk workload to build experience, and leave the most critical for later.
Check compliance and data location
Some data may have rules about where it can be stored or how it must be protected. Requirements vary by country and sector, so consult a qualified legal or compliance professional before moving regulated or sensitive data.
Phase 2: Choose an approach per workload
Teams often describe options with a few simple verbs:
- Rehost (sometimes called lift and shift): move as is, with minimal changes. Fastest, but you may carry old inefficiencies with you.
- Replatform: make small changes to benefit from the cloud, such as using a managed database instead of running your own.
- Refactor or rebuild: redesign the application to use cloud capabilities more fully. More effort, more long-term flexibility.
- Replace: swap the system for a ready-made service or software product.
- Retire: switch off what nobody uses.
- Retain: leave some systems where they are, for now.
The inventory often shows that a few systems can simply be retired, which reduces what you have to move.
Choosing a provider
Major providers such as AWS, Azure and Google Cloud all offer mature services. Compare them on the services you need, regions available, support, pricing model, your team's existing skills and how easily you could move away later. Avoid deep dependence on one proprietary feature unless it gives you clear value.
Phase 3: Plan security, access and resilience
Security in the cloud is a shared effort: the provider secures its platform, and you remain responsible for how you configure and use it.
- Identity and access: use individual accounts, multi-factor authentication and least privilege. Avoid shared logins.
- Network design: keep databases and internal services off the public internet; expose only what must be public.
- Encryption: enable it for data in transit and at rest where available.
- Secrets: store keys and passwords in a managed secrets service, not in code or documents.
- Backups and recovery: decide how often you back up, where copies live, and how quickly you must recover. Then test a restore. An untested backup is only a hope.
- Logging and monitoring: collect logs and set alerts for unusual activity.
Phase 4: Plan costs
Cloud billing is based on usage, so the bill depends on how you design and run things.
- Estimate costs per workload using the provider's pricing tools, and add a margin for data transfer and storage growth.
- Use tags or labels so you can see which team or project spends what.
- Set budgets and alerts so you hear about overspend early.
- Remove unused resources, such as forgotten test servers and old snapshots.
- Review sizing after a few weeks; many workloads start oversized.
- Compare ongoing costs with the full cost of your current setup, including hardware refresh, power, space and the staff time you spend maintaining it.
Phase 5: Prepare and test the move
- Set up a landing zone. Create the accounts, network, permissions and monitoring structure before moving any workload.
- Run a pilot. Migrate one low-risk system, learn from it and refine your process.
- Plan data transfer. Estimate how long copying data will take and decide how you will keep it in sync until cutover.
- Write the cutover plan. Include the time window, who does what, communication to staff and customers, and the steps for switching traffic.
- Write the rollback plan. Define the conditions that trigger a rollback and how to execute it. Keep the old environment available until you are confident.
- Test. Check functionality, performance with realistic load, integrations, backups, restores and user access before cutover.
Phase 6: Cut over and improve
- Choose a quiet period for the switch, and have the team on hand.
- After cutover, monitor closely for errors, slow responses and unexpected costs.
- Keep the old system in read-only or standby mode for an agreed period.
- Decommission the old environment only after sign-off, and make sure data is securely erased where required.
- Update documentation and train the team.
- Revisit costs, performance and security after the first month, then regularly.
Common mistakes
- Moving everything at once instead of in stages.
- Skipping the inventory, then discovering a forgotten dependency during cutover.
- Leaving default or overly open permissions.
- Ignoring data transfer time and bandwidth.
- Not training staff on the new environment.
- Treating the migration as finished at cutover, rather than starting a period of tuning.
A short worked example
Imagine a mid-size distribution company running its accounting integration, an internal order portal and a file server from two aged servers in the back office. Its goals are better backups and less hardware to maintain.
The inventory reveals a reporting tool nobody has used for a year, which is retired. The file server moves to a managed cloud storage service. The order portal is rehosted first as a pilot with a managed database, then tuned later. Backups are configured and a restore is tested before cutover. Budgets and alerts are set from the first week. The old servers stay powered on, read-only, for a month and are shut down after the team confirms everything works.
Getting help
Grocito's cloud solutions service lists AWS, Azure and Google Cloud work, migration and modernisation, backup and disaster recovery, and cost optimisation. Repeatable deployments are easier with DevOps practices such as CI/CD pipelines and infrastructure as code, and our guide to DevOps basics for small teams explains the ideas in plain terms. If your applications are old, website development and modernisation work can be part of the plan.
FAQ
How long does a cloud migration take?
It depends on how many systems you have, how tangled they are and how much you change them. A single simple application can move quickly, while a larger estate is usually phased over a longer period. Your inventory and pilot give the most reliable estimate.
Is moving to the cloud always cheaper?
No. It can reduce hardware and maintenance effort, and costs can scale with use, but poor sizing or unused resources can raise the bill. Compare the full cost of your current setup with a realistic estimate, then monitor after the move.
What is lift and shift?
It means moving an application to the cloud with few or no changes. It is usually the quickest route and a sensible start for some systems, but it may not use cloud capabilities efficiently.
Do I need downtime during migration?
Sometimes a short window is needed for the final switch. Careful planning, data synchronisation and staged cutovers can keep downtime small. Choose a low-traffic period and prepare a rollback.
Next steps
Start with the inventory: a simple table of your systems, owners, dependencies and criticality. If you would like an experienced second pair of eyes on the plan, contact us and we can review your inventory and options with you.
