There's no button that turns an MPP into an XER. Primavera P6 doesn't read Microsoft Project's native file at all. The working route is to export the MS Project schedule to Microsoft Project XML and import that into P6, and the moment you do, a set of predictable things go wrong, because the two tools model time differently.
None of this is exotic. The same eleven problems account for most of it. If you already have a converted file and you're wondering how much of it to trust, run it through our free schedule health check first. A few minutes of scoring will indicate whether you're tidying or rebuilding.
The route that works
Export from Microsoft Project as XML. Import into P6 using the import wizard, mapping to a new project rather than an existing one so you don't contaminate something that already works. Then check everything below before anyone looks at a date.
Treat the import as producing a draft, not a programme. The file that lands in P6 is raw material.
1. Summary tasks become WBS, and summary logic vanishes
Microsoft Project lets you draw a link between two summary tasks. P6 doesn't allow relationships on WBS elements at all.
So any logic your planner hung at summary level either disappears or gets pushed somewhere unhelpful, and the network that looked complete in MS Project arrives in P6 with holes in it. It's a leading cause of a converted programme showing an implausibly short critical path.
The fix is manual: identify every summary link in the source, decide which detail activities it was really representing, and re-link at activity level.
2. Manually scheduled tasks
Microsoft Project lets a task sit in manual scheduling mode, where its dates are typed rather than calculated. Those tasks look identical to scheduled ones on a bar chart.
On import they arrive as ordinary activities with dates, no driving logic, and often a constraint bolted on to hold them where they were. You end up with a programme that looks scheduled and isn't.
Switch the source file to automatic scheduling before you export, then look at what moves. Whatever jumps is a task that was being held in place by hand, and each one needs a real decision about logic.
3. Constraints multiply
The two tools have different constraint vocabularies, and the importer resolves the difference by adding constraints. MS Project's Start No Earlier Than, Finish No Later Than and Must Start On have P6 equivalents, roughly. There is no field called Deadline in P6 at all. The nearest behaviour is a Finish On or Before constraint, which pulls the late dates and reduces total float without moving the early dates, so a deadline that mattered in the source file has to be recreated deliberately or it disappears. Anything ambiguous tends to be preserved as a date constraint, because preserving the date is the safest thing an importer can do.
The result is a converted programme carrying far more hard constraints than the original planner ever intended. Count them immediately after import and justify each one, because a constrained programme doesn't respond to change, which makes it useless for the thing you converted it for.
4. Calendars
MS Project has a project calendar, task calendars and resource calendars. P6 has global, project and resource calendars, with an assigned calendar on each activity. Non-working days, exceptions and shift patterns rarely survive intact.
Import the calendars first, check them individually, then reassign activities. Durations expressed in days mean different things under a five-day and a six-day calendar, so expect dates to move and know which ones and why before anyone asks.
5. Lag behaves differently
This one catches experienced planners. In P6, the calendar used to calculate relationship lag is a scheduling option, and it can be the predecessor's calendar, the successor's, a 24 hour calendar or the project default. Change that setting and every lagged relationship in the programme shifts.
After import, check the scheduling options before you read a single date. A converted programme scheduled under the wrong lag calendar will be wrong by days across hundreds of links, and nothing about it will look broken.
6. Duration types and percent complete
MS Project tasks are fixed units, fixed duration or fixed work, with effort-driven on or off. P6 uses its own duration types, and it separates percent complete into duration, units and physical.
The mapping is approximate. If the source schedule was resource-loaded and effort-driven, expect durations and remaining work to need re-derivation rather than checking. If it wasn't, this matters less than the rest of this list.
7. Activity IDs
P6 requires a unique Activity ID. MS Project's IDs are row numbers and its unique IDs are internal. The importer generates something, and what it generates rarely matches any naming convention you or your client use.
Renumber to whatever convention applies, and keep a mapping table from the source IDs to the new ones. You'll need it the first time somebody asks what happened to a task they were tracking.
8. Codes and custom fields
Microsoft Project's custom text and number fields don't arrive as P6 activity codes. At best your zone, phase, discipline and subcontractor breakdowns land as user-defined fields or free text, and they're frequently dropped.
Rebuilding the coding structure is a job in itself, and it's the one that determines whether the programme can be reported on. Plan for it rather than discovering it.
9. Resources
Work, material and cost resources in MS Project map onto labour, non-labour and material in P6 imperfectly, and resource calendars, availability limits and cost rates rarely survive. If the programme is genuinely resource-loaded and the resource data matters, treat the resource layer as a separate exercise from the logic layer.
10. Baselines don't come across
You don't import a baseline. You import a programme, and then you baseline it in P6 once it's correct. Anyone expecting to see variance against the MS Project baseline immediately after conversion is going to be disappointed, and the temptation to baseline the raw import to make the variance disappear is one to resist.
11. Progress, if the job is under way
Converting a live programme adds out-of-sequence progress to the list. P6's retained logic and progress override settings produce materially different forecasts from the same data, and the setting is easy to leave on whatever the default happened to be.
Where possible, convert at a period boundary with a clean data date. Where that isn't possible, record which scheduling options you used, because the forecast depends on them.
Checking the result
Do not hand over a converted programme without testing it. At minimum:
- open ends, at both start and finish
- count of hard constraints
- negative float anywhere in the network
- out-of-sequence activities
- critical path continuity from data date to completion
- whether planned completion matches the source, and if not, why
P6 Professional 22.12 and later includes a built-in Check Schedule Report aligned to the DCMA 14-point assessment, which does most of this in a few minutes. On earlier P6 Professional releases the same checks are usually run through saved layouts or a third-party tool. P6 Web and EPPM have the native Check Schedule report.
Then compare the converted programme against the original on a small number of things that matter: planned completion, the dates of the top ten milestones, and the shape of the critical path. If those three agree, the conversion is probably sound. If they don't, the difference is information, and it's usually telling you the source programme was held together by something that didn't survive the trip.
When to convert and when to rebuild
Converting preserves what's there, including the mistakes. Rebuilding starts from the plan and constructs it properly in P6.
Convert when the source programme is sound, recent and just needs to be in a different tool. Rebuild when the source is full of manual scheduling and summary logic, when the coding structure has to change anyway, or when a client has specified a structure you'd have to demolish the import to achieve. In practice, a badly built MS Project schedule converts into a badly built P6 schedule with new problems layered on top.
Check your converted programme
If you've got a file that's already been through the mill, our free schedule health check scores it against the DCMA 14-point assessment and tells you what's wrong with it. It's free, and the scored result is yours to use. If the result needs a conversation, get in touch.
Frequently Asked Questions
Can P6 open an MPP file?
No. Export the MS Project schedule to Microsoft Project XML and import that. Older MPX exchange files exist but are a legacy route and lose more.
Is there a tool that does this automatically?
There are tools that move the data. There isn't one that rebuilds summary logic, decides which constraints were deliberate or reconstructs a coding structure, because those need someone who understands the work. Automated conversion gets you a file. It doesn't get you a programme.
Will the dates be the same after conversion?
Usually not exactly, and small differences are normal given calendar and lag handling. Large differences mean something structural didn't survive, most often summary-level logic. Investigate rather than constrain the dates back.
Our client wants the converted file in their P6 structure. Is that included?
That's a second job on top of the conversion: rebuilding into a client's WBS, coding and calendars. See what a P6 specification rebuild involves. Treating both as one piece of work avoids making the same structural decisions twice.
How do we know the converted programme is any good?
Test it. Run the checks above, or put the file through our free schedule health check for a scored result you can attach to the handover.