Skip to content

Migrate from Microsoft Project

All plansMember

This page is the hub for moving from Microsoft Project 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
A ProjectLibre .pod or GanttProject .gan plan Import a Microsoft Project file, the same importer reads both
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

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

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

For a file, follow Import a Microsoft Project file. Open Import, keep Upload a file selected under Where is your plan today?, and drag a .mpp, .mpx, .xer, MSPDI .xml, ProjectLibre .pod or GanttProject .gan file onto the drop area. Upload and review reads it, and the wizard shows a preview of what will land.

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, planned/fixed/baseline costs, and, when you import into a new project, the file’s baseline as a baseline in Onplana.

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).

Import into a new project and the file’s baseline comes across as a baseline in Onplana, so the Baseline tab compares actuals against it from day one (the Gantt shows a phantom baseline bar under each real task and a “Baseline (planned)” marker in the tooltip). See Capture and compare baselines.

If the file had no baseline, or you added it to an existing project, which keeps each task’s baseline dates but creates no baseline, take one now with the same article and treat it as your migration line in the sand.

  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.

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.

  • 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.

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.

Will my baselines from MS Project come over? Yes, into a new project. Import a .mpp or Project XML file into a new project and its baseline comes across as a baseline in Onplana, so the Baseline tab and the Schedule Quality checks compare against it from day one, and baseline costs land on each task as the Baseline Cost column. Adding a file to an existing project keeps each task’s baseline dates but creates no baseline, see Step 2. Microsoft Project’s extra baselines (Baseline 1 to 10) do not come across.

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, but the import wizard has a direct Planner source: connect your Microsoft account and choose Microsoft Planner, with an optional live sync to keep it updated. For a tiny board, recreating it in Onplana with Create your first project and the AI Kickstart can still be faster.

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.