Migration Communication Plan: Copyable Templates
A migration communication plan needs five copyable templates, a cutover-relative timeline, and a script for what to say when something breaks midstream.
Here is how migration communication fails without a plan. The PMO director sends a single email in month one: "We are migrating from Project Online. More details to follow." Finance gets copied. The sponsor sees it, nods, and moves on. Three months later the sponsor asks the PMO director when cutover is happening. A resource manager finds out from a PM who heard from another PM. IT, waiting for the integration spec from the migration team, starts asking questions in a shared Slack channel. End users hear about the change two weeks before go-live: not enough time for questions and not enough time to prepare.
A migration communication plan is the fix, and it works only if it exists as a written document in week one, not as five people improvising emails under deadline pressure. That plan needs six named audiences, a cadence, and message templates ready to copy and send rather than drafted from scratch each time. Project Online migration communication gets underfunded because it looks like soft work sitting next to the real work of data export, tool selection, and system integration. It is not. Poor communication is the second most common cause of migration delays, after skipping the pilot phase.
TL;DR: A migration communication plan needs six named audiences, a cadence tied to dates relative to cutover, five ready-to-copy templates (kickoff announcement, two-week reminder, freeze notice, go-live note, post-cutover survey), and a script for what to say when something breaks midstream. Sponsors need biweekly schedule and risk status. PMs need lead time to validate their projects before cutover. Resource managers need to understand what changes in capacity visibility. Finance needs a license-transition timeline. IT needs technical specs with enough runway to complete integration work. End users need a plain "what changes for you" message at least three weeks before go-live. One all-hands email covers none of them.
Why Project Online Migration Communication Gets Deprioritized
Migration communication gets cut because project managers estimate it as low-effort. It is not complex, they argue: just a few emails and a Slack channel. The technical work is harder. Exporting data from Project Online, validating baselines, rebuilding Power BI connections: those tasks have clear deliverables and measurable outcomes. Communication gets whatever is left after the technical work is scheduled.
The failure mode is predictable. When the migration team is heads-down on data mapping, the steering committee stops hearing from them. Silence reads as inaction or trouble. Sponsors who feel uninformed start asking questions through informal channels, which pulls the migration team out of technical work to answer questions that a standing biweekly update would have prevented.
Separately, PMOs often underestimate who counts as a stakeholder. The active inventory of a Project Online tenant goes beyond projects and PMs. It includes resource managers who maintain the Enterprise Resource Pool, finance teams tracking license overlap costs, IT teams who own Power BI connections and Power Automate flows, and a broader audience of report-readers and timesheet-submitters who never log into PWA as a PM but whose workflows break on cutover day.
Microsoft's Project Online retirement announcement confirmed September 30, 2026 as the hard deadline. After that date, the PWA site stops serving pages and the OData feed stops responding. A communication failure that delays the migration by six weeks has real consequences at that timeline.
The Project Online migration checklist covers the technical inventory: projects, resources, custom fields, workflows, integrations. The communication plan belongs on the same timeline, drafted during inventory week, owned by a single named person, and treated as a deliverable with the same weight as the data export plan.
The Six Audiences in a Project Online Migration
Six groups need to hear from you during a Project Online migration. Each gets a different message, a different frequency, and a different channel. Treating them as a single audience is the root cause of the "when is this happening?" Slack thread.
Sponsors and steering committee. They approved the migration budget and own the outcome. They need schedule status and risk updates, not technical details.
Project managers. They own the projects being migrated and will validate the migrated data. They need enough lead time to clean up their Project Online schedules before export and need to know exactly when cutover affects them personally.
Resource managers. They manage the Enterprise Resource Pool and care about what happens to capacity visibility during and after migration. In many organizations, resource managers are not PMs and are sometimes forgotten entirely until they discover their five-year resource structure is being restructured.
Finance. They approved the budget and need to know when Project Online licenses can be cancelled, when overlap costs end, and what the license structure looks like in the new tool.
IT. They own the integration layer: Power BI connections, Power Automate flows, SharePoint integrations, and custom connectors. They need technical specifications and timelines with enough runway to do real work.
End users. These are the people who use Project Online for read access: executives pulling reports, team members logging time, project stakeholders viewing progress. They need a simple message about what changes for them, where to go with questions, and when.
The diagram below maps each audience to the phases where they are most active and most in need of direct communication.
What Each Audience Needs to Hear
The message for each audience should map to what they care about, not what the migration team finds interesting.
Sponsors and steering committee. They need three things: Are we on schedule? What are the top risks this week? What decisions do we need from them? The format is a one-page status update delivered biweekly that answers those questions and nothing else. Technical details belong in an appendix they will not read. The Status Report Writer formats migration status into the executive-readable structure that lets a sponsor scan in under two minutes, which is how long a sponsor will spend on a weekly status email.
Project managers. PMs need to hear from the migration team at three specific moments. First, at kickoff: what is expected of them during the inventory phase (cleaning up their Project Online schedules, documenting custom fields, naming their migration contacts). Second, during the pilot phase: whether their project is in the pilot group and what validation they will be asked to do. Third, at least four weeks before cutover: the specific date their project migrates, what the validation checklist covers, and who to escalate to if they find problems.
Sending a general email to all PMs each week dilutes the signal. PMs respond to information that is specific to their project. Personalized communications, even if templated, outperform broadcasts. The pilot phase communication to a PM whose project is being used in the pilot should look very different from the communication to a PM whose project will migrate in the main portfolio wave four weeks later.
Resource managers. Resource managers are frequently forgotten until they discover mid-migration that the Enterprise Resource Pool they have maintained for five years is being restructured without their input. The right moment is week one: a conversation, not an email, about how resources will be represented in the new tool, whether existing availability calendars are migrating, and what the approval workflow looks like for new resource requests after go-live. If the Schedule Health Check reveals overallocations in the current resource pool, resource managers need to know that before the migration locks in those allocation patterns.
Finance. Finance has two questions: When does the Project Online license bill stop, and when does the new tool license bill start? Give them a three-date schedule: the last day of Project Online billing, the first day of new-tool billing, and the overlap period during parallel running when both run concurrently. That overlap cost should be in the business case already approved. If it was not, surface it now rather than at invoice time. Finance also needs to know whether migration costs are being capitalized as a project expense or expensed as incurred.
IT. IT needs technical specifications and timeline milestones with genuine lead time. The two most common IT communication failures: telling IT about a Power BI integration dependency three weeks before cutover (not enough time to rebuild the OData connection), and telling IT about a SharePoint integration in week eight when IT assumed it was not in scope. The right cadence is a kickoff meeting covering integration inventory, a midpoint check-in with confirmed specs and timelines, and a cutover-prep meeting two weeks before go-live. Technical exchange happens in tickets and shared documents, not status emails.
End users. End users need one clear message: on this date, projects will be in a new tool, here is how you access it, here is what changes for you specifically, and here is who to contact if you have questions. They do not need the migration backstory. They need to know where to go on Monday morning.
Send this message no later than three weeks before cutover. Six weeks is better when training is involved. Follow it with a one-week-out reminder. The message should come from the PMO director or a sponsor, not from IT. That framing signals this is a business decision, not a system change.
Five Templates for Your Migration Communication Plan
A migration communication plan is only as useful as the templates that let someone send the right message in five minutes instead of drafting one from scratch under deadline pressure. These five cover the messages every migration needs; adjust the bracketed fields and send.
1. The kickoff announcement (week 1, to sponsors and PMs).
Subject: [Project Online migration] kicks off this week
We're beginning the move from Microsoft Project Online to [destination tool], ahead of Microsoft's September 30, 2026 retirement date. Over the next [N] weeks, the migration team will inventory active projects, validate a pilot group, and prepare the full portfolio for cutover on [target date].
What this means for you now: [specific ask, e.g. "confirm your project list by Friday"]. You'll hear from us again at [next milestone]. Questions go to [named contact].
2. The two-week reminder (T-minus 2 weeks, to all six audiences).
Subject: [Destination tool] cutover is two weeks away, [date]
This is your two-week notice. Cutover happens the weekend of [date]. [Audience-specific line: PMs get their validation checklist; end users get where their projects will live and how to log in.]
The freeze window begins [freeze date]: no schedule changes in Project Online after that point will carry over. Full details below. Questions to [named contact] before [date].
3. The freeze notice (immediately before the change freeze, to PMs and end users).
Subject: Project Online is now frozen ahead of cutover
As of [date/time], Project Online is read-only. Any schedule change made after this point will not be captured in the migration and will need to be re-entered manually in [destination tool] after go-live. If you have an urgent change that must be reflected, contact [named contact] before [freeze deadline].
4. The go-live note (cutover day, to all six audiences).
Subject: [Destination tool] is live
The migration is complete. Your projects are now in [destination tool] at [URL]. [Specific access instructions.] Hypercare support is available through [channel] for the next [N] days; response time during hypercare is [SLA]. Known issues so far: [none, or a short list with status].
5. The post-cutover survey (T-plus 1 to 2 weeks, to PMs and end users).
Subject: How is [destination tool] working for you so far?
Two weeks in, we want to know what's working and what isn't. Three questions, two minutes: [link to a 3-5 question survey covering data accuracy, access issues, and training gaps]. Responses shape the hypercare backlog directly, not a future roadmap.
The Migration Communication Plan Timeline
Each template above has a specific send date relative to cutover and a specific primary audience. Mapping the two prevents the two failure modes that produce the "when is this happening?" thread: sending everything to everyone, or sending nothing until it's too late.
| Message | Sent | Primary audience |
|---|---|---|
| Kickoff announcement | Week 1 (T-minus roughly 10-12 weeks) | Sponsors, PMs, resource managers, finance, IT |
| Two-week reminder | T-minus 2 weeks | All six audiences |
| Freeze notice | T-minus 1 week (start of change freeze) | PMs, end users |
| Go-live note | T-0, cutover day | All six audiences |
| Post-cutover survey | T-plus 1 to 2 weeks | PMs, end users |
The Communication Cadence That Prevents the Slack Thread
The "when is this happening?" Slack thread appears when the gap between status updates exceeds what a stakeholder can tolerate. The tolerable gap for sponsors is roughly two weeks. For PMs it is three to four weeks between project-specific touchpoints. For end users, silence longer than three weeks before cutover produces anxiety that escalates into informal questions to whoever seems to know what is going on.
A workable cadence for a three-month migration:
Week 1, kickoff communications. All six audiences hear from you this week, but with different messages. Sponsors get a kickoff deck covering scope, timeline, and governance. PMs get a PM-specific briefing on what is expected of them. Resource managers get a one-on-one with the migration lead covering the resource pool plan. Finance gets the license transition schedule. IT gets the integration kickoff meeting with a full list of known integration surfaces. End users get nothing yet.
Biweekly, weeks 2 through cutover. Sponsor and steering committee status update. One page, three questions answered: schedule, risk, decisions needed. This is the update the Status Report Writer formats well: structured, scannable, executive-facing, and quick to draft consistently.
At pilot kickoff, weeks 4 to 5. PM-specific communication identifying pilot project owners, what validation they will do, and the two-week pilot timeline. Non-pilot PMs get a brief update confirming the migration is on track and noting when they will hear directly about their own projects.
At pilot exit. Sponsor update on pilot results, including any findings that affect the cutover plan or timeline. If the pilot found a blocking issue, this is the communication that matters most: bad news delivered directly and with a mitigation plan preserves trust; bad news discovered by a sponsor before the migration team delivers it destroys it.
Six weeks before cutover. End-user communication if training is involved. Cover what changes, when, and the training logistics. PMs in the main portfolio wave get their specific cutover date and validation instructions.
Three weeks before cutover. All-stakeholder cutover preview. Cover the cutover weekend schedule, the parallel-running window, the rollback plan, and the hypercare contacts for week one.
One week before cutover. Final reminder to all audiences. Confirm the schedule, surface any last-minute questions, and name the escalation contact for the weekend.
During and after cutover. Real-time hypercare communication via a dedicated channel with clear escalation paths. Daily status to sponsors for the first week post-go-live.
Three Reasons Communication Plans Fail Even When They Exist
No named owner. A communication plan that is owned by the migration lead gets deprioritized when the migration lead is heads-down on a data validation problem. The plan needs a named owner whose primary job for the migration period is ensuring each audience receives the right information at the right time. That person does not have to be a dedicated communications resource; a senior PMO analyst or migration coordinator filling that role part-time is enough. What they cannot be is the same person also responsible for the technical migration work.
Good news only. When a milestone slips, the instinct is to wait until the rescheduling is confirmed before telling the sponsor. The sponsor finds out from someone else in the interim, and the trust gap opens. Bad news delivered early with context and a mitigation plan preserves trust. The standard for sponsor communication is not "tell them when we know for sure." It is "tell them as soon as we know enough to give them a useful picture."
Confluence substitutes for communication. A well-written internal wiki page does not substitute for a direct message to a sponsor. Status information must travel to the audience, not wait for the audience to find it. Sponsors and PMs do not check the migration wiki. They read email, attend scheduled calls, and pick up information from people who approach them directly. The communication plan has to use channels its audiences actually use.
What to Say When Something Goes Wrong
Every migration communication plan template above assumes good news. The gap most plans skip entirely is the script for when a validation check fails, a cutover slips, or hypercare surfaces a data problem nobody caught in the pilot. Improvising that message under pressure is how a fixable technical problem turns into a trust problem.
The structure that holds up under pressure has four parts, in this order:
- State the impact first, not the cause. "The resource capacity view for the Northeast portfolio is showing incorrect allocations for 12 projects" comes before any explanation of why. A sponsor or PM needs to know what is affected before they need to know how it happened.
- State what's being done, concretely. Not "we're looking into it." Name the action: "the migration team is re-running the resource mapping script against the affected projects."
- Give a specific time for the next update, even if the next update is "we still don't have a fix, here's what we've ruled out." A specific time held to, even with no news, preserves more trust than a vague promise of updates "as we have them."
- Say who to contact for anything urgent, by name, not by role. "Contact the migration team" produces the same informal Slack-thread problem this whole plan exists to prevent.
A worked example: "The [destination tool] Gantt view for 8 projects in the Finance portfolio is showing baseline dates that don't match the exported Project Online baselines. We've confirmed the export script mishandled recurring tasks and are re-running the affected projects now. We expect corrected data by end of day [date]; if that slips we'll update you by [specific time] regardless. Contact [named lead] directly if a corrected baseline is blocking a report due before then."
That message states the impact, the cause in one clause (not the focus), the concrete fix, a firm next-update time, and a named contact. It took the migration lead two minutes to send and it is the message that keeps a sponsor from escalating past the migration team entirely.
How to Know Whether Your Communication Is Working
Two indicators signal a failing communication plan before a major escalation surfaces it.
The first is inbound volume. If the migration lead is receiving more than two to three questions per week from audiences that should already have their questions answered, the plan is not covering those audiences adequately. Track the questions and their source. Patterns in who is asking and what they are asking reveal exactly where the cadence has gaps.
The second is the content of those questions. "When is cutover?" from a sponsor means the biweekly status updates are not reaching them or are not clear. "Will my project be affected?" from a PM means they did not receive a direct communication when they should have. "What happens to my Power BI report?" from finance means IT was not looped in early enough to communicate downstream implications to its stakeholders.
The full pattern of what happens when communication is absent is documented in why Project Online migrations fail: deferring training to the week of go-live, treating communication as a soft deliverable, and discovering OData consumers after cutover are all related failures. Communication is the mechanism through which the rest of the migration plan gets executed. When it fails, the technical work fails with it.
Write migration status updates executives can scan in two minutes The free Status Report Writer formats your migration status in the structure sponsors and steering committees actually read. No signup required. Open the Status Report Writer
Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.