Companies move to Microsoft 365 for one of three reasons. Their mail server is aging and nobody wants to maintain it. Their file server is outgrowing the office. Or a customer, an audit, or insurance is pushing them toward the security model cloud providers ship as standard. Whatever the reason, the fear is the same: the migration week. This article is the roadmap that makes that week boring, because a boring migration is a successful one.
01 Before the move
Inventory everything you actually have
The migration fails on things nobody wrote down. Before a single mailbox moves, build the inventory, and it is a short list when you are honest about it: every email domain you send and receive on, every mailbox and shared mailbox, every distribution group, every alias, and the DNS provider that holds the records for each domain. Alongside that, the file side: which folders and drives your people actually use, which are dead, and which contain things that must not be lost.
Two inventory decisions save most of the pain later. Clean first, migrate second: delete or archive what is dead before you pay to carry it over. And decide the retention rule now, because one of the first questions after cutover will be "where did the old stuff go?" The answer should already be written down.
02 The plan
A staged cutover, not a big bang
The reliable pattern is staging, moving a small group first, learning from it, then widening. A pilot group of a few people who are tolerant of imperfection migrates first. Their experience shows the migration team where the plan breaks, usually mail-flow edge cases, calendar invites from the old system, or a file path people had in muscle memory. Only when the pilot is clean does the rest of the company follow in waves.
The alternative, a single-night cutover for everyone, takes one assumption too many: that everything was inventoried correctly and nothing will surprise you. It rarely survives contact with a real organization. The staged approach costs a little calendar time and buys a lot of certainty, and the wave cadence gives a natural checkpoint to pause if a wave reveals something.
03 Day one settings
Security defaults you set before anyone logs in
Microsoft 365 is only secure if the defaults are set deliberately, because the out-of-box configuration is not protective enough on its own. The list is short and not optional: multi-factor authentication enforced for every account, including service and admin accounts; conditional access policies that block sign-ins from impossible locations; admin accounts separated from normal daily accounts; and monitoring turned on for sign-ins and admin activity.
This is also the point where a migration and a security project meet. If you are moving anyway, you buy the security once instead of retrofitting it, and it costs almost nothing extra at this stage. The companies that skip it rebuild it six months later with an incident as the catalyst.
04 Cutover week
DNS, mail flow, and the day the address changes
Cutover week is the one that worries people, and it is mostly DNS. Mail flows to the address published in the domain's MX records, so pointing mail at Microsoft happens at the DNS provider, and the timing is everything: the record change must wait until the new mailboxes are ready and tested, because the moment mail starts arriving in the new system, both systems need to be able to handle the flow.
During the transition, both sides run in coexistence. Mail still landing in the old system can be forwarded or pulled over by the migration tooling, which most providers use to sync remaining mail without anyone noticing. The discipline of the week is not the technical work but the communication: everyone knows what changes when, what is being copied over, and what they should check first, because a user who is told up front is patient, and one who is surprised is not.
05 The month after
Stabilizing, backing up, and proving it works
Migration is done when nothing is still arriving in the old system and the new system has survived a month of real traffic. In that window: spam and phishing rates visibly settle, legacy shortcuts get replaced, and a few genuinely missing items surface, which is why retention was decided in advance. This is the month to retrain on the obvious: how to report a suspicious email, and how the new backup actually restores.
On backups, one point deserves its own paragraph. The built-in cloud services protect against a deleted file or a mailbox issue, but they do not protect against a compromise that deletes broadly, which is what ransomware looks like. A proper backup product for Microsoft 365, one that holds a separate copy and is tested by a real restore, is part of this project, not an optional add-on. If the backup has never been restored, it does not count as a backup.
06 The honest part
What the migration is really worth
The licensing is simple and predictable. The real cost, and the real value, is the work that happens before and after the technical cutover: the inventory, the cleanup, the security configuration, the coexistence handling, the training, and the month of stabilization. That is why the honest way to price a migration is the same as the honest way to price everything else we do: scope it after looking at the environment, quote a fixed price, and let the calendar be the variable.
We have taken companies through this pattern, from aging on-premises mail to Microsoft 365, and the work page shows the kind of systems we migrate. When the migration ends, the environment usually stays with us under managed IT, because the settings that made cutover secure are the same ones that need watching every month after.
