Import mpp Files from Project Online: Onplana vs the Microsoft Toolchain

The most backward thing about migrating off Microsoft Project Online is that Microsoft's own recommended path to get .mpp files into a competing tool starts with the same desktop application you are trying to retire. To import mpp file data from Project Online into Microsoft Project for the Web, Microsoft's documentation directs you to install Microsoft Project desktop, open the file there, and export in a compatible format. The tool you are moving away from is step two of the process to move away from it.

This is not an accident. The .mpp format is proprietary binary controlled by Microsoft. For twenty-five years it was the entry and exit point of every project plan created in Microsoft's ecosystem. The format was never designed to make leaving easy.

Onplana imports .mpp files directly, without the desktop app, without a manual field-mapping session, and without discovering mid-migration that your lag values disappeared or your three non-finish-to-start dependencies did not survive the transit. The difference is not just convenience. It determines which projects arrive in the new tool correctly and which arrive looking correct until you check the critical path math.

TL;DR. Importing mpp files from Project Online through Microsoft's own toolchain typically requires the desktop app as an intermediate step, loses dependency type fidelity (only finish-to-start survives in most paths), and provides no validation before the data lands in the new tool. Onplana imports .mpp and MSPDI XML natively, preserves FS/SS/FF/SF dependency types and lag values, retains baselines, and generates a validation report before any data enters your live environment. The Migration Preview tool lets you test the import on any .mpp file before committing.

The Two Ways to Import mpp Files from Project Online

There are two meaningful paths for getting .mpp file data out of Project Online and into a new PM tool. Which path you take determines what survives the move.

The first is the desktop-app path, which is what most competing PM tools require. The sequence: export the project from Project Online as a .mpp file, open it in Microsoft Project desktop, then export from desktop Project to whatever format the destination tool accepts: CSV, Excel, an XML variant, or a direct API push using a desktop connector. This path has wide compatibility because almost every PM tool can consume a CSV or Excel export. It also has a consistent fidelity ceiling: the conversion from .mpp through desktop Project to a generic format drops scheduling-specific data that CSV and Excel do not model.

The data that typically does not survive the desktop-app path: lag values on dependencies (if the target format does not have a lag field, the lag is silently dropped and the schedule shifts), start-to-start, finish-to-finish, and start-to-finish dependency types (most flat formats only represent finish-to-start), baseline data beyond the first baseline (numbered baselines rarely survive CSV export), resource cost rate tables (flattened to single values or dropped), and typed enterprise custom field values that become untyped text strings.

The second path is native .mpp import, which a small number of tools support as a first-party feature. The tool reads the .mpp binary format directly, extracts the schedule data at its original fidelity, and maps the result to its own data model. This path can preserve what the desktop-app path drops, if the destination tool's data model supports it.

Microsoft's own documentation on the boundaries and limitations of Project Online's data model is at learn.microsoft.com/en-us/projectonline/project-online-software-boundaries-and-limits, which is useful context for understanding what fields your .mpp files can contain.

What Gets Lost in the Desktop-App Import Path

The data losses in a multi-step .mpp import are predictable. They map to features the intermediate formats do not support.

Dependency types are the most common loss. Microsoft Project supports four: finish-to-start (FS), start-to-start (SS), finish-to-finish (FF), and start-to-finish (SF). An FS dependency means task B cannot start until task A finishes. An SS dependency means task B cannot start until task A starts, common in parallel workstreams with lead time relationships. When a project with SS or FF dependencies is exported through CSV or Excel, the dependency type field has nowhere to go in the flat format. The import tool creates finish-to-start links or no links at all. The schedule math changes without warning.

Lag values compound the dependency loss. A finish-to-start dependency with a 5-day lag means task B starts 5 days after task A finishes. A 5-day lag on a critical-path predecessor moves the project end date by 5 days when it is dropped silently. Projects with multiple dependencies containing lags can shift by weeks without any warning in the import log.

Baseline sets beyond Baseline 0 are a common silent casualty. Project Online supports up to 11 baselines per project. Most CSV and Excel export formats have columns for a single baseline (typically Baseline Start and Baseline Finish). Baselines 1 through 10 disappear. PMOs in regulated industries, audit-facing environments, or organizations that track variance against multiple approval snapshots discover this loss after the migration, when the baseline comparison reports are empty.

Enterprise custom fields (ECFs) with typed values fare poorly in flat formats. A Number field in Project Online becomes a text string in CSV. A Lookup field becomes the lookup value's display name, losing the code-behind that the organization uses in formulas and reports. The field data is technically present; its type is not.

Onplana's Native .mpp Import: Validation Before Commitment

Onplana's import reads the .mpp binary format directly. The result is that the schedule data Onplana receives is the same data that was in the file, not a CSV approximation of it.

What this preserves concretely: all four dependency types (FS, SS, FF, SF) with their original lag values. All baselines present in the file, numbered and accessible for variance reporting. Resource assignments with work-hours values, MaxUnits, and calendar exceptions. Enterprise custom field values with their original types where Onplana has a compatible type (Number fields map to Number, Text fields map to Text, Date fields map to Date). Project-level calendars and the working-time exceptions defined in them.

What the import still maps or interprets: ECF lookup tables that reference organization-wide lookup values need to be recreated in Onplana's custom field model, since the lookup codes are Project Online-specific. Certain calculated fields that Project Online derives at runtime (like cost-rate-tier calculations) become flat values at their most recent computed state. Project Server-specific workflow metadata does not have a natural mapping.

The validation report is the feature that separates Onplana's import from most alternatives. Before any data enters your live Onplana environment, the Migration Preview tool generates a structured report showing: which fields mapped cleanly, which had type mismatches, which dependencies had issues (circular logic, dangling predecessors, inconsistent lag signs), and a summary of the critical path in the imported schedule compared to the source. You can review this report, correct problems in the source .mpp file, re-run the preview, and confirm the import only when the result looks correct.

The diagram below shows the two import paths side by side.

What Each Import Method Preserves

Import Dimension	Onplana (native)	Most tools (desktop-app path)
Native .mpp import (no desktop app required)	Yes	No
MSPDI XML import	Yes	Rarely
FS dependency type	Yes	Yes
SS, FF, SF dependency types	Yes	Often lost
Lag values on dependencies	Yes	Often lost (silent drop)
Baselines beyond Baseline 0	Up to 11 baselines	Typically Baseline 0 only
Resource work-hours and MaxUnits	Yes	Partial (names often preserved, hours less so)
Typed custom field values	Yes, where type is compatible	Converted to plain text
Import validation report	Yes (before commit)	No
Critical path verification in import	Yes	No

What "Import Validation" Actually Means in Practice

Most PM tools do not distinguish between "your data was accepted" and "your schedule is correct." The import confirms that the file parsed without crashing. Whether the dependency logic produces the same critical path as the source file is something you discover weeks later when a milestone date looks wrong.

Onplana's import validation runs the critical path calculation on the imported schedule and compares the resulting project finish date against what the source .mpp computed. If they differ by more than a day, the report flags it and identifies the most likely causes: a dependency type that mapped differently, a lag that was adjusted, a resource calendar that did not transfer. This is not a guarantee of perfect fidelity; it is a structured way to catch the most common migration errors before they become tracking problems inside a live project.

The validation also checks dependency logic directly: circular dependencies (where task A leads to task B which leads back to task A, which many tools silently resolve by dropping one link), dangling predecessors (a task with a defined predecessor that no longer exists in the imported project), and inconsistent lag signs (negative lag is technically valid in MSPDI but handled differently across tools). These are exactly the kinds of hidden errors that the Schedule Health Check is designed to surface in production schedules. Catching them at import time is easier than finding them after three months of status reports.

The import validation result also feeds directly into the migration guide for existing .mpp files, which walks through what to do when the validation report flags specific types of issues: how to repair circular dependencies before re-importing, how to handle lag values that did not transfer, and how to reconstruct a lost baseline from raw task data.

When the Import Difference Affects Your Migration

For small, straightforward projects with only finish-to-start dependencies, no lags, and a single baseline, the desktop-app path and the native .mpp import produce comparable results. If all of your projects look like that, the import method is a minor convenience difference.

The import method matters in four practical scenarios. First, projects with complex dependency networks: engineering schedules, construction programs, or large IT transformations with SS and FF relationships built into the logic. Those dependency types carry schedule information that flat-format exports cannot preserve. Second, projects where the baseline is a compliance artifact: audit-facing PMOs that need baseline data available for variance reporting after the migration. Third, projects with significant custom field data: if your ECF schema is the organizational intelligence that makes reports useful, losing the type information converts your structured data into a pile of text strings. Fourth, teams migrating under time pressure: when the migration window is short, discovering that thirty projects have missing dependencies after cutover is a cost measured in weeks of rework.

The Migration Preview tool exists specifically to surface these issues before they become post-migration problems. Upload a representative sample of your most complex projects, review the validation reports, and determine whether the import will produce the schedule fidelity your PMO requires. That evaluation takes hours, not weeks, and it happens before a single project moves to the new environment.

Run the free Migration Preview Upload a .mpp file and see exactly how it maps into Onplana: dependency types, lag values, baselines, and custom fields. The validation report shows every mapping and flags every mismatch before any data enters your live environment. No signup required. → Open Migration Preview

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