Cloud migrations fail from ambition more often than difficulty: everything at once, one heroic weekend, one very bad Monday. The boring alternative works nearly every time: move in order of low-risk-first, let each quiet win buy trust for the next, and let the team acclimate in stages. The order is almost always the same.
First: email
Email is the standard opener for good reasons. The destination is mature (Microsoft 365 or Google Workspace, a decision covered in its own comparison), the migration path is well-worn, and the payoff is immediate and visible: mail on every device, no more server dependence for the one tool everyone uses hourly. Done right, nobody loses a message and most people barely notice the switch. That "barely noticed" is the point. It's your credibility deposit for the phases that will be noticed.
Second: files
Shared drives move to SharePoint, OneDrive, or Google Drive. Technically straightforward; humanly, the biggest change in the whole migration, because twenty years of mapped-drive habits die here. Two rules from the field. Don't lift the folder mess as-is; a migration is the one natural moment to fix structure, since you're touching everything anyway (how we structure SharePoint). And train before cutover, not after: an hour per team on where things live now prevents a month of "I can't find anything" tickets. This phase is also where sync-based backup assumptions need rechecking, because sync is not backup.
Third: the line-of-business apps
Accounting, the industry app, the database behind both. Slowest phase, most variance. Each app gets its own answer, roughly in preference order: the vendor's own cloud edition (often the smoothest, sometimes a downgrade, check feature parity), rehosting the existing app on a cloud VM, or replacement with something cloud-native, which is a project in its own right. Your dependency map and licensing calls decide which apps can move at all and in what clusters. One app at a time, each with its own rollback plan and its own parallel-run window.
Last: the servers themselves
By this point the server is mostly a shell: mail gone, files gone, apps gone. What remains is identity (if a domain controller still runs there), print services, and whatever odd duck the inventory found. Retire what's now redundant, move the stragglers, and only then decommission, per the month-two checklist. Servers go last because everything above depended on them; remove the dependencies first and the scary step becomes an anticlimax, which is exactly what you want a server retirement to be.
The meta-rule
Between every phase: pause, verify, let it settle for a couple of weeks. The calendar cost is small. The alternative, compounding two half-broken phases at once, is where the horror stories come from. A migration should feel almost disappointingly uneventful from the inside. The drama-free version is the one done in the right order.
Want this handled instead of homeworked? That's the job.
Email us →