White Label Email Migration: An MSP's Practical Guide

A client asks you for a migration plan and you send a PDF with your logo on the cover and a vendor's logo on every other page. That is the gap white labelling closes. You are the firm being paid, you are the firm answering the support calls at 11pm on cutover night, and the artifacts that touch the client should look like they came from you. This post is the operational checklist for MSPs running white-label email migrations under their own brand.

What white labelling actually means in a migration context#

White labelling a migration is not about concealing your toolchain. Most technical buyers know you use tools, and pretending otherwise damages trust. White labelling is about owning the customer experience end-to-end so the client has one number to call, one brand to trust, and one company to blame if anything goes wrong.

In practice that means:

• The kickoff and discovery materials carry your logo, your colours, your language.
• The user-facing comms are drafted by you, approved by the client, and signed from the client's IT team — never from a third-party vendor.
• The status updates during the migration come from your project channel, in your voice, on your schedule.
• The post-cutover report — successful mailboxes, failed items, recommendations — is written and formatted by you, with your branding.
• Support during the post-cutover window comes from your helpdesk. The client never has a reason to know the vendor's support email exists.

What stays the vendor's: the migration engine, the underlying log files, the per-mailbox throttle behaviour, the auth flows. You configure and operate the tool; the tool does its job. You wrap the human-readable layer around it.

When white labelling is worth the operational overhead#

White labelling adds work. Before you adopt it, be honest about whether your engagement model needs it.

You should white-label when:

• You charge $150+ per mailbox and the client expects a single accountable provider.
• You run more than four migrations a year, so the document templates pay for themselves.
• Your clients are in regulated industries (legal, healthcare, financial services) where vendor disclosure is a compliance question you'd rather not invite.
• You are competing against direct-to-client migration vendors and need to differentiate on accountability.

You probably don't need to white-label when:

• You are running one-off migrations under 25 mailboxes and the relationship is transactional.
• Your clients are technical enough to read the vendor's docs themselves and prefer it that way.
• You are early in the practice and the document overhead would slow your first projects down.

If you are running a structured MSP practice with repeatable engagements, the end-to-end migration playbook covers the operational scaffolding white labelling sits on top of.

The five documents you build once and use forever#

Build these in your design tool of choice (Figma, Canva, Google Slides, Word — whatever your team actually uses). Save them as templates with placeholders for client name, mailbox count, source, destination, dates.

1. Branded kickoff and discovery deck#

10 to 14 slides. Cover, agenda, scope, source environment, destination, mailbox tier breakdown, cutover plan, risks, timeline, RACI, communication plan, support window, contacts.

The whole point is that the client sees one accountable team. Do not name the migration vendor on any slide. Reference "the migration platform" generically when you must explain throttling or limits. Most engineering specifics belong in your internal runbook, not in the client deck.

2. User-facing FAQ (one page, two columns)#

Six to ten Q&As written for the user, not the admin. Examples:

• "When do I need to take action?"
• "What happens to email I receive during the cutover?"
• "Will my mobile device need to be reconfigured?"
• "Will my calendar invites still work?"
• "Who do I contact if something looks wrong on Monday?"

Sign it from the client's IT team or the named IT champion. Never sign it from your MSP and never from the vendor. Users trust their own employer's voice more than anyone else's.

3. Cutover-week comms pack — three pre-written emails#

• T-7 days. "Here is what is changing and when. You do not need to do anything yet."
• T-1 day. "Here is what is happening tonight, what to expect tomorrow morning, and where to get help."
• T+1 day. "The cutover is complete. Here is how to verify your email is working, and what to do if it isn't."

Each email under 200 words. Plain text or simple HTML. Sent from the client's IT mailbox, not yours.

4. Live status report template#

A one-page running status doc, updated daily during the migration. Fields:

• Date and time of update.
• Mailboxes complete / in flight / pending.
• Total data migrated (rounded GB).
• Failed items in the last 24 hours (with a plain-English reason for each).
• Risks for the next 24 hours.
• Decisions needed from the client today.

Most clients do not need a live dashboard. They need a daily one-pager they can forward to their CFO without explanation. Build the one-pager.

5. Post-cutover summary report#

Three to five pages, delivered seven to ten days after cutover. Sections:

• Executive summary. Three bullets a non-technical executive can read.
• What we migrated. Mailboxes, calendars, contacts, shared folders, public folders, archives. Counts and data volumes.
• What didn't migrate, and why. Failed items, with categories: source corruption, destination throttling, intentional exclusions, items still in flight.
• Recommendations. Three to five concrete next steps. Almost always includes MFA tightening, backup deployment, and a retention-policy review.
• Support window. Hours used, hours remaining, ticket categories closed.

This is the document the client remembers you by. It is what drives renewals, references, and follow-on work. Spend an hour on it.

How to brief the migration tool vendor#

Most vendors will accommodate white labelling within reasonable limits. Before your first project, get clarity on:

• Email sender domain. Can system-generated notifications come from your domain instead of theirs? Or are they suppressible entirely so you re-send through your own systems?
• Report exports. Can CSV / PDF exports come out without their logo, footer, or "Powered by" wording?
• Support escalation. Who is your dedicated support contact? Will they communicate with the client directly under any circumstance?
• Reseller agreement. Is there a formal reseller program, and does it include the right to rebrand outputs?
• Audit logs. Does the client retain the right to request raw audit logs? (For compliance clients, yes.)

The BitTitan alternatives comparison gets into which vendors are friendly to MSP reseller models, and which are not. As a rule, the vendors with strong MSP partner programs handle this well; the ones that mostly sell direct will resist anything that looks like a rebrand.

Operational changes white labelling forces#

Beyond document templates, white labelling changes how you run the engagement.

Support routing#

The client should have a single support email — yours. Set up:

• A dedicated alias per client engagement (e.g. acme-migration@yourmsp.com).
• A ticket queue tagged with the project name.
• A first-response SLA of 1 business hour during the cutover week, 4 business hours otherwise.
• An on-call rota for cutover night and the following Monday morning.

The vendor support relationship runs in the background. You raise vendor tickets, you chase vendor responses, you translate them into client-readable updates.

Status communication cadence#

Daily during the cutover week. Twice-weekly during the discovery and provisioning phases. One closing report at the end. Pick a channel — usually email + Slack/Teams shared channel — and stick to it.

Internal naming#

Use internal project codes that match the client name, not the vendor's tooling name. "Acme M365 Migration" not "Acme MigrationWiz Run." It sounds minor; it matters when someone screenshots a Jira board into a client thread by accident.

Branded URLs where possible#

If you operate a status page or a self-service portal, host it on a subdomain of your own domain. migration-status.yourmsp.com not clients.somevendor.com/yourmsp/. Most vendors with serious MSP programs support this.

Pricing implications#

White labelling sits on top of your normal MSP pricing — it does not replace it. For the underlying pricing model and per-mailbox tier structure, the MSP billing models guide lays out fixed-fee, hourly, and project pricing in detail.

Two specific adjustments for white-label work:

Tool licensing. Some vendors charge a 10 to 25 percent uplift for full white-label / unbranded output. Build this into the tooling line item.

Document production. First white-label engagement absorbs the cost of building all five templates — 8 to 16 hours of work. Amortise that across your projected next 6 to 10 engagements. Don't try to recover it on a single client.

Your headline per-mailbox fee can rise 10 to 20 percent on white-label engagements without resistance, because the client is buying single-throat-to-choke accountability. That is the actual margin lift.

The trust line you should not cross#

White labelling is about owning the customer experience, not about hiding the truth of how you operate. There are three things you should never do, even when a vendor will technically allow it:

1. Make security or compliance claims about the tool that the tool doesn't actually support. If the tool isn't SOC 2 Type II, you don't say it is. If it stores migration metadata in a region the client cares about, surface that.
2. Conceal sub-processor relationships from a client with a data-processing addendum. Regulated clients will and should ask for the list of sub-processors. Hand it over.
3. Sign the user-facing email as the vendor. Even on a white-label engagement, the user-facing comms come from the client's IT team. You sign internal runbooks and project documents in your name. You never sign as the vendor and you never let the client sign as the vendor.

If you stay on the right side of those lines, white labelling is a trust-builder, not a trust-cost.

Choosing tooling that supports white labelling well#

The honest list of what to look for:

• A vendor that explicitly markets to MSPs, not just enterprise IT departments.
• A partner portal with a sandbox tenant for testing branding.
• Unbranded or rebranded CSV and PDF exports.
• Configurable email sender names and reply-to addresses.
• A reseller pricing tier that is not punitive on small projects.
• Support engineers who will join a client call on your behalf when needed, but not unless you ask.

The MSP tooling roundup compares the major migration platforms on these dimensions and is the right starting point if you're picking a vendor for the first time. For parallel-mailbox throughput questions — which matter more on bigger white-label engagements where slow batches mean longer cutover weekends — the parallel migration guide covers what the major vendors actually deliver vs market.

Building the practice over your first ten engagements#

Engagement one will feel slow. You will draft the templates, you will mis-route a support ticket, you will discover the vendor's PDF export still has a "powered by" line and you will spend an evening figuring out how to suppress it.

By engagement five you have the templates dialled. The kickoff deck takes 20 minutes to customize. The post-cutover report takes an hour. The comms pack is two sed-and-replace operations away from ready.

By engagement ten, white labelling is invisible to you and invaluable to clients. They refer you to other clients because they trust the experience, not because they thought the slides were pretty. That is the long compound: clients refer accountable providers; they do not refer reseller arrangements.