Migrating Project Online Portfolios Without Recreating Hierarchy
Project Online portfolio migration is a rebuild, not a data export. Business drivers, scores, and portfolio hierarchy must be recreated in your destination tool.
Here is the misconception that costs PMOs the most time in any Project Online portfolio migration: the assumption that migrating the projects migrates the portfolio.
It doesn't. The portfolio layer (business drivers, prioritization models, strategic scores, scenario analyses) lives in administrative configuration, not in project files. None of it moves with a .mpp export. None of it comes across in an OData pull of project data. When the projects arrive in the destination tool, they arrive as a flat, unsorted list with no portfolio hierarchy, no strategic scores, and no relationship to the business drivers the PMO has been reporting against.
The PMO that discovers this six weeks after cutover spends the next two months rebuilding, from memory and old screenshots, the configuration it took a year to build in PWA.
Context: this post is one piece of the full Microsoft Project retirement timeline, the consolidated reference covering all three Microsoft Project ecosystem retirements happening in 2026.
TL;DR: Project Online portfolio data separates into two categories: project data (migrates with standard export tools) and portfolio configuration (does not migrate, must be rebuilt). Business drivers, prioritization scores, scenario models, and portfolio hierarchy all fall into the second category. The migration plan needs a dedicated rebuild track for each, not just a copy track.
What Project Online Portfolio Data Actually Contains
Project Online at the Plan 5 tier includes the Portfolio Analyzer, a set of tools for enterprise PMOs to govern their project portfolio at a strategic level. Understanding what data lives in this system is the first step to a Project Online portfolio migration plan that doesn't leave half the portfolio behind.
The project list. The foundation of any portfolio: the list of all projects with their schedule data, resource assignments, and custom field values. This is what .mpp exports and OData APIs return. It migrates.
Business drivers. Defined by the PMO, business drivers represent the strategic objectives the portfolio is meant to advance: "Increase Revenue," "Reduce Operating Cost," "Improve Customer Satisfaction." Each project is scored against each driver. Business drivers are PWA admin configuration, not project data. They do not exist in any export format that other tools can read.
Prioritization models. The Portfolio Analyzer uses pairwise comparison to weight business drivers against each other. The output is a weight vector: "Revenue Growth matters twice as much as Cost Reduction for this portfolio." This weighting is also admin configuration. It cannot be exported as structured data.
Strategic scores. Once business drivers are defined and weighted, each project gets a strategic score: a composite number representing how much that project advances the portfolio's priorities. These scores can be exported via OData from the Project Data reporting schema. They are portable as reference data but mean nothing without the driver definitions and weight model that generated them.
Scenario models. The Portfolio Analyzer lets PMOs model different portfolio compositions: "What if we had a budget of $5M instead of $8M? Which projects survive the cut?" Each scenario is a saved snapshot of a different portfolio selection. Scenarios are stored as Portfolio Analyzer objects in the PWA database. No standard export format captures them as structured data.
Portfolio and program hierarchy. Project Online organizes projects into a hierarchy: Projects roll up into Programs, which roll up into Portfolios. This hierarchy controls which projects appear in which dashboards, which reports aggregate at which level, and which users have visibility into which subset of the portfolio. The hierarchy is relational metadata, not project data. It migrates only if you explicitly rebuild it in the destination tool.
The Portfolio Analyzer: What to Migrate vs Rebuild
The Portfolio Analyzer is the component with the sharpest divide between exportable data and must-rebuild. Here is how each component breaks down:
| Component | Migration path | Notes |
|---|---|---|
| Business driver definitions + weights | Rebuild | Document current drivers before cutover; rebuild in destination |
| Project scores per driver | Export to CSV via OData | Use as reference when rebuilding scores in destination |
| Strategic score per project | Export to CSV via OData | Portable as a snapshot; recalculate once drivers are rebuilt |
| Saved scenario models | Export to PDF or presentation | Historical decision records, not live data |
| Portfolio/program hierarchy | Rebuild | Map to destination tool's structure before migration |
The key reframe here is that portfolio configuration is not data migration, it is system implementation. The migration team builds the new system from scratch using the old system as the specification. The old system is the reference; it is not the source file.
This matters for scope and timeline. Most migration estimates budget 2-4 weeks for importing project data. Adding a portfolio rebuild typically adds 4-8 weeks depending on the number of business drivers, the number of portfolios, and the complexity of the prioritization model.
The diagram below shows how each portfolio artifact maps to its migration action:
How to Document Your Portfolio Configuration Before Retirement
Before anything moves, capture your current portfolio configuration as a specification document. This is the input your new system needs.
Business drivers. List every driver defined in PWA: the driver name, the description the PMO uses to brief stakeholders, and the current weight relative to other drivers. The weight is usually stored as a percentage of the full driver weight vector.
Scoring rubric. Each driver typically has a scoring scale from 0 (no impact) to 10 (directly advances this driver), with specific definitions for each point. Document the definitions, not just the numbers. Future scoring will be done by people who weren't there when the original scale was created.
Portfolio hierarchy. List every portfolio and program: the name, the owner, the list of projects it contains, and any access-control rules that determine who can see it. Draw the hierarchy explicitly. Don't rely on memory.
Scenario models. For each saved scenario, document: the scenario name, the budget or resource constraint that defined it, the list of projects selected, and the strategic score total. Export to a presentation deck or PDF. This is historical decision-record, not a live input to the new tool.
Reporting templates. Portfolios drive dashboards. Document which dashboards exist, which metrics they surface, which projects they aggregate, and who uses them. Dashboard rebuilding is a separate work item that follows portfolio configuration.
The Hierarchy Problem: Three Options
Project Online's portfolio hierarchy (Portfolios contain Programs which contain Projects) is a strict relational structure built on SharePoint metadata. Destination tools handle hierarchy differently, and none of them import a PWA hierarchy definition.
Three patterns work in practice:
Option 1: Flat list with tags. The destination tool doesn't support nested portfolios but supports custom fields or tags. The former PWA "Portfolio" and "Program" levels become tag values: Project Alpha gets tagged "Portfolio: Digital Transformation, Program: Infrastructure." Reports and dashboards filter by tag. This is the simplest rebuild but loses hierarchical rollup; you manage it through filters, not structure.
Option 2: Native hierarchy in the destination tool. Some enterprise PM tools support multi-level hierarchy natively. If the destination has Portfolio and Program objects, map the PWA hierarchy to those objects directly. This is a true structural rebuild and takes the most time. It also requires the destination tool's permission model to match PWA's per-portfolio visibility rules reasonably well.
Option 3: Pragmatic reset. Many PMOs discover during this process that their current PWA hierarchy grew organically and no longer matches how the business actually thinks about its portfolio. Migration is a clean opportunity to restructure. Instead of rebuilding the old hierarchy, the PMO designs a new one that reflects current strategic priorities. This is the most disruptive option but produces the best long-term outcome.
Option 3 is more common than it sounds. After a few years with PWA, the hierarchy tends to reflect the organizational chart as it was when PWA was configured, not as it is today. The migration forces a conversation about how the portfolio should be structured, and that conversation often reveals the old structure was never quite right.
Prioritization Models: Migrate the Output, Rebuild the Engine
The strategic scores on individual projects (the numbers that say "this project has a strategic value of 7.4 out of 10") are worth preserving as historical reference. Export them via OData before retirement.
The model that generated those scores (business drivers, weights, pairwise comparisons) is what you rebuild.
In practice, rebuilding the prioritization model often reveals inconsistencies in the original. PWA's pairwise comparison engine is mathematically rigorous but not always transparent to the PMs who use it. When you rebuild it in a new tool and compare the new strategic scores against the old ones, significant deviations usually surface. They often reflect model drift: the weights were changed during a budget cycle but the documentation wasn't updated.
This is a reason to rebuild the model rather than just copy it. A rebuilt model is a reviewed model.
If your destination tool doesn't have a built-in strategic scoring framework, build the model in a spreadsheet. Many PMOs use Excel-based portfolio prioritization effectively. What matters is that the model is documented, reviewed, and applied consistently, not that it lives inside a specific tool.
For PMOs that rely on portfolio governance as a maturity signal, the pmo-maturity-tiers-explained-2026 post gives context on what portfolio-level governance typically looks like at different PMO maturity tiers. A migration is a natural inflection point for advancing that maturity.
Scenario Modeling: Archive, Don't Migrate
Scenario models in the Portfolio Analyzer represent decisions made at a specific point in time. "In Q2 2025, given a $12M budget constraint, the portfolio management committee selected these 14 projects." That decision is historical fact. The scenario model that supported it is the evidence.
You cannot migrate scenarios into a new tool in a way that makes them actionable. The budget constraints change. The project list changes. The business drivers may change. Trying to recreate historical scenarios in a new system creates confusion: team members use the old scenario data to make new decisions, without realizing the context has changed.
The right treatment: export all saved scenarios as a PDF or presentation deck before retirement. Store them in the PMO's document management system as decision records. Start fresh in the new tool with current scenarios built from the rebuilt business driver model.
A Project Online Portfolio Migration Playbook
Running a portfolio migration in parallel with the underlying project migration requires sequencing. The projects need to exist in the destination tool before you can assign them to portfolios; the business drivers need to be defined before you can score projects against them.
Here is the sequence that works:
- Export portfolio configuration from PWA: hierarchy, drivers, weights, scenario snapshots, and strategic scores via OData.
- Import project data (tasks, resources, baselines) into the destination tool using .mpp or XML.
- Configure the destination tool's portfolio structure (portfolios, programs, hierarchy).
- Rebuild business drivers and the scoring rubric in the destination tool.
- Assign imported projects to their portfolio and program structure.
- Re-score projects against the new business driver model.
- Validate: the strategic scores in the destination tool should correlate with the archived scores from PWA, though not match identically (the rebuilt model has been reviewed and may correct drift).
- Archive PWA scenario models as decision-record documents.
The project-online-migration-checklist-2026 has a full checklist of the most commonly missed migration items; portfolio configuration is a named category that maps directly to this sequence.
For the project-level migration (step 2), the why-project-online-migrations-fail post covers the most common structural reasons migrations go wrong after the tools are done, many of which trace back to skipping the portfolio layer described here.
The Onplana features page covers how the destination tool's portfolio and governance capabilities map to the PWA concepts discussed here, including stage-gate governance, portfolio dashboards, and multi-level hierarchy.
The Migration Is a Strategic Moment
Portfolio migrations are uncomfortable because they force the PMO to confront two things: what the portfolio actually looks like today, and what it should look like after migration.
PMOs that approach the portfolio rebuild as a constraint ("we have to rebuild what we had") spend weeks recreating a structure that may not have been working well in the first place.
PMOs that approach it as an opportunity use the migration as the trigger for the portfolio review they've been deferring. New tool, new driver model, clean project scores, hierarchy that reflects current strategy. The migration becomes a governance reset, not just a tool change.
Either approach requires the same first step: documenting the current portfolio configuration before it disappears with the PWA tenant on September 30, 2026.
Run the free Migration Preview Get a structured view of what's in your Project Online tenant before migration starts. Surfaces project data, resource pools, and custom fields: the foundation your portfolio rebuild sits on. No signup required. → Open the Migration Preview
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.