Migrate from Wrike to OpenProject: what moves and what you rebuild
A Wrike renewal, a licensing change or a data residency requirement usually starts this project, and the key point for the PMO is that the move is a data and configuration project with no direct import tool for Wrike. The sources we reviewed document no Wrike importer for OpenProject, and its Jira Migrator covers only Jira Data Center, so confirm the current import options with OpenProject before you plan around any of them. In practice an internal PMO leads the work, with an implementation partner handling the OpenProject installation, the Excel mapping and the workflow rebuild. Effort depends mostly on how many projects, custom fields and dependency chains you carry, and on how much of the existing plan the team wants to keep. Ask any partner for a fixed scope in writing before work starts.
The Excel route carries the structure of your plans: task titles, dates, dependencies and assignees come out of Wrike's export and map into OpenProject work packages. Wrike's Excel export has a 65,000-row limit, so large portfolios need to be split by folder or project before export, and the export does not include comments or attachments. OpenProject's Excel synchronization uses a macro-enabled workbook and an API access token to download and upload work packages, and it supports parent and relation columns. The main constraint is custom fields: only fields that already exist in the target project are accepted, so create every Wrike custom field in OpenProject first and map each one to a column before you upload. Test the workbook in a non-production project first.
Attachments and comments sit outside the Excel route. Whether you can take them depends on your Wrike plan and its full account backup, which the sibling Wrike export guidance places on Business and above, so confirm the backup contents for your plan with Wrike before you rely on it. Plan a separate step to move files into OpenProject and reattach them to work packages, and decide whether old comments are archived as documents or left behind. Workflows, request forms and dashboards must be rebuilt by hand using OpenProject's statuses, types and custom fields. Record each rebuilt decision with its PMO owner so the new configuration can be reviewed and nothing is lost without a sign-off.
Which Wrike features map cleanly to OpenProject and which need rework
This table compares the main Wrike building blocks with their closest OpenProject equivalents and labels each as clean, needs rework or gap. Read it as a planning checklist: rows marked clean can usually move through the Excel synchronization with little change, while rework and gap rows need a decision on how to rebuild them before cutover.
| Wrike feature | OpenProject equivalent | Status | What to plan |
|---|---|---|---|
| Tasks and subtasks | Work packages with parent column | Clean | Export parent references so the Excel sync can rebuild the hierarchy |
| Dependencies | Relation columns on work packages | Needs rework | Confirm relation types in the workbook match what you used in Wrike before upload |
| Assignees | Assignee field on work packages | Clean | Map Wrike users to OpenProject accounts and confirm each user is a project member |
| Start and due dates | Start and finish dates on work packages | Clean | Check date formats in the export, since Excel can alter them during editing |
| Gantt plans | Gantt charts built from work package dates and relations | Needs rework | Rebuild the timeline views and baselines in OpenProject instead of expecting a visual copy |
| Custom fields | Custom fields on the target project | Needs rework | The Excel sync only accepts custom fields that already exist in the target project, so create them first |
| Request forms | No documented one-to-one equivalent | Gap | Verify the intake approach in a pilot before retiring Wrike forms |
| Workflows and automation | Statuses, types and workflows configured per project | Gap | Rebuild status transitions by hand and test any automation separately, since no direct equivalent is documented |
| Folder structure | Projects and subprojects | Needs rework | Decide how Wrike folders map to projects, subprojects or work package hierarchy |
Which data leaves Wrike through documented exports
Wrike offers four routes to get your data out: the Excel export, the full account backup on eligible plans, OpenProject's Excel synchronization for upload, and user administration for people. Each route covers different content, so no single file carries everything. Confirm current export options with Wrike for your plan before you plan the migration.
Excel export of tasks and dates
Wrike's Excel export is available on every plan and carries the task rows, assignees and dates that form the core of a Gantt plan. Each export stops at 65,000 rows, and it leaves out comments and attachments. Use it as the structured record for OpenProject work packages, and ask Wrike to confirm which columns, including dependencies, appear in the export for your plan before you design the field mapping.
Full account backup for attachments
On Business and above, the full account backup is the route for attachments, since the Excel export carries none. Keep it as a separate archive from the spreadsheet, and check that it holds the files for every project you plan to move. Ask Wrike what the backup packages and how it is structured, because it does not map fields to OpenProject work packages. Attachments then need to be re-linked to their work packages by hand or with a script.
Per-project splitting over the row limit
An account with more tasks than one export can hold must be split by project or folder before you export. Map each export file to one OpenProject project, so parent tasks and their children stay in the same workbook. Plan the split before exporting, because a dependency that crosses two projects can lose its link unless you record it in a separate list. Illustrative: a team with three large projects would produce three exports, one per project.
Upload with the Excel workbook
OpenProject's Excel synchronization workbook uses macros and an API access token. It downloads work packages from a project or query, uploads new or changed ones, and supports parent and relation columns that carry your hierarchy and dependencies. It only accepts custom fields that already exist in the target project, so create every Wrike custom field in OpenProject before the first upload. Confirm that your security policy allows macros on the workstations that run it.
Identities through user administration
Assignees must exist as OpenProject users before work packages can be assigned to them. Create accounts through user administration, or use SSO and LDAP group synchronization, which OpenProject lists among its Enterprise features. Match Wrike users to OpenProject accounts by email address before the upload, because a missing user leaves a task unassigned. Check whether your identity provider or directory will handle provisioning, since that decides how many accounts you create by hand.
Connectors need rebuilding
Slack, Google and Microsoft connectors and other Wrike integrations are outside the Excel export and the account backup, so they cannot move as data. Inventory each connector and record its trigger, its target and who depends on it. Then rebuild the equivalent notification or sync in OpenProject or in the tool itself. Confirm the current export scope with Wrike for your plan, because you should not assume any integration setting carries over.
Migration sequence from inventory to decommission
This sequence moves Wrike work into self-hosted OpenProject in controlled stages, so each project is proven in a test instance, reconciled against the source, and only then retired from Wrike. Each step produces a record that the next step depends on.
Inventory projects, tasks and attachments by size
List every Wrike space, folder, project and task that must move, and record the owner, active status, task count, dependency count and attachment volume for each. Confirm with your Wrike administrator which plan you are on, since the full account backup that carries attachments is available on Business and above, and check whether BI Export or request forms hold data you need. Mark projects that exceed the 65,000-row limit of the Excel export so they are split before export. The output is an inventory list with one row per project and a decision for each: migrate, archive only, or retire. The step is done when the business owner of each project has signed off that row.
Pilot one project in a test OpenProject instance
Install OpenProject in a non-production environment on your own infrastructure, using the Docker-based installation the project recommends, and run the Excel synchronization against one representative project from the inventory. Create the custom fields and types in the target project first, because the Excel synchronization only accepts custom fields that already exist there. Test parent and relation columns, assignees, dates and statuses, and note every field that Wrike used but OpenProject cannot receive. The output is a pilot report listing the rows uploaded, the rows rejected with reasons, the manual rework required, and the workflow or permission changes you need to make before the next wave.
Build the reconciliation sheet
Before migrating the rest of the inventory, create a reconciliation sheet that maps each Wrike field to its OpenProject work package field, custom field or documented gap. For every migrated project, record the count of tasks, the count of open dependencies, the assignees and the start and due dates in both systems, and list the attachments that were carried over from the account backup. Ask your implementation partner or internal team to review the sheet with the pilot report so that gaps are accepted in writing. The output is a reconciliation sheet that will be used for every later wave and as evidence during cutover.
Run a parallel period for a defined set of projects
Migrate a defined set of projects from the inventory into OpenProject and keep them active in both tools for a period agreed in advance with the project owners. Teams record new work in OpenProject for these projects, and Wrike remains the system of record for everything else. Reconcile the two systems at the end of each wave using the reconciliation sheet, and fix mapping errors in the Excel workbook or the OpenProject configuration before the next wave. The output is a signed reconciliation for each wave, showing that counts, dates, assignees and dependencies match or that each difference has an approved explanation.
Freeze Wrike and take the final export
Agree a cutover date with each project owner, then stop edits in Wrike for the projects being moved and take a final Excel export and a full account backup from Wrike. Run the final Excel synchronization into OpenProject, reconcile the results against the frozen export, and confirm that attachments in the backup match the attachment list in the inventory. Ask Wrike support to confirm in writing what the export and backup do and do not include, such as comments and attachment coverage, so the gaps are documented. The output is a cutover checklist with a timestamp for the freeze, the export file names, the reconciliation result, the named approver and the list of users who have been given access in OpenProject.
Decommission Wrike and retain an archive record
After cutover, keep the frozen export and the account backup in encrypted storage under your own retention policy, and confirm with your compliance lead which retention period applies to project records. Remove Wrike users, integrations and automations that still send work to the old system, and communicate the end of access to all users. Keep the reconciliation sheets and cutover checklist with the archive so that auditors or legal teams can trace what was moved and when. The output is an archive record that lists where each backup is stored, who can access it, the retention rule applied, and the date Wrike access was closed. Confirm with Wrike how your subscription ends and how long you can access the account before the final cancellation.
What drives the cost and duration of a Wrike migration
This table lists the factors that change how much work a Wrike to OpenProject move takes, why each one matters and how to keep it under control. Read it before asking for a quote, because the same license-free Community edition can carry very different rebuild effort depending on these inputs. The main takeaway is that data cleanup and scope decisions before export usually reduce cost more than any single platform choice.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Task count | Every task must be exported, mapped and checked, and large volumes push the Excel export toward Wrike's 65,000-row limit, so the export may need splitting. | Archive completed projects, close stale tasks and export by folder so each batch stays under the row limit. |
| Projects and folders | Each project or folder becomes an OpenProject project or sub-structure to create, name and permission, so counts drive setup time. | Consolidate small projects and agree the target hierarchy in writing before any import work starts. |
| Dependency density | Predecessor and successor links must be exported and re-created as OpenProject relations, and broken links must be found by hand. | Limit dependencies to those that drive the critical path and confirm which links the Gantt plan must keep. |
| Custom field count | OpenProject's Excel synchronization only accepts custom fields that already exist in the target project, so each Wrike field must be defined first. | Retire unused fields and map the rest to a short list of agreed OpenProject custom fields. |
| Attachment volume | Attachments come from the full account backup on eligible Wrike plans, so file count, size and mapping to work packages add handling and checking time. | Confirm your plan includes the full backup, remove obsolete files and agree whether older attachments are archived instead of migrated. |
| Workflows, request forms and status sets | Wrike workflows and request forms have no direct one-to-one copy, so statuses, types and intake processes must be redesigned and tested. | Document the ten most used workflows and rebuild only those, then retire the rest. |
| Users, roles and permissions | Each user needs an account and role, and access rules must be re-created, which grows with headcount and sharing complexity. | Clean the user list before export and agree a role model, such as project member or viewer, with the client. |
| Integrations and automations | Wrike integrations and automations are not carried over, so each one needs a replacement or a manual process. | Inventory every integration and decide which are needed on day one versus later. |
| OpenProject hosting and Enterprise plan | Community is free to license, but hosting, administration, upgrades and rework are paid effort. Enterprise on-premises is priced per named user per month on OpenProject's pricing page, and SSO and LDAP features sit in paid plans. | Ask for a written quote that separates licensing, hosting, setup and rework, and confirm which features your identity model needs before choosing a plan. |
What usually goes wrong and how to prevent it
Most Wrike to OpenProject migrations stall on a handful of predictable problems, and they tend to surface after cutover rather than during the test run. The cards below cover the data, identity and access decisions that cause them. Each one names a check to complete before users start working in OpenProject.
Attachments lost without a confirmed backup
The Excel export from Wrike carries no comments or attachments, so files only move if you take a full account backup. Backups are available on Business and above, so a lower plan may leave you with task rows and no files. Confirm your plan includes the full backup before you start the export, and check that the backup contains the project folders you need.
Dependencies broken by the row split
Wrike's 65,000-row export limit means large workspaces must be split across several files. A predecessor that lands in a different file cannot be linked by the Excel synchronization, so the relation silently drops out of the plan. Keep each project's tasks and their predecessors in the same file, then review the relation columns on upload before you rely on the Gantt chart.
Custom fields missing in target projects
OpenProject only accepts custom fields that already exist in the target project, so Wrike custom fields without a counterpart will be rejected or dropped. Create every required field in OpenProject, then add it to the work package types and projects that will use it. Build a field map from Wrike to OpenProject first, and confirm each field's type matches the values in your export.
Assignee mismatches from unmatched accounts
Assignments are matched to OpenProject users by their account, so a user who has no account, or who uses a different email address, leaves the task unassigned or assigned to the wrong person. Ex-employees and external contractors are the usual cases. Provision every Wrike user in OpenProject before the upload and reconcile the assignee column against the user list in a test project.
Gantt baselines reset during the move
Wrike baselines do not travel with the task export, so the dates in OpenProject are the current planned dates, not the original commitments. Stakeholders may then see the project as on schedule when it has already slipped. Record the baseline dates from Wrike in a separate column or document and agree with the PMO which dates count as the reference before go-live.
Users working in both tools after cutover
If Wrike stays open for editing after the upload, teams update tasks in two places and the OpenProject plan drifts within days. Re-running the sync later can then overwrite newer changes. Set a cutover date, make Wrike read-only for migrated projects, and freeze the export so the final upload is the only source of truth.
Broad permissions on the sync macro and token
The Excel synchronization runs on macros and an OpenProject API access token. A token issued to an administrator, or a workbook shared widely, gives every holder the same rights as that account. Create a dedicated service user with membership only in the migration projects, issue a token for that user, and revoke it after the migration completes.
How the migration differs by team size and starting point
A small team with one or two projects and no attachments has the simplest path. The Excel export from Wrike carries task names, dates, assignees and dependencies, so the main work is checking the workbook and rebuilding the project structure in OpenProject. The Excel synchronization workbook is usually enough at this size, but it only accepts custom fields that already exist in the target project.
- Export path: Export each Wrike project to Excel and confirm that no export approaches the 65,000-row limit.
- Sync approach: Upload with the OpenProject Excel workbook, which uses macros and an API access token, and test on one project first.
- Custom fields: Create matching custom fields in the target project before uploading, because the workbook will not create them.
- Relations and parents: Check that parent and relation columns produce the dependencies you expect in the Gantt chart.
- Decision point: Decide whether to recreate Wrike request forms and approval steps by hand, which is often the smaller job at this size.
Before the team moves over, confirm that every assignee maps to an active OpenProject user and that nothing your team relied on in comments is lost, since the Excel export does not carry comments or attachments.
A mid-size PMO usually runs many Gantt plans, each with its own dependencies and a body of attachments that the Excel export cannot carry. The export path therefore has two tracks: the spreadsheet for task structure and dates, and the full account backup for files. Attachments in that backup are available on Wrike Business and above, so confirm your plan tier before planning the work. The sync effort scales with the number of plans, so a single repeatable workbook template is worth building early.
- Export path: Export task data from every plan to Excel, and pull attachments from the full account backup on an eligible plan.
- Sync approach: Standardize one workbook template across plans so that each upload uses the same columns, parents and relation fields.
- Attachments: Decide where files will live in OpenProject and map each backup folder to the matching work packages before upload.
- Schedules: Confirm how baselines and schedule changes will be recorded in OpenProject, since the export only carries current dates.
- Decision point: Choose whether closed or archived plans move at all, which can reduce the number of uploads substantially.
Before the cutover, ask the PMO to sign off on a sample plan from each project type, because a template that works for one plan can still miss custom fields used only by another.
An enterprise with several Wrike accounts or regulated project records faces a migration that is mainly about governance. Each account needs its own export and backup, and each project record may need to be retained with its history before the Wrike subscription ends. Identity also becomes a decision: single sign-on and LDAP group synchronization are part of OpenProject's paid Enterprise plans, so the choice of plan affects how users are onboarded.
- Export path: Run the Excel export and full account backup for each Wrike account separately, and record where each archive is stored.
- Sync approach: Use the Excel workbook for pilot projects, then confirm with your platform team whether scripting against the OpenProject API is needed for volume.
- Identity: Decide whether SSO and LDAP group sync are needed at go-live, since both sit in paid Enterprise plans.
- Hosting: Size the self-hosted deployment against the OpenProject system requirements, including PostgreSQL 16 or later with the required extensions.
- Decision point: Agree with records owners which fields, comments and attachments must be preserved, and how long the Wrike archives are kept.
Before approving the plan, ask your compliance lead to review the retention approach and the access controls on the exported files, because the migration itself does not establish either.
Why the Excel route needs a staging workbook and a reconciliation step
The Excel route into OpenProject works only if you treat the workbook as a staging area that is checked before it touches the production project. OpenProject's Excel synchronization uses macros and an OpenProject API access token to download work packages from a project or a query, and to upload new or changed ones. It supports parent and relation columns, so hierarchy and dependencies from a Wrike export can be carried across, but it only accepts custom fields that already exist in the target project. Any Wrike custom field you have not created in OpenProject first will not arrive, so the first decision is which fields to recreate and where. Confirm the workbook version against your OpenProject release before you rely on its column layout, because the template is tied to the installed version.
Build the staging workbook from the Wrike Excel export with a column for the OpenProject work package ID, so that every row either maps to an existing work package or is marked as new. Keep dates in one format, and add an assignee column that matches each name to an OpenProject user login, since an unmatched name is a common source of silent errors. Run the upload against a pilot project first, download the result again, and compare row counts, parent links, relations, dates and assignees with the original export. Record every mismatch and fix the source row, not the output. Repeat the pilot until the differences are explained, then schedule the production upload with a fresh export so that late changes in Wrike are captured.
Questions buyers ask before moving from Wrike to OpenProject
What does it cost to move from Wrike to OpenProject?
The cost has three parts: the OpenProject edition, the infrastructure that hosts it, and the labor to export, map, import and rebuild your work. The Community edition is free under GPL-3.0 with community support. Enterprise on-premises is billed per named user per month, listed on the OpenProject pricing page at 5.95 euros for Basic, 10.95 euros for Professional (25-user minimum) and 15.95 euros for Premium (100-user minimum). One-time costs include the migration work and workflow rebuild. Recurring costs include licenses, hosting, upgrades and administration. Costs rise with the number of projects, custom fields, attachments and users. Ask any quote to list scope, user counts, what is in and out, and which edition is assumed for each feature.
How long does a Wrike to OpenProject migration take?
No fixed duration applies to every account. The timeline is set by how much data you have and how much structure must be rebuilt. Wrike's Excel export is limited to 65,000 rows per export, so large accounts need to be split into several exports. The OpenProject Excel synchronization only accepts custom fields that already exist in the target project, so field setup comes before the upload. Attachments follow a separate route, and dependency mapping needs testing on a sample. Each of these adds steps. Ask for a timeline in the quote that is tied to a written scope, a project count, and named milestones for test and cutover.
Can our team migrate from Wrike without a partner?
A small team with a few simple projects can attempt the move in-house. OpenProject's Excel synchronization uses a workbook with macros and an OpenProject API access token. It downloads work packages from a project or query and uploads new or changed ones. Before starting, check that your security policy allows macros, that someone can create and protect the API token, and that the target project structure exists. Larger portfolios, custom fields, and reconciliation of statuses and owners usually benefit from outside help. DeployOpen plans, implements, customizes, integrates and documents self-hosted platforms in your own infrastructure. Its engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
What do IT and PMO staff need to provide for the migration?
IT provides the hosting and the database. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and Docker is the recommended installation. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. The system requirements suggest 4 cores and 4 GB RAM for up to 200 users. IT also manages TLS, backups and the identity source for SSO. The PMO provides the project inventory, owners, status meanings, custom field definitions, workflow rules and sign-off on how Wrike fields map to OpenProject work package fields.
Do comments and attachments move from Wrike to OpenProject?
Not through the Excel export. Wrike's Excel export carries task data but no comments or attachments. Attachments come from Wrike's full account backup, which is available on eligible plans. Confirm with Wrike which plan includes it and what the backup file contains, including whether comments are present. The Excel synchronization documentation covers work package fields, parent and relation columns and custom fields, but it does not describe comments or file attachments. Treat these as a separate workstream. Decide whether files are re-attached manually, by script or by another method, and test a sample project to confirm the result before cutover. Note the expected volume of files in the quote.
Do task dependencies survive the move from Wrike?
They can, provided the export contains the dependency data and the workbook maps it correctly. OpenProject's Excel synchronization supports parent and relation columns, so predecessor and successor links can be carried as relations. Check that your Wrike export includes dependency fields for your plan, because the export only includes the columns Wrike provides. After upload, compare each dependency, its direction and any lag against the source, and review the Gantt chart for shifted dates. Test a sample project first, and confirm how re-running the synchronization handles changed items so that duplicates are not created. Ask the quote to include a dependency reconciliation step.
Is OpenProject Community or Enterprise needed for SSO and LDAP?
Single sign-on and LDAP synchronization require an Enterprise plan. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards. According to the OpenProject pricing page, SSO, LDAP synchronization and SCIM provisioning sit in paid Enterprise plans. Enterprise single sign-on covers SAML, OIDC, CAS, Kerberos and Okta, and LDAP group synchronization is listed among its features. Portfolio and resource management also sit in Enterprise. Confirm which plan includes each feature you need, since tiers and feature lists can change, and ask the quote to name the plan for every requirement.
How DeployOpen scopes and runs a Wrike to OpenProject migration
DeployOpen plans, implements and hands over self-hosted OpenProject inside your own infrastructure, including the export, mapping and import work for a Wrike move. Each engagement starts with a written scope that states which Wrike data is in and out, so the migration path is agreed before any work begins.
How we scope
- Inventory Wrike projects, folders, custom fields and request forms to decide what maps to OpenProject work packages
- Confirm which Wrike plan you hold, since attachments depend on a full account backup on Business and above
- Agree in writing which dependencies, assignees, dates and attachments move, and which are rebuilt by hand
- Confirm hosting location, identity provider, and whether you need Enterprise features such as SSO or LDAP group sync
How we build
- Install OpenProject in your own cloud account, data center or air-gapped network using the supported deployment method
- Prepare Excel workbooks from Wrike exports, split by the 65,000-row limit, and load them through OpenProject's Excel synchronization
- Recreate custom fields in the target project first, since Excel synchronization only accepts fields that already exist
- Test imports on a copy, reconcile task counts, dates and assignees, and document every exception before cutover
How we hand over
- Deliver the written runbook covering export steps, mapping tables, import order and the rebuilt workflow definitions
- Record which Wrike comments, attachments and automations were migrated, rebuilt or retired, so gaps are known to the business
- Walk administrators and project managers through OpenProject work packages, Gantt views and permissions
- Document backup, upgrade and access controls for the self-hosted instance in the handover pack
How we support
- Provide post-cutover support for the hypercare period defined in the written scope
- Offer ongoing support, upgrades and continuous testing as a retainer, quoted separately from the migration
- Keep backups, patching and upgrade planning under the same scope so the instance stays current after go-live
- Confirm with your team which SLAs, if any, apply, since these are set in the signed scope rather than assumed
