"Primavera P6" actually covers two distinct products: P6 Professional, a locally installed thick client connected to an Oracle or SQL Server database, and P6 EPPM (Enterprise Project Portfolio Management), the web interface deployed on-premise or in the cloud (Oracle Primavera Cloud for the SaaS version). Both share the same scheduling engine, but not exactly the same data model — a nuance that becomes critical the moment a schedule moves between two environments.

The XER format isn't frozen in time

The XER export format carries a version number (visible on the first line of the file, e.g. ERMHDR 19.12) matching the P6 version that generated it. A file exported from a recent version can fail to import on an older installation that doesn't recognise certain fields or tables added since. The practical rule: always check the recipient's P6 version before an inter-organisation exchange, and export at the lowest common compatibility format (P6 offers an XER version selector at export).

What doesn't always survive the round trip

Certain elements are particularly fragile through an export/import cycle, especially between P6 EPPM cloud and P6 Professional:

  • Resource curves — non-linear resource distribution profiles on an activity can silently reset to a default linear distribution if the target environment doesn't recognise the custom curve.
  • "Indicator" or dropdown-type user-defined fields (UDFs) — their definition must exist identically in both environments; otherwise the value is lost silently, with no error message.
  • Financial periods — used to store historical progress, they aren't systematically included in a standard XER export and need a specific check.
  • Multiple baselines — a project with several associated baselines may retain only one after import, depending on target configuration.

Cloud (Oracle Primavera Cloud): a deeper divergence

Beyond P6 EPPM on-premise, Oracle Primavera Cloud (OPC) introduces its own data model, closer to portfolio management than a simple P6 schedule. Importing a standard XER into it works, but certain P6 concepts (shared global calendars, for instance) are reinterpreted under OPC's logic. A schedule migrated to OPC should systematically be re-verified activity by activity on its critical path before being trusted.

The checklist before any migration

Before migrating a schedule between P6 environments, four systematic checks: the target XER version, whether custom field definitions are identical between the two databases, whether the expected baselines are present after import, and a before/after critical path check to catch any silent date recalculation.

This vigilance matters particularly for organisations operating across countries where P6 version and hosting differ from one partner to another — a frequent case on our assignments between Europe and the Gulf.