Trestle Path AnalyticsSchedule Review, On Your Computer

Guide · MS Project XML

Reviewing a Microsoft Project schedule from its XML export

Most schedule review tooling was built for Primavera P6, and a Microsoft Project file is a different animal: a different key for each task, a different calendar model, lags in three units, and an export that can quietly contain part of the schedule. This guide covers what the XML export carries, how two exports are compared honestly, and where the review has to say "the file cannot tell me".

Reviewed 27 September 2026Trestle Path Analytics Corp.Worked example: Vireo Line demonstration set5 min read

Start the free trial See how it is checked

Sign in ↗Product tour →Pricing →

The short answer

Save the schedule from Microsoft Project as XML (the MSPDI format) and Trestle Path Analytics reads it in the browser, without Project installed and without uploading it: the critical path recomputed from the logic, the DCMA checks, the month-over-month comparison and the delay analysis all run on it. Tasks are matched between two exports by Project's Unique ID, never by row number; the data date is the file's Status Date; lags are read in the unit Project stored them in; and where Project's export leaves something out (the Active flag, part of the schedule), the review says it cannot tell rather than reporting a false change.

Read from the XML exportMatched by Unique IDStatus Date as the data dateSays when it cannot tell

What the XML export carries

File › Save As › XML Format in Microsoft Project writes an MSPDI file: every task with its Unique ID and row ID, dates, durations, percent complete, constraints, calendars, predecessor links with their lags and lag formats, resources and assignments, stored baselines (Baseline, Baseline1 to Baseline10), custom fields and the Status Date. It is complete enough to review from. Three things it does not carry, compared with a P6 XER: activity types (a task is a task; level-of-effort and milestones are inferred from summary flags and zero durations), activity codes (only custom fields and outline codes), and resource curves. What is missing is stated on the pages that depend on it rather than approximated.

Matching two exports: Unique ID, not row number

The row number in Project (the ID column) changes whenever a task is inserted, deleted or moved. A comparison that pairs tasks by row number reports thousands of changes an ordinary monthly update never made. On a real pair of April and June exports of one 2,165-task project, row matching produced 1,490 false renames and 2,124 false "actual dates changed"; matching by Unique ID reports 103 added tasks, 1 deleted, 0 renames and 6 moved actual dates. Trestle Path keys every Project task by Unique ID, shows the row number beside it ("2759 · row 1050"), and applies the same key to the baseline file, the engine and the windows analysis. The pairing check confirms that the shared Unique IDs name the same tasks, names the two ways it can fail (unrelated projects, a rebuilt file), warns rather than passes when fewer than ten tasks are shared, and refuses to compare a P6 file with a Project file as a pair.

Six traps in Project files, and what the review does about them

TrapWhat happensWhat Trestle Path does
The data dateProject has a Status Date and a Current Date; only the first is the data date, and it is often left unsetReads the Status Date. Without one it falls back to the latest actual finish and says so; with neither, the review is refused with instructions for setting a Status Date.
Lags in three unitsA lag can be working time, elapsed time or a percentage of the predecessor. "2YRS after Rock Weir" is 720 calendar days, not 2,160 working daysReads each lag in its own unit and counts it on the successor's calendar (or the project calendar), as Project does. A change of lag kind between updates is always reported as an edit.
Started tasksA started task's remaining work resumes from its Resume date, not its actual start; split tasks have their ownTakes the remaining start from Resume, keeping split tasks' resume dates.
Stored baselinesA file can hold up to eleven baselines; the default one is not always the contractual oneThe upload card lists every stored baseline with its coverage; you choose, the choice is remembered per project and named on the DCMA page and in the workbook. A baseline file in the Baseline slot overrides the embedded ones.
The Active flagProject's own export writes no Active field at all, so "inactive tasks: 0" means "cannot say"Says exactly that, on the Data Mapping page, instead of reporting zero as a fact.
Partial exportsProject can save an XML holding only part of the schedule, with the rows renumbered from zero and no gap; a first July export held 1,864 of 2,165 tasks and read as 196 deletions, 104 of them completed workCautions wherever deletions are listed that a shorter file may be a partial export, and to re-export before concluding that work was removed. The re-export gave all 2,165 tasks and zero deletions.

Links on summary tasks are a seventh. Project allows them; a CPM network does not have summaries. They are listed on Logic & Network Health and named on the delay pages as not in the network, rather than silently dropped or silently applied to the child tasks.

Reviewing a Project schedule in Trestle Path Analytics

  1. In Project, set the Status Date (Project › Project Information) and save as XML. Export the whole schedule, not a filtered view.
  2. Load the XML as the current schedule; last month's XML as the prior; the baseline XML, or choose an embedded baseline on the upload card.
  3. Press Run. The float and duration figures come from the stored hours, not rounded days; the critical path is recomputed from the logic.
  4. Read Data Mapping first: it says what the file contained, what was carried into the review, what was held out and why, and where Project's export could not answer.
  5. Then the review as for any schedule: DCMA, critical path, month-over-month, delay analysis, the workbook.

How the Project path is checked

The Project path has its own test suite (114 checks, in the release gate) with two reference pairs of Project files and deliberate breakages that the checks must catch; it was audited three times in September 2026, with every finding reproduced, fixed and published. The P6 path is proved unchanged alongside it: six P6 reference schedules give byte-identical results before and after each Project change. Real April, June and July 2026 exports of one project, in both .xml and .mpp, are the files the traps above were found on. Still unconfirmed on a real file: percent lags and external links, which those schedules do not carry.

Limits

  • Convert .mpp yourself. The product reads XML; save as XML from Project (or convert with a tool such as MPXJ). There is no in-product .mpp converter.
  • Thinner registers. With no activity codes, types or resource curves, the calendar, resource and code-based views are thinner for a Project pair than for a P6 pair, and the DCMA checks that depend on activity types rely on the file's summary and milestone flags.
  • Summary-task logic is reported, not applied to the child tasks.
  • Logic repair (the dangling and redundant tools) analyses and reports a Project schedule but writes a repaired file only from an XER, because the repair is written into a copy of the original P6 file.

Where to find it

Microsoft Project XML is read on every plan, from the Reader plan up, and in the fourteen-day trial. Current prices are on the pricing page.

Fourteen days free

Try it on your own schedule

Fourteen days free, no credit card, every section open. Your XER or XML file is read in your browser and never uploaded; only anonymous numbers reach the calculation service, and nothing is stored.

Start the free trial See the plans

RelatedHow to compare two schedule updatesDCMA 14-point assessmentReading a P6 XER without P6