The server in the back room is out of warranty, the lease on the office is up for renewal, and half the staff already work from home two days a week. Moving to the cloud has stopped being a question of whether and become a question of how, and the how is where migrations go wrong. The technology is rarely the problem. The problems come from things nobody wrote down before the cutover weekend. This checklist is the list we work through, in the order that tends to save the most grief.
Before anything moves
Inventory everything, including the embarrassing bits
List every server, application, database, shared folder, printer queue, scheduled task and integration. Then look for the things that are not on any list: the spreadsheet with a macro that pulls from a database share, the label printer driven by an old workstation, the scanner that emails to a folder. Migrations fail on the items nobody knew were load bearing.
Map the dependencies
For each application, note what it talks to and what talks to it. An accounting package that reads from a file share, a line-of-business system that authenticates against the local directory, a reporting tool pointed at a database by name. When one piece moves and another does not, the dependency is what breaks, and it breaks on Monday morning.
Identity first
Users, groups, permissions and multi-factor authentication should be sorted out before data moves, because everything in the cloud hangs off identity. Clean up stale accounts, agree a naming convention, decide how the on-premises directory and the cloud directory will relate during and after the move, and switch on multi-factor authentication for everyone before the new environment holds anything valuable.
Classify the data
Not all data is equal. Decide what is sensitive, what has a retention obligation, what is simply old, and what can be archived rather than migrated. Moving a decade of abandoned project folders costs time and money and gives you a cluttered new environment. Migration is the best moment you will ever get to leave things behind.
Planning the move
Check the internet connection honestly
Once your files and applications live in the cloud, the office connection becomes the road everything travels on. Measure upload as well as download, because the initial data transfer and daily synchronization both push data out. Consider a second connection from a different carrier for resilience, and check that the firewall and switches can actually carry the throughput you are paying for.
Understand the licensing shift
On-premises software is usually bought once and depreciated; cloud services are subscribed to per user, per month. That changes how the cost behaves, how it is budgeted and who approves adding a user. Work out which tiers you need, which staff need which features, and how leavers are removed so you are not paying for empty seats.
Plan the cutover in writing
Decide what moves in what order, whether the migration is a single weekend or a staged sequence by department, what the point of no return is, and how you would roll back if something fails. Write down who does what, in what sequence, and how success will be confirmed before staff arrive. A cutover plan that lives in someone’s head is not a plan.
During and after
Train people before the switch, not after
The most common complaint after a migration is not that something broke but that nobody knew where things went. Short, practical sessions before cutover, a one-page guide to the new locations, and a visible help channel for the first fortnight turn a stressful week into a mildly annoying one.
Decommission deliberately
Once the new environment has proven itself, the old one must be retired properly: final backups kept for the agreed retention period, data securely erased from old drives, licences and support contracts cancelled, and monitoring updated so nobody is alerted about a server that no longer exists. Old systems left running “just in case” become unpatched security risks within months.
Decide what stays on premises
Not everything should move. Applications that need very low latency to local equipment, systems tied to hardware on the shop floor, or workloads with large local files that would be slow over the internet may be better left in place, at least for now. A hybrid pattern is a legitimate destination, not a failed migration. Our cloud migration work starts with that judgment rather than assuming everything belongs in the cloud.
Common questions
How long does a cloud migration take for a small business?
It depends on how much data there is, how many applications have dependencies, and how much cleanup is done first. Email alone can move in a short window; a full move of files, applications and identity is usually planned in stages over weeks so each step can be verified. The preparation, especially inventory and identity, typically takes longer than the transfer itself.
Should we move everything to the cloud at once?
Rarely. A staged approach, moving identity first, then email, then files, then applications, lets each stage be checked before the next begins and limits the impact of any problem. Some workloads may stay on premises for good reasons such as latency or hardware ties. A hybrid outcome is a legitimate design, not a compromise.
What happens to our old server after migration?
It should be decommissioned deliberately: a final backup retained for the agreed period, data securely erased, licences and support contracts cancelled, and monitoring updated. Keeping it running “just in case” is a common mistake because it becomes an unpatched, forgotten machine on the network. If some workload must remain, it should be scoped and managed like any other system.
Who manages the cloud environment after the move?
Someone has to. Cloud services still need identity administration, security configuration, backup, cost control and monitoring, and the platform provider does not do those for you. Many businesses hand this to a managed cloud provider so the environment stays patched, backed up and correctly configured, while internal staff focus on the business rather than the platform.
If a migration is on your horizon and you would like the checklist applied to your own environment, our cloud migration solutions and managed cloud pages describe how we plan and run the move, and you can contact us to start with an honest inventory.
