On 30 September 2026, Microsoft switched off Project Online. The desktop version of Microsoft Project carries on, but every planner who kept live schedules in Project Web App has spent the last few months pulling .mpp files out of the cloud. A surprising number then received the same follow-up request from a client or head contractor: “Can you resubmit that in P6?”

The import itself takes about forty seconds. The problems it creates can take weeks to surface. Primavera P6 rarely refuses a Microsoft Project file. It accepts it, quietly reshapes the parts it has no home for, and hands you a schedule that looks complete. Sometimes the finish date even matches. That is exactly why this job catches experienced people out.

This is the checklist I would want a junior planner to follow before sending a converted schedule to anyone. It assumes you already know your way around both tools. It focuses on what silently changes in transit, how to spot it, and how to fix it before a delay analyst finds it for you.

Why this conversion is suddenly on everyone’s desk

Three pressures have landed at the same time. None is new on its own, but together they have turned an occasional chore into a routine project controls task.

One point worth clearing up early: the retirement affected the cloud service only. Microsoft Project desktop and your .mpp files still work. Nobody is forcing you to convert. Your contract might be.

The real problem: the two tools think differently

Most people treat this as a file-format problem. It is not. It is a data-model problem. MS Project and P6 store schedules in genuinely different ways, and the importer has to make decisions about anything that does not translate one-to-one. It makes those decisions without asking you.

The clearest example is the summary task. In MS Project, a summary task is a real task. It can carry predecessors, successors, constraints and even resources. In P6, the equivalent structure is the WBS, and a WBS node is a container. It cannot hold a relationship. When the importer meets a link attached to a summary task, there is simply nowhere to put it.

Read that table as a list of places where your schedule will change meaning without changing appearance. Everything in the rest of this guide is about controlling those nine points.

The six-stage migration workflow

Figure 1 — The six-stage migration workflow. A failed reconciliation sends you back to the clean-up stage, not to manual edits in P6.

Stage 1: Take a diagnostic read before you touch anything

Never convert a schedule you have not measured. Before exporting, record a fingerprint of the MS Project file. These numbers become your reconciliation targets later, and without them you have no objective way to prove the conversion worked.

★ Expert tip — Keep the fingerprint. Save it as a one-page PDF with the migration record. When someone questions the converted schedule six months later, usually during an extension of time claim, it is the only evidence of what you started with.

Stage 2: Clean in MS Project, not in P6

It is always cheaper to fix a problem in the tool where the logic was written, ideally with the person who wrote it. Fixes made in P6 after import are fragile. If anyone re-imports the source file, every one of them disappears.

1. Move every link off summary tasks. Re-attach each one to the first or last detail task, or to a start or finish milestone placed inside the summary.
2. Replace percentage lags with fixed values. Note the original intent — for example, “SS +50% of excavation” — in a spare text field so the reasoning survives.
3. Convert manually scheduled tasks to auto-scheduled and give each one proper predecessors and successors.
4. Deal with deadlines. Replace them with a finish milestone carrying a Finish No Later Than constraint, or record them in a text field and rebuild them in P6 as secondary constraints.
5. Check the calendar options. Hours per day, hours per week and days per month must agree with the project calendar.
6. Set the status date and confirm that all progress is recorded against it.
7. Copy the Unique ID into a spare text field. It gives you a stable key to trace every activity across both tools.

One quirk worth knowing about step 5: if the days-per-month setting in MS Project does not agree with its hours settings, the P6 XML importer can reject a calendar with an error saying hours per year cannot exceed 8,784 — the number of hours in a leap year. The fix lives in MS Project’s options, not in P6.

✘ Common mistake — Cleaning up in the wrong tool. Planners often import first and fix later because P6 feels more powerful. Then the subcontractor sends a revised .mpp, someone re-imports it, and two days of corrections vanish. Clean the source. Import once.

Stages 3 and 4: Export, then import with the options set first

1. In MS Project, choose File › Save As › XML Format. Export one project per file.
2. In P6 Professional, choose File › Import, select Microsoft Project and the XML format, and create a new project under the correct EPS node.
3. Review the calendar and resource options. Only map to existing global calendars when you have confirmed that their working hours match.
4. Before you press F9, set the data date to the MS Project status date and set the schedule options below.
5. Schedule, save the schedule log, and keep it with the migration record.

⚠ Watch out — Patch levels matter. Some P6 Professional releases have shipped with XML import defects. In one documented case, Microsoft Project files imported with activities but no relationships until a later patch fixed it. Always count relationships after import. Never assume.

Stage 5: Reconcile until the numbers agree

Reconciliation is where the real work happens. Lay the fingerprint beside the P6 results and go line by line. A schedule is not converted until every difference is either fixed or explained in writing.

Figure 2 — What a “clean” import changed

Figure 2 — What a “clean” import changed in a 380-activity worked example. No error message flagged any of it.

Notice that the biggest category, links on summary tasks, produced no warning at all. The activities still exist, the WBS still looks right, and the Gantt chart still reads sensibly. The only symptom is a handful of activities that now have open ends, which P6 will cheerfully schedule as early as the data date allows.

Real-world example: a live hospital ward refurbishment

Consider a Level 3 ward refurbishment inside an operating hospital. The fit-out subcontractor planned the works in MS Project. The head contractor’s contract required monthly P6 submissions, so the schedule was converted and the import ran without a single error message. The handover milestone moved from 15 December to 19 December. Nobody had changed anything.

Figure 3 — Level 3 Ward Refurbishment: MS Project plan versus first P6 import

Figure 3 — Gantt comparison. Durations are simplified to calendar days for readability. The 48-hour elapsed hold became six days on a five-day, eight-hour calendar.

The cause was a single activity: the medical gas pressure hold. In MS Project it was entered as 2 elapsed days, meaning 48 continuous hours, which is exactly how a pressure test works. P6 has no elapsed duration type, so the importer converted 48 hours against the project’s five-day, eight-hour calendar. Forty-eight working hours is six working days. Because the hold sat on the critical path, ceiling close-up, commissioning, the infection-control clean and handover all slid with it.

The fix took ten minutes once it was found. A 24-hour, seven-day calendar named “24/7 – Tests and Holds” was created, assigned to the pressure hold, and the duration reset to 48 hours. Handover returned to 15 December. Finding it took most of a day, because the finish date was the only visible symptom.

► Lesson learned. Elapsed durations are rare in most schedules, but they almost always sit on critical holds: concrete curing, pressure tests, paint and screed drying, and settlement monitoring. Search for them first. They are small in number and large in consequence.

The same reconciliation turned up the 46 dropped summary links. One had tied the finishes package to the completion of above-ceiling services. In P6 the finishes activities had become open-ended at the start, and with the hold fixed they would have shown three weeks of float that did not exist. On a hospital job, where infection control dictates the sequence, that kind of phantom float is exactly what leads a site team to start the wrong work in the wrong room.

Common mistakes that turn a clean import into a claims problem

• ✘ Signing off because the finish date matches. Errors can cancel out. Matching finish dates prove nothing about the logic underneath.
• ✘ Mapping calendars by name. A P6 global calendar called “Standard” is not the same as the MS Project “Standard” calendar unless hours, holidays and exceptions match.
• ✘ Leaving the data date at the import default. Remaining durations then start from the wrong point and progress looks wrong.
• ✘ Baselining straight after import. You lock every conversion error into the reference for future variance.
• ✘ Re-importing over a corrected project. Import into a new project every time and compare; never overwrite.
• ✘ Ignoring resource types on cost-loaded schedules. A Material resource mapped as Labor will wreck your earned value curves.

Expert tips from the conversion desk

Key takeaways

Related career guides and references

For a broader migration framework, read the MS Project to Primavera P6 migration field guide. The Riverside P6 tutorial shows how a clean P6 programme is built from first principles, while how expert planners read a P6 schedule in ten minutes explains the checks a client reviewer will apply. Use the encyclopedia entries on the baseline schedule, float management, critical path method and schedule compression when you need a concise technical reference.