Billing Clients for Email Migration: MSP Pricing Models

You quote a 200-mailbox migration as a flat $4,000, and three weeks later you've burned 90 engineering hours, eaten the cost of a weekend cutover, and the client is still emailing you about a shared calendar that "looks wrong". Pricing email migrations is where MSPs leak the most margin, because the work looks linear from the outside and is anything but. This post walks through the three pricing models MSPs actually use, when each one fits, and the line items most quotes forget.

The three pricing models, and what each one signals#

Every migration quote you write is some combination of three models. The model you lead with tells the client how you think about risk.

Fixed-fee per mailbox says: I know this work, I have done it many times, you pay me a predictable unit price. It is the cleanest model for clients to approve and the easiest for you to scale.

Hourly time-and-materials says: I do not yet know what we are walking into. You pay for the work as it happens. Clients accept this for discovery but resist it for delivery.

Fixed-fee per project says: I will absorb the unknowns inside a single number. You pay one invoice, I take the variance risk. This is the most common model for SMB projects under 500 mailboxes because it removes the procurement friction.

Most healthy MSP quotes lead with a per-mailbox rate, then layer a per-project floor for jobs under 25 mailboxes, and an explicit T&M section for anything outside the agreed scope.

When fixed-fee per mailbox actually works#

Per-mailbox pricing assumes the unit of work is roughly constant. That is only true when the source and destination are well-understood and the data set is reasonably clean. Use this model when:

• Source and destination are both modern: M365, Google Workspace, hosted Exchange Online, or major IMAP providers.
• No archive ingest. Archives like Mimecast, Barracuda Cloud Archiving Service, or Proofpoint Enterprise Archive double or triple per-mailbox time.
• No journaling rehydration. Pulling journal data back into user mailboxes is its own project.
• The client owns their DNS and is willing to make changes during the cutover window.
• MFA, conditional access, and OAuth consent are either already in place or the client has admin available to enable them on demand.

When those five conditions hold, per-mailbox pricing is honest, and your variance per project drops to something you can budget.

Suggested tiers by source/destination complexity#

You will not get the pricing right without a complexity tier. Treat the tier as the first question on your intake form, not a calculation you do at the end.

Tier 1 — Vanilla M365 to M365 or Google Workspace to M365. Standard mailboxes under 50 GB, no public folders, no PST imports, no journaling. Per-mailbox MSP fee in the $80 to $140 range. Tool license sits on top.

Tier 2 — IMAP source to M365 or Google Workspace. cPanel, Rackspace Classic, GoDaddy IMAP, hosted Zimbra. Per-mailbox MSP fee in the $120 to $200 range, because IMAP is slower per mailbox and folder name conversion adds rework.

Tier 3 — Hybrid Exchange to Exchange Online. On-prem 2016/2019 with hybrid config, public folders, room mailboxes with delegate chains. Per-mailbox MSP fee in the $200 to $350 range. Public folder migration is usually a separate line item entirely.

Tier 4 — Tenant-to-tenant with compliance. Same product, different tenants, plus shared mailboxes, eDiscovery holds, retention policies, Teams chat history. $300 to $500+ per mailbox is normal here, because the engineering hours per mailbox triple.

The tier you quote should match the discovery output. If you cannot get clean discovery data, quote discovery first and the migration second.

Hourly is for discovery, not delivery#

The mistake most new MSP practices make is quoting delivery hourly. Clients hate it because the number is unbounded. You hate it because every billing dispute becomes a debate over engineering minutes.

Use hourly only for two phases:

Discovery. You cannot price a migration without knowing what is in the source. Bill four to eight hours of discovery up front, fixed-fee, before you quote the project. If discovery reveals tier-shifting issues (a forgotten archive, an undisclosed legal hold, public folders), you raise the project quote with evidence.

Post-cutover overflow. Once you have burned the agreed support window, anything beyond goes to T&M at your standard rate. Put the threshold in the SOW. "Support hours included: 16. Hours beyond billed at $185/hr in 30-minute increments." That sentence resolves a year of arguments.

For MSPs who run a structured migration practice, see the end-to-end MSP migration playbook for how discovery, delivery, and support map onto your quoting model. (Use msp-email-migration-playbook as the related slug — leaving the inline link as a placeholder if your CMS resolves it later.)

The hidden costs every quote forgets#

You will lose money on these line items if you do not surface them.

Post-cutover support window#

Plan for one calendar week of elevated ticket volume per cutover. For a 100-mailbox project, that is realistically 8 to 14 hours of engineering and helpdesk time across that week, even on a clean cut. Tickets cluster around:

• Outlook profile re-creation on user laptops you don't manage.
• Mobile device reauth, especially iOS Mail with OAuth.
• Shared mailbox auto-mapping not appearing for delegates.
• Calendar permissions on rooms and resources.
• Send-as / send-on-behalf-of regressions on shared mailboxes.

Bake this into the per-mailbox fee. Do not bill it as a surprise. Clients respect honesty more than they respect a low headline number that grows during delivery.

Comms and change management#

Drafting the user-facing email, the FAQ doc, the day-of timeline, and the IT champion brief takes between 4 and 10 hours per project regardless of size. A 25-mailbox project and a 500-mailbox project both need a comms pack. Add a fixed comms line item of $400 to $900 to your quote. If the client wants to write their own comms, discount it but require approval rights so you are not blindsided by user expectations you did not set.

After-hours and weekend work#

Cutovers happen on Friday evenings, Saturday mornings, and the occasional Sunday. Bill at 1.5x your standard rate, or roll a flat after-hours premium into the per-mailbox fee for cutover work. A clean way to express it: "Weekday cutover included. Saturday cutover +$25/mailbox. Sunday cutover +$40/mailbox."

License management and provisioning#

If you are not licensed as the client's CSP, you may still spend hours assigning destination M365 licenses, removing source licenses post-cutover, and reconciling Azure AD groups. Either own the licensing as part of the deal or add a flat $1,000 to $2,500 license-management line.

DNS, MX, autodiscover, SPF/DKIM/DMARC#

Almost every cutover requires DNS changes. Half the time the client does not control DNS, or the person who does is on holiday. Add a discovery checkpoint that confirms DNS access two weeks before cutover. Bill the time to remediate broken SPF and DMARC records after cutover — broken auth on day two is a 30-minute job that becomes a six-hour day if you are not paid for it.

Training and enablement#

Even technical clients underestimate the number of "where did my email go" tickets. A 30-minute recorded walkthrough of the new webmail, mobile setup, and shared mailbox access is worth more than five hours of helpdesk time per 100 users. Charge a flat $300 to $700 for a custom recording.

How tool licensing should appear on the invoice#

Migration tooling — whether it is a per-mailbox SaaS license or a desktop tool — is a separate procurement category from your labor. Show it as a separate line on the SOW and the invoice.

Two ways to handle it cleanly:

Pass-through at cost. The client procures the license in their own name. You configure and operate it. Cleanest for compliance-heavy clients who want the audit trail in their own tenancy. Lowest margin for you.

MSP-owned with markup. You own the license, you mark up 15 to 25 percent, you eat the renewal risk. Required for white-labelled engagements where the client never sees the underlying tool. For the operational side of that approach, the white-label playbook covers what changes when you remove the vendor's name from everything customer-facing.

For benchmarking what tools actually cost in 2026, the per-mailbox cost guide lists current ranges across BitTitan, CodeTwo, MigrationWiz alternatives, and desktop tooling. And if BitTitan's per-mailbox license is the budget pinch in your quote, the BitTitan alternatives roundup breaks down which competitors target which use cases honestly.

Sample SOW structure clients will sign#

Here is the shape of an MSP migration SOW that wins on clarity rather than price.

1. Scope summary — one paragraph, in plain English. Source, destination, mailbox count, target cutover window, what is in and what is out.
2. Complexity tier — Tier 1/2/3/4, with the one-line description.
3. Per-mailbox fee — the headline number, with a count and a subtotal.
4. Project line items — discovery, comms, training, after-hours premium, license management. Each as its own line with a flat amount.
5. Tooling — separate line, pass-through or MSP-owned, clearly labelled.
6. Support window — duration in days, hour cap, hourly rate beyond.
7. Assumptions and exclusions — short, factual, no jargon. The five things you assume the client will provide (admin access, DNS access, MFA enrolment, user list, cutover date).
8. Change control — one sentence: scope changes outside this SOW go to a written change request before work begins.

That structure cuts your quoting time in half and dramatically reduces billing disputes. Clients sign faster when they can see where the money goes.

What to do when the client pushes back on price#

Three reactions, three correct responses.

"That's a lot more than your competitor." Ask which competitor, and what tier the competitor is quoting. Most cheaper quotes are quoting Tier 1 against a Tier 2 or 3 source. Show your tiering math, including the line items they will get billed mid-project elsewhere.

"Can you discount if we sign today?" A 5 to 10 percent discount in exchange for a signed SOW, a deposit, and an agreed cutover date is a fair trade. A 20 percent discount because the client "feels it's too much" is the start of a project you will lose money on.

"Can we drop the post-cutover support window?" No. Offer to reduce the hour cap if you must, but never remove the window. Day-three issues become breach-of-contract conversations if there is no contract that covers them.

Tracking margin so you can quote the next one better#

You cannot price the next migration accurately if you do not know what the last one really cost. Track per project:

• Total engineering hours, split between discovery, delivery, cutover, and support.
• Tool license cost.
• Out-of-pocket expenses (paid Microsoft tickets, third-party tooling, courier costs for any on-prem work).
• Variance from quoted hours, with a one-line root cause for each instance of >20 percent variance.

Six projects in, you will have a real number for cost per mailbox by tier. Twelve projects in, you can quote confidently without the spreadsheet. For broader cost benchmarks across the industry that you can compare your own data against, see the Office 365 migration cost breakdown which covers total project cost — labor, licenses, comms — for 25, 100, 500, and 2,000-mailbox projects.

A note on retainers and post-project work#

The client you just migrated is the client most likely to need:

• A retention policy review three months after cutover.
• An MFA / conditional access tightening pass at the six-month mark.
• A backup-tool deployment (M365 Backup, Veeam, AvePoint Cloud Backup) inside the first year.
• A Teams or SharePoint migration as a follow-on.

Price the migration so you can afford to be useful in the months after. The MSPs that bill clean migrations and never come back are leaving the bigger revenue on the table. The ones that bill clean migrations and earn a managed-services retainer turn one project into a five-year customer.