Exchange to Microsoft 365 cutover runbook

Inventory what talks to Exchange, not what you bought

Pull the EWS usage report and sort by application ID. The inventory records what was purchased; the usage report records what is actually connecting. The gap between them is where the cutover fails. Name an owner for every caller, including the ones bought by facilities and finance rather than IT.

warningRoom booking panels, digital signage and desk reservation systems authenticate against your tenant and appear on no IT asset list. They are physical objects on walls with no vendor contact recorded.

Build a pilot group that is actually representative

Stop asking for volunteers. Pull the inventory and select against the dimensions that produce different outcomes: Office build and update channel, profile age, PST attachments, device join state, and whether the user normally works on the corporate network.

warningTen volunteers from one team share a laptop model, an OS build and a set of habits. That is one configuration tested ten times.

Run the pilot end to end, including the client side

Move the pilot mailboxes for real and then sit with those users while they open Outlook. The server side reporting success tells you almost nothing about what Monday looks like. This is the last point at which discovering a blocker costs nothing.

Decide the Autodiscover plan and write it down

Autodiscover is an ordered list and stops at the first thing that answers. Decide now what happens to the service connection point in Active Directory, what the autodiscover DNS record will point at, and in what order you will change them.

warningThe SCP does not know the migration happened. Nothing in the migration process removes it, and it will keep answering with a confident wrong answer for as long as it exists.

Brief the service desk on what the new sign-in looks like

Show them the actual new prompt on a screen. Most of Monday's volume is not a fault, it is a changed dialog nobody was warned about, and a service desk that recognises it on sight resolves those calls in under a minute.

Freeze changes

No Office updates, no policy changes, no network work, no unrelated projects touching identity. When something breaks at the weekend you need the list of things that changed to be short enough to read.

Tell users what will change, in their words

One message, three sentences: you will be asked to sign in again, it will look like this, here is who to call. Not an architecture summary. The measure of this message is whether it reduces calls, not whether it is complete.

Stage the repair tooling on the machines that will need it

Put the client repair path in place before the cutover, not after the tickets arrive. If it needs administrator rights it will not get run at the moment it is needed, so it has to work in the user's own context.

Move the mailboxes in batches, largest first

Largest first means the long tail finishes while you still have a weekend. Watch the failed item count rather than the completion percentage: the percentage looks healthy right up until the point it does not.

Cut DNS and retire the service connection point

The mail record is the visible half of this and the half everyone remembers. The half that causes Monday is the SCP in Active Directory, which keeps serving Autodiscover long after the server behind it is gone. Retire it deliberately, as a step, not as cleanup somebody does later.

warningThis is the last step that is cheap to reverse. After the clients start caching answers from the new path, undoing it means touching every machine.

Repair the clients before Monday, not after

Clear cached credentials, sign out the old Office identity, clear the Autodiscover cache, and rebuild the profiles that do not recover on their own. In that order: clearing credentials alone works until the next lookup, and rebuilding a profile alone just makes a fresh profile ask the same stale question.

warningIf the sign-in window never appears at all, no amount of cache clearing helps. That is modern authentication disabled by an old policy key, and it needs checking early because it looks identical from the help desk.

Staff the floor, not the queue

Be physically where the users are for the first two hours. One person standing in the room resolves a changed sign-in prompt faster than any ticket system, and it stops twenty identical tickets being raised before anyone reads the first one.

warningIf two hundred tickets arrive, that is not two hundred problems. Sort by creation time and look for where the rate changes, then look at what the reporters have in common.

Work the long tail deliberately

People on extended leave return to machines that were switched off for the whole migration, with no policy refresh and credentials that expired in a drawer. It is a small population and a guaranteed one. Put it on the plan so it arrives as an expected item rather than a strange escalation three weeks after everyone declared success.