How to choose a Microsoft 365 migration partner

Every partner you shortlist will say the same nine things: certified, experienced, zero downtime, dedicated team, proven methodology. The words are free, which is why everyone uses them.

Here are the questions that actually separate the people who have done this from the people who have read about it — with the answers you should expect, and the answers that should end the conversation.

1. What is the concurrency limit on mailbox moves, and what does that mean for our headcount?

What a good answer sounds like: a number, followed by arithmetic. Mailbox moves run a limited number at a time — around twenty in practice — so a thousand users is fifty passes through that queue regardless of budget. A partner who has run these will do that multiplication in front of you.

What should worry you: “It depends on bandwidth.” It does not. Volume divided by throughput is the wrong model, and anyone still using it has not hit the ceiling.

2. Can you show me a mailbox size report from a project, and tell me what the top ten rows changed?

Averages hide the problem. A thousand mailboxes averaging 8 GB sounds manageable until four of them turn out to hold 2 TB archives, which will still be running long after the other nine hundred and ninety-six have finished.

Good answer: they ask for your report before quoting, and they can describe a project where the distribution changed the plan.

Bad answer: a price per user with no reference to data at all.

3. Tell me about a project that went wrong, and what you changed afterwards.

This is the single most useful question on the list, and the one most partners handle badly.

Every migration of any size hits something unplanned. A partner with six flawless case studies is either very new or editing heavily. What you want is a specific failure, the mechanism behind it, and the process change that came out of it — because that change is the thing you are actually buying.

Good answer: “Our migration host died mid-project and duplicated mail in live mailboxes. We now size hosts at 120% of mailbox volume and cut mail flow to the source before any re-run.”

Bad answer: “We have never had a project go wrong.”

4. Who is actually doing the work, and are they employed by you?

Plenty of firms sell the engagement and subcontract the delivery. That is not automatically wrong, but you should know before signing rather than discovering it when an unfamiliar name appears in your tenant.

Good answer: named team, employment status stated, and an honest split if different parts are done by different groups.

Bad answer: “our global delivery network”.

5. What will not migrate with full fidelity, and where will we notice?

Teams private chat history has real limits. Version history depends on the workload and the tool. Anonymous sharing links do not transfer at all. Conditional Access policies are not migrated; they are rebuilt.

Good answer: a specific list, per workload, given before you ask.

Bad answer: “everything comes across.” It does not, and finding out during user acceptance testing is expensive.

6. What is the rollback position for each wave?

Not “we have a rollback plan” — what specifically happens if wave three fails on Saturday night. Who decides, by when, and what state is everyone in on Monday morning.

Partners who have been through a bad weekend answer this immediately. Partners who have not describe a process.

7. Which entity will invoice us, in which currency, and what happens to VAT?

Irrelevant if you are one company in one country. Decisive if you are a group.

Microsoft’s Cloud Solution Provider programme is regional: a partner authorised in one region can only sell into that region’s country list. Most resellers can invoice in exactly one country, which is why groups end up with a different reseller, contract and renewal date per entity.

Good answer: the entity, the currency and the VAT treatment, per country, without having to check.

8. What is your first response time, and what is your restoration SLA?

The second half is the interesting part. A large share of Microsoft 365 incidents are resolved on Microsoft’s side, which means a restoration-time SLA is a promise about something the partner does not control.

Good answer: a first-response commitment, and an honest explanation of why there is no restoration number.

Bad answer: a four-hour restoration SLA. Ask what happens when the outage is Microsoft’s. The follow-up is usually more revealing than the original claim.

9. What would make this project take twice as long, and how would we know early?

The best diagnostic question of the nine, because it cannot be answered from a template.

An experienced partner has a short, specific list: personal archives above 100 GB, an unsigned target architecture, a works council approval nobody started in parallel, a third-party application authenticating against the source tenant that nobody owns. And they will tell you which week each one becomes visible.

Bad answer: “it will be fine.”

Three things worth ignoring

The number of certifications. Certifications are held by individuals and say nothing about whether those individuals will be on your project. Ask who is doing the work instead.

“Zero downtime” as a slogan. Everyone claims it. Ask how the cutover weekend is structured and what queues rather than bounces — the answer separates the two groups immediately.

Total user counts. “Ten thousand organisations migrated” tells you the firm is large. It does not tell you whether the people on your project have done anything like yours. Ask for one project at your size and shape.

And one question to ask yourself

Do you actually need a partner, or do you need a tool? And if a partner, which kind — local reseller, global integrator, or one like us? For a straightforward move of under a hundred mailboxes with clean permissions and no compliance constraints, a migration tool and a competent internal admin may genuinely be enough. That question deserves its own answer.

The honest test is not the size of the estate. It is how much of it nobody can currently explain.