Using MSPDI XML to Migrate Project Online: When and Why
Most migrations from Project Online default to .mpp. For version-mismatch or interop cases, MSPDI XML export is safer. When to use it and what to watch for.
Most Project Online migration guides treat .mpp and XML as interchangeable. They are not.
Both formats export from the same source, Project Professional connected to Project Online, and both carry task, dependency, and resource data. But the cases where each format performs better are specific enough that choosing the wrong one without thinking about it first costs time during import validation. Some destination tools read MSPDI XML more faithfully than they read .mpp binaries. Some migration scenarios produce corrupted .mpp files that export cleanly as XML. And for any organization that needs to inspect or transform project data between export and import, XML is the only format that actually supports that.
TL;DR: .mpp vs MSPDI XML
Use .mpp when the destination tool explicitly supports it and you want maximum fidelity for complex schedule data. Use MSPDI XML when you need a version-independent format, when the destination import engine prefers XML, or when you need to inspect or transform the data between export and import. Both formats cover the same core data; the differences are in calculated fields, binary-only features, and tool compatibility.
What is MSPDI XML?
MSPDI stands for Microsoft Project Data Interchange. It is an XML schema defined by Microsoft that represents project schedule data in a structured, text-based format. Unlike the .mpp binary format, which encodes project data in a proprietary compressed structure, MSPDI XML is a plain-text file you can open in any text editor or XML parser.
The schema covers the same primary data types as a .mpp export: tasks with their attributes, dependency relationships between tasks, resource definitions, resource assignments, calendar definitions, and project-level properties. It also includes baselines if the project has them. Microsoft publishes the complete schema reference at Project XML Data Interchange Schema Reference on Microsoft Learn.
The MSPDI schema has been relatively stable across Microsoft Project versions since Project 2007. A file exported as XML from Project Online today should be readable by any tool that supports the MSPDI specification, regardless of which version of Project Professional was used to export it. This version independence is the key practical advantage over .mpp.
When MSPDI XML beats .mpp for Project Online migration
Four scenarios consistently favor MSPDI XML as the export format.
Destination tool has native XML support but limited .mpp support. Several project management platforms support MSPDI XML import as a deliberate design choice, because implementing an MSPDI XML parser is simpler than reverse-engineering the .mpp binary format. If your destination tool's import documentation specifically calls out MSPDI XML, use XML. Attempting a .mpp import on a tool that only half-supports the binary format produces silent data loss that is harder to debug than a schema mismatch in XML.
Version mismatch between the exporting client and the destination tool. The .mpp binary format has different versions: Project 2010, 2013, 2016, 2019, 2021. A .mpp file saved by Project Professional 2021 (connected to Project Online) imports differently in a tool calibrated to the 2013 binary format. MSPDI XML sidesteps this entirely because the schema is version-independent.
You need to inspect or transform data before import. If your migration plan involves cleaning up data between export and import, such as retiring obsolete custom field values, correcting date errors, normalizing resource names, or filtering tasks by status, XML gives you that option. You can write a simple XSLT or Python script to transform the XML before loading it into the destination. You cannot reasonably transform a binary .mpp file without going through Microsoft's object model.
Archival for compliance. Some organizations need to retain project data in a format that is readable without proprietary software. MSPDI XML satisfies most compliance requirements for text-based archival. A .mpp file opened 15 years from now depends on whether a compatible version of Microsoft Project still runs.
When .mpp beats MSPDI XML
Maximum schedule fidelity for complex projects. The .mpp binary format stores some calculated fields and internal scheduling metadata that MSPDI XML does not represent, or represents differently. For projects with complex earned value tracking, cost resource rate tables, or macro-driven schedule automation, the .mpp export is the more complete capture of what was in the plan.
The destination tool has a mature .mpp parser. If the tool you are migrating to has invested in a high-fidelity .mpp parser (as Onplana has), the binary format is the right choice because the parser accounts for the nuances of the format that an XML schema representation can miss. The Migration Preview tool, which accepts both .mpp and XML, will tell you which format produces a cleaner import for your specific files.
Speed. Opening and saving a project as .mpp from the desktop client is marginally faster than as XML, because .mpp is the native format and no serialization step is needed. This is not a meaningful factor for small portfolios but can matter when scripting hundreds of exports.
The comparison table below summarizes the key differences.
| Dimension | .mpp binary | MSPDI XML |
|---|---|---|
| Tasks, dependencies, resources | Full fidelity | Full fidelity |
| All four dependency types (FS/SS/FF/SF) | Yes | Yes |
| Lag and lead values | Yes | Yes |
| Baselines (up to 11) | Yes | Yes, as separate Baseline elements |
| Enterprise Custom Field values | Yes | Yes |
| Calculated fields (EVM, cost totals) | Full | Partial |
| Resource cost rate tables (A-E) | Yes | Limited |
| Version independence | No | Yes |
| Human-readable / transformable | No | Yes |
| Typical file size | Smaller | 3-5x larger |
| Import compatibility (most tools) | Good to excellent | Good |
How to export MSPDI XML from Project Online
The export process is identical to .mpp export, with one change: the file format selection.
Step-by-step:
Open the project in Project Professional connected to your Project Online tenant. Wait for the schedule to load fully.
Go to File > Save As.
Select Computer as the save location (not Project Online).
In the Save as type dropdown, select XML Format (*.xml) rather than Project (*.mpp).
Name the file. Use a consistent convention:
ProjectName_YYYYMMDD.xml. The same naming rules as .mpp apply.Click Save. If the project has VBA macros, Project Professional will warn you that macros cannot be saved to XML format. Confirm and proceed; the macros are not part of the migration anyway.
The resulting file is an MSPDI XML document. Open it in a text editor to confirm it starts with <?xml version="1.0" encoding="UTF-8"?> followed by a <Project> root element. If it is empty or contains error text, the export failed.
Gotchas of the MSPDI schema
Constraint type encoding. MSPDI XML represents constraint types as numeric codes: 0 for As Soon As Possible, 1 for As Late As Possible, 2 for Must Start On, and so on. If the destination import engine interprets these codes differently, tasks end up with the wrong constraint, which silently breaks critical path calculations.
Lag values on dependencies. MSPDI XML encodes lag in a duration string format (for example, PT8H0M0S for 8 hours). Positive lag and negative lag (lead) are both represented as duration strings, with negative values prefixed by a minus sign. Some import engines misparse the negative lag format and import leads as positive lags.
Calendar exceptions. Project Online schedules often use calendar exceptions for company holidays. MSPDI XML includes calendar exception data in the <Calendars> section, but the format for recurring exceptions (such as a floating holiday like Thanksgiving) is more complex than for fixed-date exceptions. Verify that your calendar exceptions imported correctly by checking a task that spans a holiday: its duration should account for the non-working day.
Baseline encoding. MSPDI XML represents baselines through baseline elements within each <Task>. A project with all 11 baselines populated has 11 baseline entries per task. Some import engines only read Baseline (the first baseline, numbered 0) and ignore Baseline1 through Baseline10. If preserving all baselines matters for your audit requirements, verify the destination tool's behavior before committing to MSPDI XML.
Summary task rollup behavior. In some versions of the MSPDI schema, summary task dates are stored explicitly rather than being recalculated from child tasks. If the destination tool recalculates summary dates from children and the children have slightly different schedules due to calendar differences, the summary task dates will not match what was in Project Online. This is usually cosmetic, but it produces confusing validation discrepancies.
What to validate after an MSPDI XML export
Before importing the XML into your destination tool, run a quick structural check on a sample of the exported files.
Use any XML viewer or the following PowerShell snippet to inspect the key counts:
param([Parameter(Mandatory)][string]$XmlPath)
[xml]$doc = Get-Content $XmlPath -Encoding UTF8
$ns = @{ ms = "http://schemas.microsoft.com/project" }
$tasks = Select-Xml -Xml $doc -Namespace $ns -XPath "//ms:Task"
$resources = Select-Xml -Xml $doc -Namespace $ns -XPath "//ms:Resource"
$assignments = Select-Xml -Xml $doc -Namespace $ns -XPath "//ms:Assignment"
$dependencies = Select-Xml -Xml $doc -Namespace $ns -XPath "//ms:PredecessorLink"
Write-Host "Tasks: $($tasks.Count)"
Write-Host "Resources: $($resources.Count)"
Write-Host "Assignments: $($assignments.Count)"
Write-Host "Dependency links: $($dependencies.Count)"
Compare these counts against the Project Online project detail page for the same project. If the task count is off, the export captured an intermediate state of the schedule rather than the published version.
After import into the destination tool, apply the same validation checks used for .mpp imports: task count match, dependency type and direction spot-check, baseline date comparison on a sample of tasks, and custom field value verification.
The Project Online Inventory Checklist is the right starting point before any bulk export. Run it first to count what you have, then use the results to verify your export is complete.
Choosing the right format for each project
Not all projects in your portfolio need the same export format. A reasonable approach for a mixed-complexity portfolio:
- Use MSPDI XML for projects where you need to inspect or transform the data, where the destination tool documentation recommends XML, or where version mismatch was a known issue during testing
- Use .mpp for the majority of projects, especially those with complex earned value tracking, cost resource tables, or calculated fields that need maximum fidelity
- For any project where you are unsure, export both and run both through the Migration Preview tool to compare what each format produces
For most PMOs, the .mpp format is the right default. MSPDI XML is the right tool when a specific condition makes .mpp the worse choice. Knowing the difference before migration day saves debugging time during validation.
A full discussion of the .mpp export process, including batch scripts and throttle handling, is in how to export Project Online to mpp step by step. If you also need to migrate historical data that lives outside the project files themselves (timesheets, resource pool metadata, custom field values across the portfolio), the Project Online OData export guide covers that path.
Preview your MSPDI XML import before committing Upload your .xml file to the free Migration Preview tool and see which schedule features transfer cleanly into Onplana and which need manual attention. No signup required. Open Migration Preview
Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.