Project Online Field Mapping: Translating ECFs, Lookup Tables, and Calendars

Here's the assumption that drives most Project Online field mapping sessions: pull the Enterprise Custom Field inventory, match each field to its equivalent in the destination tool, export the .mpp files, and move on. It's a reasonable assumption. It's also why most migrations lose metadata they never knew they were losing.

The problem is architectural. Project Online field mapping isn't one problem: it's four different data categories, each stored differently, each with different export behavior, and each requiring a different migration decision. Enterprise Custom Fields, lookup tables, resource calendars, and baseline sets all look like "field data" from the outside. Inside a migration, they behave almost nothing alike.

TL;DR. Project Online field mapping covers four categories that each fail differently. ECFs split between the .mpp file and the PWA reporting database; anything stored only in the database requires an OData export before the retirement date. Lookup table values must be recreated in the destination tool before import, not after. Resource calendars silently break schedule math when enterprise calendar exceptions don't migrate with them. Baseline fields require explicit export if you need to preserve anything beyond the active baseline. Cover all four categories in the mapping session or you'll spend more time repairing gaps than the mapping work itself would have cost.

What "Project Online field mapping" actually covers

Field mapping in a Project Online context means something specific: deciding how every structured metadata element in your source PWA environment translates to an equivalent in your destination tool. That scope is larger than most PMs expect going in.

The diagram below shows the four major categories and their key migration characteristics at a glance.

These categories interact too. A resource calendar exception that doesn't migrate changes task start dates. A task whose start date shifts may violate an ECF-based constraint. The mapping session isn't just a field-by-field exercise: it's a dependency graph, and the order you work through it matters.

Enterprise Custom Fields: where mapping starts and where it usually breaks

Enterprise Custom Fields (ECFs) in PWA come in three flavors: project-level, task-level, and resource-level. Each has a data type (text, number, cost, date, flag, or duration) and may or may not use a lookup table for controlled values. On the surface, mapping them to destination tool custom fields sounds mechanical.

Where it breaks: ECFs live in two places at once. The .mpp file for a project carries the ECF values that were written to the local schedule file. But PWA stores a second copy in the reporting database, and those copies can diverge, especially for fields updated through PDP (Project Detail Page) forms rather than through the schedule itself. When you export the .mpp, you get one version. When you query the ProjectData OData endpoint, you may get another, and in some fields the OData version is the authoritative one.

The safe approach is to run both exports before your mapping session: export the .mpp files for your active project set and run a parallel OData query for every ECF across all active projects. Compare the values. Where they agree, the .mpp export is sufficient. Where they differ, the OData value is almost always the correct one. See Enterprise Custom Fields and lookup tables in Project Web App for the full schema reference.

The custom fields migration guide covers the OData query patterns in detail. For the field mapping session itself, the key question for each ECF is: does this field have a lookup table? If yes, the lookup table must be recreated before the field mapping can close.

Lookup tables: silent data loss at the value level

Lookup tables in PWA define the allowed values for choice-type ECFs. A project status field with values of "On Track," "At Risk," and "Off Track" is backed by a lookup table. That lookup table does not travel in a .mpp export. It lives entirely in the PWA enterprise environment.

When a destination tool imports a project that has a choice-type ECF set to "At Risk," one of two things happens depending on the tool: the import fails with a validation error (good, at least you see the problem) or the import succeeds but sets the field to blank, because "At Risk" doesn't exist in the destination's equivalent dropdown (bad, silent data loss with no error message).

The fix is sequence-dependent. Recreate every lookup table in the destination tool before you run any data import. The order matters: lookup tables first, ECF definitions second, project data third. Flipping any two of those steps produces blank fields or failed imports.

One edge case that catches PMOs off guard: nested lookup tables (lookup tables with hierarchical values like "Division > Team > Sub-team"). Many modern tools support flat dropdowns but not nested ones. If your PWA has nested lookup tables used in active projects, you need an explicit decision about how to flatten them before the import. The Migration Preview tool will surface which of your fields have nested lookup dependencies when you upload a sample project, so you can make that decision before committing to an import strategy.

Resource calendars as a field mapping problem

Most migrations treat resource calendars as an operational concern, not a field mapping concern. They're actually both, and treating them as purely operational is what causes post-migration schedule shifts.

In PWA, a resource's effective working calendar is assembled from three layers: the Enterprise Global Calendar (org-wide default hours and holidays), the project calendar (overrides for that specific project's schedule), and resource-specific exceptions (individual variations like part-time schedules, personal holidays, or temporary capacity changes). The resulting calendar determines when a resource is available and therefore when any task assigned to that resource can start.

When you migrate to a destination tool without reconstructing all three layers, the tool defaults to its own global calendar, which may have different holidays, different business hours, or different working-day definitions. Tasks that were scheduled around those exceptions shift silently. Nobody sees an error; they just see that all the tasks moved by two days, or that three resources are suddenly showing as overallocated in the same week.

The Resource Heatmap can help you spot post-migration allocation changes by comparing pre- and post-migration utilization patterns. But the better approach is to export and validate calendar exceptions before the migration, not after.

Baseline fields and the numbering mismatch

Project Online stores up to 11 baselines per project, numbered Baseline (also called Baseline 0) through Baseline 10. Each baseline captures a snapshot of task start dates, finish dates, work, and cost at the time it was set. PMOs use multiple baselines to track scope changes formally: Baseline 0 might be the original approved plan, Baseline 1 the first approved change, and so on.

Most destination tools preserve the active baseline on import. Baseline 0 survives. Baselines 1 through 10 may not, depending on the tool and the import format. For PMOs that don't rely on historical baselines, this is acceptable. For any PMO subject to audit or with contractual baseline-tracking requirements, it is not.

The full baseline migration strategy is covered in the project online baseline migration guide. For the field mapping session, the decision to make is: for each project, which baselines carry live audit data and which are just stale saves that can be archived? That classification drives both the export scope and the import validation criteria.

The field mapping table: what each type requires

Before the mapping session begins, it helps to have the full scope in front of you. The table below summarizes the six field categories in a Project Online migration, what each requires, and where the typical loss point is.

Field Type	Where Stored in PWA	Travels in .mpp?	OData Export Needed?	Mapping Complexity	Typical Loss Pattern
ECFs (text, number, cost, date)	ECF library + reporting DB	Partially	Yes	Medium	Reporting DB values differ from .mpp values
ECF formula fields	ECF library	Read-only in .mpp	Yes	High	Auto-calculated values don't transfer
Lookup table fields	PWA lookup library	No	Yes	High	Value absent in destination: blank on import
Resource calendars	Enterprise Global + per-project + resource	Base rules only	Yes	High	Exception layers lost, tasks shift dates
Baseline fields (B0-B10)	Per-project in PWA + .mpp	Yes if saved locally	For PWA-only baselines	Medium	Only active baseline preserved by most tools
Timeline/Gantt flags	Per-project file	Yes	No	Low	Display-only flags; low data risk

A field inventory and triage process

The mapping session produces better results when the inventory work is done first. Here is a repeatable process that takes about half a day for a mid-size PMO.

1. Run the OData ECF inventory. Query /_api/ProjectData/Projects with $expand=ProjectCustomFields to retrieve all non-null ECF values across active projects. Export to a spreadsheet. This takes 15-30 minutes.
2. Export the lookup table library. In PWA, go to Server Settings > Enterprise Custom Fields and Lookup Tables. Export the full list of lookup tables and their values to CSV.
3. Map ECF types to destination types. For each ECF, identify the closest equivalent field type in the destination tool. Flag any ECF with a formula: formula fields almost never migrate and must be rebuilt in the destination tool's formula engine.
4. Classify baselines. For each active project, identify which baselines carry live audit data. Projects with only Baseline 0 set are straightforward. Projects with baselines 1-4 all populated require explicit export decisions.
5. Audit resource calendar exceptions. Export the Enterprise Global Calendar and compare it against each project calendar. Flag projects where the project calendar differs from the enterprise default: those are the projects where calendar migration is most likely to shift task dates.
6. Run a pilot import. Pick one representative project with complex ECFs and run the full import before touching the rest of the library. Validate field values, lookup values, calendar behavior, and baseline data. What fails in the pilot informs the import template for everything else.

The Schedule Health Check surfaces calendar and baseline anomalies in your .mpp files before you commit to an import. Running it on your pilot project before the full migration often catches the category of problem described in steps 4 and 5 above.

Verifying the field mapping before cutover

Field mapping verification is a comparison exercise: for a sample of projects, does every mapped field in the destination tool carry the value you expected from the source? A spreadsheet with three columns (field name, source value, destination value) is enough. Any row where source and destination differ is a gap.

Run verification on a stratified sample: one simple project, one complex project with nested lookup tables, one project with multiple baselines set, and one project whose resources use non-standard calendar exceptions. Cover all four mapping categories in your sample and verification becomes a real quality gate rather than a checkbox exercise. If you find gaps at this stage, fix the import template, not the destination data, and re-import. Re-importing is far cheaper than patching individual records post-cutover.

Run the free Migration Preview Upload a sample .mpp file and see exactly which fields, lookup values, and calendar exceptions survive the tool boundary before committing to a full migration. No signup required. Open Migration Preview

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.