Microsoft 365 migration: how such a project actually runs
Moving to Microsoft 365 sounds simpler on paper than it is. What happens from preparation to cutover, what your staff notice, and where a do-it-yourself migration comes unstuck.
Moving to Microsoft 365, or migrating from one tenant to another, often sounds simpler on paper than it turns out to be. Below is how such a project runs, what staff notice, and where it usually goes wrong when a company attempts it alone.
Inventory and preparation
Before anything moves, we map out everything involved: how many mailboxes, how much data in OneDrive and SharePoint, which shared mailboxes and groups exist, which applications are tied to Microsoft 365, such as an accounting package or CRM using single sign-on, and which domain names and DNS settings belong to it. This is the least visible part of the project, and usually the part that takes the most time.
Setting up the new environment
The target environment is prepared: licences, security policies, groups and access rights, mail flow rules, and where needed device management through Intune. All of this happens entirely separately from day-to-day operations. Staff notice nothing yet.
The migration in the background
This is normally the longest part of the project, and the part people most often misjudge. Rather than moving everything at once, data (mailboxes, calendars, contacts, files) is copied in the background while the old environment stays in use.
After that come one or more delta synchronisations, transferring only the changes from the intervening period. The new environment stays increasingly current, without anything changing yet for the user.
The cutover weekend
At an agreed moment, usually a weekend, the final switch takes place: a last delta synchronisation, repointing the DNS records to the new environment, and moving the users themselves across. Because most of the work has already happened in the background, this window stays relatively short.
Follow-up after the switch
In the first days we keep a close watch on whether mail arrives correctly, whether connected applications keep working, and whether everyone can reach their files and mailbox. Small loose ends are part of it and are usually resolved within a few days.
What your staff notice
In a well-prepared project: surprisingly little, until the cutover weekend itself. The preparation and the data transfer deliberately happen out of sight, precisely so the working day is not disrupted.
Around the switch they usually do notice something: signing in again on their device, possibly a short period where Outlook or Teams has to set itself up again, and sometimes a brief interruption to mail while the DNS changes propagate worldwide. That last part usually takes a few hours, exceptionally up to a day.
After that they mostly notice that everything looks roughly the same, with the same mail, calendars and files as before. That is exactly the point: a move with as little impact on the working day as possible.
What goes wrong in a do-it-yourself migration
Trying to move everything at once. Without the intermediate step of delta synchronisations, the entire transfer gets squeezed into the weekend itself. With little data that sometimes works; with larger volumes the weekend overruns, leaving mailboxes not fully synchronised on Monday morning.
Making DNS changes too late or incompletely. It gets forgotten that those changes need time to propagate everywhere, or one record is updated while others are left behind. The result is mail arriving temporarily in the wrong place, or not at all.
Overlooking connected applications. A CRM or accounting package that signs in through Microsoft 365 is often missed during preparation. After the switch it turns out people can no longer log in to something they use every day.
No fallback plan. If something goes seriously wrong during the cutover weekend, speed matters. Without a rollback scenario worked out in advance, valuable time is lost at exactly the wrong moment.
Underestimating rights and groups. Shared mailboxes, distribution groups, shared calendars and file permissions in SharePoint or OneDrive are sometimes only noticed afterwards. For users that means suddenly losing access to something they worked with daily, which does no favours to confidence in the new environment.
Expect roughly one weekend of genuine disruption. Everything else happens in the background while you carry on working.
Unsure about an upcoming migration, or already running into trouble on one you started yourself? Get in touch. A conversation costs nothing, and correcting course early usually saves a lot of frustration later.