What survives the export: XER, P6 XML and MPP compared

The four formats, briefly

• MPP. Microsoft Project's binary working file. Complete by definition, since it is the file MSP itself works on, and proprietary by design. Nothing else writes it, and everything else that reads it does so by reverse engineering.
• MSPDI XML. MSP's documented XML export. Readable by almost everything, and lossy in specific places: it is an export of the schedule as data, not of the working file, and some of what MSP keeps internally never makes it out.
• XER. P6's tab-delimited flat text export. Near-complete for schedule data within one database's worth of context, with quirks that come from its age: single-byte character encoding, calendars serialised as an inline nested-bracket blob rather than structured records, and everything keyed on internal database IDs.
• P6 XML (PMXML). Oracle's sanctioned exchange format and the one they actively maintain. Structured, schema-defined, and the only P6 export that can carry a baseline project inside the same file.

The general rule: a native file read natively loses nothing, an export loses a little, and an import loses more, because the receiving tool has to force what arrived into its own vocabulary. The interesting question is always which little.

Baselines: the most common casualty

XER carries no baselines at all. What people mistake for a baseline in an XER is the planned or target date set, which P6 populates from current values and which tools reading the file surface as a baseline substitute. In P6, a real baseline is a separate project in the database, and it only travels if someone deliberately exports it as one. If a counterparty sends a single XER and the variance report references a baseline, you cannot check that variance from the file you were sent. Ask where the baseline lives.

PMXML fixes this: the schema can embed a baseline project alongside the current one, which is the strongest practical argument for requesting P6 XML instead of XER. The failure mode is that the export dialogue makes including the baseline optional, and most people click through without ticking it, so specify it in the data request.

On the MSP side, baselines 0 to 10 live in the MPP file, including the estimated variants MSP writes when a baseline was captured on auto-scheduled tasks without hard dates. MSPDI carries baseline fields too, but the set thins out relative to the binary, and any onward import typically keeps one baseline at best. If a dispute may ever turn on Baseline 3 versus Baseline 0, the MPP is the record.

Calendars: the top cause of shifted dates

When dates move after an import and nobody edited anything, look at calendars before anything else. The two tools model them differently: hours per day, working-week patterns and exception lists all exist in both, but the mapping is approximate. A P6 calendar with 10-hour days imported into an MSP environment that assumes 8 changes every duration displayed in days without changing a single duration in hours, and suddenly the durations "grew". Exceptions (holidays, shutdowns, half days) survive the export formats themselves reasonably well; what mangles them is the import step, where the receiving tool maps them onto its own calendar structures and quietly drops the ones it cannot represent.

XER deserves a specific warning here. Its calendars are stored as a nested inline text blob, and tools vary in how faithfully they parse it. Two readers can open the same XER and disagree about working time, which means they disagree about dates. If a date discrepancy between two parties traces back to the calendar, compare the calendar definitions first, then argue about logic.

Resources, rates and costs

Resource assignments themselves travel well in every format: who is assigned, how many units, how many hours. What thins out is the pricing machinery behind them. P6 rate tables with effective dates, cost accounts, and expense items have no clean MSP equivalent, so an XER or PMXML landing in MSP keeps the assignment and loses the costing structure, or collapses it into a single rate. Going the other way, MSP cost rate tables A to E and fixed costs on tasks degrade similarly into P6. If the review is about cost loading, review in the native tool or from the native file. A converted cost number is a derived number, and it will not reconcile to the source system to the cent.

Activity codes, custom fields and UDFs

This is the classic mapping casualty. P6 has activity codes (hierarchical, project or global scope) plus user-defined fields. MSP has custom fields Text1 to Text30, numbers, flags, dates and outline codes. There is no natural correspondence, so every conversion invents one: codes land in arbitrary text columns, hierarchies flatten, global codes lose their dictionary, and the second time the same file makes the trip the mapping is different. Any reporting, filtering or grouping built on the coding structure should be treated as unavailable after a format hop unless someone has explicitly rebuilt the mapping and documented it.

Constraints: two vocabularies, one-way traffic

MSP has roughly ten constraint types, from As Soon As Possible through the no-earlier and no-later pairs to Must Start On and Must Finish On. P6 has its own set, including Mandatory constraints that override logic and an As Late As Possible that behaves differently from MSP's. The sets overlap without matching, so importers substitute the nearest available type. A Mandatory Finish becomes a Must Finish On, which sounds equivalent and is not: one wins against logic, the other negotiates with it. After any conversion, a constraint listing from before and after is a ten-minute check that regularly explains otherwise mysterious float.

Progress: the values survive, the recalculation differs

Actual starts, actual finishes, remaining durations and percent complete generally make the trip intact in every format. Two cautions. First, percent complete is not one number: P6 distinguishes duration, physical and units percent complete, and whichever one drove the update needs to land in the field the receiving tool actually uses. Second, the receiving tool reschedules on arrival under its own rules, its own calendars and its own handling of out-of-sequence progress, so the same actuals can produce different forecast dates. The progress data survived; the schedule it implies did not, exactly.

MSPDI earns an honest warning here: import of progressed tasks is the least reliable part of the format in practice. In-progress tasks with splits, where work stopped and resumed, are routinely mangled by importers, with the split collapsed or the resume date shifted. A statused programme that has been through MSPDI should have its in-progress tasks spot-checked against the source before anyone quotes a forecast from it.

The round-trip warning

A file that has been through tool A to tool B and back to tool A is not the file you started with. Each hop applies a mapping, and mappings compose destructively: constraints substituted, calendars approximated, codes re-homed, IDs reassigned. The second-generation file can look plausible while carrying dozens of small divergences, which is worse than looking wrong. This leads to the practical rule: when the job is review rather than editing, analyse the native file the other party actually issued. Import only when you genuinely need to edit or integrate, and when you do, keep the original alongside as the reference artefact. The counterargument is real, sometimes the contract mandates a format nobody works in natively; in that case the mandated export is the contractual record, and the review should cover both it and the native file, plus the differences between them.

If you need it to survive, send this

• A P6 baseline: PMXML with the baseline project explicitly included. Never bare XER.
• MSP baselines beyond Baseline 0: the MPP itself.
• Full P6 schedule data between P6 databases: XER is fine and universally accepted; PMXML is the better default where both ends support it.
• Cost and rate structures: native format only, reviewed in or against the source tool.
• Coding structures for reporting: native format, or a documented field mapping agreed before the first exchange, then never changed.
• A progressed MSP schedule for review: the MPP, given the MSPDI behaviour on in-progress splits above.
• Something a spreadsheet or unknown tool must read: MSPDI or XER, with the understanding that it is a data extract, and dates recalculated from it are the reader's, not the scheduler's.

And whichever format is agreed, agree it once, early, in the schedule management plan, together with who owns the mapping. Most exchange losses are not caused by the formats. They are caused by the format being chosen at 4pm on submission day.