Export data from monday.com: what moves and what doesn't

How to export your data from monday.com before the contract ends

If a renewal, a price change or a data residency requirement has you planning an exit from monday.com, start with the export, because it determines what you can move and how much rebuilding follows. The documented programmatic route is monday.com's GraphQL platform API, which reads and updates boards, items, column values, users and workspaces inside an account. Automations, integrations and dashboards do not carry over through that route, so they belong on a separate inventory. Before you rely on any scripted extract, confirm the export options available in your own account with monday.com, including any built-in board export and what your plan and role permit, because those options and their limits are set by the vendor and can change.

This section covers three steps. First, record what you have: the boards, the column types on each board, the workspaces that hold them, and the users who own or are assigned items. Second, decide how you will pull that data. You can use the built-in board export for people who only need a file, or you can write a script against the GraphQL API that requests each board's items and column values and saves them as JSON. The API returns values in column-specific formats, so the script must handle people, dates, status and dropdown columns differently from plain text. Third, check the output against the live boards by counting items per board and spot-checking assignees and dates before you delete anything. Keep a copy of the raw export, since you will need it again if the target mapping changes.

Plan for the items that will not come across. Automations, integrations, dashboards and their filters must be written down as requirements and rebuilt in the target tool, and their logic should be exported as a record even when it cannot be imported. Attachments and comments depend on what the API returns in your account, so test them on one board first. Once the data is staged in a clean, documented format, the next steps differ by target: OpenProject and Plane each take their own import route, which the sibling migration pages describe. Note the contract end date and schedule your final export well before it, so that any gaps can be fixed while your monday.com account is still active.

Which monday.com data you can export and by which route

This table maps each monday.com data type to the documented GraphQL platform API route and the points you must confirm in your own account. Use it to plan what to extract programmatically and what to check in the admin area before you start. The main takeaway is that the API is the only documented programmatic route, while export formats and limits are not stated in the supplied material and need confirmation.

Data type	Export method	Output format	Limits to confirm
Boards	GraphQL platform API, reading board objects in the account	JSON responses you transform into your own files	Query complexity and rate limits, and which boards your token can read
Items	GraphQL platform API, reading items on each board with pagination	JSON, with one record per item	Page size and how many items a single request returns
Column values	GraphQL platform API, reading column values attached to each item	JSON keyed by column ID and type, needing your own mapping	Which column types return full values and how formula or mirror columns resolve
Users	GraphQL platform API, reading account users	JSON with names and email addresses you map to OpenProject or Plane accounts	Whether deactivated users and guests appear and what personal fields your token exposes
Workspaces	GraphQL platform API, reading workspace objects in the account	JSON used as a structure map for projects or teams	Whether workspace membership and permissions are returned in the same call
In-product board export	Board export in the monday.com interface, if your plan offers it	Confirm in the admin area of your account	Confirm the file format, included fields and any size or row limits

How the GraphQL API pulls boards, items and column values

An export script reads monday.com through its GraphQL platform API, and the first thing to settle is which user the script runs as. The API authenticates with a token tied to a specific user, and every request returns only what that user can see in the account. If the token belongs to an admin, the export can reach boards that a standard member cannot open. If it belongs to a member, private boards and boards shared with other teams may be missing from the output. Before you write code, confirm with the account owner which user will hold the token, check that this user has access to every workspace being moved, and record that decision so the exported set can be reconciled later. The usual pattern is to query boards for each board ID, then request its items_page with the column_values for each item, reading both the item name and the value of every column. Large boards return their items in pages, so the script must follow the cursor on each page until none remains, and it should store each page before requesting the next so a failure mid-run does not force a full restart. Column values come back in a format that depends on the column type, so people, dates, status labels and linked items each need their own parsing rule. Users and workspaces are read through separate queries, and the user records matter because assignee columns refer to user IDs that must be resolved to names and email addresses. Developers should read the current monday.com API basics page before writing a line of code, because the details that shape an export change over time. That page covers authentication, query complexity and rate limits, and a large export can hit those limits quickly if the script requests too many fields or items at once. Ask the developers to build in retries and to measure a test run on one small board first. Treat the output as a record of what the token could see, not a full account backup, and confirm with the account owner which boards, if any, remain outside the export.

What does not transfer from monday.com and how to rebuild it

Board data is only part of a monday.com account. Automations, integrations, dashboards, connected apps, column formulas and saved views often carry the working logic of a team, and they usually stay behind when you export. The supplied facts do not confirm which of these items the monday.com export includes, so check each one in your own account before the contract ends.

Automations and triggers

Automations are the rules that move items between statuses, notify owners or set dates when a column changes. Before the contract ends, list every active recipe on each board, its trigger, its conditions and its recipients. Export does not reliably carry these rules, so treat them as a rebuild list. In OpenProject, most rules become workflow steps, notifications or saved queries. In Plane, check which automation features sit on the plan you run, since paid features depend on the Commercial Edition.

Third-party integrations

Connections to Slack, Google Drive, Jira, email tools or custom services push and pull data on schedules you may not see from the board itself. Record each connected system, the direction of data flow, the fields it reads and writes, and the account that owns the connection. These links do not transfer, so each one either needs a replacement connector, a scheduled script against the API or a documented manual step. A developer should confirm which fields the external system depends on before you switch it off.

Dashboards and widgets

Dashboards combine charts, counts and workload views across several boards into one page that managers use in reviews. Record each widget, the boards and columns it reads, its filters and the audience that relies on it. Rebuild these in OpenProject with saved queries, Gantt views and the dashboard module, or in Plane with its built-in views, and confirm which layouts your version provides. Keep a screenshot and the underlying figures so you can check the rebuilt numbers match.

Formulas and column logic

Formula columns, mirrored columns and dependency columns calculate values from other columns, often in ways nobody has written down. Export the resulting values, but record the formula text, the columns it reads and any rounding or date rules it applies. Because the calculated values may not transfer as live logic, you can recreate the calculation as a custom field or a documented spreadsheet step. Ask a developer to confirm the formulas before the export so the migrated numbers can be verified against them.

Saved views and filters

Personal and shared views decide which items people see, how they are grouped and which columns appear first. Record the view name, owner, filter conditions, sort order and visible columns for every view that a team uses daily. These settings are not data and are unlikely to move with a board export. In OpenProject, rebuild them as saved work package queries. In Plane, rebuild them as filtered views, then confirm each one returns the same items as the original.

Users, roles and permissions

Board access depends on account users, guest status, team membership and per-board permissions. Export lists users and workspaces through the platform API, but the access rules attached to each board are a separate record. Note which people hold admin, member or guest roles on each board, and which boards are restricted to specific teams. Map these to OpenProject roles or Plane roles before import, and confirm the mapping with the people who own each board.

Export sequence: from inventory to verified copy

This sequence turns a monday.com account into a complete, checksummed copy of its boards, items, column values and users that you control, so the data can be loaded into OpenProject or Plane with a known baseline. Each step ends with a check you can repeat before the account is changed or closed.

Inventory boards, workspaces and users
Start by listing every workspace, board, and active or inactive user in the account, using the account admin view and, for a complete list, the API queries described in the monday.com developer documentation. Record each board's ID, name, state (active, archived or deleted), item count as shown in the board view, and the owner of each board. Save this inventory as a dated file in your own storage. The step is complete when every board ID in the inventory can be traced to a workspace and an owner, and the board count matches what an admin sees in the account.
Document automations, integrations and dashboards
Before extracting anything, record the automations, integrations, dashboards, forms and connected apps attached to each board, with their triggers, conditions and targets. These do not transfer as data, so this list becomes the rebuild plan for OpenProject or Plane. Ask the account owner to confirm which items are still in use, because unused automations are often the ones that surprise a migration later. The step is complete when each automation and integration has a row in the rebuild list, and each row names the board it belongs to.
Create a scoped API token for a dedicated export user
Create a separate user for the export, give it access only to the workspaces and boards in scope, and generate an API token from that user's profile rather than from a personal administrator account. Confirm with your monday.com administrator which permissions the export user needs, and remove the token once the export is verified. Record who created the token, when, and for which boards, so the access trail is clear. The step is complete when a test query returns the expected board names for the export user and fails for any board outside its scope.
Run queries per board and save raw JSON with timestamps
Using the GraphQL platform API, query each board separately for its items, column values, groups and the users referenced by those items, and paginate until no next page remains. Save each response as raw JSON, named by board ID and run timestamp, without editing it. Keeping the raw responses means any later transformation can be repeated and checked against the original. The step is complete when every board in the inventory has at least one raw JSON file, and the pagination cursor is empty at the end of each query series.
Reconcile counts, column values and user lists
Compare the exported data with the account. Item counts per board in the saved JSON should match the item counts in the board view for the same time, and the number of distinct column values per column should be consistent with what the board shows. Compare the user list in the export with the account's user list, and note any users who were removed or deactivated. Where counts differ, rerun the query for that board and check for archived items or pagination errors before going further. The step is complete when every board's counts match or each difference has a documented explanation.
Store a checksummed archive in your own storage
Package the inventory, the rebuild list, and the raw JSON files into a single archive, then generate a SHA-256 checksum for the archive and for each file it contains. Store the archive and checksum file in storage your organization controls, such as an on-premises file server or an object store under your own account, and restrict access to the export team. Keep the export token revoked and the archive read-only after storage. The step is complete when a second person can recompute the checksums and get the same values, and the archive can be opened without access to monday.com.

Staging the data for OpenProject or Plane

OpenProject's documented Jira Migrator does not apply to a monday.com export. The migrator is in beta, supports only Jira Data Center 10.x and 11.x, and does not support Jira Cloud, so it cannot read monday.com data. Before you load anything, ask OpenProject which import path your target version supports for generic CSV or API data, whether that path is included in your edition, and how it handles custom fields, users and statuses. Until that answer is in writing, treat the export as input to a staging step that your team controls.

Staging workbook: Build one sheet per monday.com board, with one row per item and one column per target field, such as subject, status, type, assignee, start date, finish date and parent. The column list is illustrative and should follow the fields your OpenProject version accepts.
Column mapping: Map each monday.com status, people, date and dropdown column to an OpenProject status, user, date or custom field. Record every value that has no equivalent so that someone decides how it is handled before the load.
User matching: Match monday.com members to OpenProject users by email address, and list the accounts that need invitations or deactivation before the cutover.
Raw export: Store the original API or board export unchanged, with its date and a checksum, and run every cleaning step on a copy.
Test load: Load a single board into a non-production OpenProject instance and check item counts, dates, assignees and comments against the source before running the full import.

Check the import route, the user matching rule and the handling of attachments with OpenProject before you schedule the cutover.

What to plan before the monday.com renewal or termination

The export is the easy part to start and the hardest part to finish well. The cards below cover the dates, people and decisions that shape a clean export, so that the data you move into OpenProject or Plane is complete, frozen at a known point and signed off by someone who owns the result.

Confirm notice and renewal dates

Find the renewal date, the notice period and any auto-renewal clause in your monday.com order form or subscription terms. Those dates set your real deadline, because access usually ends when the subscription does. Ask your monday.com account team to confirm in writing what happens to boards, workspaces and API access after the end date, and whether any data retention window applies. Do not rely on memory or on this page for those terms.

Set the export window

Work backward from the access end date and schedule a first test export, a second full export and a final export close to cutoff. Each pass should be timed and logged, so the team knows how long extraction takes for the largest boards. Keep at least one full pass ahead of the cutover so that gaps can be found while monday.com is still available to check against.

Count seats for the export and target teams

Decide which named user will run the API extraction and whether it needs an admin or member role to read every board, workspace and user record. Then count the people who need access in the target tool during migration and testing, separately from the people who will use it after go-live. Confirm with monday.com how seats and roles are billed during the notice period, and with OpenProject or Plane how their seat rules apply to the target team.

Freeze board changes during final export

Agree a cutoff time after which no one edits items, column values, statuses or board structure in monday.com, and tell every board owner in writing. Without a freeze, the final extract and the verified copy describe different data. Record the cutoff time with each export file so that any later difference can be traced to edits made after the freeze.

Assign owners for automations and integrations

monday.com automations, integrations, dashboards and connected apps do not move with the board data, so each one needs a named owner and a rebuild decision. List every automation and integration from each board, record what it does and which system it touches, then decide whether it will be rebuilt in OpenProject or Plane, replaced by a workflow tool or retired. Owners should sign off on each item before the cutover.

Agree sign-off criteria for the verified copy

Define what counts as a verified copy before the first export runs. Typical checks include item counts per board, column values for a sample of items, user and workspace mapping, attachment counts and a spot check of comments and dates against the live board. Name the business owner who signs off each board, and record the sign-off in a file kept with the export.

Questions buyers ask before exporting monday.com data

Can we export our monday.com data without outside help?

Yes, if your team has an API-capable developer and someone who owns verification. Simple boards can be exported from the monday.com interface, but a full extraction of boards, items, column values, users and workspaces runs through the monday.com GraphQL API. Your team would write the queries, handle pagination, store the results in a staging format and check them against the source. Teams with a small number of boards and no integrations can often manage this in-house. Teams with many boards, custom column types or automations usually decide earlier whether to bring in a partner.

What drives the effort of a monday.com data export?

The effort rises with the number of boards, the number of items per board, the variety of column types and the amount of connected configuration. Each board adds its own structure, so a workspace with dozens of boards takes more mapping and checking than one with a handful. Automations, integrations and dashboards add scope because they do not come across in a data export and must be documented and rebuilt. Attachments and comments add volume and separate handling. Ask any provider to price the work against a written inventory of boards, item counts, column types, automations and integrations.

How long does a monday.com export project take?

The duration depends on the scope, so no fixed timeline applies to every account. The main variables are the inventory of boards and items, how many column types need custom mapping, how many automations and integrations must be rebuilt, and how many test cycles your verification owner needs. Extraction itself is often the shorter part of the work. Ask for a written scope with deliverables and a timeline that lists each stage, including testing and sign-off. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

What does our team need to staff a monday.com export?

Three roles cover most exports. An API-capable developer writes and runs the queries, transforms the JSON and loads the staging files. An admin on the monday.com account confirms access, workspace structure, user records and which boards are in scope. A verification owner, usually someone from the business team, compares record counts, checks sample items and signs off on each board. Without the third role, errors such as missing statuses or misassigned owners often surface only after cutover. Agree on who makes the final acceptance decision before the work starts.

Can we export monday.com data without using the API?

You can export some board content through the monday.com interface, but this route is limited to what the interface offers for each board and is hard to repeat consistently across many boards. Full extraction of items, column values, users and workspaces is documented through the GraphQL platform API, so most teams with more than a few boards will rely on it. Manual exports still have a role in spot checks. Confirm the current export options and their limits in your own account before you decide the approach for each board.

Will attachments and comments transfer from monday.com?

Attachments and comments need explicit handling and should not be assumed to come across with board data. Files are stored separately from item records, so they usually require their own retrieval and a plan for where the files will live in OpenProject or Plane. Comments are linked to items and users, so they must be mapped to the right records after user identities are matched. Confirm in the current monday.com API documentation which fields return attachments and comments and what access rights your API token needs. Then test one item with both before you plan the full run.

Should we test a monday.com export on one board first?

Yes, a single-board pilot is the safest way to find mapping problems before the full run. Choose a board that uses most of the column types you rely on, has a realistic number of items, includes attachments and comments, and has members with different roles. Export it, load it into a test instance of OpenProject or Plane, then compare item counts, dates, owners, statuses and sample attachments against the source. Record each difference and the fix. The results of the pilot give you a basis for a written scope covering the remaining boards.

When should we bring in an implementation partner like DeployOpen?

Bring in a partner when the scope, the timeline or the verification work exceeds what your team can staff. Common triggers include many boards, heavy use of automations and integrations, a deadline tied to a renewal or licensing change, or a requirement for evidence that the export is complete. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure. Engagements are fixed-scope, with a quote that follows from the written scope. DeployOpen does not issue audit reports or certifications, so ask your independent auditor what evidence they will need.

How DeployOpen scopes and delivers a monday.com data exit

DeployOpen approaches a monday.com data exit as a fixed-scope piece of work agreed in writing before any extraction starts. The scope covers which boards, workspaces and users move, how the data is staged for OpenProject or Plane, and what gets rebuilt by hand.

How we scope

Inventory every board, workspace, column type and user group that the export must cover.
List automations, integrations and dashboards that will not transfer, and agree how each is rebuilt or retired.
Confirm the target platform, edition and hosting location before any data leaves monday.com.

How we build

Write GraphQL extraction scripts against the monday.com platform API for boards, items, column values and users.
Map monday.com columns to OpenProject work package fields or Plane properties in a documented mapping file.
Run test loads into a non-production instance and check item counts, dates, assignees and attachments.

How we hand over

Deliver the extraction scripts, mapping documentation and staged data sets inside your own infrastructure.
Document the reconciliation results, open exceptions and the list of items that were rebuilt manually.
Walk your project and operations staff through the target instance and the rebuilt workflows before cutover.

How we support

Offer ongoing support, upgrades and continuous testing for the self-hosted platform as a retainer.
Keep the scripts and mapping current if you re-run the export or add boards after the initial load.
Confirm support terms, response expectations and included services in the written scope before work begins.

How to export your data from monday.com