The MSP Email Migration Playbook

Running email migrations as an MSP is a different sport from running one migration for one company. You're juggling overlapping client windows, mixed source providers, varied SLAs, and clients who don't read your project plans. The work that pays is the work you can repeat: a runbook a junior tech can execute, billing that doesn't bleed when a job slips, and tooling that doesn't fall over at 20 mailboxes in parallel. This playbook is how to make that real.

What "MSP scale" actually changes#

A one-off migration tolerates improvisation. An MSP practice does not. When you're running three client migrations in the same week, the bottleneck stops being the migration tool and starts being everything around it: client communication, password resets, MFA handling, after-hours coverage, and the handful of edge cases that always show up on Sunday at 3am.

The shape of the work changes too. Your costs are mostly engineer time, not licences. A tool that's 30% cheaper per mailbox but takes twice as long to troubleshoot is a worse deal. A tool that's twice the per-mailbox cost but lets one engineer run 80 mailboxes overnight is the better deal — assuming it doesn't break.

Three traits separate MSP-grade migration work from one-shot work:

• Repeatability. Every job follows the same runbook. Deviations are documented, not invented on the fly.
• Parallelism. You're rarely running one migration at a time. Tooling and process must support multiple concurrent jobs without conflating their state.
• Defensibility. When something goes wrong (and it will), you need logs, timestamps, and a chain of custody that protects you in the post-mortem.

If your current setup misses any of those three, you're not running a migration practice — you're running migrations one at a time and calling it a practice.

The MSP runbook: what every job should share#

A runbook is not a project plan. A project plan is bespoke to the client. A runbook is the standard sequence every project plan inherits from. Build yours once, then refine it after every job.

Phase 1: Discovery (Day -14 to -7)#

Discovery is where most MSP migrations go wrong before anyone touches a mailbox. You're trying to answer four questions:

1. What's the source environment, exactly? Not "Gmail" — Gmail for Workspace with a specific SSO setup, third-party 2FA, custom labels, and a 12-year-old legacy account that's been forwarding from somewhere weird.
2. What's the destination, including tenant region and licensing?
3. What are the must-keep artefacts? Folders, labels, calendar items, contacts, shared mailboxes, distribution lists, aliases, signatures?
4. What's the cutover constraint? A regulator-mandated date, a fiscal year-end, a payroll cycle?

Use a discovery questionnaire that's the same for every client. The first three clients will surface the gaps in your questionnaire; after that, it stabilises. You want to walk out of discovery knowing the mailbox count within 2%, the total data volume within 10%, and the destination licensing already provisioned.

Phase 2: Pilot (Day -7 to -3)#

Pilot a minimum of three mailboxes per client. Pick:

• A heavy user (large mailbox, many folders).
• A delegated/shared mailbox if any exist.
• An executive or anyone who'll notice every imperfection.

The pilot is not just a test of the tool. It's a test of your runbook on this specific tenant. Pilot results tell you the realistic per-mailbox throughput, expose authentication quirks, and force you to write the client-specific deltas to your standard runbook.

Phase 3: Bulk migration (Day -3 to -1)#

Bulk migration runs in parallel batches. For most providers, you'll batch by 20–40 mailboxes per worker, with multiple workers per tenant. The exact ratio depends on what the source provider tolerates before throttling — see the running parallel mailbox migrations guide for provider-specific numbers.

The work here is mostly monitoring. You're not babysitting individual mailboxes; you're watching the queue, catching auth failures fast, and re-queuing where needed. A good MSP engineer can monitor 80 mailboxes if the tool surfaces failure categories cleanly. A bad tool turns the same workload into a frantic spreadsheet.

Phase 4: Cutover (Day 0)#

Cutover is the smallest phase by duration and the largest by client perception. The actual technical work — DNS flip, MX cutover, final delta sync — should be 30–90 minutes per tenant. The client-facing work around it (comms, support standby, validation calls) is most of the day.

Run a final delta sync after the MX flip, not before. Mail received during the cutover window needs to land in the new tenant once DNS propagates. The delta vs cutover migration comparison covers when each makes sense.

Phase 5: Validation and decommission (Day +1 to +14)#

Two weeks of soft monitoring. You're watching for:

• Users who can't authenticate (often delegation or alias issues).
• Missing folders or items reported by users (compare against your migration report).
• External senders still hitting the old MX (rare after 72 hours; investigate if persistent).
• Mobile client reconfiguration that didn't happen.

Decommission the source only after the validation window closes and the client signs off. Keep your migration logs for at least the retention period agreed in the contract — 90 days minimum.

Tool selection from an MSP perspective#

The tool decision is structural. You're not picking a tool for one job; you're picking the substrate your practice runs on for the next two years. Five criteria matter more than the rest:

1. Concurrency model#

How many mailboxes can the tool run at once before you hit a wall? Some tools are single-threaded per tenant. Others scale linearly with workers but require manual sharding. Cloud-relay tools cap you at whatever the vendor sells you.

For an MSP, you want either unbounded local concurrency (limited by your hardware and the source provider's throttling), or a clearly documented batch size that matches your typical client.

2. Cost model#

Per-mailbox pricing is the most common. Per-GB exists but is usually worse for MSPs because mailbox sizes vary wildly and you can't quote a fixed-fee. Annual seats only work if your migration volume is predictable.

The per-mailbox cost has to leave room for your margin. If you charge clients $40/mailbox and the tool costs you $25, you have $15 to cover engineer time, support, and risk. That's tight. Aim for tool cost under 25% of your billed rate.

3. Local-first vs cloud-relay#

Local-first tools run on a machine you control (yours or the client's). Data flows directly from source provider to destination provider via your workstation. Cloud-relay tools move data through the vendor's infrastructure.

For MSPs, local-first is usually the right call:

• No data residency questions to litigate with the client.
• No vendor outage taking down all your in-flight migrations at once.
• No surprise data egress charges.
• Easier story for regulated clients (see the email migration compliance guide).

The trade-off is that local-first needs hardware and bandwidth. For most MSPs that's a non-issue; you already have it.

4. Reporting and audit#

You need per-mailbox, per-folder, per-item reporting that survives the job. If your tool only shows a green checkmark when the job finishes, you have no defence when a user claims their 2018 emails are missing.

Minimum reporting requirements:

• Source and destination item counts per folder.
• Timestamped log of every authentication attempt.
• Itemised error list with retryable vs permanent classification.
• Exportable as CSV or JSON for client handover.

5. White-labelling#

Whether you need a white-label tool depends on your delivery model. If you deliver fully managed migrations and the client never touches the tool, branding doesn't matter. If clients self-serve any part of it, you want either white-label or a tool whose branding is neutral (no competitor logo in front of your client).

The white-label email migration breakdown covers what to look for, but the short answer: don't pay extra for white-label unless your delivery model actually exposes the tool to clients.

Billing models that survive contact with reality#

Three billing models cover almost every MSP migration engagement. Each has a sweet spot and a failure mode.

Fixed-fee per mailbox#

You quote a per-mailbox price, multiply by mailbox count, add a base project fee, and that's the number. Common rates run $35–$120 per mailbox depending on complexity, source/destination pair, and your market.

Where it works. Standardised jobs. Gmail to Microsoft 365, Microsoft 365 tenant-to-tenant, mid-sized clients (50–500 mailboxes). When your runbook is mature, fixed-fee per mailbox is the highest-margin model because your cost per mailbox keeps dropping while your price stays steady.

Failure mode. Out-of-scope discovery surprises. The client has 80 mailboxes in active use but also 200 shared mailboxes, 40 distribution lists, and a public folder hierarchy nobody mentioned. Fixed-fee turns into fixed-loss fast.

Defence: a tight scope document, a contractual change-request process for anything outside it, and a discovery questionnaire designed to surface those surprises before you quote.

Hourly time-and-materials#

You bill engineering time at your standard rate plus tool licence pass-through.

Where it works. One-off complex migrations. Legacy on-prem Exchange. Hybrid environments. Clients with unusual compliance requirements. Anywhere you genuinely can't predict scope.

Failure mode. Clients hate it. T&M creates an adversarial dynamic where every hour is a question. Some clients will refuse to sign T&M at all.

Defence: a not-to-exceed cap that converts to fixed-fee once you've burned the cap. This gives the client predictability while protecting your margin if scope explodes.

Project-based blended#

A single project fee that covers everything: discovery, pilot, bulk, cutover, two weeks of validation, and a defined number of support hours after.

Where it works. Mid-market and up. Clients who want one number on the invoice. Engagements where you're bundling other work (M365 tenant setup, security baselining, training).

Failure mode. Scope ambiguity, just like fixed-fee per mailbox, but harder to defend because there's no clear unit price to renegotiate from.

The billing clients for email migration breakdown gets into specific rate cards and contract clauses; the email migration cost per mailbox post has market rate ranges by region.

Running multiple clients in parallel#

The hardest part of MSP migration work isn't any individual job. It's keeping four jobs from contaminating each other.

Separate everything#

Each client gets:

• A separate project directory on the migration workstation.
• A separate credential store (don't share OAuth refresh tokens across clients in your password manager).
• Separate logs, separate reports, separate Slack/Teams channel.
• A separate cutover window. Never schedule two cutovers for the same Sunday unless you have two engineers genuinely owning one each.

This sounds obvious. It's not what most MSPs actually do. The shortcut is real and so are the consequences.

Schedule like an air-traffic controller#

Build a rolling 6-week migration calendar with these columns: client, mailbox count, source/destination, pilot date, bulk window, cutover date, lead engineer, on-call backup.

When a client asks for an urgent slot, you look at the calendar, not at your gut. Two cutovers in one weekend means two engineers committed to that weekend, and you say so before you commit.

Communicate on a schedule, not on demand#

Non-technical clients will text you mid-migration to ask if it's done. If you let that drive your day, you're done.

Set a comms cadence per client and stick to it:

• T-14 days. Kickoff email, scope confirmation, discovery questionnaire.
• T-7 days. Pilot report, cutover plan, end-user comms template.
• T-1 day. Final go/no-go, support contact list, what to expect timeline.
• T+0. Cutover started, cutover delta done, cutover complete. Three updates, timestamped.
• T+1 to T+14. Daily summary first three days, then weekly.

The email migration communication plan has templates you can adapt. The point isn't the exact words; it's that your client knows when to expect the next update, so they stop pinging you in between.

Native tools vs third-party: when to pick which#

Both Microsoft and Google ship native migration tooling. They're free, they work, and they have meaningful limits.

When native is fine#

• Single-tenant Microsoft 365 imports from a small IMAP source. The native IMAP migration in Exchange Online handles SMB Gmail-to-M365 jobs reliably for under 50 mailboxes.
• Google Workspace data migration from another Workspace tenant, for small jobs without complex label structures.
• One-off jobs where you'd spend more on a third-party licence than on engineer time fighting the native tool.

When native breaks down#

• Tenant-to-tenant Microsoft 365. The native cross-tenant migration has narrow scope and significant prerequisites. Most MSPs end up reaching for a third-party tool anyway. See the tenant-to-tenant migration guide for what's involved.
• Anything requiring delta sync. Native tools generally do full or none — they're not built for the staged approach an MSP needs over a multi-night cutover.
• Complex source environments: Exchange on-prem with public folders, mixed Google Workspace + consumer Gmail, hosted Exchange providers with non-standard configurations.
• Multi-client batch operations. Native tools are tenant-scoped. Switching tenants every five minutes is how MSP engineers lose their afternoon.

The rule of thumb: use native for jobs that fit cleanly inside its scope, and bring out the third-party tool the moment you start writing workarounds.

Escalation playbook#

Things will fail. The question is how fast you notice, how fast you contain, and how cleanly you communicate.

Tier 1: in-flight failures#

Authentication errors, throttling, individual mailbox failures. Lead engineer handles. Documented in the runbook. Resolution time: minutes to hours.

If you're seeing more than 10% of mailboxes failing in the same way, stop. Don't push through. The pattern is the signal.

Tier 2: tenant-level issues#

Source or destination provider is rate-limiting your entire tenant. Destination licensing isn't provisioned. OAuth app consent has been revoked. Lead engineer + senior on-call. Resolution time: hours.

Pause migration. Communicate to the client within 30 minutes of identification. Resume only after you've isolated the cause.

Tier 3: data integrity concerns#

User reports missing data. Folder counts don't match. Calendar items duplicated. Senior engineer + practice lead. Resolution time: hours to a day.

Pause migration. Preserve all logs. Do not retry without understanding what happened — retrying is often what creates the duplicates that triggered the call.

The email migration troubleshooting hub covers the technical diagnosis side. The escalation side is procedural: who you call, what you stop, and what you tell the client.

When to call the source/destination vendor#

Microsoft and Google both have escalation paths for partners. Use them earlier than you think you should. A 4-hour delay calling Microsoft is a 4-hour delay; you don't get those hours back later.

Call when:

• You're seeing tenant-wide errors you can't reproduce in a different tenant.
• You suspect the issue is on the provider's side (recent service health dashboard event, regional incident).
• You're inside a maintenance window with a hard end and a stuck migration.

Don't call:

• For documented behaviour you don't like.
• For tool-specific errors that don't involve the provider's surface.
• Before you've tried the standard runbook recovery steps.

The MSP-specific runbook checklist#

Before every migration, walk this checklist. The email migration checklist is the general version; this is the MSP overlay:

• Client-specific runbook deltas documented (deviations from your standard).
• Both source and destination admin access tested 72 hours before cutover.
• Discovery numbers reconciled to within 2% (mailbox count) and 10% (data volume).
• Pilot results signed off by client.
• Cutover window confirmed in writing with the client decision-maker.
• On-call backup named and briefed.
• Comms template populated and sent to the client's primary contact for forwarding to end users.
• Migration workstation has confirmed bandwidth and storage headroom (target: 2x expected peak).
• Tool licences provisioned for the full mailbox count plus 15% buffer.
• Rollback plan written (what happens if cutover fails at 2am).

The last one is the one most MSPs skip. Write the rollback before you start, not when you need it.

Building the practice#

The work above scales because of one thing: every migration teaches you something that goes back into the runbook. After the third client, your standard runbook should be at v3 with measurable improvements. After the tenth, it's the substrate of the practice.

The MSPs who run good migration practices treat the runbook as the product. The tools change. The client list changes. The runbook is what you're really selling.