Email Migration Communication Plan: Templates, Timing, Scripts

Most failed email migrations are not technical failures. They are communication failures. The mail moved fine; users did not know it was happening, so they kept sending from the old account, kept clicking the wrong shortcut, and kept ringing the help desk at 09:00 Monday morning. A migration communication plan fixes that. This guide gives you the timing, the templates, the channels, and the help-desk script you need so the people you serve treat the cutover as a planned event, not an outage.

Why a written communication plan beats ad-hoc updates#

If you have ever run a migration where "we just told everyone in the all-hands", you already know the answer. Three things go wrong without a written plan.

First, message drift. The status someone hears at the kitchen table on Tuesday is not the status the help desk sees on Thursday. By Friday, half the company is convinced the migration is cancelled.

Second, channel mismatch. You send the announcement by email, but the executive who needs to approve the cutover window is on holiday and reads Slack from her phone. Your important note sits unread in a mailbox you are about to migrate.

Third, ticket spike. Without a clear "what changes for you" message, every minor confusion lands in the queue. You spend the day after cutover explaining the new IMAP host name instead of fixing the three legitimate issues that need your attention.

A written plan with fixed send dates, named owners, and approved templates removes all three problems. It also gives you something to point at when leadership asks why the migration "went so smoothly".

The six-touch schedule#

Six scheduled communications cover the full migration arc. Each one has a single job. Resist the urge to combine them — combined messages get skimmed, and the important sentence gets lost.

Touchpoint	When	Channel	Job
T-30	30 days before cutover	Email + intranet post	Announce, set expectations
T-14	2 weeks before	Email + Slack/Teams	Remind, request mailbox cleanup
T-1	The day before	Email + Slack/Teams	Final timing, what to do tonight
Day-of	Cutover day	Slack/Teams + status page	Live updates, ETA
T+1	Day after	Email	"You are live", what changed
T+7	One week after	Email	Reminder, common gotchas, survey

The same schedule works for a 50-mailbox cutover or a 5,000-mailbox staged migration. For longer migrations, repeat T-1 and day-of for each wave.

For the planning side of this — wave sizing, runbook ownership, change control — see the email migration project plan and the email migration checklist so the comms calendar lines up with the technical one.

T-30: the announcement#

The T-30 email has one purpose: tell users a migration is coming and what it means for them in plain language. It is not a runbook. It is not a sales pitch for the new platform.

Sample T-30 email#

Subject: We are moving company email to [New Platform] on [Date]

Hi [Name],

On [Date] at [Time], we will move your company mailbox from [Old Platform] to [New Platform]. You do not need to do anything before that date. Your address ([user@company.com]) stays the same.

Here is what to expect:

• From [Date] at [Time] until [Time], you may not be able to send or receive mail. Plan around this window.
• Your existing mail, folders, and calendar will move automatically.
• On [Date+1], you will receive setup instructions for [Desktop client], [Mobile], and [Webmail].

If you have a shared mailbox, a delegated calendar, or a mail-enabled meeting room, you will hear from us separately about your specific cutover.

Questions: reply to this email or message #email-migration on Slack.

Thanks, [Name], IT

That is 130 words. It is intentionally short. Long emails do not get read; short emails set expectations.

What to do in your intranet post#

Mirror the email on your intranet or wiki and add a FAQ. Users who miss the email will search for "new email" or "migration date" and you want them to land somewhere accurate. Pin the post for the duration of the migration.

T-14: the cleanup nudge#

Two weeks out, send a focused nudge that asks users to do three things that materially reduce migration risk: empty deleted items, archive or delete anything older than your retention policy, and check that shared mailbox owners know who actually uses what they own.

Sample T-14 email#

Subject: Two weeks until your mailbox moves — please do 3 things

Your mailbox moves on [Date]. Before then, please:

1. Empty your Deleted Items folder. We do not need to copy 6GB of trash.
2. Move anything older than [X years] to your personal archive, or delete it if you do not need it.
3. If you own a shared mailbox or distribution list, reply to this thread and confirm who still needs access.

These steps shorten the migration window and reduce the chance that mail ends up in the wrong place.

Help: #email-migration on Slack, or reply here.

If you skip the T-14 cleanup nudge, expect a 10–25% jump in your total transfer payload from mail that nobody needs. That payload costs you migration time and, on metered providers, money.

T-1: the final timing email#

The T-1 email is the most important one in the sequence. It is the message users will quote back to you when something is unclear. Make it specific and make it boring.

Sample T-1 email#

Subject: Tomorrow: your mailbox moves at [Time] [Timezone]

Tomorrow, [Day Date], we move your mailbox from [Old Platform] to [New Platform].

Tonight, before you leave:

• Sign out of email on your phone. We will send setup steps in the morning.
• Close your desktop email client.
• Do not forward your mail to a personal account during the cutover. It will not be migrated.

Tomorrow, between [Start Time] and [End Time]:

• You may see "password incorrect" or "connection failed" errors. That is expected.
• Wait for our "You are live" email before reopening any email app.

If you have an urgent inbound message during the cutover window, it will queue and deliver afterwards. Nothing will be lost.

Status updates: #email-migration on Slack. Live status page: [URL].

Help desk: [phone], [email].

Send the T-1 between 15:00 and 17:00 local time. Earlier and people forget; later and people have already left.

Day-of: the live update channel#

On cutover day, the email channel is broken by design. Use Slack or Teams as the primary update channel, with a status page as the backup for anyone outside the messaging platform.

What to post and when#

• 30 minutes before start: "Starting migration at [Time]. You will see send/receive failures until we post the all-clear."
• At start: "Migration started. ETA [Time]. Status: [URL]."
• At 25% / 50% / 75%: Progress checkpoints with a fresh ETA. Even if the ETA has not changed, post it. Silence makes people anxious.
• If something slips: Acknowledge inside 10 minutes. Give a new ETA. Do not promise a recovery time you cannot hit.
• At completion: "Migration complete. Setup steps coming by email in the next 15 minutes. Help desk is open."

For the technical sequencing behind these update timestamps — when each wave starts, when DNS flips, when the freeze window ends — pair this comms plan with your email migration timeline.

T+1: the "you are live" email#

The T+1 email triggers as soon as a user's mailbox finishes its post-migration validation. Do not send it from a script the moment the mailbox copy completes. Send it after you have done at least a basic check that the user can actually sign in.

Sample T+1 email#

Subject: Your new mailbox is ready — set up in 5 minutes

Your mailbox has moved to [New Platform]. Sign-in works now.

Set up in this order:

1. Webmail first: [URL]. Sign in with your normal company password. Confirm you can see your recent mail.
2. Mobile next: delete the old mail account, then add a new one using [autodiscover URL or manual server settings].
3. Desktop last: [link to platform-specific setup page].

Common questions:

• "Where are my filters?" Filters/rules do not transfer between platforms. Recreate them in webmail under Settings.
• "Where is my signature?" Signatures are stored locally. Recreate in your client.
• "I cannot see a folder I had before." Check that the folder is expanded in the left pane. If still missing, raise a ticket with the folder name.

Help: [phone], [email], #email-migration on Slack.

Notice this email does most of the help-desk's job before the help desk opens. Each line you write here is a ticket you do not get.

The folder question links naturally to the post-migration validation work, which is where you catch missing folders before users notice.

T+7: the wrap-up and survey#

Seven days after a user goes live, send a short follow-up. The purpose is twofold: catch lingering issues that users have not bothered to report, and capture a satisfaction score while the experience is fresh.

Sample T+7 email#

Subject: One week in — anything still broken?

You have been on [New Platform] for a week. A quick check:

• Are you receiving all the mail you expect, from the senders you expect?
• Do your calendar invites work both inbound and outbound?
• Is your mobile pushing new mail within a few minutes?

If any of those is "no", reply to this email and we will fix it.

Two questions for our records:

• How would you rate the migration overall (1–5)?
• What would you change next time?

Thank you.

Keep the survey to two questions. Three or more and your response rate halves.

Slack and Teams announcements#

Email is your record-of-truth channel. Slack or Teams is your awareness channel. Use both.

The dedicated channel#

Create #email-migration (or the Teams equivalent) at T-30. Pin a single message that contains:

• The cutover date and time
• A link to the intranet FAQ
• A link to the live status page
• Help desk contact details

Lock the channel to announcement-only posts from IT until day-of, then open it for questions.

The two short announcements#

Slack and Teams allow exactly two effective broadcast messages before users start muting the channel. Use them at T-14 and T-1.

T-14 announcement:

Reminder: company email moves to [New Platform] on [Date]. Please empty Deleted Items and archive old mail before then. Details: [link to intranet post].

T-1 announcement:

Tomorrow at [Time], company email moves to [New Platform]. Expect send/receive interruptions until [Time]. We will post live updates in this channel. Setup instructions go out by email when each mailbox is ready.

That is it. Anything else goes in the dedicated channel.

The help-desk script#

Your help desk needs three things to handle migration tickets well: a one-page script, escalation thresholds, and the authority to fix the top-five common issues without raising a ticket back to the migration team.

One-page script#

For every migration-related call or message, the help desk follows this order:

1. Identify: name, email address, and "is your mailbox migrated yet?"
2. Triage: choose one of five common issues, or "other".
3. Resolve at L1 or escalate to migration team.

The five common L1-resolvable issues are:

• Cannot sign in to new account: confirm correct webmail URL, confirm password is the company password, walk through password reset if needed.
• Cannot set up mobile: send the platform-specific setup link, ensure the old account is fully removed first.
• Missing folder or mail: ask for folder name and most recent message they remember. If missing in webmail too, escalate.
• Calendar invite shows wrong time: confirm timezone setting in new account profile.
• Signature missing: explain that signatures are local; offer to walk them through recreating it.

Anything else, or any of the five that the L1 script does not resolve in 10 minutes, escalates to the migration team with the ticket pre-tagged so it lands in the right queue.

Escalation thresholds#

Set explicit thresholds so the help desk does not absorb a real outage.

• More than 5 "cannot sign in" tickets in 15 minutes → page the migration team
• Any "I sent mail and it bounced" ticket → migration team, immediate
• Any ticket from a named VIP list → migration team, immediate, do not queue

Publish these thresholds inside the help desk channel so L1 does not have to interpret severity in the moment.

Writing for the different audiences#

The templates above are for the general user population. Three other audiences need different copy.

Executives#

Three bullets, no instructions. "Migration starts [Date Time], ends [Date Time], you will see service interruption in that window, your assistants have been briefed, your phone is the fallback if anything breaks." Send it personally, not from a distribution list. Get a "received, thanks" reply if you can.

Shared mailbox owners#

A separate thread per shared mailbox. Confirm current delegate list. Tell them their cutover may be on a different day from their personal mailbox. Make explicit that they need to re-grant access to the new mailbox after migration. If you do not warn them, expect a stream of "I cannot see the support@ inbox" tickets on day-of.

External recipients#

If your domain or sending IPs change, customers and suppliers will notice. Write one short note from the IT or operations leader to send to your top-N external contacts at T-1. Explain that internal email systems are changing, that addresses stay the same, and that they may see a brief delay if they reply during the cutover window.

For the broader playbook that ties all this together, the complete email migration guide is the parent document this comms plan slots into.

Common comms-plan mistakes#

A few patterns recur across migrations of every size.

Mistake 1: trying to be funny. A migration is an inconvenience to your users. Humour reads as not taking it seriously. Write plainly.

Mistake 2: omitting the timezone. If you run a multi-region migration and say "Tuesday at 9 PM", you will get tickets from three time zones asking what you meant. Always include the timezone abbreviation.

Mistake 3: separating the "what" from the "why". Users do not care why you are migrating. They care what they have to do. Put the "what" at the top. The "why" is optional.

Mistake 4: linking to a 40-page wiki page. Users will not read it. Put the three key steps in the email itself; link the wiki only as a "more detail" anchor at the end.

Mistake 5: forgetting the day-of channel. If your only update channel is email and email is broken, your day-of communications fail by definition. Always have a non-email channel ready.

A pre-flight checklist for the comms plan#

Before you press send on T-30, confirm:

• All six templates are drafted and approved by the migration lead and one non-IT stakeholder
• The dedicated Slack/Teams channel exists and has the pinned announcement
• The intranet post is published and pinned
• The status page URL works and shows "Healthy"
• The help-desk one-pager is printed at the desk and the L1 team has read it
• The VIP escalation list is written down somewhere both the help desk and the migration team can see it
• The day-of incident commander knows they own the update cadence

When all of those are green, send T-30.