The client works in MS Project and you work in Primavera P6. Or the other way around. Someone has to convert the schedule, and every time it is done "with whatever is at hand", something gets lost: a calendar, twenty lags, the entire critical path. This guide explains what changes between the two data models, the right way to convert and how to verify the result in ten minutes.
Why it is not a simple "Save As"
Primavera P6 and MS Project represent the same schedule with different structures. Conversion does not copy a file: it translates one model into another, and every translation loses something if it is not controlled. These are the points where it breaks most often:
| Concept | Primavera P6 | MS Project | Conversion risk |
|---|---|---|---|
| Calendars | Global, project and resource calendars; hours/day defined per calendar | Base calendar + task calendars; hours/day in the project options | High: durations stored in hours are reinterpreted if hours/day do not match |
| WBS | A structure independent of the activities | Nested summary tasks | Medium: empty levels or lost WBS codes |
| Relationships and lags | Lag calculated on the successor or predecessor calendar (configurable) | Lag on the successor task calendar | Medium: 1 to 3 day shifts on long lags |
| Constraints | Start On, Finish On, Mandatory, As Late As Possible… | Fewer types; Mandatory does not exist | Medium: hard constraints are downgraded to soft ones or vice versa |
| LOE and WBS summary activities | Dedicated activity types | Do not exist | High: an LOE converted into a normal task can become critical |
| Percent complete | Duration, physical or units (selectable) | % Complete (duration) and % Work Complete | Medium: physical progress is lost if it is not mapped to a custom field |
| Codes and UDFs | Activity codes and user-defined fields | Custom fields Text1…Text30, etc. | Low if mapped; high if ignored |
| Baselines | Several, stored as separate projects | Up to 11 inside the file | Medium: exporting without a baseline leaves the client with no reference |
The number one cause of different dates after a conversion is the calendar: a P6 schedule with 10 hours/day and 6 days/week opened in an MS Project set to 8 hours/day and 5 days/week stretches the project by whole weeks without touching a single duration.
Three ways to convert
- Export from P6 to MS Project XML. P6 Professional does this from File → Export → Microsoft Project XML. It works for simple networks, but it is known for losing multiple calendars and activity codes, and for generating odd summary tasks when the WBS has levels with no activities.
- Convert with a specialized tool. TecnoAdmin's The Converter reads the .xer directly and generates a ready-to-open .mpp or .xml, preserving the WBS, relationships, lags, calendars, constraints and codes as custom fields. It also works in reverse (.mpp → .xer) and exports Candy backups to Excel. It is free and requires no installation.
- Rebuild by hand. This only makes sense for small schedules or when the target requires a very different structure. Beyond 200 activities, the risk of human error outweighs any benefit.
See all our free schedule tools, including the converter and the DCMA validator, on TecnoAdmin Products.
Step by step: XER to MPP with The Converter
Clean up the schedule in P6
Run Schedule (F9) with the correct data date, delete orphan activities and codes, and check that there is no unexplained negative float. Whatever is broken in P6 will arrive broken at the destination.
Export the .xer
File → Export → Primavera PM (XER). Export only the project, without unnecessary global resources. If the client needs the baseline, also export the baseline project or keep its .xer at hand.
Upload the file and choose the format
In The Converter, drag in the .xer, review the preview (number of activities, start and finish dates, detected calendars) and choose MS Project .mpp or .xml. If you have the baseline, load it in the same step.
Open in MS Project and recalculate
Once it opens, press F9. In Project → Project Information, confirm that the status date matches the P6 data date and that all tasks are in Auto Scheduled mode.
Verify
Do not deliver without running the checklist in the next section. Ten minutes now saves the week of arguing that follows when the client finds the discrepancy.
A 10-minute verification
Compare the original and the converted file on these eight points. Any difference has a specific cause, and it is almost always in the risk table above.
| Check | Expected result | If it does not match, review |
|---|---|---|
| Number of activities | Same (excluding summaries) | Dropped LOE activities or milestones |
| Number of relationships | Same | Duplicate relationships or links to summaries |
| Project finish date | Same date, zero tolerance | Calendar (hours/day, days/week) |
| Total duration in days | Same | Misinterpreted hour-based durations |
| Critical path | Same first 10 critical activities | Downgraded constraints, LOEs converted into tasks |
| Contract milestones | Same dates | Lost constraints |
| Overall progress to date | Same physical or duration % | Unmapped percent complete type |
| DCMA assessment | Same results on all 14 points | Lags, new open ends, new invalid dates |
Quick trick: run both the original and the converted file through Centinela DCMA. If the 14 points give the same results for both files, the logic survived the conversion. If point 1 (logic) or point 3 (lags) changes, you know where to look.
Common errors and how to fix them
- The project finishes weeks later. It is almost always the calendar. In MS Project, set Options → Schedule → Hours per day / Days per week and the base calendar to the same pattern P6 had.
- Tasks that were not critical become critical. LOE activities converted into normal tasks. Identify them and mark them as inactive or turn them into manual summary tasks.
- Lags shifted by one or two days. A different calendar is used for the lag. Check the Calendar for scheduling relationship lag option in P6 and adjust the affected relationships.
- Actual dates in the future. The MS Project status date ended up earlier than the P6 data date. Correct it and recalculate.
- Lost activity codes. Check the custom Text fields; a well-configured tool places them there. If you converted with P6's native exporter, they did not make it across.
And back again: MPP to XER
The reverse direction has its own pitfalls. Tasks in Manually Scheduled mode (MS Project 2010 onwards) have no real logic, and P6 imports them with fixed dates: switch them to Auto Scheduled before exporting. MS Project deadlines do not exist in P6 and are either lost or turned into constraints. And summary tasks become WBS levels, so a messy summary structure produces an equally messy WBS. The article on how to migrate from MS Project to Primavera P6 covers that direction in detail.
Contractual recommendation: agree from the start which file is the "master" and in which format it is exchanged. Our practice is to always deliver three things together: the native file, the converted version and a PDF of the Gantt chart showing the critical path. That way nobody argues over which version is valid.
Converting correctly is not a hard technical problem; it is a matter of discipline. With the right tool and the verification checklist, it stops being a project risk and becomes a ten-minute routine task.