Importing and Exporting XER
Last reviewed 9 September 20262,273 words10 min read
Import options, and what each one overwrites — the dialog read line by line
🟩 In one line: The XER import dialog has three decisions — how to bring in the project (Create New / Update Existing / Replace), what to do with each data type (Update Existing / Keep Existing / Insert New / Do Not Import), and whether to Delete data not in the file — and the production answer is Create New in a sandbox first, then Keep Existing on all global data with Delete unticked; the export side is simpler but has two traps: the file carries every global object it touches and none of your baselines.
👤 Who this is for: J/M. Prerequisites: what-is-an-xer-file, cleaning-an-xer-before-import, p6-global-vs-project-data.
First, let's be honest about why this page exists
Three pages already cover the XER: what it is, why it won't import, and how to clean it. This is the fourth and the most mechanical — the dialog itself. People click Next four times without reading, and the defaults are written for a single-user laptop, not a shared database with 30 projects.
The export dialog gets less attention and causes fewer disasters, but the two things it doesn't carry — baselines and layouts — cause a phone call every month.
🟨 The standard — what "good" looks like
| Source | What it asks for (paraphrased) | Consequence |
|---|---|---|
| Client schedule specifications (typical Gulf) | Native XER submitted each period; sometimes a specific P6 version; sometimes XML alongside | Export format and version per spec; declare in transmittal |
| AACE RP 38R-06 | Basis identifies the software version and file format | Version in SBM and every transmittal |
| SCL Protocol 2nd ed., Guidance Part B (records) | Native electronic programme files retained | Every received and sent file archived unedited |
| DCMA 14-Point / GAO BP 9 | Assessments run on the native file | A clean import is the precondition |
| Convention (cleaning-an-xer-before-import) | Sandbox first; Keep Existing / Do Not Import; Delete unticked; original archived; ERMHDR edit declared; POBS safe to delete | This page is the dialog those rules point at |
🟢 Rule: every received XER is imported into a sandbox database with Create New Project; production imports use a saved configuration with Keep Existing on all global data and Delete unticked; every export declares the P6 version and lists the global objects and baselines it does or doesn't carry.
How it actually works
1. Import — the screens
| Screen | Choice | Production answer | Why |
|---|---|---|---|
| Format | Primavera PM – (XER) | — | XML is a different route with different rules |
| File | Browse | Archived copy, not the original | Original stays read-only |
| Import Project Options → Import To | Create New Project / Update Existing Project / Replace Existing Project / Ignore | Sandbox: Create New. Production: Create New under a "Received" EPS node; Update Existing only for your own project returning from your own laptop | Update Existing merges by ID and can overwrite your logic; Replace deletes and recreates — baselines lost |
| Import Project Options → Import To EPS | Node | "Received – [Sub/Consultant]" | Keeps received files apart from production |
| Update Project Options → Configuration | Default or saved | "Prod-Safe" (saved, see table below) | Default is Update Existing on everything |
| Currency | Select | Project currency | Wrong currency scales cost |
| Finish | Import | Read the log | Log lists rejected rows and objects created |
2. The "Prod-Safe" configuration — data type by data type
Configuration → Modify opens a table: one row per data type, an Action column and a Delete tick box.
| Data type | Action | Delete | Note |
|---|---|---|---|
| Activities | Update Existing (own project) / Insert New (Create New) | Unticked | Ticked Delete removes activities in your project that are absent from the file — the classic "half my schedule vanished" |
| Relationships | Update Existing / Insert New | Unticked | Same |
| Resource assignments | Update Existing | Unticked | |
| Activity codes | Keep Existing | Unticked | Incoming global codes do not overwrite yours |
| Calendars | Keep Existing | Unticked | The most damaging default |
| Resources | Do Not Import (or Keep Existing if agreed) | Unticked | Protects the pool |
| Roles | Do Not Import | Unticked | |
| Cost accounts | Do Not Import | Unticked | |
| Project codes | Keep Existing | Unticked | |
| UDF definitions | Keep Existing | Unticked | Prevents duplicate "Qty" |
| Notebook topics, units of measure, currencies | Keep Existing | Unticked | |
| Expenses, issues, risks, work products | Update Existing | Unticked |
Save the configuration once; select it every time; change it only with the database admin.
3. What "Keep Existing" does to a file that needs the incoming calendar
If the incoming project's activities are assigned to a global calendar named the same as one of yours, Keep Existing assigns them to your calendar of that name. Different hours or exceptions → different dates. That is why the sandbox exists: import with Create New there, check the calendars the file actually used, compare dates to the sender's PDF, then decide whether the production import needs a renamed project-calendar copy first (cleaning-an-xer-before-import).
4. Import Spreadsheet — a different door
File → Import → Spreadsheet (XLS/XLSX) updates activity fields, relationships, resources or assignments from a workbook whose columns match P6 field names. It is the safe bulk route for statusing (p6-keyboard-and-speed) and for loading quantities to UDFs. It does not create global objects and cannot damage calendars. Export the template first with File → Export → Spreadsheet so the headers are right.
5. Export — the screens and the two traps
| Screen | Choice | Note |
|---|---|---|
| Format | Primavera PM – (XER) | Some versions offer a version selector; otherwise the file's ERMHDR line records the exporting version and may be edited to an older version if declared in the transmittal |
| Projects | Tick the project(s) | Ticking several writes one multi-project file; the receiver can pick |
| File name | Naming convention | "AUH-RT14_Upd09_DD01Oct25_v20.xer" — project, update, data date, P6 version |
| Finish | Export | Open the file in a text editor and check the ERMHDR line |
Trap 1 — global objects travel. Every calendar, code, resource, cost account and UDF definition the project references goes in the file. Run the 5-minute pre-export check (p6-global-vs-project-data) and list what the file carries in the transmittal.
Trap 2 — baselines don't. The XER holds the project only. To send the accepted baseline: export the baseline project separately (it exists as its own project in the database until assigned; if already assigned, the archived accepted XER from the baseline register is the file to send — never Restore a baseline out of the live project except into a sandbox). Alternatively XML export can carry assigned baselines with the project — declare which route was used. Layouts go as .plf; user preferences don't go at all.
6. Transmittal — the six lines
| Line | Content |
|---|---|
| File | Name, size, P6 version exported from (and ERMHDR version if edited) |
| Contents | Project ID, data date, update number, activity count |
| Baseline | Which baseline this compares to; whether the baseline file is attached or previously issued (register reference) |
| Global objects carried | Calendars (project/global), activity codes (project/global), resources, cost accounts |
| Settings | Scheduling options screenshot attached; hours-per-day basis |
| Edits | Any post-export edit to the file (ERMHDR, POBS removed), stated plainly |
7. Import log — what to read
The log lists every object created, updated or skipped, and every rejected row. Read it before opening the project: rejected relationships (missing activity IDs), calendars created (a global one just landed), resources created (pool grew). Archive the log with the file.
🟥 Where people go wrong
- Default configuration in production. Update Existing on every global object. Calendars, codes and UDFs overwritten in one click. Prod-Safe, always.
- Delete ticked. Activities and relationships in your project but not in the file are removed. Unticked, every row, and checked before Finish.
- Update Existing on someone else's file. Their IDs match yours; their logic replaces yours. Received files are Create New under a Received node; only your own returning project is ever Update Existing.
- Replace Existing to "start clean". Deletes the project and its baselines, then recreates. The baseline register now points at nothing. Never on a production project.
- Assuming the export carries the baseline. The client receives the update with no comparison target and asks again. Baseline file per the register, or XML with baselines, declared in the transmittal.
- Editing the original received file. Archive it unedited; clean a copy. The original is the contemporaneous record.
- No log read, no transmittal. The receiver finds the 112 new resources a week later. Log archived; six-line transmittal every time.
⚖️ When you're challenged
"Your XER won't open in our version." The ERMHDR line records version 20; if your database is older I can re-export with the version selector, or edit the header line to your version — the data is identical, and the transmittal will say the header was edited and from what to what.
"We imported your file and our calendars changed." The transmittal listed two project calendars and no globals, so nothing in the file could overwrite a global calendar unless the import was set to Update Existing on calendars and matched by name. Keep Existing on calendars is the production setting; the archived original is available to re-import into a sandbox to confirm.
"Why can't you just send the baseline in the same file?" The XER format holds one project per project — a baseline assigned inside the project isn't written out. The accepted baseline XER is BL1-Accepted-DD 01Dec25 in the register, issued 4 December; I'll attach it again, or send XML with the baseline embedded if your side prefers that route.
📄 Related pages
- What Is an XER File — the file structure and the ERMHDR/POBS conventions
- XER File Won't Import — when step 3 fails
- Cleaning an XER Before Import — what to do in the sandbox
- P6 Global vs Project Data — the pre-export check
- P6 Baselines: Assign and Maintain — why the baseline is a separate file
- Xer vs xml vs mpp — when XML is the better route
- Handing over a schedule — the full transmittal at project close
✏️ Worked example
Consultant's planner receives Upd 09 from the contractor on a Doha office tower:
| Step | Action | Result |
|---|---|---|
| 1 | Archive "DOH-OT_Upd09_DD01Oct25_v20.xer" read-only; copy to working folder | Original preserved |
| 2 | Open copy in text editor: ERMHDR shows v20 (consultant DB is v19); POBS block present | Header edited to v19 on the copy; POBS removed; both noted |
| 3 | Sandbox DB: File → Import → XER → Create New Project → EPS "Received – Contractor" → Default config | Log: 2 project calendars created, 0 global; 11 project activity codes; 0 resources (contractor sent unresourced); 0 rejected rows |
| 4 | Compare dates to contractor's PDF Gantt; check Schedule Options against transmittal screenshot | Match |
| 5 | Production DB: same file, Create New under "Received – Contractor", configuration Prod-Safe | Log clean; no global objects touched |
| 6 | Assign BL1-Accepted (previously imported, register ref) as project baseline in the received copy | Variance columns live |
| 7 | Layout 03 Review; DCMA pass; Schedule Comparison vs Upd 08 | Review comments issued day 3 |
| 8 | Import log and edited-copy note filed with the received file | Record complete |
Elapsed: 35 minutes from receipt to review-ready, none of it spent repairing a database.
📖 References
- AACE International RP 38R-06, Documenting the Schedule Basis
- SCL Delay and Disruption Protocol, 2nd ed. (2017), Guidance Part B
- DCMA 14-Point Schedule Assessment; GAO Schedule Assessment Guide (GAO-16-89G), Best Practice 9
- Oracle Primavera P6 Professional User Guide — Import/Export Primavera PM (XER); Import Configuration (Update Project Options); Import/Export Spreadsheet; Maintain Baselines (field labels as in P6 Professional v20; earlier versions differ)
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about importing and exporting xer. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience