How to Build an Email Migration Project Plan That Holds Up

An email migration is not primarily a technical project. The data movement is the easy part. The hard part is coordinating fifty people who do not normally work together — IT, security, finance, HR, an outside MSP, sometimes a regulator — around a single switchover date that nobody can move. This post walks through the project-management spine of a migration: milestones, ownership, communication, budget, and risk. The technical detail lives in the email migration checklist; this is the wrapper around it.

Why migrations need a real project plan#

Small migrations get away with a Google Doc and good intentions. Once you cross about 50 mailboxes, or once you touch two business units, or once a regulator cares about the outcome, "good intentions" stops working.

The failure mode is predictable. A migration starts as an IT side project. The cutover date gets picked by IT in isolation. Finance discovers two weeks before cutover that the date overlaps quarter-end. The cutover slips. The slip exposes that nobody owns the shared mailbox remap. That stretches another week. Now the marketing campaign that was timed to "after migration" is also delayed, and someone has to explain it to the CEO.

A project plan is not bureaucracy. It is the document that prevents this exact chain of events.

The milestone map#

A migration project has roughly seven milestones. Hit them in order, do not skip.

1. Kickoff. Sponsor identified, scope written, budget approved.
2. Discovery complete. Inventory locked, dependencies known, integrations mapped.
3. Design signoff. Approach (cutover/staged/hybrid), tool selection, batch plan, rollback plan all agreed.
4. Pilot complete. A representative subset migrated, validated, and signed off.
5. Pre-stage complete. Bulk data copied to destination. Deltas running.
6. Cutover complete. MX switched, final delta done, destination is the system of record.
7. Validation and closeout. Counts reconciled, integrations verified, source decommissioned, post-mortem written.

Each milestone has an explicit owner, a definition-of-done, and a go/no-go gate. If you cannot answer "did we hit milestone 2", you do not start milestone 3.

Mapping milestones to a Gantt#

Lay these on a Gantt with realistic spacing. For a 200-mailbox project:

• Week 1: Kickoff and discovery start
• Weeks 2–3: Discovery complete, design begins
• Week 4: Design signoff, pilot prep
• Week 5: Pilot runs
• Weeks 6–7: Pilot validation, production scheduling
• Week 8: Pre-stage starts
• Week 9: Delta syncs, cutover prep
• Week 10: Cutover weekend
• Weeks 11–12: Validation, closeout

You will compress this for smaller projects and extend it for larger ones. The shape stays the same; only the duration of each phase scales. See the migration timeline post for sizing by org headcount.

Stakeholder mapping#

Before you can build a RACI, you have to know who is involved. The typical email migration stakeholders are wider than IT teams initially assume.

Sponsor. The executive who signed off the project and absorbs the political cost if it fails. Often the CIO, sometimes the COO. They do not need detail; they need to know status and red flags.

IT operations lead. The person whose team will actually move data. Owns technical execution.

Information security. Reviews the migration tool's data handling, OAuth permissions, and audit logging. May require a sign-off before the tool touches production data.

Compliance/legal. If the data is regulated (HIPAA, GDPR, FINRA), legal needs to know where the data sits during transit and at rest. Some tools that pass data through a cloud broker are problematic for certain regulators.

HR. Owns the user-facing impact. Knows about pending departures who should not be migrated and new hires who need accounts on the destination.

Finance. Owns budget and may have month-end close dates that constrain cutover timing.

Department heads. Each major business unit has habits and workflows. Marketing depends on bulk-send tools. Sales depends on CRM email integration. Customer support depends on shared mailboxes with response-time SLAs.

External vendors. The MSP doing the work, the migration tool vendor, the DNS provider, anyone whose system sends mail from the domain.

End users. Will absorb the most direct impact and have the loudest voice if things go wrong.

The RACI matrix#

A RACI assigns each task to four roles: Responsible (does the work), Accountable (single owner, sign-off), Consulted (gives input), Informed (kept in the loop).

For an email migration the matrix usually looks something like this:

Task	R	A	C	I
Discovery inventory	IT ops	IT lead	HR, dept heads	Sponsor
Tool selection	IT ops	IT lead	Security, MSP	Sponsor, Finance
Security review	InfoSec	CISO	IT ops	Sponsor
Pilot user selection	Dept heads	HR	IT ops	Sponsor
Pilot execution	IT ops	IT lead	Pilot users	Sponsor
User communication	Comms team	HR	IT ops	All
DNS changes	IT ops	IT lead	Security	Sponsor
Cutover execution	IT ops	IT lead	MSP	Sponsor, dept heads
Validation	IT ops	IT lead	Dept heads	Sponsor
Source decommission	IT ops	IT lead	InfoSec, Legal	Sponsor

Each task should have exactly one A. If two people are Accountable, neither is. The classic failure is shared mailbox permissions where IT thinks HR owns the access list and HR thinks IT owns it; both believe someone else has it and nobody does until cutover day.

Communication plan#

Migrations fail in user experience even when the data moves correctly. The fix is over-communication. The communication plan post has templates; here is the cadence.

T-4 weeks: kickoff announcement. From the sponsor. What is happening, why, what users need to do. Set expectations early.

T-2 weeks: details. From IT. Specific dates and times. What to expect. Where to get help. Whether to expect downtime.

T-1 week: reminder. Short. Cutover is this weekend. Here is the link to instructions.

T-1 day: final reminder. Today/tomorrow. What to do if mail is broken Sunday morning.

T-0: live notice. "Migration is complete. Here is how to log into the new system. Here is how to get help."

T+1 day: follow-up. "We are seeing some users with X issue. Here is the workaround."

T+1 week: closeout. "Migration is fully complete. Source system will be decommissioned on date Y."

Each message goes through the same review (HR, Comms, IT) before sending. Inconsistent messaging confuses users; consistent messaging absorbs concern.

Budget line items#

Migration budgets are usually too low because they are quoted on tool cost alone. The full budget has at least seven lines.

Tool licences. Per-mailbox or annual subscription. Usually 15–30% of total cost.

Internal engineering time. Hours x rate. Often the largest single line. Include the cutover weekend explicitly.

External MSP or consultant fees. If you are using one. Cutover support is usually billed separately from project work.

End-user support cost. Helpdesk volume spikes for 1–2 weeks post-cutover. Budget temporary capacity, not just regular staffing.

Training and documentation. New system means new shortcuts, new mobile setup, new search behaviour. Budget time to produce materials.

Contingency. 15–20% on top. Migrations find surprises; budget for them rather than absorbing them.

Post-cutover monitoring. Mail flow monitoring, SPF/DKIM check tools, sometimes deliverability consulting if you are moving domains.

Put these in a single sheet, signed by Finance. The post-cutover blame game over "who approved this overrun" is avoidable with a signed budget.

Risk register#

Every migration project should maintain a risk register. Five rows minimum, ranked by probability x impact.

Cutover slip. Most likely risk. Mitigation: pre-stage early, have rollback ready, communicate the possibility upfront.

Data loss in transit. Low probability with good tooling, high impact. Mitigation: pilot rigorously, keep source live for 2 weeks post-cutover, validate counts before decommissioning.

Authentication failure. Specifically OAuth tokens expiring mid-batch, app passwords being revoked, MFA challenges blocking the tool. Mitigation: use service accounts where possible, refresh tokens before cutover, test auth in pilot.

Throttling and bandwidth. Source provider rate-limits the migration tool or destination accepts data too slowly. Mitigation: test throughput in pilot, batch sizes calibrated, schedule for off-hours.

Shared mailbox and group breakage. Highest "trailing issue" risk. Mitigation: explicit ownership of permission remap, pilot a shared mailbox specifically, validate access immediately post-cutover.

Integration failure. Third-party systems that send via SMTP relay or read via IMAP break when credentials change. Mitigation: inventory integrations in discovery, update credentials in advance where possible, day-one tasklist for the rest.

Key personnel unavailable. The cutover engineer gets sick. Mitigation: pair on every cutover, document the runbook in detail, have a fallback engineer briefed.

Review the risk register at each weekly status. Risks that materialise become issues; new risks get added as you learn. A risk register that never changes is not being read.

When the project is an M&A migration#

Merger and acquisition timelines are different. The cutover date is often dictated by the deal close, not by IT. Discovery has to happen alongside legal due diligence. Communication is constrained by what employees can be told and when.

The M&A migration post covers this case specifically, including the awkward problem of running parallel mailboxes during the legal handover period.

Project tooling#

You do not need expensive PM software for a 200-mailbox migration. A spreadsheet with milestones, RACI, and risk register works. For larger projects, anything that gives you Gantt visualisation and dependency tracking — Smartsheet, Asana, monday.com, Jira's roadmap view — is fine. The tool is less important than the discipline of updating it weekly.

What does help: a shared status page (one URL) where every stakeholder can see current state, next milestone, recent risks. Email-based status updates get lost. A page that updates in place stays usable.

Tying it back to the technical work#

Once the project plan is in place, the technical execution lives in the email migration checklist. The checklist is what your migration engineer ticks off on cutover weekend. The project plan is what your sponsor reviews on Wednesday afternoons. They are different artifacts, both required.

The complete email migration guide covers how the two fit together end-to-end, plus the pillar-level technical decisions (cutover vs staged, tool selection, validation depth) that flow into both documents.

A note on velocity#

A common mistake on first migrations is to plan everything in detail before starting anything. By the time the plan is "complete", discovery is stale.

The better pattern: write the plan in two passes. The first pass is rough — milestones, owners, dates — and gets you started. The second pass, after pilot, is detailed. By then you know the throughput, the auth quirks, and the team's capacity. Detailed planning before pilot is fiction; detailed planning after pilot is reliable.

FAQ#