Migrate from Microsoft Project to OpenProject

Migrate from Microsoft Project to OpenProject: what moves and what gets rebuilt

Schedule content moves out of Microsoft Project through exports, but baselines, resource leveling and some resource logic have to be rebuilt in OpenProject. If your driver is a renewal, the Project Online retirement, a data residency requirement or a licensing change, plan the migration around that split: task names, hierarchy, durations, dates, predecessors and assignments can be carried across, while the saved plan history and the scheduling engine's behavior cannot. Most of this work is run by IT or the PMO, often with an implementation partner who handles the data mapping and the cutover. The effort and risk depend less on the tool and more on how many plans you are moving, how many of them are linked through cross-project dependencies or a shared resource pool, and how much custom field and enterprise data sits behind each plan.

Start with an inventory. For each .mpp file or Project Server project, record the task count, outline levels, predecessor types and lags, constraints, custom fields, and any resource calendars or enterprise resource pool links. Export the schedule to Excel in the form OpenProject's Excel synchronization expects, then open the file and check how Microsoft Project flattened the hierarchy and dependencies. Confirm the exact column mapping, the supported relation types and how OpenProject treats work packages that carry more than one assignee with the vendor documentation and a test import in a non-production instance. Treat the baseline as a separate deliverable: export the baseline dates to a sheet or PDF so auditors and sponsors can compare planned against actual, because OpenProject does not hold those saved baselines as Microsoft Project does.

Rebuild the parts that depend on Microsoft Project logic. Map each resource to an OpenProject user, group or placeholder, decide which custom fields need to exist before import, and re-create any leveling decisions manually after the dates are loaded. Agree a go or no-go check with the project owners: a sample plan reconciled line by line, the critical path reviewed by a scheduler, and a sign-off of the baseline archive. Ask any implementation partner for a written scope that lists the plans in and out, the data mapping, the test cycles and the cutover window, since these drive the quote. Recurring costs will follow the OpenProject edition you choose, so confirm which features your teams need, such as LDAP synchronization or single sign-on, before you size the license.

Which Microsoft Project features map to OpenProject, and which need rework

This table maps the main Microsoft Project features to their closest OpenProject equivalents and marks each as clean, needs rework or gap. Read it before you export anything, so you can plan which schedule elements arrive intact and which must be rebuilt by hand. The main takeaway is that task structure and dependencies move well, while baselines, leveling and some resource views need a deliberate plan.

Microsoft Project feature	OpenProject equivalent	Status and notes
Tasks and durations	Work packages with start and due dates	Clean. Confirm how durations and working time calendars map in the Excel import for your release.
Predecessor and successor links	Work package relations (precedes, follows)	Needs rework. Relation types and lag values must be checked row by row after upload.
Summary tasks and outline levels	Work package hierarchy (parent and child)	Clean for most plans. Verify indentation and parent references after import, since deep outlines are easy to misplace.
Milestones	Work packages flagged as milestones	Needs rework. Confirm the milestone type is set on each row in the import template.
Gantt chart view	Gantt charts in the Community edition	Clean for viewing and editing dates. Layout, colors and printed views will differ from the Project desktop client.
Resources and resource assignment	Assignees in the Community edition; resource management in Enterprise plans	Needs rework. Resource calendars and work-based allocation must be rebuilt, and resource management sits in Enterprise plans.
Custom fields and enterprise fields	Custom fields on work packages	Needs rework. Recreate each field type and its allowed values before the upload.
Baselines	No direct equivalent confirmed for migrated schedules	Gap. Keep the baseline as an exported file or snapshot. Confirm baseline behavior against the OpenProject release in use.
Resource leveling	Not a documented migration feature	Gap. Level the plan in Project before export, or confirm the OpenProject behavior in your release.
Timesheets and actuals	Time tracking against work packages in the Community edition	Needs rework. Map timesheet periods and approval steps, then test cost reports with finance.
Portfolio views	Portfolio and resource management in Enterprise plans	Gap for the Community edition. Confirm which Enterprise plan covers the dashboards you rely on.
Project desktop client	Browser-based work packages, Gantt and dashboards	Needs rework. Power users will need training, and offline editing of .mpp files stays with Microsoft.

Which exports and records to move from Project files and Project Server

Migration from Microsoft Project starts with deciding which records leave the source and in what form. The four inputs below cover schedule data, server-side data, people, and linked documents, and the integration choices that follow from them. Confirm which export routes your Microsoft licensing and tenant policies allow before you plan any extraction.

Project desktop files and task tables

Export each .mpp schedule's task table to Excel from the Project desktop client, keeping task ID, outline level, predecessors, dates and assignments as columns. This table is the input for OpenProject's Excel synchronization, which creates work packages with hierarchy and relations. Check that outline levels and predecessor links survive the export, because a flat list loses the parent-child structure. Baselines and leveling settings will not come across, so record them separately if you need them for reference.

Project Server and Project Online data

Data held in Project Server or Project Online is reached through the reporting or API routes your organization already licenses and administers. Ask your Microsoft administrator which OData reporting feeds, custom reports or API access your tenant allows for extraction. Extract projects, tasks, resources and timesheet actuals as separate sets so each can be reconciled against OpenProject later. Confirm the allowed routes before planning, since tenant policies may restrict bulk extraction.

Users and resource identities

Build a mapping of Project resources to OpenProject accounts before any work packages are assigned. Resource names in Project often differ from directory identities, and unmatched names become unassigned tasks. Decide which resources need a login at all, since OpenProject's Community edition does not provide the directory integration that large user lists usually need. Plan the mapping in a spreadsheet that the project owners sign off before import.

Single sign-on and directory sync

SSO with SAML or OIDC, LDAP group synchronization and SCIM provisioning sit in OpenProject's paid Enterprise plans, not in the free Community edition. If your directory should control who can see each project, confirm the plan covers the group synchronization you need before you migrate permissions. Tell your identity team which group names will map to project roles, so memberships are not hand-built for hundreds of users.

Attachments and linked documents

Files attached to Project tasks are usually stored outside the schedule file, often on SharePoint or file shares, and links point to those locations. Decide whether documents move into OpenProject, stay in place, or move to a self-hosted file store. If the team already stores project documents in Nextcloud, OpenProject has a Nextcloud integration that links files to work packages, which avoids copying content. Verify link targets after migration, because broken paths are common when storage moves.

How task hierarchy and dependencies come across through Excel

The Excel route carries a schedule as a flat table, so most of the work happens before upload. Build one row per task with a stable identifier that stays the same across test runs, a parent reference that points to the identifier of the summary task, start and finish dates, predecessor references and an assignee. Outline levels in the Project file have no meaning once the file is flattened, so the parent reference column is what creates the hierarchy in OpenProject. Before you export anything, confirm the column set and relation types that your OpenProject version's Excel synchronization accepts, because that list determines how every other column must be written.

Dependencies need an explicit mapping before import. Project supports several link types, including finish-to-start, start-to-start, finish-to-finish and start-to-finish, and each carries lags and sometimes date constraints such as a must-start-on date. Build a table that maps each link type in your source plans to an OpenProject relation type, and decide in advance what happens where no direct equivalent exists: convert the link to the closest supported type, keep it as a note on the work package, or model it another way. Lags and constraints are where dates shift without warning, so record every one of them as its own item to check.

Resources and custom fields must exist in OpenProject before the table is uploaded. Assignee values need to match user accounts that already belong to the project, or rows import without an owner or fail. Custom field columns need matching names and types, so create them first in the administration area and confirm each field is enabled for the relevant work package types. Then run a test pass on a copy of one project in a non-production instance. Compare task counts, parent structure, start and finish dates and the critical path against the source file, and check that lagged links landed where you expected. If your users are managed through LDAP, confirm with your OpenProject plan whether group synchronization is included, since it sits in the Enterprise features.

Migration sequence from inventory through decommission

The sequence moves Microsoft Project schedules into OpenProject in controlled stages, so each plan has one owner, one system of record and a documented check before the old files or Project Server data are archived. Each step produces a artifact that the next step depends on.

Inventory plans, owners and integrations
Project managers and the PMO list every schedule in use, including .mpp files on file shares, plans stored in Project Server or Project Online, and the owner of each. For each plan, record custom fields, enterprise resources, baselines, the reports and Excel or Power BI feeds that read from it, and any integrations with other systems. Confirm with your Microsoft administrator which data your tenant can export and at what level of access. The step is done when the inventory has one row per plan with its owner, its dependencies and a decision on whether it moves, archives or retires.
Pilot one plan end to end
Select one active plan of moderate size and move it fully: export the tasks to Excel, prepare the hierarchy, relations and dates in the OpenProject Excel synchronization format, import the work packages, and rebuild the resources and custom fields by hand. The plan owner then reviews the result line by line against the original, paying attention to parent and child tasks, predecessor links, start and finish dates, and assignees. Record every item that did not carry over, such as baselines or leveling results, and decide how each will be handled. The pilot is complete when the owner signs off on the list of gaps and the corrected import procedure is written down.
Run both tools in parallel
Keep the Microsoft Project files and OpenProject live for a period agreed with the sponsor, with one named system of record for edits. Most teams choose OpenProject for new work and keep Project read-only for historical reporting, but the choice must be written into the migration plan with its exception rules. Compare the two views at a fixed interval, check that dates and assignments match for each migrated plan, and log every discrepancy with its cause. Ask the vendor or your implementation partner to confirm how the Enterprise features you need, such as LDAP group synchronization or single sign-on, will be configured before users depend on them. The step ends when discrepancies have stopped appearing and the owners accept OpenProject as the working copy.
Cut over with a freeze and reconciliation
Announce a freeze date, block edits in the old tool, and run the final export from each plan. Import the final export into OpenProject, then reconcile dates, durations, assignments, cost and effort totals and open issues against the frozen source. Any difference is resolved and recorded before the plan is marked live. Confirm that access groups, roles and project membership match your identity source, since these do not come across from a schedule file. The cutover is done when every plan in scope has a signed reconciliation record and the business owners confirm that OpenProject is the only place where changes are made.
Archive, revoke and retire
Archive the Project files and a full export of Project Server or Project Online data in a read-only location with a retention period set by your records policy, and confirm that the archive can be opened later. Revoke Project desktop and Project Web App licenses for the users who no longer need them, and remove the integrations, scheduled reports and service accounts that depended on the old system. Update access reviews and the asset inventory so the retired platform is no longer listed as active. Ask your compliance lead which evidence of the decommission they need to keep. The step is complete when the archive is verified, the licenses are released and the integrations are removed.

What drives migration cost and duration, and how to keep each down

This table breaks migration effort into its components, showing who is paid for each, what makes it larger and what to ask for in a quote. Read it as a checklist for scoping, since most overruns come from inventory and cleanup work that is easy to underestimate. Microsoft costs are not quoted here, and OpenProject Enterprise prices are shown only as OpenProject publishes them.

Cost component	What makes it larger	How to keep it down	What to ask for in a quote
Discovery and inventory	Many .mpp files, Project Server farms with custom enterprise fields, and undocumented resource calendars	Limit scope to active schedules, archive closed projects, and list fields in use before any export	A written inventory of projects, fields, resources and portfolio reports with the agreed cut-off
Mapping and cleanup	Deep task hierarchies, manual outline numbering, and dependencies that carry lag or constraints	Agree a mapping of tasks, milestones, summary tasks and relations before import; fix data in the source file	Mapping rules for each Project field, and who signs off the cleaned plan
Import and reconciliation	Excel synchronization runs that need repeated correction passes, and checks of dates and relations against the source	Import a pilot project first, compare start and finish dates and predecessor counts, then batch the rest	Number of test imports included, and the reconciliation report format
Rebuilt resources and custom fields	Enterprise resource pools, cost rates and custom fields that OpenProject does not carry over automatically	Rebuild only the resources and fields still used for reporting, and document the rest as retired	Named list of resources, rates and fields to rebuild, with the owner of each
Parallel run support	Teams that keep Project and OpenProject side by side for several reporting cycles	Set one reporting cutover date and freeze edits in the source after the final export	Length of the parallel run, who maintains both systems, and the cutover criteria
OpenProject hosting	Server sizing: the system requirements suggest 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. PostgreSQL 16 or later is required, with the pg_trgm, btree_gist and unaccent extensions	Size to the named user count, provision the database with the required extensions from the start, and use packaged or Docker installs for repeatable builds	Server specification for your user count, database version and extensions, backup and restore design, and the operating system chosen from the supported list
Enterprise per-user licensing	SSO, LDAP group synchronization and portfolio features sit in paid plans. OpenProject publishes Basic at 5.95 euros, Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), and Corporate on request for 250 or more users, all per named user per month	Confirm which features you need before choosing a tier, and keep the Community edition if SSO and LDAP are not required	Tier, named user count, billing term, and confirmation of the features each tier includes

What usually goes wrong when schedules move to OpenProject

Schedule migrations rarely fail loudly. Dates shift quietly, allocations disappear, and two versions of the plan drift apart while the team is still working in both. The six risks below share one cause: the Microsoft Project file holds logic and history that OpenProject represents differently, so each risk needs a check before cutover.

Silent date shifts from dependencies and lag

Finish-to-start links, lag values and constraint types do not always translate one for one into work package relations. A relation that looks correct on screen can move successor dates by days, and the error only appears when someone compares the two plans. Before cutover, take a sample of critical-path tasks, compare start and finish dates in both tools, and sign off the reconciliation sample with the schedule owner.

Lost resource allocations

Work and allocation percentages set per resource in Project do not arrive as the same structure in OpenProject. Assignees may carry over while the effort split, overallocation view and calendars do not. Plan to rebuild resource assignments deliberately, and check the workload view against the source file for the named people who carry the most work.

Custom fields with no matching type

Project custom fields, lookup tables and formula fields often have no direct equivalent in OpenProject's custom field types. Values can be dropped, flattened into text or misread as the wrong type. Build a field map that lists each source field, its target type and who approved the mapping, and get that map signed off before any data is loaded.

Editors still working in the old file

During a parallel run, some owners keep updating the .mpp file or Project Server plan while others update OpenProject. The two versions then disagree, and the team cannot tell which one is current. Set an edit freeze date for the source plan, announce it in advance, and state that OpenProject becomes the only system of record from that point.

Baselines assumed to carry over

Baselines are central to how many teams judge schedule slippage, and OpenProject does not import a Project baseline as a comparable set of saved dates. Teams that expect variance reporting to continue often find it missing after cutover. Export baseline dates to a dated spreadsheet or PDF archive, label it clearly, and keep it with the project record.

Unsized hosting that slows large plans

A plan with thousands of tasks, many relations and heavy reporting places more load on the database and application than a small team project. A server sized for a small team can respond slowly once the full portfolio is loaded. Check the sizing guide for your expected user count, then run a load test with a representative large plan before users depend on it.

How the migration changes by project count and starting point

A small team with a handful of .mpp files usually has schedules on local drives or a shared folder, with no central database behind them. The work is mostly manual, and the main effort goes into deciding how each plan should be structured in OpenProject, not into tooling. Each file is exported to Excel, reviewed for outline levels and predecessor links, and then uploaded as work packages with parent relations.

Restructuring takes most of the effort: Check outline levels and dependency links in each exported sheet before upload, because the hierarchy you set becomes the work package structure.
Community covers basic scheduling: Gantt charts, work packages, agile boards and dashboards are in the free Community edition, so confirm whether you need any Enterprise features before buying a license.
Resources and custom fields are rebuilt: Resource names, assignments and custom fields are recreated in OpenProject from the exported columns, so keep one naming list for people and fields.
Baselines stay in the original files: Baseline dates do not carry over, so keep the source .mpp files as the record of the original plan.

Before you start, confirm how many plans you have, who edits them and whether anyone needs single sign-on, which is an Enterprise feature.

How much effort does a Microsoft Project to OpenProject migration take?

How much does a Microsoft Project to OpenProject migration cost?

The cost has five parts: the OpenProject plan, the servers, the migration work, your internal staff time and ongoing support. OpenProject Community is free and comes with community support. Enterprise on-premises is priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users, according to the OpenProject pricing page. Licenses recur monthly or yearly. Migration work is mostly one-time, and it grows with the number of plans, tasks, custom fields and resources to rebuild. Ask any quote to separate one-time migration lines from recurring license, hosting and support lines.

How long does a Microsoft Project migration to OpenProject usually take?

No single duration applies to every migration, so treat any fixed number with caution. The length is set by the number of schedules, the task count and depth of the work breakdown, how many cross-project dependencies exist, how many custom fields and resources must be rebuilt, how many test rounds the plan owners need, and when the cutover window is available. A small set of simple plans moves faster than a portfolio with shared resources and heavy reporting. Ask the partner to state the phases, the test rounds included, the acceptance criteria and the dates the client must meet, all in the written scope before work starts.

What does our internal team need to provide during the migration?

Three inputs come from your side and cannot be delegated to the implementer:

Plan owners who confirm which tasks, dependencies, dates and owners are current, and which are obsolete.
A field map decision that states how each Project field and custom field maps to an OpenProject work package field, which fields move to a custom field, and which are dropped.
A cutover window agreed with stakeholders, with a freeze on edits to the source files and a named person who signs off the reconciliation.

You also need an owner for user accounts and role mapping, because resource names must match OpenProject users before assignments can be rebuilt.

Can our own team migrate Microsoft Project schedules to OpenProject without a partner?

A capable team can migrate a small number of plans with a simple hierarchy, using a test instance and the Excel export and import route. The work is harder when plans share resources, depend on each other across projects, or carry many custom fields and calendars. It also needs someone who can check the result task by task, since dates, predecessors and durations can shift on import. A partner adds the most value in the field map, the test rounds, the reconciliation report and the cutover runbook. Decide early which parts your team will own and which the partner will deliver, and write that split into the scope.

Can baselines and resource leveling be kept when moving to OpenProject?

Do not expect them to carry over as they work in Microsoft Project. Baselines and leveling are among the items that do not migrate as-is, so plan for them explicitly. The practical approach is to keep the original baseline dates in a separate archive, such as a dated export file or a custom date field labeled as the baseline, so reviewers can still compare planned and actual dates. Leveled dates are recalculated in OpenProject from the current scheduling rules, so record the pre-migration dates for audit. Confirm how the OpenProject version you deploy handles baselines and resource allocation before you promise any feature to stakeholders.

What should we ask a partner to include in a written migration scope?

Ask for a written scope that lists each deliverable and the acceptance test for it. Useful items include an inventory of source files and plans, the agreed field map, a test migration into a non-production instance, a reconciliation report comparing task counts, dates and assignments, a cutover runbook with a rollback path, user and role mapping, training for plan owners, the hosting design and a stated support period after cutover. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask which items sit outside the scope, such as baselines or leveling archives.

Which OpenProject server size and database do we need for our user count?

OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB RAM for about 500 users, and 16 cores and 16 GB RAM for about 1,500 users, according to the system requirements page. Docker is the recommended installation, with .deb and .rpm packages for 64-bit Linux and Kubernetes with Helm charts for horizontal scaling. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm the current supported operating systems and database versions for the release you plan to deploy, and load test with your real schedule volume before cutover.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements the move from Microsoft Project files or Project Server to OpenProject inside your own infrastructure, from the first schedule export to the final handover. Engagements are fixed-scope, so the schedules, resources, custom fields and deliverables are agreed in writing before any migration work starts.

How we scope

Inventory which .mpp files, Project Server projects and custom fields are in scope for migration.
Agree in writing which schedule data moves, and which items such as baselines and leveling are rebuilt or retired.
Define the target OpenProject edition, hosting model and user count before deployment begins.

How we build

Deploy OpenProject on your own servers or cloud accounts, using the Docker-based installation path.
Map project hierarchy, work package relations and resources through the Excel synchronization workflow, then test on sample projects.
Recreate custom fields, roles and project templates, and run a reconciliation of task counts and dates against the source.

How we hand over

Document the export steps, import mapping, field decisions and known gaps so your team can repeat or audit the work.
Run user acceptance testing with your project managers against agreed checklists before cutover.
Hand over runbooks for backups, upgrades and access control, along with the archive of original Microsoft Project files.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
Confirm with your team which support hours and response expectations apply, and record them in the written scope.
Plan OpenProject upgrades in your own change process, with a retainer covering patching and post-upgrade checks if you choose.

Migrate from Microsoft Project to OpenProject