HomeServicesManaged IT ServicesClaude DeploymentInsightsAnswersAboutContact
Cost & timeline

How should we communicate a Microsoft 365 migration to users?

Short answer

Communicate early, briefly and by wave. Announce the why and the timeline a few weeks out, send each wave a notice about a week before with what changes for them, a reminder the day before, and a one-page day-one guide. Give one clear support channel. Tell users what they must do, what will look different and what will not change.

Key facts

  • Most migration help desk tickets come from surprises, not technical failures.
  • Messages should say what changes for the user, what they must do and where to get help.
  • Wave-specific notices beat company-wide blasts once migration starts.
  • A one-page day-one guide with screenshots answers most first-morning questions.
  • Executive assistants, reception and power users should hear first and get extra support.

Why communication matters as much as tooling

A migration can be technically clean and still feel like a failure if people come in on Monday and cannot find their shared mailbox or their phone asks them to sign in again. Communication turns expected changes into non-events.

Plan communications alongside the technical schedule, with the same wave structure. The migration lead owns the plan, and a business sponsor signs the main announcement.

The communication timeline

Exact timing depends on project length, but this sequence works for most migrations.

WhenMessageAudience
Several weeks beforeAnnouncement: why, what, when, sponsorEveryone
Two to three weeks beforePreparation steps, such as MFA registration or cleanupEveryone or each wave
About a week before the waveWave notice with date, changes and actionsThat wave
Day beforeReminder and day-one guideThat wave
Migration dayDone notice with support detailsThat wave
A week afterTips, known issues, feedback requestThat wave
Project closeSummary and thanks, what is nextEveryone

What to tell users

Every message should answer three questions in the first few lines: what is changing for me, what do I need to do, and where do I get help. Keep messages short and put detail in a linked guide.

  • Date and time of their move, and whether to stay signed out or keep working.
  • Actions before the move, such as registering for MFA or installing an app.
  • What will look different: new sign-in prompts, Outlook profile, mobile setup.
  • What will not change: email address, phone number, file locations where true.
  • What will not move, such as very old archives or personal settings.
  • The one support channel and its hours on migration day.

Day-one support

Publish a one-page guide with screenshots: signing in, setting up Outlook on desktop and mobile, finding shared mailboxes, and opening files in OneDrive, Teams or SharePoint. Make it available as a PDF and on the intranet, and print a few copies for reception and shared areas.

Offer floor walkers or a Teams drop-in call during the first morning of each wave. Give executive assistants, reception and other high-impact users a named contact and a quick check before others start work. Track day-one questions and update the guide for the next wave.

Channels and tone

Use email for formal notices, a Teams post or intranet page for the reference guide, and managers for reinforcement in team meetings. Avoid relying on email alone for a mail migration; the message about the change should not depend on the system being changed.

Write in plain language, avoid technical terms, and be honest about known issues. Users forgive minor problems when they were told what to expect and how to get help.

How Accred Consulting approaches it

Accred Consulting includes a user communication plan in every Microsoft 365 migration. Discovery identifies waves, high-impact users, support channels and what will change for each group, and the proposal sets scope, fixed price and timeline. The US-based specialists assigned to your engagement draft announcements, wave notices and day-one guides, align them with the technical schedule, and provide first-morning support for each wave. In one consolidation of about 1,200 users after an acquisition, 6 waves over 8 weeks avoided an all-hands outage. Handover includes documentation and knowledge transfer.

Track record: 475+ client projects, 2,000+ migration workstreams and 210,000+ users migrated by a US-based team. Company facts · Case studies

Related questions

Several weeks before the first wave is typical, which gives time for preparation steps such as MFA registration. Shorter projects can compress this, but users should always get a wave-specific notice about a week before their move.
A business sponsor, such as a COO or managing partner, should sign the main announcement so it carries weight. IT or the migration team sends wave notices and guides. Managers reinforce the key dates in team meetings.
Yes, briefly. Tell them about expected changes such as re-entering passwords on phones, and any known limitations. Being upfront reduces frustration and support calls, and builds trust if something unexpected happens.
Use several channels: Teams posts, manager briefings, printed notices in shared areas and a short sign-in banner where possible. For key users, a quick personal call or message the day before works best.

Want this scoped for your environment?

Book a free consultation. After discovery you get a written plan with scope, a fixed price and a timeline.

Book a free consultation