Skip to content
Onplana Docs

Migrating from Microsoft Project

All plans Member

You’re moving a project (or a portfolio of projects) from Microsoft Project to Onplana. This is the most common migration into Onplana, so the path is well-trodden. Six articles in the order that gets you from a .mpp or Project Online file to a running Onplana project, with the gotchas called out where they matter.

Estimated reading + setup time: an hour for a single-project migration. A portfolio migration runs about half a day per ten projects.

Step 1: import the file

Section titled “Step 1: import the file”

  1. Import from Microsoft Project — the canonical import path for .mpp, .mpx, and MSPDI .xml files. Drag the file into the importer; Onplana parses it client-side and shows a preview of what will land.

  2. Migrate from Project Online — for projects living in 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

Section titled “Step 2: capture the baseline”
  1. Capture and compare baselines — right after import, take a baseline. 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

Section titled “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

Section titled “Step 4: price the work”
  1. Configure rate cards — 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 timesheet rather than guessed-up-front values). Set up rate cards before the first timesheet week so the math reconciles.

Common gotchas

Section titled “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 org 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 baselineCost on each task. The Earned Value math in Read the EVM dashboard uses this when available.

What’s next

Section titled “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 tab 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

Section titled “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. The faster path is to recreate the planner in Onplana from scratch using Create your first project with the AI Kickstart, since Planner schedules are usually small enough to do in 10 minutes.

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.