Project Online Baseline Migration: Keeping History Through the Move

Most Project Online baseline migration plans preserve one baseline. Project Online actually stores eleven. Here's the gap most PMOs don't discover until they're two weeks into the cutover and a change control board asks to compare current scope against the original approved plan.

The default behavior of almost every migration path out of PWA is to carry over the active baseline, the one a PM would see in a standard Gantt view, and treat the rest as disposable history. For PMOs whose projects are purely internal, that's often fine. For any PMO whose projects have contracts, formal change control processes, or audit obligations, losing baselines 1 through 10 is a compliance problem disguised as a technical default.

TL;DR. Project Online baseline migration is a two-part problem: getting all 11 baselines out of PWA before retirement, and getting them into the destination tool in a usable form. Baselines set locally in the .mpp file travel with the export. Baselines saved through the PWA publish workflow live in the reporting database and require an OData export before September 30, 2026. Most destination tools need explicit configuration to accept more than one baseline set. Audit-driven PMOs should classify which baselines carry live data before migration begins, so the export scope is defined before the retirement window closes.

Why Project Online stores eleven baselines

The baseline numbering model in PWA inherits from Microsoft Project's desktop baseline system. Microsoft Project has always allowed up to 11 baselines per project because real project management involves approved changes. A project that runs for 18 months may have its original scope approved in month 1, a formal scope extension in month 6, and a second extension in month 12. Each of those approval events justifies a new baseline snapshot: "this is what we agreed to as of this date."

In practice, different PMOs use the baseline slots differently. Some use Baseline 0 as the original plan and Baseline 1 for each approved change, accumulating history over the project lifecycle. Some use the baseline numbers to track different contract phases. Some use them as ad hoc saves with no formal meaning. The value of the full baseline set depends entirely on how your PMO defined the baseline convention. That's the first thing to document before a migration: for each active project, which baselines have formal meaning and which are administrative artifacts.

Understanding critical path method and how schedule dependencies anchor baseline dates helps contextualize why a baseline shift is significant: it changes the reference point for every variance calculation in the project.

Where PWA-stored baselines actually live

This is the detail that surprises most migration teams. When a PM sets a baseline inside the desktop .mpp file and saves locally, the baseline data lives in the file. When a PM sets a baseline through the PWA Publish workflow (the more common enterprise pattern), the baseline data is written to the PWA reporting database, not just the .mpp file.

The diagram below shows both storage paths.

When you download a .mpp from PWA and open it in Microsoft Project desktop, baselines that were published through PWA may appear in the file because PWA writes them back. But the authoritative record of a published baseline is in the reporting database, accessible via OData at /_api/ProjectData/ProjectBaselines. If the .mpp was last modified before the baseline was set, the file version won't reflect the correct baseline values.

The practical rule: for any project where baselines were set through the PWA Publish workflow, treat the OData export as the authoritative source. Don't rely on the .mpp alone.

Which baselines are worth migrating

Not every baseline slot carries meaningful data. In many PWA tenants, Baseline 0 is set for every project at kickoff, Baselines 1 and 2 are set for approved scope changes, and Baselines 3 through 10 are administrative saves: a PM set a baseline before a replanning session to compare against, then forgot to clear it. Migrating all eleven baselines for every project is not the right answer.

The classification exercise takes about 30 minutes per project for a trained PMO analyst. For each project, query the baseline set via OData and ask four questions:

• Is this baseline referenced in any change control record, contract, or audit document?
• Is this baseline the basis for any variance calculation in a current report?
• Was this baseline set at a formal approval event (kickoff, change approval, phase gate)?
• Does anyone in the PMO know why this baseline was set?

Any baseline that gets a yes to any of those questions is a migration candidate. Anything that gets four nos is an archive candidate: preserve it as a flat-file record (CSV or PDF) for compliance purposes, but don't pay the cost of importing it into the destination tool as live data.

The Project Online migration checklist includes a baseline classification section in the Projects and Schedules inventory step. Run that first if you haven't done a full tenant inventory yet.

What .mpp export handles and where it fails

For projects where baselines were managed entirely in the desktop .mpp file, the export is clean. All 11 baseline slots travel with the file. The baseline field names (Baseline Start, Baseline Finish, Baseline Work, Baseline Cost, Baseline Duration) are standard MPXJ-readable fields, so most modern PM tools can import them if they support multi-baseline imports.

The gaps appear in two scenarios. First: the project was managed primarily through PWA (schedules published, baselines set via Publish), and the .mpp export doesn't reflect all baseline sets accurately. Second: the destination tool only imports Baseline 0 and ignores fields named Baseline 1 Start, Baseline 2 Start, and so on, even when those fields are present in the file.

For scenario one, the fix is an OData export before retirement. For scenario two, the fix is checking the destination tool's import documentation before committing to .mpp as the migration format. Some tools support multi-baseline import via MSPDI XML even when they don't handle it via .mpp. Worth testing before the full migration.

A four-step process for full baseline preservation

Migrating the full baseline set from PWA requires working through four steps in order.

1. Export the OData baseline snapshot. Query /_api/ProjectData/ProjectBaselines for all projects in scope. Each row includes project ID, baseline number, baseline start date, baseline finish date, baseline work, and baseline cost. Export to CSV. This is your reference record: it should exist even if the destination tool import doesn't carry all baselines, because it gives you an archival record of what the baselines were.

2. Classify each baseline per project. Use the four questions above to decide: migrate live or archive as flat file. Mark your classification in the CSV export. Projects with only Baseline 0 needing live migration are the straightforward cases. Projects with Baselines 0 through 4 all classified as live migration are the complex ones that need destination tool testing first.

3. Test multi-baseline import on a pilot project. Choose a mid-complexity project with two or three classified-live baselines. Run it through the destination tool's import process and verify that Baseline 1 Start for Task A in the destination matches Baseline 1 Start for Task A in the OData export. If they match, your import template works for the full set. If they don't, fix the import template before touching the rest of the library.

4. Validate post-import baseline values for sampled tasks. After the full import, spot-check ten tasks per project for your complex projects: compare baseline start, finish, and work values in the destination against the OData export. Any discrepancy requires investigation before cutover.

Running the Schedule Health Check on your post-import .mpp files will surface baseline anomalies alongside other schedule quality issues. It catches cases where a baseline date exists in the source but is missing or zeroed in the destination, which is harder to spot manually across a large task list.

When archiving beats migrating

The migration calculus changes for historical projects. A project that closed 18 months ago, whose baselines were set during execution, and whose contract is now complete has little need for live baseline data in the destination tool. Nobody is running variance calculations against it. But a compliance requirement might mandate that the baseline record be preserved in some accessible form.

For historical projects, the better path is usually a flat-file archive: export the full baseline set as a structured CSV or PDF, store it in a document management system with an appropriate retention tag, and mark the project as archived rather than migrated. This cuts migration scope without losing the compliance record.

The rough threshold most PMOs land on: any project that closed within the last 12 months and whose contract or audit period is still open is a live migration candidate. Anything closed more than 18 months ago with no open audit exposure is an archive candidate. The 12-to-18-month window in between is judgment-call territory and should be reviewed with whoever owns the audit exposure.

Run the free Schedule Health Check Upload your .mpp files and catch baseline anomalies, missing baseline sets, and schedule quality issues before the migration starts. No signup required. Open Schedule Health Check

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.