How Does Cloud Migration Work for a Small Business?

Cloud migration for a small business is a sequence, not an event: inventory what you have, decide per application whether it moves as-is or gets replaced, fix identity and licensing first, migrate email and files before anything else, cut over the line-of-business application in a planned window, then decommission what you left behind. Done in that order, a 25 to 100 person business is usually finished in three to six months with no unplanned downtime.

Table of Contents

Done in the wrong order, the failure is predictable. Someone moves the file server to the cloud, nobody fixed permissions first, and every user now has a slower version of the same mess with a monthly bill attached.

Step 1: inventory before you plan

You cannot migrate what you have not listed. The inventory is one row per application and one row per data store, with: what it does, who owns it, how many people use it, what it depends on, where its data lives, how big that data is, what the vendor support position is, and what it costs today. Include the things nobody mentions in meetings: the Access database in accounting, the scanner that emails PDFs to a shared folder, the machine under someone’s desk running a licence server.

The inventory is also where the business case comes from. Cloud migration rarely saves money on a straight line-for-line comparison; it changes what you buy from capital hardware refreshes to an operating cost, and it removes a class of risk. Say which of those you are buying, because the answer sets the budget.

Step 2: decide per application

Five options, and most small businesses use three of them.

Retire. Nobody uses it. Confirm, archive the data, and turn it off. Every inventory has some.
Replace. Swap it for a software as a service equivalent. This is usually the right answer for email, file storage, phones, and increasingly for line-of-business applications where the vendor offers a hosted version.
Rehost. Lift the server into a cloud virtual machine unchanged. Fastest, and it carries the existing problems along with it. Reasonable as a transitional step for an application the vendor has not modernized.
Replatform. Move it and change a component, typically the database, to a managed service.
Keep on-premises. A legitimate answer. Applications with hardware dependencies, large local data sets with latency sensitivity, or vendor support terms that forbid cloud hosting should stay where they are, and a plan that admits this is more credible than one that does not.

Step 3: fix identity and licensing first

Identity is the foundation everything else lands on, and retrofitting it is expensive. Before the first workload moves:

Decide the identity model: cloud-only, or synchronized from an existing directory, and if synchronized, which attributes are authoritative where.
Multi-factor authentication on every account, without exceptions for executives.
Conditional access policies written before there is anything sensitive to protect, not after.
Clean up group membership and file permissions before the data moves. This is the single highest-value hour in the whole project, and skipping it is what produces the migration that improved nothing.
A named administrative account owned by the business, separate from any provider account.
Licensing checked against what you will actually consume, since the tier you need for conditional access or data protection is often above the one you bought.

Step 4: migrate in the right order

Email. Highest value, most mature tooling, most predictable. Do it first and let staff acclimatize.
Files. After the permissions cleanup. Expect this to take longer than the data size suggests, because the decisions about structure are the slow part, not the copying.
Collaboration and phones. Once email is stable.
Line-of-business applications. One at a time, each with its own test window, rollback plan, and a named business owner who signs off that it works.
Backup and monitoring for the new environment, configured before the old environment is switched off rather than after.

Two rules make the difference between a quiet migration and a loud one. Run parallel where you can, so there is always a working path back. And migrate a pilot group of 5 to 10 people through each phase before the whole company, chosen to include the two or three people with the strangest workflows.

Step 5: decommission deliberately

The step everyone skips. Keep the old environment running read-only for 30 to 60 days, verify nothing still points at it, then decommission properly: wipe the storage, cancel the maintenance contracts, remove the DNS entries, close the firewall rules, and stop paying for the internet circuit you sized for it. Businesses routinely pay for a year of hosting for a server nobody has logged into since the migration.

What it costs and what it does not save

Be clear about the shape of the numbers. Project cost is one-time and covers planning, the migration work, and the parallel-running period. Ongoing cost is per user per month for the cloud services plus your managed IT agreement. What usually disappears is the hardware refresh cycle, the server room power and cooling, and the on-premises backup infrastructure. What usually does not disappear is IT support cost, because someone still has to run identity, security, backups, and the help desk.

Our managed IT services pricing guide covers the ongoing side. For the project side, the driver is application count and data complexity rather than headcount.

The cloud migration checklist

Application and data inventory complete, including shadow systems.
A disposition decision recorded for every row: retire, replace, rehost, replatform, or keep.
Business case stated as risk reduction, cost shape change, or capability, not as a vague saving.
Identity model decided and multi-factor authentication deployed.
Conditional access policies in place before data moves.
Group membership and file permissions cleaned up.
Licensing verified against what the design actually requires.
Migration order agreed: email, files, collaboration, line-of-business.
Pilot group named, including the awkward workflows.
Rollback plan per workload, with a decision point and an owner.
Backup configured for the new environment before the old one is retired.
Bandwidth and network path reviewed for the new traffic pattern.
Staff communication and training scheduled per phase.
Decommission plan with dates, including contracts and circuits to cancel.

Frequently Asked Questions About Cloud Migration

How long does a cloud migration take for a small business?

Three to six months for a 25 to 100 person business with a typical mix of email, file shares, and one or two line-of-business applications. Email is usually done within the first month, files take longer than the data size suggests because the structural decisions are slow, and each line-of-business application needs its own test window. What extends a project is application count and data complexity, not headcount.

What should we migrate first?

Email, then files, then collaboration and phones, then line-of-business applications one at a time. Email first because the tooling is mature and the value is immediate, which buys goodwill for the harder phases. Files after email because they need a permissions cleanup first. Line-of-business applications last because each one needs a test window, a rollback plan, and a business owner who signs off that it works.

Does moving to the cloud save money?

Not usually on a straight comparison, and that is the wrong reason to do it. What changes is the shape of the spend: capital hardware refreshes and server room costs become a predictable monthly operating cost, and a class of risk around aging hardware disappears. IT support cost does not go away, because identity, security, backups, and the help desk still need running. Decide which of those outcomes you are buying and set the budget against that, rather than promising a saving that may not appear.

Should every application move to the cloud?

No, and a plan that says otherwise is not credible. Applications with hardware dependencies, large local data sets that are sensitive to latency, or vendor support terms that prohibit cloud hosting should stay on premises. Some applications should be retired rather than migrated, and some should be replaced with a software as a service equivalent rather than lifted. Record a disposition decision for every row of the inventory: retire, replace, rehost, replatform, or keep.

What is the most common cloud migration mistake?

Moving file shares without cleaning up permissions first. The result is the same access sprawl you had before, now searchable, slower, and billed monthly. Fixing group membership and folder permissions before the data moves is the highest-value hour in the whole project, and it is also the one people skip because it produces nothing visible on the day it is done.

Will there be downtime during a cloud migration?

There should be little to none if you run parallel and pilot. Email and file migrations are done with both systems available so users always have a working path. Line-of-business application cutovers usually need a defined window, often a weekend, with a rollback decision point and a named person who makes the call. Downtime in a migration is almost always the result of no rollback plan rather than of the migration itself.

Do we still need an IT provider after moving to the cloud?

Yes, and the work changes rather than disappears. Nobody is replacing failed drives, but someone has to run identity and conditional access, monitor and respond to security alerts, manage licensing so you stop paying for departed staff, back up the cloud data, and answer the help desk. Businesses that treat a cloud migration as a reason to end IT support usually rediscover the need within a year, typically after a licensing surprise or an account compromise.

What happens to our old servers after the migration?

Keep them running read-only for 30 to 60 days as a safety net, confirm nothing still points at them, then decommission properly: wipe the storage, cancel the maintenance contracts and any hosting, remove the DNS entries, close the firewall rules, and resize the internet circuit if it was sized for inbound traffic you no longer have. Decommissioning is the step most often skipped, and the usual result is paying for a year of infrastructure nobody has used since cutover.