Project Online Migration Communication: The Stakeholder Plan PMOs Miss
Project Online migration communication is underfunded in most PMO plans. The six-audience stakeholder plan that prevents 'when is this happening?' chaos.
Here is how migration communication fails. 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.
That sequence is not the exception. It is the pattern. 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. It costs real calendar time when sponsors redirect resources because they do not understand the scope, and real money when training has to be repeated because end users were not ready.
TL;DR: A Project Online migration requires a six-audience communication plan drafted in week one, not improvised as questions arrive. 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. Each audience needs different information at different frequencies, and 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.
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.
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.