Project Online Baselines Missing After Migration: How to Detect, Recover, or Accept the Loss

There is a pattern in Project Online migrations that is consistent enough to have a name: Monday morning baseline discovery. The migration finishes on the weekend. The PM opens the migrated project on Monday. The Gantt looks right, the tasks are in the right order, the current schedule is intact. Then the PM opens the variance view and finds that every project shows zero schedule variance and zero cost variance across the board.

Not because the projects are on track. Because all the baselines are gone.

TL;DR. Project Online supports up to 11 baseline slots per project. Most migration tools import the current schedule but silently omit the BaselineX fields that store historical snapshots. The fix has three paths depending on timing: detect the scope of loss via an OData query now, recover what you can from OData before the September 30, 2026 retirement, or document as known-lost with an archived export for future reference. The free Schedule Health Check tells you which baselines survived import into your destination tool.

Why Project Online baselines go missing in migration

Project Online stores baseline data in dedicated fields: BaselineStart, BaselineFinish, BaselineDuration, BaselineWork, and BaselineCost for the primary baseline, and BaselineXStart through BaselineXCost for Baselines 1 through 10. Each field is separate from the current schedule fields (Start, Finish, Duration, Work, Cost).

When a migration tool imports a project, it reads the current schedule fields because those are what drive the visible Gantt. Reading the BaselineX fields requires a second pass, a different import logic, and a destination tool that has somewhere to put the data. Many tools skip this entirely.

The result: the import succeeds, the log shows no errors, and the migrated project looks correct. The baseline data is quietly omitted. The PM only discovers this when running a variance report and finding that the baseline dates are all null or, worse, that the tool has substituted the import date as a pseudo-baseline, producing meaningless variances.

The diagram below shows what happens to a project's earned value reporting when baselines are lost.

The lost baselines do not produce noise; they produce silence. Every project shows zero variance, which is the most misleading possible output from a variance report.

The scope problem: how many baselines does a typical PMO have?

Project Online supports Baseline 0 through Baseline 10 per project: 11 slots, each holding a full snapshot of task dates, durations, work, and cost. In practice:

• Baseline 0 is the original approved plan, set when the project was chartered and the schedule was baselined for the first time.
• Baselines 1 through 3 are typically re-baselines after major approved changes: a scope change, a contract amendment, a significant approved delay.
• Baselines 4 through 10 are either unused or populated in PMOs with very formal change-control disciplines that baseline at each gate.

For a 200-project portfolio, the number of populated baseline records can easily reach 600 to 800 across the portfolio. Each one took a formal approval to create. Each one is the reference point for variance reporting on a specific period of the project's life.

Losing them all in a single weekend migration is a significant data loss event, even if the current schedule data is intact.

Use the Project Online Inventory Checklist to enumerate how many baselines exist across your portfolio before migration. The checklist queries /_api/ProjectData/Projects and surfaced populated Baseline fields, giving you a count of what is at risk before you start the migration process.

Three paths forward depending on where you are in the migration timeline

The right response to missing baselines depends on whether Project Online is still live, how close you are to the September 30 retirement date, and whether the destination tool can store the recovered data.

Path 1: Export all baselines before migration

If Project Online is still live, the baseline data is still there. The window to recover it is open. The correct action is to export all BaselineX fields for all projects via OData before running the migration.

The OData query for task-level baseline data:

GET /_api/ProjectData/Tasks?$select=
  ProjectId,TaskId,
  TaskBaselineStart,TaskBaselineFinish,TaskBaselineDuration,
  TaskBaselineWork,TaskBaselineCost,
  TaskBaseline1Start,TaskBaseline1Finish,
  TaskBaseline2Start,TaskBaseline2Finish,
  TaskBaseline3Start,TaskBaseline3Finish
&$filter=ProjectId eq guid'<your-project-id>'

Run this query for every active project and save the output as a CSV or JSON file per project. Store the exports in your document management system as the authoritative baseline archive.

If your migration tool supports importing baseline values from these exports, use them. If the destination tool cannot accept historical baselines, the export still serves as the reference archive: the PM can compare current performance against the exported baseline values manually, and any future reporting tool can reference them as a data source.

Path 2: Post-migration recovery while Project Online is still live

If the migration has already run but Project Online is still live in read-only mode, recovery is still possible for any project where the destination tool accepts baseline imports. The procedure:

1. Run the OData baseline export query above for each project where baselines are missing in the destination.
2. For each project, determine which baseline slots are populated (not all 11 slots have data in every project).
3. Import the baseline data into the destination tool using whatever baseline-import mechanism it provides. This is typically a bulk-import from CSV or a dedicated project-settings panel.
4. Validate by running a variance report in the destination tool and confirming that variances appear where you expect them (projects with known delays should show non-zero schedule variance).

This path works as long as Project Online remains live. Once Project Online is archived after September 30, 2026, recovery requires a support ticket and is not guaranteed. Do not defer this work past the retirement date.

Path 3: Post-retirement archive and documentation

If Project Online has already been retired and baseline data was not recovered, the options are more limited. The data exists in Microsoft's archive infrastructure, but access requires a support ticket and the timeline is not predictable. Microsoft has not committed to a specific recovery SLA post-retirement.

The practical response for most PMOs in this situation:

1. Document every project as "baseline lost in migration" with the date of loss recorded in the project management system.
2. Set a new baseline in the destination tool using the current schedule as the baseline date. This is not the same as the original baseline, but it gives the schedule a reference point for future variance reporting.
3. For projects that had long historical baselines (projects in execution for two or more years with multiple re-baselines), escalate to the sponsor and PMO director to decide whether to seek Microsoft recovery support.
4. Treat future reporting as "from re-baseline date forward" and document the caveat wherever variance data is displayed.

How to detect exactly which baselines survived migration

Before deciding on a recovery path, the first step is knowing precisely which projects have intact baselines and which do not.

Run this OData query against Project Online (while it is still live):

GET /_api/ProjectData/Projects?$select=
  ProjectId,ProjectName,
  ProjectBaselineStart,ProjectBaselineFinish,
  ProjectBaseline1Start,ProjectBaseline2Start,ProjectBaseline3Start

This returns one row per project with the project-level baseline start dates for the four most common slots. If the baseline was set, the date will be present. If it was never set or was lost, the field will be null.

Cross-reference the results against what the destination tool shows. For any project where Project Online shows a non-null baseline date but the destination shows null, the baseline was lost in migration. That project is a recovery candidate.

The Schedule Health Check performs this cross-check automatically: upload the .mpp file from the source, and the analysis report lists which baseline slots are populated in the source file and which survived into the tool's representation.

The critical path relationship: why baselines matter more after migration

After migration, the PMO typically enters a period of elevated schedule pressure. The retirement deadline has been met, but the organization is now learning a new tool, processes are being re-established, and the first month of operation is often rough. This is exactly the period when accurate variance reporting matters most, because PMs need to detect and communicate schedule problems early before they compound.

The critical path method gives you the structural view of which tasks drive the finish date. Baselines give you the historical view: the path was this before, it is that now, and the delta is the change that needs to be explained to the steering committee. Without baselines, the PM can see the current critical path but cannot tell the stakeholder whether the project is ahead, behind, or exactly on track relative to the approved plan.

This is the fundamental reason baseline recovery is worth the effort even when the migration has already completed. The investment in recovering or re-establishing baselines pays off in every project status review for the remainder of the project's life.

The known-lost protocol

For baselines that genuinely cannot be recovered, the right approach is to document the loss formally rather than ignore it. The "Monday morning baseline discovery" problem gets worse when the absence of baselines is not acknowledged: PMs run variance reports, see zero variance, and either believe the false result or distrust the tool entirely.

A known-lost baseline should be documented with:

1. The project name and ID.
2. Which baseline slots were populated in the source (from the OData export or pre-migration inventory).
3. The date on which the migration ran and the baselines were lost.
4. A brief description of what each baseline represented (original plan, post-scope-change re-baseline, etc.).
5. The name of the PM who owned the decision to accept the loss.

Store this record in the project management system alongside the project. Future PMs working with the project will know why baselines are missing and not assume the project was never baselined.

The Project Online Inventory Checklist includes a baseline inventory export that produces this documentation in a standard format suitable for storing alongside migrated projects.

The retirement window closes on September 30, 2026

Every path that involves recovering baseline data from Project Online requires Project Online to still be live. The OData endpoint returns data only while the tenant is active. Once Microsoft retires Project Online on September 30, 2026, the self-service recovery path closes. Recovery after that date is possible only through Microsoft's support process, with no committed timeline.

If baselines are a meaningful part of your PMO's governance and reporting, the baseline export and recovery work needs to be completed before the retirement date. This is not a nice-to-have; it is a date-constrained decision. Deferring baseline recovery until after cutover is a common decision that becomes irreversible after September 30.

The practical advice: run the OData baseline export today for your entire active portfolio, even if you are not yet in the migration process. The export is a read operation that takes a few hours and produces a file you can store safely. If the migration goes cleanly and baselines are preserved, the export file is redundant. If something goes wrong, the export file is the difference between a recoverable and an irrecoverable situation.

Run the free Schedule Health Check Upload your .mpp file to see which baseline slots survived migration, which are empty, and what the variance calculations look like with the baselines that remain. Takes under a minute, no signup required. → Open Schedule Health Check

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