Migrate from Microsoft Project

This page is the hub for moving from Microsoft Project or Project Online to Onplana. The table routes you to the right entry point; the rest of the page walks the journey in order, with the gotchas called out where they matter.

You have	Start with
A .mpp, .mpx, .xer, or .xml file on disk	Import a Microsoft Project file
Projects living in Project Online	Migrate from Project Online
A whole Project Online portfolio, and you want the effort sized first (read-only)	Assess your Project Online estate
A file, and you want to see what survives the move before you commit	Preview what a plan keeps before you migrate
A work breakdown structure kept in Excel or CSV	Import a WBS from Excel

Note

Microsoft Project Online is being retired by Microsoft on September 30, 2026. This is the right time to migrate. Onplana imports both file and OData formats directly, so you don’t have to bridge through Excel.

Budget about an hour for a single project, or half a day per ten projects in a portfolio.

Step 1: import the file

Follow whichever import path the table sent you to, then come back here. Both land in the same place: a project you can baseline.

• From a file: Import a Microsoft Project file. Drag a .mpp, .mpx, .xer, or MSPDI .xml file into the importer; Onplana parses it and shows a preview of what will land.
• From Project Online: Migrate from Project Online. Onplana reads the OData feed directly with read-only credentials, so you don’t have to export anything.

What’s preserved automatically: project name and dates, task hierarchy (parent → child up to any depth), task names, dates, estimated hours, milestone flag, percent-complete (mapped to Onplana’s status + progress), priority (LOW/MEDIUM/HIGH/CRITICAL from MS Project’s 0-1000 scale), dependencies with type (FS / SS / FF / SF) and lag, ExtendedAttribute custom fields, resource assignments by email, and planned/fixed/baseline costs.

What stays behind: notes on individual tasks (those land as attachments instead), custom view layouts, calendar exceptions (import a working calendar separately), and any timeline / report formatting (Onplana has its own).

Step 2: capture the baseline

Right after import, take a baseline with Capture and compare baselines. This snapshots the as-imported plan so you can compare actuals against it later (the Gantt shows a phantom baseline bar under each real task and a “Baseline (planned)” marker in the tooltip).

If MS Project’s baseline was meaningful to your team, this is how you preserve it through the move. If it wasn’t, take a fresh baseline today and treat it as your migration line in the sand.

Step 3: verify the schedule

1. Link task dependencies. Most schedules import cleanly, but a few edge cases need touching up:

   • Hanger tasks (no predecessor and no successor in the middle of the schedule) usually mean a dependency was implicit in MS Project but didn’t make it into the file. Add the link.
   • Negative lag (a successor starts before the predecessor finishes) imports as-is. Verify the lag value is correct in Onplana’s days unit.
   • Cross-project dependencies are out of scope for the importer; recreate them by hand after both projects are imported.

2. Plan on the Gantt chart. The most reliable way to spot dependency issues is to look at the timeline. Walk the critical path end-to-end; any task that looks “floating” usually needs a missing link.

Step 4: price the work

Set up rate cards before the first timesheet week so the math reconciles. MS Project carries cost via “Cost” (planned), “Fixed Cost,” and “Actual Cost” on each task. Onplana imports the first two directly and uses rate cards for actuals, which is more accurate because it derives from timesheets rather than guessed-up-front values.

Common gotchas

• Hours vs days: MS Project often shows duration in days; Onplana stores it in hours. The importer converts using your org-level working day length (default 8). If your team uses 7.5 or 6 hour days, set the working calendar before importing.
• Resource matching: Onplana matches MS Project resources to Onplana users by email. Resources whose email doesn’t match any organization member land in the import warnings; invite those users first if they should be assigned.
• Custom fields on tasks: MS Project ExtendedAttributes import as per-project custom fields, not org-wide. If you want a particular field to appear on every project, promote it to org-wide after the import (see Scope custom fields to one project).
• Baseline cost columns: imported as Baseline Cost on each task. The Earned Value math in Read the EVM dashboard uses this when available.

What’s next

Your project is in. Natural follow-ons:

• Track the work: invite the team and the PM onboarding bundle has the operating-rhythm articles.
• Compare actuals to baseline: the Baseline view on every project shows variance live.
• Roll up across the migrated portfolio: if you imported many projects, the cross-project Reports builder is where the portfolio-level view lives.

FAQs

Will my baselines from MS Project come over? Yes, task-level baseline dates and costs import directly. The Gantt’s “phantom baseline bar” shows them immediately.

What about Project Server (on-prem)? Export your projects to .mpp or MSPDI .xml and import them the same way. Onplana doesn’t read Project Server’s database directly.

My team uses Microsoft Planner, not Project. Should I follow this guide? Planner has no .mpp import. Its export is task-list-shaped CSV, so the faster path is to recreate the plan in Onplana using Create your first project with the AI Kickstart. Planner boards are usually small enough to recreate quickly.

Can I run Onplana alongside MS Project during a transition? Yes, for a few months. Most teams keep MS Project as the read-only system of record while they validate the imported plan in Onplana, then cut over at a natural boundary (sprint end, quarter end). Onplana doesn’t write back to MS Project; the transition is one-way by design.