Cloud Migration SOW Template: What Every MSP Should Include

Cloud migrations are the high-margin, high-visibility projects every MSP wants. They're also the projects most likely to blow up the client relationship if scoped poorly. An Exchange to Microsoft 365 migration scoped at $8,000 can easily balloon to $15,000+ when coexistence complexity, slow mailbox migration rates, and licensing surprises hit at the same time.

The SOW isn't just a contract protection tool — it's a communication device that sets client expectations before anything goes wrong. Here's how to build one that actually works.

Anatomy of a Cloud Migration SOW

A cloud migration scope document needs more structure than a typical IT project because the failure modes are more varied and the timeline is longer. A well-built SOW has these sections:

Project Overview — The business case: why the client is migrating, what platform they're moving to (Microsoft 365, Google Workspace, Azure, AWS, hybrid), and what the target state looks like. This grounds everything that follows.

Current Environment Assessment — Mailbox count, shared mailboxes, distribution lists, public folders, on-premises server specs, current Active Directory structure, third-party integrations. You can't scope what you haven't inventoried.

Migration Approach — Cutover, staged, or hybrid. Each has different coexistence requirements, user impact profiles, and total hours. Document your choice and the reasoning.

Coexistence Plan — This is the section most SOWs skip. It costs them.

Data Migration Scope — Exactly what is moving, in what phases, at what rates.

Licensing Plan — What the client is buying, who is buying it, what's included vs. not.

Cutover Plan — MX record changes, DNS TTL staging, client profile reconfiguration, user communication plan.

Exclusions — Explicit, comprehensive, numbered.

Assumptions — Everything you're taking for granted about the client's environment.

Acceptance Criteria — How both parties know the project is done.

The Coexistence Phase: Why It's Critical

Coexistence is the period when on-premises infrastructure and cloud infrastructure are running simultaneously and mail (or files, or identities) needs to flow correctly between them. It's not an afterthought — it's often the most technically complex part of the project.

For an Exchange to M365 migration, coexistence typically means:

• Hybrid Configuration Wizard (HCW) — setting up Federation trust, OAuth, and free/busy sharing between on-prem Exchange and Exchange Online
• Mail routing — deciding whether mail routes through on-premises first (classic hybrid) or directly to Exchange Online (modern hybrid), and updating send connectors accordingly
• Directory synchronization — Azure AD Connect running and syncing user objects with the correct UPN before migration begins

A coexistence phase can run 2–6 weeks depending on the client's environment complexity. It requires a Senior Exchange/M365 engineer, and it requires that the on-premises infrastructure stay healthy during the entire migration window.

Scope it as a discrete phase with its own deliverables and sign-off criteria. If you bury it in "migration prep," you'll be doing it for free when the client doesn't understand why the project is taking so long.

Data Migration Math

This is where optimistic proposals kill projects. Clients see "migrate 150 mailboxes" and assume it takes a weekend. The math is more nuanced.

Mailbox migration rates using Microsoft's native migration tools or third-party tools like BitTitan MigrationWiz or Migrate2Tenants typically run at 1–3 GB/hour per mailbox thread. A client with 150 users averaging 10 GB mailboxes is moving 1.5 TB of mailbox data.

At 2 GB/hour per concurrent thread, and running 10 concurrent mailbox migrations, that's 75 hours of migration time — not counting delta syncs, which you'll run for the 48–72 hours pre-cutover. Build that into your timeline.

File migration (OneDrive, SharePoint, file server to SharePoint) runs at 1–4 TB/day with tools like SharePoint Migration Tool (SPMT) or Sharegate, heavily dependent on file count (small files are worse than large files per byte). A 10 TB file share with 2 million files is a multi-week migration, not a weekend job.

Bandwidth is often the real constraint. A client with a 200 Mbps internet circuit has a theoretical max of ~2 TB/day — but real-world utilization, ISP shaping, and Microsoft throttling cut that significantly. Document the client's WAN bandwidth in the current environment section and note it as a variable that affects migration duration.

Licensing Gotchas

Licensing confusion is the single most common source of post-project disputes in cloud migrations. Document it with precision.

Migration tooling licenses — Tools like BitTitan MigrationWiz are per-mailbox or per-GB, charged once for the migration. These are not ongoing costs. Make clear whether they're included in your project fee or passed through separately.

Ongoing subscription licenses — Microsoft 365 Business Basic vs. Business Premium vs. E3 have very different price points and feature sets. Document which SKU you're recommending and why. Confirm who is purchasing — some MSPs manage the tenant and billing; others have the client purchase directly from Microsoft CSP or direct.

Active Directory licensing — If the migration requires Azure AD P1 (for Conditional Access policies) or P2 (for Identity Protection), that's often a surprise line item. Include it in the BOM or call it out as client-procured.

Legacy licensing decommission — When do the on-premises Exchange licenses, CALs, and server software licenses get retired? Who manages that? If the client has an EA or MPSA, there may be implications for true-up timing. Flag it as out of scope if you're not handling licensing optimization.

Common Exclusions for Cloud Migrations

Be explicit. Number them. These are the ones that save you:

1. End-user training — Teaching 150 users how to use Outlook on the web, Teams, or OneDrive is not in scope. That's a separate training engagement or a project for the client's IT trainer.
2. Desktop application reconfiguration — Outlook profile rebuild on each workstation is in scope for a pilot group; mass deployment uses Autopilot or Group Policy, and that configuration effort is its own project.
3. Third-party integrations — Line-of-business applications that authenticate against on-premises Active Directory or relay mail through on-premises Exchange need reconfiguration. Each integration is its own scoped effort.
4. Custom email domain hosting changes — If the client's domain registrar or DNS is managed by a third party, coordination with that party is the client's responsibility.
5. Data archiving and compliance configuration — Exchange Online Archiving, Litigation Hold, or eDiscovery configuration is not part of a standard migration scope.
6. Mobile device management — Configuring Intune policies for BYOD or corporate devices is a separate engagement.

Don't Leave Money on the Table

Cloud migrations are complex enough that a single overlooked line item can wipe out your margin. The exclusions section alone can be the difference between a profitable project and a three-month support nightmare.

ScopeDrafts generates cloud migration scope documents with all of these sections built in — coexistence planning, data migration sizing, licensing documentation, and industry-standard exclusions — tailored to your specific project. Try it free at scopedrafts.com.