Why migrations go wrong before they start
Moving to the cloud, meaning shifting your email, files, or a server from a box in your office to a service like Microsoft 365 or a hosted platform, is a one-weekend job when it's planned well and a one-month ordeal when it isn't. The difference is almost never technical skill during the move. It's the work done before anyone touches anything.
The failures I get called in to clean up share a pattern: nobody knew everything that was connected to the old system, nobody could log into a critical account, and there was no way back once things went sideways. All three are preventable, and prevention is cheap. Here's the checklist I use.
Inventory: find everything before you move anything
Start with a written inventory. Not from memory, from evidence.
- Every system in scope: email, shared files, any line-of-business app, the accounting system, the phone system if it touches the server.
- Every device that connects: office PCs, laptops at home, phones, the scanner that emails PDFs, the printer with a saved password. Scan-to-email devices break in almost every migration because everyone forgets them.
- Every integration: what sends email through your current system? Website contact forms, invoicing tools, and alarm systems often do, silently.
- Every account and who owns it. This is identity work: list every username, what it can access, and whether the person still works for you. A migration is the best moment you will ever get to shut off ex-employee access, so take it.
Expect this list to be longer than you think. In a 10-person office, forty-plus items is normal.
Backups and the way back
Before the move, take a complete backup of the old system and, this is the part people skip, actually restore a few files from it to prove it works. A backup you have never restored from is a hope, not a plan.
Then write down your rollback plan: if the migration fails at 9pm Sunday, what exactly do we do so people can work Monday morning? Sometimes the answer is to point everything back at the old system, which you have not touched. That answer only works if you genuinely have not touched it, so plan to run old and new side by side for a period rather than converting the old system in place. Keep the old system intact and reachable for at least 30 days after cutover.
DNS, email, and downtime honesty
DNS is the internet's address book: the records that tell the world where your email and website live. Most migration downtime is really DNS downtime, and it's controllable.
- Get access to your domain registrar account before migration week. You would be surprised how many businesses discover the domain is registered to a former web guy's personal email. Recovering that access can take weeks, so start now.
- Lower the TTL, the time-to-live setting that controls how long the old address stays cached, to five minutes a day or two before cutover. Then changes take effect in minutes instead of hours.
- For email, plan the mail-record switch for an evening or weekend, and know that mail sent during the switch window is typically queued and retried rather than lost. Tell your team anyway.
Be honest with staff about downtime. Saying email may be interrupted Saturday afternoon costs you nothing. Surprise downtime Monday at 9am costs trust.
Costs and keys
Two business items get skipped in technical checklists.
Costs: price the new world monthly before committing. Microsoft 365 runs roughly 8 to 25 dollars per user per month depending on plan; hosted servers and storage vary widely. Compare against what you spend now, including the electricity, hardware refresh, and hourly fixes the old server quietly eats. Watch for one-time migration labor, typically the largest line, and get it quoted fixed, not open-ended.
Keys: at the end of the migration, the owner of the business must hold admin access to every new account: registrar, cloud console, email admin, backup system, all stored in a password manager you control. Your IT provider should have access too, but a setup where only the vendor can log in is a hostage situation waiting for a billing dispute.
After cutover: verify, then close it out
A migration is not done when the data is moved. It's done when you've verified the business works. Here's the closing sequence:
- Send and receive email from inside and outside the company, including to and from the scanner and the website contact form.
- Open, edit, and save files from a desktop, a laptop, and a phone.
- Run one real business cycle: create an invoice, take a payment, print something.
- Confirm backups are running on the new system and do one test restore.
- Confirm every ex-employee account is disabled and multi-factor authentication is enforced for everyone remaining.
- Write the one-page runbook: what lives where, who has admin, how to reach support. Store it outside the systems it describes.
- After 30 quiet days, decommission the old system deliberately. Wipe it, don't just unplug it.
If you'd rather have someone run this checklist with you, this is standard work for us at HashWhales, and the inventory conversation is the best first phone call.