Validate Data After Project Online Migration: The Audit

"Import successful" is the most dangerous sentence in any Project Online migration. It confirms the tool moved bytes from one system to another. It says nothing about whether those bytes are the same schedule you had before, which is exactly why you validate data after migration instead of taking the log at its word. By the time anyone finds out otherwise, the wrong numbers have already fed a status report, a resourcing decision, or a slide in front of a sponsor.

Every migration tool logs success when the import job finishes without throwing an error. That log entry means the file parsed and every row landed somewhere. It does not mean the row landed in the right field, that a dependency kept its lag value, or that a baseline is a genuine historical snapshot instead of a flat copy of the current schedule. Those failures are silent by design: nothing crashes, nothing shows a red banner, and the Gantt chart looks correct at a glance. The only way to catch them is to validate data after migration deliberately, before anyone builds on top of it.

Why "Import Successful" Isn't the Same as Correct

A migration tool's success message answers one narrow question: did the parser reach the end of the file without an unhandled exception? That is a useful signal, but it is a parsing signal, not a data-fidelity signal. The parser can succeed while dropping a field it doesn't recognize, flattening a structure it doesn't support, or silently defaulting a value it can't map.

This is why the audit discipline behind missing baselines after migration exists as its own post: a tool can report a clean import while every baseline in the portfolio has silently collapsed into a copy of the current schedule. The failure is invisible until someone opens the variance view three weeks later and finds every project reporting zero variance, which reads as good news until you realize it means the comparison data is gone, not that performance is perfect.

Treat the import log as step zero, not step done. It tells you the migration didn't crash. Whether it's correct is a separate question that needs its own evidence.

The Eight-Layer Audit: How to Validate Data After Migration

Work through eight layers in sequence, from coarse to fine, to validate data after Project Online migration properly. Each layer catches a different failure mode, checks against a specific view or query in both systems, and carries its own tolerance, so running them in order means you find the cheap-to-fix problems before spending time on the expensive ones.

1. Task counts and dates. Pull the original Project Online project list and match it against the destination tool, project for project, task for task. The view that proves it: the project's task list export, sorted by task ID, on both sides. Tolerance: zero. A task count mismatch is the fastest, cheapest signal that something didn't import cleanly, and it should be the first thing you check on every project.
2. All four dependency types with lag. Finish-to-Start is the easy case almost every migration tool handles correctly. Confirm Start-to-Start, Finish-to-Finish, and Start-to-Finish dependencies carried their lag or lead values, not just the relationship type. The view that proves it: a dependency export listing predecessor, successor, type, and lag for every task, diffed side by side. Tolerance: zero on relationship type; zero on lag value. A dependency that imports as FS with no lag when it was SS with a 3-day lag in the source changes the computed critical path without anyone noticing.
3. Calendars and resource exceptions. The enterprise base calendar and every resource-specific exception (holidays, part-time schedules, approved leave) have to carry across, not just the task dates that were computed from them. The view that proves it: open the resource calendar for a sample of five resources per project on both systems and diff working versus non-working days across the project's active date range. Tolerance: zero difference on non-working days. A migration tool that silently defaults every resource to a standard five-day week will shift computed finish dates without throwing a single error.
4. Baseline snapshots, not flat copies. A baseline that matches the current schedule exactly, field for field, almost certainly imported as a copy rather than a preserved historical snapshot. The view that proves it: the variance view, described in the baseline-collapse section below. Tolerance: zero tolerance for a baseline that is a byte-for-byte copy of current dates across more than a handful of projects. Every variance report depends on the baseline being a true point-in-time capture, which is why this layer is where the most consequential silent failures hide, as detailed in migrating Project Online baselines without losing history.
5. Custom field values, not just field names. A custom field that exists in the destination tool with the right label but shows blank or default values for every migrated project has a mapping problem: the field structure moved, the data didn't. The view that proves it: a field-by-field export of the five most-used enterprise custom fields, compared value for value, not just checking the column header exists. Tolerance: zero for blank values where the source had data.
6. Resource assignment percentages against original allocations. Assignment percentages sometimes survive import while the underlying leveling delays that had adjusted them do not, which quietly shifts computed finish dates earlier than the source schedule actually supported. The view that proves it: the assignment view for each task, comparing allocation percentage and any leveling delay field. Tolerance: five percent variance to absorb rounding between systems, zero tolerance for a leveling delay that disappears entirely.
7. Actuals: actual start, finish, work, and percent complete. Actuals are what turn a schedule into a status report, and they are also the fields migration tools most often deprioritize because they don't affect whether a file "opens correctly." The view that proves it: pull Actual Start, Actual Finish, Actual Work, and Percent Complete from both systems for every task that has started, and diff them task by task. Tolerance: zero for a task showing 0% actual work in the destination when the source records completed work; five percent variance on Actual Work hours is acceptable to absorb rounding between hour-based and day-based time units.
8. Portfolio metadata: EPTs and enterprise lookup tables. Beyond individual project fields, Enterprise Project Types (EPTs) and portfolio-level lookup tables (department, program, strategic driver) determine how a project rolls up into portfolio reporting. The view that proves it: the portfolio-level report or project center view used before migration, checked against the destination's equivalent grouping field for every project. Tolerance: zero. A project that silently reclassifies into the wrong program or portfolio bucket changes which executive dashboard it appears on, and nobody notices until a rollup number looks wrong months later.

The diagram below shows these eight layers as a validation gate: a project only reaches the sign-off document after clearing every layer, and a failure at any layer routes the project to a hold list rather than letting it through by default.

Run these eight checks against a sample before running them against the full portfolio. If layer four (baselines) fails on more than a handful of projects, stop and diagnose the migration tool's baseline handling before continuing the audit; a systemic failure caught early is a configuration fix, while the same failure discovered project by project across a 150-project portfolio is weeks of manual rework, and it's the kind of finding that turns your migration from a scheduling exercise back into a data-engineering problem.

How Do You Verify All Four Dependency Types Survived?

Dependency verification is where most audits get shallow, because Finish-to-Start dependencies are common, easy to eyeball, and rarely broken. The other three types are where migrations quietly fail.

Pull a dependency export from both the Project Online source and the destination tool, then compare relationship type and lag value side by side for every non-FS dependency in the project. Start-to-Start dependencies with a lag are especially prone to importing as plain FS, because some migration tools default unmapped relationship types to Finish-to-Start rather than flagging them as unsupported.

The consequence compounds. A dependency that silently changes type doesn't just misrepresent one relationship; it changes the computed critical path, which changes float on every downstream task, which means every schedule risk assessment built on top of the migrated data is working from a wrong picture without any visible error. For the mechanics of what specifically goes wrong at the dependency layer, see broken dependencies after migration, which catalogs the failure patterns this audit step is designed to catch.

Detecting Baseline Collapse Before Variance Reporting Breaks

Project Online stores baseline data in fields separate from the current schedule: BaselineStart, BaselineFinish, BaselineWork, and BaselineCost for the primary baseline, with BaselineXStart through BaselineXCost for baselines 1 through 10. A migration tool that imports current schedule fields correctly can still fail this layer entirely if it never reads the BaselineX fields at all.

The tell is specific and checkable in minutes: open the variance view for a sample of migrated projects. If baseline dates match current dates exactly, project after project, the baseline imported as a copy, not a snapshot. Genuine baselines almost never match current dates perfectly across an entire portfolio; real projects drift, and a drift-free baseline is itself the signal something is wrong.

If baseline collapse shows up in your sample, export Project Online data for the BaselineX fields directly via OData while the source tenant is still live, and treat the fix as a re-import of baseline data specifically, not a full re-migration. Waiting to discover this after the source tenant goes read-only turns a data-mapping fix into a permanent, unrecoverable loss.

Building the Line-by-Line Comparison Method

A spot check tells you a problem might exist. A line-by-line comparison tells you exactly which projects and which fields are affected, which is what a sign-off document actually needs.

1. Export the source of truth. Pull a complete OData export of every project, task, dependency, baseline, custom field, and assignment from Project Online before it goes read-only.
2. Export the same scope from the destination. Match the export to the same field set and the same project list, project ID to project ID.
3. Diff programmatically, not visually. Load both exports into a spreadsheet or a lightweight script and compare row by row. Visual comparison across more than a handful of projects misses exactly the silent, single-field discrepancies this audit exists to catch.
4. Log every discrepancy with its tolerance status. A discrepancy inside your pre-set tolerance (see below) gets logged and passed. A discrepancy outside tolerance routes the project to the hold list.
5. Re-run after any re-import. A fix to one field mapping can introduce a regression in an adjacent field; re-run the full comparison, not just the field you fixed.

Set your tolerance before you see the results, not after. A defensible working threshold for most PMOs is zero tolerance for missing tasks, missing dependencies, or missing baselines, paired with a five percent variance ceiling for cost and duration fields, which absorbs rounding differences between systems without absorbing an actual data-mapping bug. Choosing tolerance after seeing which projects fail is how audits quietly get watered down until nothing fails.

What Tools Skip Silently

Every migration tool documents what it imports. Almost none document, with the same prominence, what it silently drops. The gaps worth checking explicitly, because they rarely appear in a migration tool's marketing material:

• Baseline history beyond baseline zero. Many tools import only the active baseline, dropping baselines 1 through 10 without a warning, even though PWA supports up to eleven per project.
• Lag and lead values on non-FS dependencies, as covered above.
• Enterprise Custom Field lookup table values, as opposed to just the field definition. A dropdown field can migrate with its structure intact and every stored value blank.
• Resource calendar exceptions tied to individual resources rather than the enterprise calendar, which quietly changes computed working time for those resources' assignments.
• Deleted-but-not-purged tasks that still appear in OData exports and can inflate task counts on the source side in a way that makes an otherwise-correct migration look like it lost data, when the real issue is a comparison artifact.
• Actual work on tasks re-leveled after the actual was recorded, which overwrites the historical actual with a recalculated value and makes percent-complete disagree with the hours actually logged.
• EPT and portfolio lookup table membership, since a project can migrate with every task field intact and still land in the wrong portfolio grouping if the destination tool maps enterprise project types by name rather than by ID.

Before starting your comparison, ask your migration tool's documentation, or its vendor directly, which of these seven it handles and which it doesn't. A vendor who can answer specifically is a different signal than one who says "everything migrates."

The Sign-Off Checklist a PMO Lead Can Hand to Auditors

The end product of this audit isn't a feeling that the data looks right. It's a document with enough specificity that someone outside the migration team, a compliance auditor, a new PMO director eighteen months from now, can verify the claim without redoing the work.

For each project, the sign-off record should capture:

1. Project ID and name, matched between source and destination.
2. Task count in source versus destination, with any discrepancy explained.
3. Dependency audit result: pass or fail, by dependency type, with lag values spot-checked.
4. Calendar audit result: working and non-working days diffed for the resource sample, exceptions noted.
5. Baseline audit result: confirmed as historical snapshot, with the baseline date range noted.
6. Custom field audit result: fields checked, with any blank-value fields flagged.
7. Assignment audit result: allocation percentages compared, with any leveling-delay discrepancy noted.
8. Actuals audit result: actual start, finish, work, and percent complete compared task by task.
9. Portfolio metadata audit result: EPT and lookup table grouping confirmed for every project.
10. Overall status: passed, passed with noted exceptions, or held for remediation.
11. Auditor name and date.

Store this alongside the project in your document management system, not in a spreadsheet that lives only on the migration lead's laptop. When a 2029 audit request asks whether a specific project's data was verified after migration, this record is the answer, and "we're pretty sure it was fine" is not an acceptable substitute for it.

When to Escalate: What Validation Failures Mean for Go-Live

Not every discrepancy should stop a rollout, but every PMO needs a pre-agreed threshold for what does. A single custom field with a mapping gap on one low-priority project is a remediation ticket. Baseline collapse across more than 10 percent of a sample, or a systemic dependency-type failure, is a stop-the-rollout finding: continuing to migrate more projects on a broken pipeline just multiplies the cleanup.

Escalate systemic findings to whoever owns the migration decision, using the specific evidence from the sign-off checklist, not a general concern. "Baselines failed the audit on 14 of our first 20 migrated projects, all showing baseline dates identical to current dates" is a finding a sponsor can act on. "Something seems off with the data" is not.

The free Schedule Health Check runs a version of the dependency and baseline checks in this audit against your own .mpp file, which is useful both for validating a destination-tool export and for confirming what a source Project Online file actually contains before you migrate it. For teams still deciding what to expect before cutover, the Migration Preview tool shows which data elements are likely to survive the tool boundary for a given file, which pairs well with this audit as an upfront check rather than a replacement for it.

Run the free Schedule Health Check Upload a .mpp or MSPDI XML from your destination tool and get a per-project breakdown of dependency integrity, baseline presence, and critical path validity, the same checks this audit runs by hand. No signup required. → Run the Schedule Health Check

Microsoft's Project Online lifecycle page confirms September 30, 2026 as the retirement date, which sets a hard limit on how long the source data stays live for comparison. Run this audit while Project Online is still reachable; every week closer to the deadline is a week less time to re-export anything the comparison flags.

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