IMPORTANT NOTE:
Project Online retired on September 30, 2026.
Microsoft has stated that after retirement, organizations will no longer be able to access their Project Online projects or associated data within the service.
That creates a different question for organizations that relied on Project Online workflows: What happens to the business processes those workflows supported?
If you migrated workflows before retirement, you’ll need to evaluate whether they are working as intended in their new environment. If you didn’t migrate them, the retirement may have exposed processes that now need to be rebuilt, redesigned, or intentionally retired.
The goal is no longer to recreate Project Online exactly as it was. It’s to make sure the important work those workflows supported can continue—and ideally, work better.
There is a moment that happens in almost every Project Online transition conversation.
Someone opens a list of workflows, customizations, reports, automations, intake forms, approval processes, or resource management configurations that have been built over the last eight or ten years and says:
“What happens to all of this now?”
That’s a fair question.
Project Online retired on September 30, 2026, and organizations that depended on its workflows may now be dealing with a different question than they were during the migration itself: Which processes should move forward, which should be rebuilt, and which no longer need to exist?
The answer will not be the same for every workflow.
Some processes are still critical to how an organization operates. Others may have already been recreated in a new environment. And some may have survived for years simply because nobody had a reason to revisit them.
That leaves organizations with three paths:
- Migrate the workflow functionality that still makes sense to preserve
- Rebuild important processes that need a different implementation
- Retire processes that no longer provide enough value to justify maintaining them
The challenge is knowing which path applies to which workflow.
The Biggest Mistake Organizations Make
The most common mistake we see is assuming every existing workflow deserves to survive.
It’s understandable. Teams have invested years into these environments. People are attached to the systems they built. Sometimes, entire reporting structures or governance models are tied to them.
But longevity is not proof of value.
A surprising number of Project Online workflows exist today because of old limitations, temporary business rules, leadership preferences from five years ago, or platform constraints that no longer matter.
Some workflows are still mission-critical.
Others are just institutional habits wrapped in technology.
The transition away from Project Online creates an opportunity to evaluate that distinction rather than automatically recreate everything that existed before.
The goal is not to preserve every workflow. The goal is to preserve the business value those workflows provided.
That starts with understanding what each workflow actually did.
When a Workflow Should Be Migrated
“Migrate” can mean different things depending on where an organization is in its transition.
For some organizations, workflow functionality has already been moved into another environment. In that case, the question is whether the migrated process is working as intended.
For others, important workflow assets, documentation, business rules, or supporting components may need to be preserved so they can be redeployed or incorporated into a new solution.
Either way, migration makes the most sense when the underlying process remains valuable and the organization needs continuity.
These are usually workflows that:
- support core operational processes,
- have strong user adoption,
- produce reliable reporting,
- align with current governance models,
- and still solve a valid business problem.
A mature resource planning process is a good example.
If an organization has spent years refining capacity planning, demand management, or portfolio governance and the process still reflects how the organization operates today, there may be significant value in preserving that capability.
The key distinction is whether the workflow still reflects how the organization actually operates today.
That sounds obvious, but it is surprisingly rare.
Many organizations discover that their documented process and their real process diverged years ago. If users consistently work around the process, that’s usually a warning sign that migration alone is not enough.
Executive reporting structures, financial tracking requirements, compliance controls, and enterprise portfolio management functions may all warrant preservation—but the implementation does not necessarily need to remain identical.
Preserve the value, not necessarily every step.
When a Workflow Should Be Rebuilt
Some Project Online workflows still solve important problems, but the original implementation no longer fits the organization.
This happens frequently with legacy Project Online customizations.
Over the years, organizations built highly specialized systems to compensate for platform limitations. Some created elaborate approval chains. Others developed complicated Power Automate flows, custom fields, reporting structures, or other supporting processes that technically worked but became difficult to maintain.
Now those organizations are operating in a different technology environment.
That does not automatically mean the original process was wrong. It means the organization has an opportunity to reconsider how that process should work.
Rebuilding often makes sense when:
- the business process is still valuable,
- but the original implementation became overly complicated,
- fragile,
- difficult to maintain,
- or dependent on outdated platform behavior.
This is where it becomes important to step back and redesign around business outcomes rather than tool limitations.
Instead of asking:
“How do we recreate this exactly?”
Ask:
“What problem were we actually trying to solve?”
Those are not the same thing.
A rebuild might involve multiple Microsoft tools working together differently than they did in Project Online. It might mean reducing unnecessary approval layers. It might mean changing how information is collected or reported. Or it might mean replacing a complicated series of automations with a simpler process.
A good rebuild simplifies intentionally without stripping away the operational controls the organization genuinely needs.
That balance matters now more than ever.
When a Workflow Should Be Retired
This is often the hardest conversation.
Not because the workflow is valuable, but because nobody wants to admit it may no longer be useful.
Many organizations have Project Online workflows that survive purely because:
- nobody revisited them,
- leadership changed,
- the original owner left,
- or people are afraid removing them will create risk.
In some environments, entire approval structures exist for decisions that no longer require that level of oversight. Reporting fields continue to be populated even though nobody reads the reports. Intake processes ask for information that has been irrelevant for years. And workflows continue to run simply because they always have.
The transition away from Project Online creates an opportunity to identify this kind of operational drift.
If a workflow disappeared tomorrow, ask:
- Would anyone notice?
- Would it create measurable operational risk?
- Does it improve decision-making?
- Does it reduce confusion?
- Does it help leadership or project teams act more effectively?
- Is the information it produces still used?
If the process no longer provides meaningful value, there may be no reason to recreate it.
Retirement is not necessarily a failure of the original workflow. Sometimes it is simply an acknowledgment that the business has changed.
Not every process needs a replacement.
Why “Lift and Shift” Can Create More Problems
During a transition, the temptation to perform a straight migration is understandable.
It feels safer.
It feels faster.
It feels less disruptive.
But simply recreating years of accumulated processes can also preserve years of accumulated operational debt.
Worse, organizations often discover too late that the new platform does not fully support the same behavior patterns anyway. That leads to awkward compromises where teams recreate legacy processes through increasingly fragile workarounds.
We are seeing this more frequently as organizations move into newer Microsoft work management environments.
The tools are evolving quickly, but not always in ways enterprise PMOs expected.
Features move.
Capabilities change.
Roadmaps shift.
Reporting changes.
Resource management changes.
Workflows may be distributed across multiple technologies rather than handled through a single platform.
That means a successful transition is not necessarily about reproducing the old environment.
It is about ensuring the important work continues.
Organizations that approach the process purely as a technical exercise may end up recreating old problems in a new environment.
Organizations that evaluate the underlying business processes have an opportunity to make more intentional decisions.
That mindset changes the conversation entirely.
Three Questions to Ask About Every Workflow
Instead of asking whether every Project Online workflow can be recreated, ask three questions:
1. Does this process still matter?
Start with the business need.
What decision does the process support? What problem does it solve? Who depends on it?
If the answer is unclear, that is a reason to investigate before rebuilding anything.
2. Does the current implementation still make sense?
A valuable process can have a poor implementation.
If users work around it, if maintaining it requires excessive effort, or if it depends on outdated technology, rebuilding may make more sense than preserving it as-is.
3. What is the best way to support it now?
The answer may involve a combination of Microsoft technologies or a different work management approach altogether.
The important thing is to choose the technology based on the business requirement—not force the business requirement to fit whatever technology happens to be available.
What Happens to Complex Workflows?
Some Project Online workflows were never just workflows. They were combinations of:
- business rules,
- custom fields,
- approval processes,
- Power Automate flows,
- reports,
- notifications,
- resource management practices,
- governance requirements,
- and integrations with other systems.
That complexity makes a simple “move or don’t move” decision difficult.
Before rebuilding a complicated process, map what it actually does.
Identify:
Inputs → Process → Decisions → Outputs → People → Supporting Technology
That exercise can reveal that what appeared to be one large workflow is actually several separate business processes. Evaluate these processes based on their actual value.
Some may need to be preserved.
Some may need to be redesigned.
Some may no longer be necessary.
And some may be better handled by a combination of technologies rather than one replacement workflow.
Ready to Evaluate Your Project Online Workflows?
Project Online retirement does not necessarily mean the business processes that depended on it should disappear.
That may involve rebuilding functionality, preserving and redeploying important workflow components, simplifying processes, improving reporting and governance, or evaluating a broader Microsoft work management environment.
The goal is not to recreate Project Online. It is to make sure the work that mattered continues to work.
Advisicon can help organizations evaluate existing Project Online workflows and the business processes behind them, determine what should be preserved or reconsidered, and identify the right technology approach for what comes next.
