The Definitive Guide to Migrating to Microsoft Project

Microsoft Project is a project management product developed and sold by Microsoft since 1984 — the company's third Windows-based application and the long-running default for Gantt-driven scheduling in the enterprise ¹. Its proprietary file format is .mpp, and from 2015 to 2020 it was the most popular project management application according to Project Management Zone ¹.

The typical customer profile splits across three editions whose migration mechanics diverge sharply: Microsoft Project Desktop (Standard or Professional, MPP files, single-planner or local workgroup); Project Online (SharePoint-backed Project Web App, on a retirement trajectory after Project for the Web took over the modern roadmap); and Project for the Web / Microsoft Planner (Dataverse-backed, integrated with Power Apps, Power Automate and Teams) ¹.

Licensing is tier-based — Project Plan 1 at $10/user/month for the lightweight web experience, Plan 3 at $30 including the desktop client, and Plan 5 at $55 for portfolio management and resource pools. Project for the Web was set to retire on August 1, 2025, folding into the new Microsoft Planner ¹.

The shapes of migration that land on Microsoft Project fall into four patterns. First, edition modernisation — teams moving from Project Online or Project Server PWAs onto Project for the Web / new Planner. Second, on-prem-to-cloud moves from Project Server installations onto Project Online or Project for the Web, typically driven by SharePoint version end-of-life ¹¹.

Third, consolidation onto Project from Asana, Smartsheet, Wrike, Jira or Monday, where teams want stronger critical-path scheduling and resource levelling than work-management tools provide¹⁴⁸. Fourth, desktop-to-server moves where a team standardises a collection of .mpp files into a single PWA or Project for the Web tenant for resource pool sharing and Power BI reporting.

What makes migrating *to* Microsoft Project easier than the category average is the maturity of the file ecosystem — desktop reads MPP, MPT, MPX, XML, XLSX, CSV and ASCII text, and the Import Wizard can map columns by hand or by saved map ⁵³⁵⁷.

What makes it harder is the edition fragmentation: Project for the Web caps custom fields at ten, has no formula support and no cross-project field reuse ⁴³⁴⁴, while Project Online's programmatic surface area is narrow and undocumented for many fields practitioners actually need ²⁶.

Schedules, baselines, dependencies and resource assignments do not move cleanly between editions without a tool that understands the underlying object model. Teams that pick the right edition first finish on time; teams that pick the import tool first do not.

Pick the right edition first and the right import path second. Teams that do this in reverse finish late.

Microsoft Project's object model is documented in the VBA reference — the Application sits at the root, Projects under it, and within each Project sit Tasks, Resources, Assignments, Calendars, WorkWeeks and Subprojects ³⁶. Project for the Web reshapes the same concepts onto Dataverse tables, while Project Online exposes them through the Project Server Interface (PSI) and CSOM ²²²⁶.

Before you can map a field on the source side, you need to know exactly which destination object the row belongs on, what fields it requires, and which value will serve as its upsert key. The table below summarises the objects you will touch in a Microsoft Project migration.

Tasks use a numeric Unique ID (UID, stable for the life of the project) and a positional ID that renumbers when rows shift; Resources use the same scheme. There is no platform-wide GUID across projects on the desktop — Project.GUID is per-file. On Project for the Web / Dataverse, every record gets a Dataverse id (GUID) that is the canonical primary key ²⁷.

When you import on the desktop, the Import Wizard does not upsert against a stable key — it appends to the active project or creates a new one ⁵⁷. For upsert semantics, use the PSI/CSOM (Project Online) or the Dataverse layer (Project for the Web), upserting against the Dataverse id or an Alternate Key defined in advance ¹⁸²⁷.

Custom field types determine validation and storage. On Project Desktop you get a fixed catalogue of typed slots (Text1-30, Number1-20, Date1-10, etc.) renamed via Project → Custom Fields, with optional lookup tables and formulas ⁴⁴⁵⁰. On Project for the Web you can create at most 10 custom fields per project, only the types listed below, and you cannot change a field's type after creation ⁴³⁴⁴.

Relationships in Project are modelled as Task Dependencies — Finish-to-Start (FS, the default), Start-to-Start (SS), Finish-to-Finish (FF) and Start-to-Finish (SF) — with positive or negative lag expressed in time units or as a percentage of predecessor duration ¹³⁵. Resources attach to tasks via Assignments carrying Units, Work, Actual Work and Remaining Work ²⁶.

Project Online imposes a 25 GB quota per Project Web App site, separate from SharePoint Online limits ³⁴. Subprojects (master/insert) allow nested project hierarchies on desktop and Project Server but are not supported in Project for the Web ¹¹.

The single most-important detail for any practitioner mapping into Project: task type (Fixed Units / Fixed Duration / Fixed Work) drives how Work, Duration and Units recalculate during import — get the project default wrong and your durations will silently drift after the load.

The single best predictor of a clean Microsoft Project migration is how much work you do on the source side before the first file is opened. Most teams discover this on day two when a 1,200-task plan imports with the wrong calendar, no baseline and resource assignments that arrived as plain text — every one of which traces to a missing pre-flight step.

Most Microsoft Project migration failures trace to three pre-flight gaps: wrong calendar, wrong task type default, and no resource pool plan.

Treat the source export as raw material that needs to be shaped to Project's expected formats — durations in consistent units (hours, days or weeks; pick one), dates rewritten to a culture-stable format, resource names resolved against the target Resource sheet, and outline levels expressed as integers your WBS column can read.

Source-side prep

• Audit and dedup the source project list before export — duplicate task names will not collide (Project allows them), but duplicate resource names across the Resource sheet break Assignment rollups and Cost calculations.
• Standardise duration units — pick hours or days for the entire dataset and convert. Project stores duration in minutes internally and infers display units from the import; mixed units in one file produce silent errors ⁶⁰.
• Re-encode CSV files as UTF-16 LE with BOM or legacy ANSI — recent Project updates broke parsing of UTF-8 and ANSI CSV, and the workaround is to save as Unicode in Excel before importing ⁷¹.
• Normalise dependency notation — Project accepts 5FS+2d, 5SS, 5FF-1d etc., but rejects free-form text. If the source exports Task 5, FS, 2 days you must transform before import.
• Decide what is in scope for historical data — actual work, actual start, actual finish, % complete and baselines must be imported on a separate pass after the schedule shape lands, or auto-scheduling will overwrite them.

Destination-side prep

• Pick the edition and tier first — Project for the Web caps custom fields at 10 and lacks formulas ⁴³⁴⁴; Project Online has a 25 GB PWA quota ³⁴; desktop has no shared resource pool unless you wire Project Server. Get this wrong and you re-do the migration.
• Create the Project calendar and Resource calendars before importing — set working hours, exceptions, and base calendar (Standard / 24 Hours / Night Shift). Imports use the project calendar to translate Duration into Start/Finish, and getting this wrong moves every date.
• Pre-create every custom field on Project Desktop or Project for the Web with the right type — type is immutable after creation ⁴⁴; the only fix is delete-and-recreate, which loses any data already loaded.
• Provision the Resource sheet or Resource Pool before importing assignments — assignments to unresolved resources are silently dropped or, worse, create new resources with the source's text representation as the name.
• Set Auto-Schedule vs Manually Scheduled as the project default before import — Manually Scheduled tasks honour the dates you load; Auto-Scheduled tasks recalculate from constraints and dependencies, which can reshuffle imported dates.

People prep

Cutover only works if humans cooperate. Lock a source-system freeze window — typically 24 to 72 hours — and communicate it to every project manager who owns a plan. Train PMs on the destination's scheduling defaults (Auto-Schedule behaviour, baseline workflow, time tracking entry) before go-live, not after.

A pilot migration of two or three representative plans — one simple, one complex with dependencies, one with significant financial tracking — surfaces 80% of the rollout's edge cases in week one. A full rollout typically takes four to eight weeks depending on the number of active projects, plan complexity, and reporting standardisation.

Microsoft Project exposes several load paths and the right one depends on edition, dataset shape, and whether you need re-runnable upserts. The desktop Import Wizard covers file-based loads (MPP, MPT, MPX, XML, XLSX, CSV, TXT). The Project for the Web Dataverse stack handles modern, web-native loads via Power Apps / Power Automate or direct Dataverse writes. The Project Online PSI/CSOM surface handles programmatic loads against PWA sites.

Desktop Import Wizard (Project Standard / Professional)

On the desktop, the Import Wizard runs from File → Open → [file type] or File → New → New from Excel workbook ⁷⁵. Supported source formats are Project Plan (.mpp), Project Template (.mpt), Project Exchange (.mpx, read-only in modern versions), Project XML (.xml), Excel Workbook (.xls, .xlsx, not .xlsm), tab-delimited text (.txt), comma-separated values (.csv) and XPS ⁵³⁵⁷⁹⁷.

The wizard walks Task Mapping, Resource Mapping and Assignment Mapping pages where each source column is mapped to a Project field by hand or via a saved map ⁵⁷. You choose New project, Append the data to the active project, or Merge the data into the active project.

There is no documented row-count cap — practitioner reports describe successfully importing schedules of 5,000+ tasks — but plans above roughly 1,000 tasks tax the default cache and undo limits, both of which should be raised before the load (cache to 100+ MB, undo to 99).

The right call: desktop Import Wizard for any file-format source under a few thousand tasks, single-planner migrations, or when you are consolidating a folder of MPP files into a master via Insert Subproject.

Project for the Web — Dataverse

Project for the Web stores everything in Dataverse — the same backend used by Dynamics 365 — and is loaded via the Dataverse layer with the CreateMultiple / UpdateMultiple / UpsertMultiple bulk actions ¹⁸. Bulk operations are throttled by Dataverse service-protection limits — honour the Retry-After response when throttling kicks in rather than calculating rates yourself ¹⁹.

Tables you write into include msdyn_project, msdyn_projecttask, msdyn_projectteam (resources), msdyn_resourceassignment and msdyn_projecttaskdependency. Power Automate, Power Apps and FluentPro Project Migrator all sit on this same Dataverse layer and are commonly used in the migration corner of the ecosystem¹⁵¹.

Project Online — PSI and CSOM

Project Online exposes the Project Server Interface (PSI) and the CSOM against the PWA site ²²²⁶. Practitioners commonly report needing the AssignmentTimephasedDataSet to pull resource hours per day, which requires CSOM or OData against /_api/Projectdata ²⁶.

Throughput patterns from the Dynamics 365 service-protection guidance carry over: use multiple threads with Retry-After backoff, distribute load across multiple service principals if a single one hits per-user limits, and prefer batch operations over per-record calls ¹⁹.

Third-party migration tools

FluentPro Project Migrator and FluentBooks, Relokia Migration Wizard, Birdview PSA's migration service and PPM Express all run on top of the load paths above. Project Migrator specifically lists Asana, Smartsheet, Planner, Project Online and Project for the Web as supported routes¹⁵¹.

Mapping is where every PM migration earns its scars. The decisions you make in the field-mapping spreadsheet determine whether the critical path matches the source on day two, whether time-tracking entries reconcile on day five, and whether PMs trust the schedule on day thirty.

Work object by object, top to bottom of the import order: Calendar first (so dates translate correctly), then Resources (so assignments can land), then Tasks with outline structure, then Dependencies, then Assignments, then Baselines, then Actuals.

Project hierarchy and task dependencies

Project hierarchy in Microsoft Project is expressed as an outline — summary tasks at outline level 1, sub-tasks at level 2, sub-sub-tasks at level 3, with no formal cap on depth. When importing from a flat source like Excel or CSV, include an explicit Outline Level column with integer values, or include a numeric WBS column (1, 1.1, 1.1.1) that the Import Wizard can use to generate the outline structure ⁶⁹.

Without one of these columns the wizard imports everything as siblings at level 1 and Summary Tasks are not generated. Add Outline_Level to your CSV as the first preprocessing step.

Task dependencies on import require the predecessor task to already exist in the same project — a common failure mode for streaming imports where dependencies arrive before their predecessor row ³. Two strategies: (1) sort the source by Outline Level and within-level by ID so predecessors load first, or (2) make a second pass after all tasks are loaded that only writes the Predecessors column.

Resources and assignments

Assignments require Task ID and Resource ID to both resolve. Source files that carry the resource as a free-text string (e.g. "Jane Doe") need a lookup-and-rewrite pass against the destination Resource sheet before assignment rows are imported, or assignments will create duplicate resources or fail silently.

Time tracking — Work, Actual Work, Remaining Work

Microsoft Project models time tracking on assignments via three core fields: Work (planned), Actual Work (logged), and Remaining Work (computed or entered). On the desktop, Actual Work can be imported via the wizard, but only if the import target field is mapped explicitly — practitioners frequently report imports where Outline and Tasks land but Actual Work shows 0 hours because the column was not in the import map ⁶⁰¹¹⁵.

Project Online and Project for the Web add timesheet entries (AssignmentTimephasedDataSet for the per-day breakdown) — these require CSOM or the OData _api/Projectdata path to read or write ²⁶. If you need per-day time history (not just totals), plan to either re-key in the destination or use a third-party tool that wraps the timesheet load.

Comments and attachments threading

Microsoft Project Desktop does not have native comment threads — it has the Notes field per task and per resource, accepting RTF on desktop and plain text everywhere else ⁸⁴. Project Online layers PWA discussion threads via SharePoint, and Project for the Web / new Planner uses Task chat (the modern replacement for legacy task comments) for threaded conversation ¹³³.

If you are migrating from a tool with rich comment threads (Asana, Monday, ClickUp), the practical mapping is: collapse the source comment thread into the destination Notes field as a chronological text blob, optionally with a SharePoint or Teams deep link to the original. Microsoft retired legacy Planner task comments in mid-January 2026 — migrations into Planner / Project for the Web must use Task chat going forward ⁸.

Attachments do not move inline through the Import Wizard. The supported path is to upload the file to the SharePoint document library backing the PWA (Project Online) or to the Dataverse msdyn_projectattachment table / Teams files (Project for the Web), then add a link in the task's Notes or Hyperlink field ⁹³¹⁰².

Custom workflow status and recurring tasks

Microsoft Project does not have a true Kanban-style workflow engine — the closest equivalents are: (1) the Status field, which is computed by Project from %Complete and Status Date and cannot be customised ⁴⁵; (2) a Text field (Text1 through Text30 on desktop) renamed to *Status* and populated with a lookup table of custom values ⁴⁵; and (3) the Project for the Web Bucket field for board-style grouping ⁴⁴.

If your source has a state machine like To Do → In Progress → Blocked → Done, the cleanest mapping is to import the state into a renamed Text field with a lookup table, then either drive %Complete from it via a formula (desktop only) or leave the two parallel as a manual reporting field.

Recurring tasks are created on the desktop via Project tab → Insert Recurring Task and stored as a single parent task with auto-generated children for each occurrence. There is no bulk-import path for recurrence rules — you import the parent and let Project generate the instances, or pre-expand the recurrence in the source CSV and import every instance individually.

Baselines and snapshots

Microsoft Project Desktop and Project Online support up to 11 baselines (Baseline plus Baseline1 through Baseline10), each storing a frozen snapshot of Start, Finish, Duration, Work and Cost for every task and assignment at the moment the baseline was set ¹³⁴. Baselines do not auto-import — once the schedule lands, run Project → Set Baseline to capture the current state, then any later actuals work shows as variance from the imported plan.

If you need to preserve baselines from the source, the only supported path is to write to the Baseline Start, Baseline Finish, Baseline Duration, Baseline Work and Baseline Cost columns explicitly during import — these are all individually mappable in the Import Wizard but absent from default import maps.

Audit trail, ownership and original timestamps

Standard Created, Created By, Modified and Modified By are platform-managed on Dataverse and SharePoint backends — they cannot be overwritten during a normal bulk import. Dataverse does expose overriddencreatedon for the create timestamp on a per-record basis when the calling user has the right privileges, but modifiedon and modifiedby always reflect the import job's identity ¹¹³.

If you need to preserve the original audit trail, the pattern is to create two custom fields per object — *Legacy Created Date* (Date1) and *Legacy Created By* (Text1) — and populate them from the source export. Owner/Assignee mapping during import only succeeds if the destination user exists in the tenant at the moment of import; assignments to unresolved users either fail silently or land against the import job's principal.

PM-specific: Power BI, Roadmap, Teams integration

Power BI reporting against Project data is configured *after* the data lands — the OData feed for Project Online is /_api/Projectdata; for Project for the Web it is the Dataverse connector. Roadmap and the Project / To Do / Planner shared task list inside Teams both refresh automatically once the underlying projects exist, but they are read-mostly surfaces — task-level edits there do not propagate back into Project ¹⁴⁸.

Validation is the bridge between the import finishing and PMs being allowed to schedule against the new plan. Practitioners recommend a three-stage validation: a pilot of 2 to 3 representative projects with PM spot-checks, the full load with real-time monitoring of task counts and dependency integrity, and a 30-day post-migration audit on actuals and baselines.

The most reliable signal is having the project's owning PM verify their own schedule — they know what the critical path should look like better than any reconciliation script.

Build a reconciliation queries spreadsheet that compares source and destination on the counts below. Anything outside a 0.5 percent variance gets investigated before PMs get edit access.

• Total tasks per project vs source — including summary tasks; mismatches usually trace to outline-level parsing gone wrong.
• Total dependencies per project — count Predecessor links and compare; dependency drops are the most common silent failure during Excel/CSV imports.
• Total assignments per project — and total Work hours summed across all assignments; a non-trivial hour variance usually signals unresolved resources.
• Critical path length (project Finish - project Start) — should match the source to within a calendar day; if it doesn't, calendar or task-mode mismatches are in play.
• Baseline coverage — count tasks with a non-null Baseline Start; this should be 100% for projects you baselined before migration, 0% for projects you intend to re-baseline after.
• Resource roster — count distinct resources on the Resource sheet; any duplicates indicate the resource-name lookup transform missed cases.
• Per-resource Work totals — GROUP BY Resource on Assignment Work and confirm against the source's capacity planning.

On top of reconciliation, run a manual spot-check: pick 10 random tasks across the most complex projects and verify Name, Duration, Start, Finish, Predecessors, Assignments and %Complete against the source UI. Pick three high-complexity dependency chains and trace each predecessor link visually on the Gantt chart. If a non-trivial discrepancy shows up in three or more of the 10, halt the load, fix the root cause, and re-import the affected projects.

Dataverse-backed Project for the Web supports record restoration: deleted Dataverse table records can be restored from the recycle bin via the Power Platform admin centre for a limited window (usually 30 days) ¹⁰⁴. Project Desktop has no native undo across a closed-file boundary — close the file after import and the undo stack is gone, which is why every desktop migration should keep the original MPP file as the rollback artefact.

The real rollback strategy remains: export every source plan to MPP and XML before the import starts, stamp every imported task with an *Import Batch ID* custom Text field, and if catastrophe strikes, bulk-delete by that batch ID and re-import from the cleaned source.

Cutover sequencing: (1) source goes read-only and PMs are notified; (2) final delta export captures everything that changed during the pilot window; (3) delta is imported; (4) reconciliation runs; (5) PMs get edit access and a 48-hour hyper-care window with the migration lead on call; (6) baselines are set on the destination after PMs sign off on the schedule; (7) source decommission is scheduled for 30 to 90 days out, never the same day.

The Microsoft Partner Network tiers consultants by competencies — Project Management is a recognised competency and there is a publicly-searchable Partner Directory. Practices that specifically deliver Project Online and Project for the Web migrations include Katalyst Partners (which lists 1,000+ Project Server migrations), Progent, PPM Express, Birdview PSA, and Aelum Consulting in the ServiceNow corner of the market for teams moving off Project Online entirely.

On the specialist migration-tool side, FluentPro ships Project Migrator and FluentBooks specifically for project-management platform migrations and is listed in the Microsoft Marketplace; it supports Asana, Smartsheet, Planner, Project Online, and Project for the Web with built-in object mapping¹⁵¹.

Relokia Migration Wizard covers MS Project to common PM destinations and exports Groups, Tasks (with Comments and Custom Fields), Task Dates, Created Date, and Users — practitioners note that MS Project does not have native task comments and Relokia synthesises one from the Notes field instead.

On the ETL and iPaaS side, Fivetran, Airbyte, Stitch, Workato and MuleSoft all have Microsoft Dataverse and Microsoft 365 connectors. Their role in a Project migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts resource names and resolves dependencies, and the ongoing-sync layer that takes over once the one-time migration is complete.

Microsoft's own implementation guidance for Dynamics 365 / Power Platform — which Project for the Web shares as a backend — recommends a sandbox-first environment strategy, with separate Dev, Test and Production tenants and a tested promotion pipeline ⁷⁴.

Managed-migration cost ranges vary widely. PPM Express advertises predictable enterprise pricing starting around $7,200/year for unlimited users, and partners scoping a migration service typically price by project rather than by seat.

A clean desktop-MPP consolidation of 25 to 50 plans without resource pools usually lands in the $5,000–$15,000 range; an enterprise Project Online to Project for the Web move with custom fields, baselines, timesheets and Power BI report rebuilds typically runs $40,000–$150,000 depending on plan count and historical depth¹⁴⁸.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Microsoft Project migrations and handles the field mapping, edition-fit assessment, calendar and resource pool setup, baseline preservation, and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on plan count and source platform, with separate line items for historical actuals depth and timesheet preservation so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Microsoft Partner Network consultancy, a specialist tool like FluentPro Project Migrator, an iPaaS-first approach, or an end-to-end managed migration. Explore FlitStack →