Many small businesses are running a mix of ageing on-premise servers, a few cloud services adopted piecemeal, and a lot of workarounds. A migration is an opportunity to tidy that up. It is also where projects go wrong, usually because the planning was skipped in favour of the technical move. This guide covers how to approach it sensibly.
Start With Why
"Everyone else is doing it" is not a business case. The reasons that actually hold up tend to be concrete:
- Hardware is reaching end of life and the cost of replacing a server is hard to justify.
- Staff work in more than one place and need dependable access without a VPN and a long list of caveats.
- Resilience. A single server in a cupboard is a single point of failure.
- Predictable costs. Spreading spend across a subscription rather than a periodic capital outlay.
- Security and patching that is easier to keep on top of in a managed platform.
Be equally honest about what you are not trying to achieve. Cloud migration doesn't automatically make things cheaper — it moves cost from capital to operating expenditure, and poorly planned moves can cost more.
Step 1: Know What You Have
You cannot plan a move you cannot see. Before anything else, build an inventory of servers, applications, data stores, integrations and who depends on each. Include the awkward items: the old application only one department uses, the scheduled job nobody remembers writing, the shared mailbox that three suppliers email.
Step 2: Decide What Goes Where
Not everything belongs in the same place. A useful way to think about each system is to choose one of these paths:
- Move to a SaaS equivalent. Email, files and collaboration usually belong in Microsoft 365 rather than on a server. See SharePoint vs file server for one common example.
- Rehost. Lift an application onto a cloud virtual machine more or less as it is. Quick, though it doesn't gain much from the cloud on its own. Our IaaS hosting covers this route.
- Replace. Retire the old application in favour of a modern cloud-native one.
- Retain. Leave a system where it is because of licensing, latency, specialist hardware or cost. This is a legitimate answer.
- Retire. Switch off what nobody uses. Every migration turns up a few of these.
The most common mistake: migrating the mess. Permissions, folder structures and old data that accumulated over a decade get copied across unchanged. A migration is the cheapest moment you will ever have to clean up.
Step 3: Check Connectivity and Dependencies
Cloud services are only as good as the connection to them. A site that coped with a local server may struggle once everything depends on the internet. Review bandwidth, resilience and whether a backup line makes sense — our connectivity guide explains what to look for. Also check which line-of-business applications expect a local file path or a local database, since these are the ones that tend to break.
Step 4: Plan the Sequence
A staged approach lowers risk. A typical order for a small business looks like this:
- Identity and security first. Get accounts, MFA and device management in order before moving anything of value.
- Email and collaboration. Usually the most visible change, and the best-understood.
- Files. Move in pilot groups, not all at once.
- Line-of-business systems. Last, and with the most testing.
- Decommission. Switch off the old kit only once everything has been verified.
Step 5: Protect It on the Way In
Backups should be in place before the move, not after. It is also the right time to revisit protection of cloud data itself — see our piece on Microsoft 365 backup — and to confirm the cutover has a rollback plan if something does not work.
Step 6: Look After the People
Technical success can still be a business failure if staff feel left to cope. Tell people what's changing and when, give them short guidance on new ways of working, and make sure there is quick support in the first week after each stage. Most migration complaints are about communication rather than technology.
Where Projects Go Wrong
- No inventory, so surprises appear after switch-over
- Underestimating data volumes and the time to transfer them
- Cutting over without testing the line-of-business applications
- Switching off old systems too soon
- Forgetting ongoing costs, such as licensing and storage, in the business case
Questions worth asking any provider proposing a migration: What is the plan if a stage fails? How will we keep working during the move? What will it cost to run once it is live, not just to get there?
The Bottom Line
A good cloud migration is mostly planning: knowing what you have, deciding what belongs where, and moving it in a sensible order. Done that way it is far less dramatic than it sounds — and the business is usually simpler and safer at the end.