Every few months someone sends me a Primavera P6 schedule that was "converted from MS Project last week" and asks why the completion date moved nine days when nothing changed on site. The honest answer is nearly always the same. The import worked. Nobody checked what the import actually did.

In 2026 that trickle has become a queue. Microsoft retires Project Online on 30 September 2026, and plenty of contractors who ran their programmes in Project Web App are using the moment to rethink their tools. At the same time, more owners and public agencies are writing native P6 submissions straight into their contract specifications. So a lot of schedules are crossing from one tool to the other right now, many of them mid-project, with progress, baselines and delay notices already attached.

This guide is the process I use, and teach, for that crossing. It isn't a click-by-click software tutorial. It's the thinking a scheduler needs before, during and after the import, so the P6 version tells the same story as the MS Project original. And where it doesn't, so you can explain exactly why.

Quick answer: can you import an MS Project schedule into Primavera P6?

Yes. P6 Professional imports Microsoft Project data through the Microsoft Project XML format (and the older MPX format), using an import template that controls how fields, calendars and custom fields map across. You need an Admin Superuser account with access to all resources to run an MSP XML import, and any cost-type or number-type custom fields in MS Project have to be mapped to matching user-defined fields (UDFs) in P6, or the import throws errors.

What the import does not do is make the two scheduling engines agree with each other. That part is on you, and it's what the rest of this article is about.

Why so many schedules are moving to P6 in 2026

Let's get the Microsoft news straight first, because I've already heard it misquoted in site meetings. It's Project Online, the SharePoint-based Project Web App service, that is being switched off. The desktop application most schedulers simply call "MS Project" isn't going anywhere.

Table 1 — What Microsoft is retiring, and what it isn't.

The retirement is only part of it. On the projects I work around, three other pressures keep pushing schedules towards P6:

• Contract specifications that require native P6 files (usually XER) for the baseline and every monthly update, particularly on public infrastructure and larger commercial work.
• Delay and extension-of-time claims. Forensic schedule analysis is overwhelmingly done on P6 data, so an MS Project programme often gets converted once a dispute starts. That's the worst possible moment to do it.
• Joint ventures where one partner plans in MS Project and the lead partner reports to the client in P6.

The 6-stage migration workflow

Figure 2 — The six stages of an MS Project to Primavera P6 migration, each with an output someone else can check. Gate rule: a second person checks each output before the next stage starts.

Treat the conversion like a small project with its own gates. Each stage produces something tangible that a second person can review before you move on. On a 300-task fit-out programme the whole thing might take a day. On a 3,000-activity, resource-loaded hospital schedule, budget one to two weeks, most of it in Stage 5.

Stage 1 — Freeze the source and take a fingerprint

Agree a cut-off with the project team and stop editing the MS Project file. Save three things side by side: the native MPP, an XML export, and a PDF of the Gantt at the status date. Then record what I call the schedule fingerprint: a short set of numbers that describes how the schedule behaves, not just how it looks.

Table 2 — The schedule fingerprint: capture it before you export.

On a 2,000-task schedule this takes about an hour. It's the most valuable hour in the whole conversion, because it turns "the dates look about right" into a pass-or-fail test.

Stage 2 — Clean the schedule in MS Project first

This is where most of the value sits. Every problem you fix here is a problem you won't have to explain to the client's P6 reviewer later.

• Switch manually scheduled tasks to auto scheduled. P6 has no equivalent, and manual tasks carry dates that logic isn't driving.
• Move logic off summary tasks and onto the first or last detail task underneath. WBS elements in P6 can't hold relationships.
• Review every Start No Earlier Than constraint. MS Project quietly adds one whenever someone types a start date into an auto-scheduled task in a forward-scheduled project. Keep the ones that reflect a real access date or contract restriction; remove the rest.
• Delete blank rows and presentation-only "heading" tasks. P6 won't accept activities without names.
• Check the Hours per day option against your real working calendar (see the note below).
• Decide how elapsed durations and lags will be handled. A 7ed curing lag needs a deliberate P6 equivalent, usually a 7-day or 24-hour calendar.
• Copy MS Project's Unique ID into a text custom field and map it across, so every activity stays traceable to the RFIs, early warnings and delay notices that quote the old IDs.

Stage 3 — Export to XML

In MS Project, use File › Save As and choose XML Format. Put the status date in the file name (for example, TowerA_Prog_Upd14_2026-06-30.xml) so there's never an argument later about which version was converted. I'd resist reaching for a third-party converter on the first attempt unless the native route genuinely fails. Every extra tool adds another field mapping you'll have to verify.

Stage 4 — Import into P6 with a deliberate template

Import into a sandbox EPS node, never straight into production. The import wizard lets you create a new project, add into an existing one, or replace or update an existing project. The last two are powerful and unforgiving: pointed at the wrong project, they can overwrite relationships in a live schedule. Before you click Finish, settle four things:

1. Activity ID convention. Decide it now. Renumbering after the first submission breaks every cross-reference in correspondence.
2. Calendars. Import as project calendars for the first pass, then map to your organisation's global calendars once you've proven they behave identically.
3. UDF mapping. Map the MS Project Unique ID, any cost or number fields, and any codes you rely on for reporting.
4. Security. Confirm the importing account has Admin Superuser rights and access to all resources, or the job will fail partway.

Stage 5 — Schedule, read the log, reconcile

Set the P6 data date to the MS Project status date, press F9 with the Log to file option ticked, and read the schedule log before you look at a single bar. It lists open ends, constraints, out-of-sequence progress and activities with no predecessors or successors. Then compare the result against your fingerprint.

Table 3 — Reconciliation tolerances: match, explained variance, or unexplained.

Stage 6 — Re-baseline and write a conversion report

P6 baselines are copies of a project. Baselines stored inside an MPP file don't arrive as usable P6 baselines, so plan to re-establish the baseline in P6 and record how you did it. Then write a one- or two-page conversion report: source file and status date, import template, schedule options used, the fingerprint comparison, and a plain-English explanation of every variance. Submit it with the first P6 update. It's a small document that heads off a lot of rejection letters.

Real-world example: the tower that "slipped" two weeks during conversion

Here's a pattern I see all the time. Picture a residential tower with the structure running level by level on a two-week slab cycle. The MS Project status date is the end of week 6. Levels 4 and 5 are finished and statused properly. But the level 5 columns and core, and the façade brackets for levels 4–6, were planned to start before the status date, haven't started, and nobody updated them. MS Project is perfectly happy to show that unstarted work sitting in the past.

P6 is not. The data date is a hard line: remaining work can't be scheduled before it. The first F9 pushes the level 5 columns to the data date, and the rest of the structure follows like dominoes.

Figure 3 — Gantt comparison: MS Project dates (light bars) against P6 dates after the first F9. Unstarted work behind the status date moves to the data date and the roof slab finishes two weeks later.

The P6 schedule isn't wrong. It's the first honest version of that programme in two months. The fix belongs in MS Project, before export: use Project › Update Project › Reschedule uncompleted work to start after the status date. That way the slip appears in the right reporting period, in the native tool, and the converted file matches the source on day one.

MS Project vs Primavera P6: the differences that actually move dates

Most comparison articles talk about price, licensing and user interfaces. That's useful when you're choosing software. When you're converting a schedule, these are the behaviours that matter:

Table 4 — Scheduling behaviour compared, with the action to take.

If you only remember three rows, make them the data date, typed-date constraints and hours per day. Between them they account for most of the date movement I get asked to explain.

Where the conversion effort really goes

The chart below is an illustrative issue log from a hospital expansion schedule of roughly 1,850 activities. The mix is typical of what I see on busy, multi-author MS Project programmes.

Figure 4 — Illustrative reconciliation log: activities flagged by issue type during conversion of a 1,850-activity schedule.

Look at the top bar. More than one in ten activities carried a Start No Earlier Than constraint that nobody had consciously set. Planners had simply typed dates into the start column during coordination meetings. Under DCMA-style checks these don't count as hard constraints, so they rarely raise alarms. But they stop activities moving earlier when predecessors finish early, and they make parts of the network look date-driven rather than logic-driven. In a delay analysis that distinction matters a great deal.

Common mistakes to avoid

• ✘ Treating the import log as quality assurance. A clean import log only tells you the file was readable. It says nothing about whether the schedule still behaves the same way.
• ✘ Importing straight into production. Use a sandbox EPS node until the reconciliation passes, and be very careful with Replace or Update Existing Project.
• ✘ Scheduling with the wrong data date. If the P6 data date doesn't equal the MS Project status date, every comparison afterwards is meaningless.
• ✘ Leaving typed-date constraints in place. They survive the import, they mask logic, and a client reviewer running a constraint report will find them before you do.
• ✘ Accepting default float and critical path settings. Check what the contract says about critical path definition and float calculation, then set P6 to match.
• ✘ Renumbering activity IDs without a cross-reference. Keep the MS Project Unique ID in a UDF, permanently.
• ✘ Submitting without telling the client it was converted. Disclose it, attach the conversion report, and move on. Surprises are what turn a routine review into a formal rejection.

Expert tips from the scheduling desk

• Count relationships, not just dates. A finish date can match by coincidence while 40 links are missing somewhere in the middle of the network.
• Create a CONV activity code with values such as Clean, Adjusted and Rebuilt. Every activity you touched is then filterable and auditable.
• Test each calendar with a one-activity dummy project. Put a 10-day activity across a public holiday and check that both tools give the same finish date.
• Rebuild SS + FF pairs on linear work. Pipelines, pavements and façade runs were often modelled with a single SS lag in MS Project because it only allows one link between two tasks.
• Convert site supervision and preliminaries to Level of Effort so they stretch and shrink with the work they span.
• Keep both files under the same naming convention and store them together. Future-you, or a claims consultant, will be grateful.

Lessons learned from real conversions

Field note 1 — The hospital schedule with 212 invisible constraints

On a large healthcare programme, removing unjustified Start No Earlier Than constraints before export changed the critical path. A mechanical services sequence that had looked comfortable turned out to be driving completion once logic, not typed dates, was in charge. Nobody enjoyed that discovery, but it came out during conversion rather than in the middle of an extension-of-time negotiation.

Lesson: a conversion is an audit whether you plan it that way or not. Plan it that way.

Field note 2 — The motorway night works that "lost" 20% of their durations

Night works ran four 10-hour shifts a week, but MS Project's Hours per day option still said 8. In P6, using calendar-based hours, every 5-day activity displayed as 4 days. The client's reviewer flagged dozens of "reduced durations". Not one date had changed. A single paragraph in the conversion report, with a worked example, closed the comment.

Lesson: explain display differences before the reviewer asks about them.

Field note 3 — The fit-out programme whose finish date matched by luck

A joint-venture fit-out programme converted with a finish date identical to the source, and everyone relaxed. The relationship count told a different story: 63 links had been attached to summary tasks and simply disappeared. The float on two floors of services was fiction until the logic was rebuilt.

Lesson: a matching finish date is a hypothesis, not a result.

Template: pre-submission conversion checklist

Table 5 — Copy this checklist into your conversion report.

Final thoughts

Software migrations tempt us to think about software. A schedule conversion is really about evidence: can you show, with numbers, that the P6 programme describes the same plan, the same progress and the same risks as the MS Project file it came from? If you can, the client reviewer has very little to argue with. If you can't, the most sophisticated P6 layout in the world won't save the submission. Freeze, fingerprint, clean, import, reconcile, document. It's not glamorous work, but it's the kind that keeps projects out of arguments.

If you want to sharpen the P6 side of this work, how expert planners read a P6 schedule in ten minutes covers the review habits a reviewer will apply to your converted file, the negative float case study shows what happens when constraints go unexamined, and the Riverside office building tutorial walks through building a clean P6 programme from scratch. For the underlying terminology, the PMMilestone Encyclopedia A–Z defines every term used above.