MS Project to Primavera P6 Conversion: What Breaks, What Survives, and How Experienced Schedulers Fix It

The conversion that looked perfect

The converted file opened without a single error. Same activity count, same practical completion date, same critical path running straight through the precast culvert install. The scheduler signed it off on a Friday afternoon.

Three weeks later the client’s reviewer sent it back with one question: why was the culvert install starting two days before half of the trench had been excavated?

That question sums up the whole problem with moving a schedule from Microsoft Project into Primavera P6. Conversion errors do not announce themselves. They hide inside a schedule that looks finished, and sometimes two of them cancel each other out so neatly that the finish date never moves. A matching completion date is not proof of a good conversion. It is barely evidence.

With Microsoft retiring Project Online on 30 September 2026, plenty of contractors and consultants now hold exported .mpp files and a client who wants XER submissions. This Learning Track walks through what survives that trip, what bends, what breaks, and the routine I use to prove a converted schedule can be trusted. It complements the wider Knowledge Pillars and PMMilestone Academy.

Before converting anything, decide whether you should

Not every schedule deserves a migration. Some should be archived. Some should be rebuilt, using the MS Project file as a scope list rather than a source of logic. Making that call early saves more time than any import trick.

The traffic-light map: what survives the trip

After enough conversions, you stop thinking in terms of features and start thinking in three buckets. Green items arrive intact. Amber items arrive but need checking. Red items arrive damaged or not at all.

Five failure points—and how experienced schedulers fix them

1. Percentage lags become frozen numbers. MS Project lets you write a lag as a percentage of the predecessor’s duration. A planner might link culvert installation to excavation as Start-to-Start plus 50%, meaning “start laying units once half the trench is open.” P6 only stores lags in time units. On import, 50% of a 10-day excavation becomes a fixed five-day lag. If excavation is re-estimated to 14 days, MS Project would move installation to day seven; P6 keeps it at day five. Review every converted percentage lag whenever its predecessor duration changes.

2. Logic on summary tasks disappears. In MS Project it is common, if not good practice, to link a whole summary such as “Civil works” to the next phase. P6’s WBS cannot hold that link. Before export, move every summary link onto a detail activity or a start or finish milestone inside the summary. Then compare relationship counts in both tools.

3. Elapsed durations shrink or stretch. Seven calendar days of concrete curing is a physical fact, not a working-time estimate. P6 has no elapsed-duration type. Unless the activity receives a seven-day calendar, seven working days on a five-day calendar becomes nine calendar days. Create dedicated calendars for cures, holds and tests, assign them after import, and verify their dates.

4. Constraints change shape and deadlines lose their home. MS Project stores one constraint plus a separate deadline. P6 offers primary and secondary constraints but no deadline field. List every non-ASAP constraint before export, confirm how each arrived, and deliberately rebuild deadlines—usually as Finish On or Before on a contract milestone.

5. Progress is measured from a different reference point. MS Project reports against a status date; P6 calculates from a data date and applies Retained Logic, Progress Override or Actual Dates. Set the P6 data date to the MS Project status date before scheduling, select the rule required by the contract, and record the choice in the conversion note.

These issues matter most when a programme later supports delay analysis and an extension-of-time claim. The Project Controls Glossary defines the scheduling terms used throughout this guide.

Worked example: the culvert that hid two errors

The stormwater culvert upgrade from the introduction carried a percentage lag on installation and an elapsed-duration cure on the headwall. After conversion, excavation was re-estimated in P6 from 10 to 14 days.

Where the time really goes

The import itself is a rounding error. Most effort sits in two places: cleaning the source file before export and reconciling the result afterwards. If someone quotes half a day to “convert” a live contract schedule, they are quoting for the import button and nothing else.

A ten-point validation routine for converted schedules

Once reconciliation counts agree, run a structural health check. These thresholds follow the widely used DCMA 14-point assessment. Use the Float Erosion Analyzer and Delay Impact Calculator to investigate material changes rather than accepting a matching finish date.

Mistakes I see repeatedly

✕ Treating conversion as an IT task. Whoever converts the schedule must understand the construction sequence well enough to notice when it stops making sense.

✕ Converting the wrong version. Agree in writing whether you are converting the accepted baseline, the latest update, or both.

✕ Discarding the source XML. Keep the exact file you imported. Without it you cannot prove what the conversion changed.

✕ Leaving custom fields behind. Area, trade and subcontractor codes in MS Project text fields should become P6 activity codes or UDFs, or your filters and layouts stop working.

✕ Saying nothing to the client. A converted schedule submitted without explanation looks like a schedule that changed for no reason.

The consequences of weak schedule governance are visible in the Mega Project Case Studies and the Project Failure Database.

Expert tips

Write a conversion transmittal. Submit a one-page note with the first converted schedule: source file name and date, P6 version and patch, schedule options used, every percentage lag converted, every calendar created, and every difference you could not eliminate. It turns a potential dispute into a documented decision.

Give converted lags a marker. Put a code such as “LAG-CONV” on every activity whose lag came from a percentage. A single filter then tells you which links to review whenever durations change.

Check your P6 patch. XML import behaviour has varied between P6 Professional releases, including at least one patch that imported activities without their relationships. Record the version and patch level in your transmittal.

Key takeaways

1. Decide first: migrate, rebuild or archive. Not every schedule earns a conversion.

2. Summary-task links, percentage lags, elapsed durations, deadlines and manual tasks are the five red items. Hunt them before export.

3. A matching finish date proves nothing. Check sequence on the critical and near-critical paths.

4. Most of the effort is clean-up and reconciliation, not the import.

5. Validate against DCMA-style checks and document every decision in a transmittal.

What should a conversion transmittal include?

Include the source file and date, P6 version and patch, schedule options, converted lags, new calendars, constraint changes, and any differences you accepted—with the reason for each.

For further professional context, review Dr. Hassan Eliwa’s publications, Founder page and the About PMMilestone.org page. Continue with the seven differences that change your dates and the Primavera P6 learning guide.