Migrate from monday.com to OpenProject

Migrate from monday.com to OpenProject: what the move involves

The move is an extraction, a remapping and a rebuild, and a platform or IT team usually owns all three. Teams leave monday.com for OpenProject because of a renewal, a data residency requirement or a lock-in concern, and the data itself is rarely the hard part. The first step is pulling boards, items, column values, users and workspaces out of the monday.com GraphQL platform API, which is the documented programmatic route for reading an account. Someone with API access and a scripting background writes that extraction, and the output should be staged as structured files before anything reaches OpenProject. Confirm with monday.com which plan and token permissions your account needs for full reads, and check how it handles rate limits and paginated item queries, since those determine how long the pull takes on a large account.

The second step maps monday.com concepts onto OpenProject work packages. Board items become work packages, status and people columns map to statuses and assignees, and date columns map to start and finish dates. Columns with no clean equivalent, such as formula or mirror columns, need a decision about whether to store the value as a custom field or drop it. OpenProject's own Jira Migrator does not apply here, because it reads only Jira Data Center 10.x and 11.x and is in beta, so the mapping is usually custom work. The third step is the rebuild. Automations, integrations and dashboards do not transfer, so every monday.com automation must be listed, rewritten as an OpenProject workflow or notification where one exists, or retired. Dashboards are rebuilt from OpenProject's work package views and dashboards.

OpenProject Community is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. SSO, LDAP group synchronization and custom branding sit in paid Enterprise plans, which are priced per named user per month. Before you commit, list the features your teams need, decide whether they require Enterprise, and ask for the named user count and minimum seats in a written quote. Your main costs are then the hosting, the extraction and mapping work, the rebuild of automations, user training and ongoing administration. Confirm the operating system and PostgreSQL requirements against the OpenProject system requirements before you size the environment.

Which monday.com capabilities map cleanly to OpenProject

This table compares monday.com's main work management capabilities with their closest OpenProject equivalents. Each row is marked clean, needs rework or gap: clean means the concept carries over with little reshaping, needs rework means the data or configuration must be reshaped, and gap means the feature must be rebuilt or replaced. Confirm parity for your own column types, board structures and permission model in a test instance before you set a cutover plan.

Capability	OpenProject equivalent	Fit
Boards and items	Work packages grouped in projects, with types, statuses and board views	Clean
Column values	Custom fields and work package attributes, each with a fixed field format	Needs rework: map each monday column type and confirm supported formats
Users and assignees	Users, project memberships and assignments on work packages	Needs rework: roles and memberships are set per project
Workspaces	Projects and subprojects, with portfolio views in paid plans	Needs rework: decide how each workspace becomes a project tree
Timelines and Gantt views	Gantt charts driven by work package dates and relations	Needs rework: confirm dependency types and baseline needs
Automations	No direct equivalent in the Community edition; rebuild as manual steps or custom work	Gap
Integrations	Rebuilt through OpenProject's APIs or connectors; confirm each one before migration	Gap
Dashboards	Dashboards in the Community edition, with widgets that differ from monday.com dashboards	Needs rework: rebuild each dashboard and confirm widget coverage
Time tracking and SSO	Time entries on work packages; SSO and LDAP group synchronization are Enterprise features	Clean for time tracking; gap for SSO and LDAP sync on Community

What to extract from monday.com and what to rebuild

Moving from monday.com to OpenProject is mostly a data-staging and rebuild exercise. The platform API gives you the content, but the configuration that makes boards behave, such as automations, integrations and dashboards, has to be recreated by hand in the target system.

Extracting boards and items through the API

The documented route is the monday.com GraphQL platform API, which lets an app read boards, items, column values, users and workspaces inside an account. Write a small extraction script that pages through each board and writes every item and its column values to structured files. Confirm that the account's API token has read access to every board in scope, and note boards that are archived or shared across workspaces, since they are easy to miss.

Staging the export before import

Write the extracted data to staging files, one per board, with item IDs, column IDs and user IDs preserved as stable keys. Keep the raw JSON alongside a flattened CSV so you can re-run the mapping without calling the API again. Staging also gives you a point to review record counts per board against what monday.com shows in its interface before anything reaches OpenProject.

Mapping columns to work package fields

Map each monday.com column to an OpenProject work package attribute, such as subject, status, assignee, start and due dates, or to a custom field where no standard attribute fits. Status and people columns need explicit value tables, because labels in monday.com do not carry over automatically. Decide early how subitems become child work packages or relations, and document every mapping choice so reviewers can check it against a sample of real items.

Handling the lack of a ready importer

OpenProject's Jira Migrator does not apply to monday.com data. It reads only Jira Data Center 10.x and 11.x, and it is in beta, so it cannot be repurposed for this source. No documented monday.com importer is supplied, which means the extraction, transformation and load steps are custom work. Ask any implementation partner to price this as a scripted pipeline with test loads, not as a configuration task.

Rebuilding automations and dashboards

monday.com automations, integrations and dashboards do not transfer as data, so each one needs a deliberate rebuild. Inventory every automation rule and dashboard widget before cutover, then decide which ones OpenProject covers natively, such as status-driven views, Gantt charts and dashboards, and which need a workflow engine or a script. Record the trigger, condition and action of each rule so the rebuild can be tested against the original behavior.

Rebuilding notifications and integrations

Notifications, Slack or email hooks, and connections to other tools are configured inside monday.com and are not part of the board export. List each integration with its owner and purpose, then recreate the notification rules in OpenProject or in the systems they feed. Map user identities carefully, because user IDs from monday.com must match OpenProject accounts before any assignments or mentions can be restored.

The migration sequence from inventory to decommission

This sequence moves monday.com work into a self-hosted OpenProject instance in controlled stages, so each board is inventoried, tested, run in parallel and verified before monday.com access is removed. Each step closes with a named output that the next step depends on.

Inventory boards, automations and integrations
The project owner and a platform administrator list every board, its column types, its owners, the automations and integrations attached to it, and the dashboards people rely on. Use the monday.com admin view and the API to confirm counts instead of relying on memory. Automations and integrations do not transfer, so each one is recorded with a decision: rebuild in OpenProject, replace with another tool, or retire. The output is a board inventory and a rebuild register, signed off by the team leads who own the work.
Build the column mapping document
A platform engineer maps each monday.com column type to an OpenProject work package attribute, status, custom field, or project structure element, and records what has no equivalent. Status labels, people columns, date and timeline columns, and subitems each need an explicit target. Lossy mappings, such as formula or mirror columns, are written down with the value that will be kept as static text. The output is a column mapping document that the business owners approve before any data moves.
Extract and stage a pilot board
An engineer uses the monday.com GraphQL platform API to read one representative board, including items, column values, users and updates, and writes the raw responses to versioned JSON files. The extract is transformed to match the mapping document and loaded into a test OpenProject instance, not production. OpenProject's own Jira Migrator is not a fit for this path because it covers Jira Data Center only. The output is a pilot extraction with a reconciled item count, where the number of exported items matches the number of work packages created, and a list of exceptions.
Validate the pilot with its owners
The board owners compare the test OpenProject project against the source board, item by item for a sample and in full for items with attachments, assignees and dependencies. They check that statuses, dates, owners and hierarchy look right and that comments or updates are either carried over or archived. Issues found are fixed in the scripts and the pilot is reloaded from scratch to prove the process is repeatable. The output is a signed-off pilot record listing the defects found, the fixes applied and the open exceptions.
Run a parallel period on a defined project set
Selected teams work in both monday.com and OpenProject for an agreed window, with a named owner for each project and a rule for which system is the source of truth. Repeated incremental extracts keep OpenProject current, and reconciliation reports compare item counts, statuses and due dates between the two systems. Discrepancies are logged and resolved before the set is moved on. The length of the window is set by the project owners against their own delivery calendar. The output is a reconciliation log with zero open discrepancies for the agreed project set.
Cut over and rebuild critical workflows
The final extract is taken, loaded and reconciled once more, then the team switches to OpenProject as the system of record and announces the cutover date. Automations and dashboards on the retire-or-rebuild register are rebuilt in OpenProject, using its work package views, Gantt charts and dashboards, and tested with the people who rely on them. The output is a cutover record with the final reconciled counts and a rebuilt-workflow checklist that each owner has tested.
Archive the export and decommission monday.com access
Before access ends, the team stores a complete archive of the monday.com data extracted through the API, along with the mapping document, reconciliation logs and pilot record, in a location the organization controls. Accounts are removed, API tokens are revoked, and integrations are disconnected. Retention of the archive is set by the organization's own records policy and any legal hold requirements. The output is an archived export and a decommission checklist signed by the platform owner and the security lead.

What drives migration cost and duration

This table lists the factors that raise or lower the effort of moving monday.com boards into OpenProject, with the reason each one matters and how to keep it under control. Read it as a checklist for scoping and for the questions to put in a written quote, since no fixed price or duration is implied.

Driver	Why it moves cost or effort	How to keep it down
Number of boards and items	Every board needs a mapping decision, and item volume drives extraction time, load runs and reconciliation checks against the monday.com API.	Archive stale boards before extraction and migrate in waves by project, with a count reconciliation per wave.
Column type variety	Status, people, timeline, dependency and formula columns each need a defined target in OpenProject work package attributes, and unmapped types usually mean manual rework.	Inventory column types per board first and agree a written mapping table before any data moves.
Automations to rebuild	monday.com automations do not transfer, so each rule must be redesigned as an OpenProject workflow, notification or manual step and then tested.	List active automations, retire unused ones and rank the rest by how many teams depend on them.
Integrations and dashboards	Connected apps and dashboards are outside the data export, so each integration needs a replacement or a retirement decision.	Document every integration and dashboard owner, then keep only those with a named business need.
User count and Enterprise tier	Enterprise on-premises plans are priced per named user per month with minimum user counts, so the tier chosen sets the recurring license cost.	Map monday.com users to active OpenProject accounts, remove inactive users and compare tiers against the features you actually need.
Hosting sizing	OpenProject's sizing guide scales cores and memory with user count, and PostgreSQL 16 or later must be provisioned with the required extensions.	Size for the real active user count, and ask the implementer which sizing tier the quote assumes.
SSO and LDAP setup	Single sign-on and LDAP group synchronization are Enterprise features, and identity integration adds testing time before cutover.	Confirm the identity provider early and include login testing for each user group in the scope.
Parallel-run length	Running monday.com and OpenProject side by side keeps two sets of licenses and two sets of users working, and extends reconciliation.	Set a fixed cutover date and a defined sign-off test, so the parallel period has an end.

How the migration changes by team size and starting point

A single department with a handful of boards is usually the smallest migration. The data is contained, the people who own it are few, and the automations are often simple status changes or notifications. The main risk is assuming that the export is the whole job, because automations, integrations and dashboards stay behind in monday.com and must be rebuilt by hand in OpenProject.

Extraction scope: Pull the boards, items, column values, users and the workspace structure through the GraphQL platform API, and keep a record of which boards were in scope.
Rebuild work: Map status and person columns to OpenProject statuses, types and assignees, then recreate the few views and automations the team relies on as OpenProject boards and queries.
Hosting reference: A department-sized user base sits well inside the sizing guidance for up to 200 users in the system requirements, so a small single node is a reasonable starting reference to confirm with your own load.
Cutover approach: Run one trial import, have the team check a sample of work packages, then freeze edits in monday.com for the department and switch on the new instance in one step.

Confirm with the team which views and notifications they actually use before the cutover date, since those are the items that are most often missed.

What usually goes wrong and how to prevent it

Most failed monday.com to OpenProject migrations fail in the handover, not in the data copy. The cards below cover the gaps that appear during extraction, loading, user setup, parallel running and installation, with a prevention step for each.

Assuming automations and dashboards export

The GraphQL platform API returns boards, items, column values, users and workspaces, but automation recipes, integrations and dashboards are not part of that data set. Teams that inventory only their boards often discover the gap after cutover, when a status change no longer notifies anyone. Before extraction, list every automation, integration and dashboard by workspace and record its trigger, action and owner. Treat each one as a rebuild item in OpenProject, with a named owner and a test case.

Losing column value types in transit

monday.com column values are returned as typed fields such as status, people, date and timeline, and the API output often needs parsing before it fits a target field. A status column that becomes free text, or a people column that becomes a text list of names, breaks filters and reporting in OpenProject. Map each column to a custom field type or status before loading, and load a sample board first. Compare counts of statuses, dates and assignees between source and target for every sample.

Creating duplicate users during import

Users in monday.com are tied to email addresses, and the same person may already exist in OpenProject through LDAP, SSO or a manual account. Loading the user list without matching on email can create a second account that owns the historical work packages, while the active user sees none of them. Reconcile the user list against the target directory first, decide which identity source is authoritative, and confirm which accounts stay after import. Remember that LDAP group synchronization and SSO are Enterprise features, so confirm your plan before relying on them.

Running both tools with the same people

During a parallel run, teams often keep updating monday.com while OpenProject receives the same work, so two versions of a project drift apart. People who hold accounts in both tools then answer status questions from different data. Set a freeze date for each board, state in writing which tool is the system of record for each project, and reconcile changes made after the last extract. Close monday.com edit rights on migrated boards once the freeze is in effect.

Missing PostgreSQL extensions at installation

OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. A database that lacks these extensions can fail during setup or later affect search and filtering, and the error may appear only after data has been loaded. Before installation, confirm the PostgreSQL version and that the three extensions are available in the database the installer uses. Check the system requirements page for the exact supported package versions for your operating system.

Questions buyers ask before moving from monday.com to OpenProject

How much effort does a monday.com to OpenProject migration take?

Effort depends mostly on how many boards, items and column types you carry over, how much history you need to keep, and how many automations and dashboards must be rebuilt by hand. A simple set of boards with a few status and date columns is far less work than a portfolio with cross-board dependencies, custom formulas and integrations. The extraction runs through monday.com's GraphQL platform API, which is the documented route for reading boards, items, column values, users and workspaces. Mapping monday.com columns to OpenProject work package attributes, custom fields and statuses is usually the step that takes the most judgment. Ask any provider to break the effort down by extraction, mapping, load, validation and rebuild, and to state which of those they include in the quote.

What sets the timeline for moving monday.com projects into OpenProject?

The timeline is set by scope decisions and access, more than by the loading itself. The main drivers are the number of workspaces and boards in scope, how much cleanup monday.com data needs before it maps well, whether historical activity is required, how many people must sign off on the mapping, and how long the rebuilt automations and dashboards take to validate. Your own environment also matters: server provisioning, identity integration and access approvals can run in parallel or hold up the project. Because the scope is agreed in writing before work starts, ask for a schedule that lists each milestone and the client decisions it depends on, rather than a single end date.

What does the migration need from our own team?

Expect to supply a few specific people and decisions. A business owner should confirm which boards are active, which are archived and which must be kept as reference. Someone who administers monday.com needs to grant the access and API token used for extraction, and someone who administers your identity provider and infrastructure needs to approve the OpenProject environment. Board owners should review sample mappings for status names, owners and date fields, because those are where teams disagree most. Finally, plan for user acceptance testing with real project managers. Ask the provider to list these roles in the statement of work so that delays can be traced to a named dependency.

Can our team run the monday.com to OpenProject migration ourselves?

Yes, a capable internal team can do it, provided it has someone comfortable with GraphQL queries, scripting for transformation, and OpenProject administration. The monday.com API documentation describes how to query boards, items and column values, so extraction is achievable in-house. Work that often needs experience is validating the loaded data, matching user accounts, deciding how to represent dependencies and rebuilding automations and dashboards in OpenProject. Be realistic about the ongoing side too: once live, someone must own upgrades, backups and access control. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, so you can choose to do part of the work yourselves and contract the rest under a fixed scope.

What does not transfer from monday.com to OpenProject?

Automations, integrations, dashboards and the configured views on monday.com generally do not carry over as they are, so each one needs to be rebuilt or retired. Expect to recreate recurring notifications, status-driven actions and reporting views using OpenProject's own features, and confirm each one against the current OpenProject release notes before promising it. Third-party integrations need new connections, and any data that lives only in those integrations must be exported separately. Attachments, comments and activity history may need extra handling depending on the extraction method, so confirm each category explicitly with the provider and list the exclusions in the written scope.

Is OpenProject Community enough, or do we need Enterprise features?

The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Enterprise on-premises plans add features that many regulated teams need, including single sign-on (SAML, OIDC, CAS, Kerberos and Okta), LDAP group synchronization and custom branding, according to OpenProject's pricing page. Enterprise on-premises is priced per named user per month, with Basic at 5.95 euros, 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. Confirm current prices on the pricing page before budgeting, and decide early whether SSO and group sync are mandatory, since that determines the edition.

What should a written quote for this migration include?

A useful quote lists the scope in concrete terms: which workspaces and boards are in, the item count and column types, the mapping rules, the target OpenProject edition and hosting, and the exclusions such as automations and dashboards. It should separate one-time work (planning, extraction, mapping, load, validation, rebuild and documentation) from recurring work (hosting, upgrades, backups and support), and state what the client must provide. Ask for the acceptance criteria, the test approach, the timeline with dependencies, and how change requests are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the quote follows from that written scope.

How do we confirm OpenProject can handle our data volume and users?

Start with OpenProject's sizing guidance, which suggests 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, according to its system requirements page. Those figures are a starting point, not a substitute for testing with your own item counts and attachment volumes. Docker is the recommended installation method, with packaged installs supported on Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and PostgreSQL 16 or later is required. Ask the provider to load a representative subset and measure performance before the full cutover.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements the move from monday.com to a self-hosted OpenProject instance inside your own infrastructure. Each engagement starts with a written, fixed scope that covers boards, items, column values, users and the rebuilt workflows, so the work is agreed before any data moves.

How we scope

Inventory every monday.com board, item group, column type and user to decide what maps to work packages
List automations, integrations and dashboards that must be rebuilt in OpenProject, with owners for each
Agree the deliverables, timelines and acceptance tests in writing before work starts
Confirm hosting target, PostgreSQL version and sizing against your user count and access rules

How we build

Set up OpenProject on your servers or cloud account with the Docker-based installation your team operates
Script API extraction from monday.com's GraphQL platform API and stage the data for controlled loading
Map monday.com columns to OpenProject work package attributes and custom fields, then test on a sample board
Rebuild required workflows, statuses, roles and project templates, and document each mapping decision

How we hand over

Run reconciliation reports comparing item counts, owners and dates between monday.com exports and OpenProject
Provide runbooks for installation, upgrades, backups and user administration in your environment
Deliver a record of what did not transfer, such as monday.com automations and dashboards, with rebuild notes
Walk your administrators through the handover and confirm sign-off against the written acceptance criteria

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope migration
Plan OpenProject upgrades against published release notes and test them in a staging copy first
Review backups and restore procedures on a schedule agreed with your team
Ask for a written quote based on your scope, and confirm which OpenProject edition your plan requires

Migrate from monday.com to OpenProject