Migrate from ClickUp to Plane

How to migrate from ClickUp to Plane without losing project history

If a renewal, a pricing change, a data residency requirement or lock-in has pushed you toward self-hosted Plane, know this first: tasks and lists move through Plane's ClickUp importer, while Docs and some other content need a separate export. An internal platform or IT team usually runs the import, often with an implementation partner who builds the server, reviews the field mapping and checks the results. Effort and risk depend mainly on how many spaces, lists and custom fields you have, and how much history sits in Docs, attachments and comments. Size the work from an inventory of those items, not from the task count alone.

Plane's importers, including ClickUp, are available on Plane Cloud and on the self-hosted Commercial Edition, so a Community install must move to the Commercial Edition before the import can run. Confirm the edition and license key your deployment uses before you schedule the work, and check the Plane importers documentation for the current ClickUp steps, including how the personal access token is generated and scoped. Then run the import into a test workspace first, using a copy of the data. Compare folders, lists, task statuses, assignees, due dates and custom fields against the source, and record every field that did not map.

Docs are not part of the task import, so export them separately and decide where each one will live before cutover. Plane pages can hold some of this content, but a document that needs a different structure may belong in a dedicated wiki. Re-link documents to their tasks by hand, because those references will not survive the move automatically. Keep a reconciliation log that lists what was imported, what was exported separately and what was archived or rebuilt, such as views, dashboards and automations. Get sign-off from each project owner before you turn off ClickUp access for their teams.

Which ClickUp structures map cleanly to Plane and which need rework

This table compares the ClickUp structures teams use most with their closest Plane equivalents and marks each as clean, needs rework or gap. Read clean as a likely direct carry-over, needs rework as a step that reshapes data by hand, and gap as something to recreate or export separately. Confirm the exact mapping against Plane's ClickUp importer documentation for the version you run before planning the cutover.

ClickUp structure	Plane equivalent	Mapping status	What to confirm
Folders	No direct level in the project hierarchy	Needs rework	Where folder groupings should land: projects, modules or labels
Lists	Plane projects or modules	Needs rework	Whether each list becomes a project or a module
Tasks and subtasks	Work items and sub-work items	Clean	Parent links, dates, assignees and status values
Custom task types	Work item types	Needs rework	Whether custom types import as types or flatten into one type
Custom fields	Work item properties for supported field types	Needs rework	The supported field list; unsupported types need a manual step
Comments	Work item comments	Clean	Whether original authors and timestamps are kept
Attachments	Work item attachments	Needs rework	Whether files transfer or only links; download files first if needed
Docs	Plane pages	Gap	Not part of task import; export Docs separately and load them as pages
Views and dashboards	Saved views, cycles and modules	Gap	Dashboards need rebuilding; views need recreating from their filters
Automations	No direct equivalent in the importer	Gap	Rebuild rules by hand or in a workflow tool; confirm Plane options

Migration sequence from inventory to decommissioning ClickUp

This sequence moves ClickUp work into Plane in controlled stages, so each step produces a record the team can check before the next one starts. It ends with a frozen ClickUp archive and a documented cutover, not a single import run.

Inventory spaces, lists, fields and integrations
Project owners and a ClickUp workspace admin list every space, folder, list, custom field, custom task type, automation, integration and view in use, and mark which ones are active. Record the owner, task count and open-task count for each list. The output is an inventory sheet that names what must map to Plane, what will be rebuilt by hand and what will be retired. The step is done when each active list has an owner who has confirmed the inventory.
Build the field mapping sheet
A migration lead takes the inventory and maps each ClickUp folder, list, status, custom field and custom task type to a Plane project, state, work item type or property. Mark every field the importer does not support, and decide whether it moves into the description, a comment or a separate archive. Check the importer documentation for the current list of supported custom fields before you sign off. The output is a field mapping sheet reviewed by the project owners, and the step is done when no active field is left unassigned.
Run a pilot import into a test workspace
An administrator creates a separate Plane test workspace on a non-production instance and runs the ClickUp importer using a personal access token from an account with access to the pilot lists. Choose one representative folder with tasks, subtasks, comments, attachments and custom fields. Confirm that the import is available on your edition, since the importer requires the Commercial Edition on self-hosted installs. The output is a working import log and test workspace.
Reconcile the pilot against ClickUp
The migration lead compares the pilot import with the source list, field by field. Count tasks, subtasks, assignees, due dates, statuses, tags, comments and attachments, and record every difference with its cause. Ask the project owners to review a sample of tasks in both tools. The output is a pilot reconciliation report with a list of accepted gaps and the fixes required in the mapping sheet. The step is done when the owners sign the report and the mapping sheet is updated.
Import production lists and run in parallel
After the pilot is accepted, the team imports the production lists into the production Plane workspace in the agreed order, and logs each import with its source list and date. For a defined period, both tools stay open, and teams record new work in Plane while they check for missing updates in ClickUp. The output is a parallel run log listing discrepancies and their resolution. Each discrepancy must be closed or accepted by an owner before cutover.
Export ClickUp content the importer does not carry
Before cutover, someone exports the items outside the importer scope, including Docs, whiteboards, dashboards and any view or report that the team relies on. Confirm the export options on your ClickUp plan, since Docs export one at a time and some views need a higher plan. Store the files in a controlled location with an index that links each file to its Plane project or owner. The output is an exported content inventory that is checked by the business owner.
Cut over and freeze ClickUp
The team announces the cutover date, makes ClickUp read-only for migrated lists, and reruns a final import or delta check for tasks changed during the parallel run. Update integrations, notifications and any automation that pointed to ClickUp. The output is a cutover record with the final reconciliation and the list of retired integrations. Confirm each change in writing with the business owner.
Archive the ClickUp export and decommission
After the business owners accept the cutover, the team stores a frozen archive of the ClickUp exports, the mapping sheet, the reconciliation reports and the parallel run log in a retention location your compliance team approves. The workspace is then closed or downgraded according to your contract, and access is removed for former users. The output is a decommissioning record that lists the archive location, the retention owner and the date access ended. Confirm retention requirements with your legal and compliance teams before deleting any data.

Why the ClickUp import needs the Commercial Edition of Plane

The ClickUp importer is not part of the Community Edition of Plane, so a team that plans to move ClickUp data into Plane must plan for the Commercial Edition from the start. Plane Community Edition is licensed under AGPL-3.0 and matches the feature set of Plane Cloud's Free tier. The Commercial and Airgapped editions are proprietary, and Plane's importers, including the ClickUp importer, are offered on Plane Cloud and on the self-hosted Commercial Edition. The Community Edition can therefore run the workspace after the move, but it is not the edition that performs the import.

Moving a self-hosted Community install to the Commercial Edition is a deliberate step, not a setting you flip inside the app. The Commercial Edition unlocks paid plans through a license key, and seats are counted by users with paid roles. Before you buy, ask Plane in writing which plan includes the ClickUp importer, how the license key is issued and renewed, whether the Commercial Edition has its own release cycle that your upgrade process must follow, and how seats are counted for guests, viewers and users who only receive imported data. Also confirm whether a Free plan on the Commercial Edition, which includes 12 seats according to Plane's Kubernetes documentation, is enough for a pilot import before any paid seats are purchased.

Treat the licensing check as part of the migration plan, with the same owner as the import itself. Record the edition, license terms and seat count your organization is approving, and confirm that your security and procurement teams accept the proprietary Commercial Edition alongside the AGPL Community Edition they may have already reviewed. If your policy requires open-source components only, decide before the import whether ClickUp data will be carried by Plane's importer or exported to CSV and loaded through a route your policy allows, because switching editions after the data is in place adds a second change window.

What to export separately from ClickUp: Docs, views, attachments and integrations

The task CSV does not carry everything a ClickUp workspace holds. Docs, view and dashboard configurations, attachments and automations each need their own export or rebuild step. Plan these pieces before the Plane importer runs so that nothing is lost by assumption.

Docs exported one at a time

ClickUp Docs are not part of the task import path. Each Doc has to be exported individually, and the export formats available to you depend on your ClickUp plan and current product options. Confirm the formats offered in your workspace, then decide where each document lands: a Plane page, a separate wiki, or Markdown files kept in your own storage. Record which Docs are linked from tasks, because those links will break unless you re-point them after the move.

Task CSV with comments and links

The task CSV is the primary input for the migration, but it is a flat view of tasks. Check whether your export includes comments and attachment links, and whether the importer you run in Plane maps the fields you rely on, such as assignees, dates, status and custom fields. Run a small test export first and compare row counts and sample tasks against ClickUp before the full run.

Attachments and their storage

Attachment links in a CSV point back to ClickUp-hosted files, which may stop resolving once you cancel the subscription. Download the files you need first, store them in your own S3-compatible bucket, and decide whether Plane should reference the new location. Confirm with your ClickUp administrator how attachments are retrievable on your plan and whether any size or retention limits apply.

Views and dashboards

Saved views, filters and dashboards are configuration, not work items, so they do not move with the task data. Document the views your teams use daily, such as board groupings, filtered lists and reporting dashboards, and check which of them your plan lets you export. In Plane, plan to recreate the equivalent cycles, modules and filters manually, and confirm the mapping with the team that uses each view.

Automations and integrations rebuilt by hand

ClickUp automations and connected apps do not transfer to Plane as part of a data import. Inventory every automation, its trigger and its action, then decide which ones Plane supports natively, which need an external workflow tool, and which should be retired. Also list the apps that write to or read from ClickUp, such as chat notifications or time tracking, and confirm each one has a replacement endpoint before cutover.

How the migration changes by team size and deployment method

A small team usually runs the Community Edition on a single host with Docker Compose, which Plane documents for small and mid-size teams. The import is the simplest part of this path, but the Community Edition is licensed AGPL-3.0 and matches the Free tier feature set, so the importer itself needs the Commercial Edition. Plan that switch before you export anything from ClickUp, because the Commercial Edition changes the install and the license key process.

Edition switch: Confirm with Plane whether moving from Community to Commercial on Compose is an in-place change or a fresh install, and back up the Postgres volume first.
Identity: Local accounts are usually enough at this size, but SAML and OIDC sit on Pro and above, so confirm the plan before you promise single sign-on.
Storage: Attachments land in the bundled object store, so size the host disk for the ClickUp attachment export.
Validation: Run the importer against a copy of one folder first, then compare task counts and assignees by hand.

Before you start, ask Plane which Compose version and Commercial Edition release your host needs, and confirm the exact seat count under the Free plan.

What usually goes wrong when moving ClickUp to Plane

Most failed ClickUp to Plane moves come from assumptions made before the first import runs. The cards below cover the gaps between what ClickUp holds and what Plane's importer carries across, and the checks that close each gap before cutover.

Assuming every field and automation carries over

Teams often expect custom fields, statuses, automations and views to move with their tasks. Only some custom field types and task structures map to Plane, and ClickUp automations do not come across as logic. Build an inventory of every custom field, automation and dashboard in use, then mark each one as mapped, rebuilt or retired. Ask the Plane importer documentation which field types it supports before you commit to a timeline.

Missing the Docs export

ClickUp Docs are not part of the task import, so pages written in Docs stay behind unless you export them separately. Export each Doc in a format you can reuse, such as Markdown, and decide in advance where it will live. Without this step, specifications and meeting notes quietly disappear from the project record after cutover.

Importing into production before a pilot

Running the importer directly against a live workspace makes duplicates and mis-mapped fields hard to undo. Create a test Plane workspace on the self-hosted instance, import one representative folder with its lists, and check task counts, assignees, dates and custom fields against ClickUp. Repeat until the pilot matches, then schedule the production import with a rollback plan.

Licensing surprises from seat counts

The importer requires the Commercial Edition on self-hosted Plane, and paid plans count seats by users with paid roles. Guest users, viewers and inactive ClickUp accounts can change the seat count you license. Confirm which ClickUp users need Plane access, assign roles deliberately, and ask Plane how seats are counted for your role mix before you purchase.

Losing comment and attachment links

ClickUp task exports carry comments and attachment links, and links break when the source workspace is closed or files are removed. Check whether comments and attachments arrive in Plane for a sample of tasks, then confirm that file links still open. Keep a copy of the original ClickUp export so that any missing history can be recovered or verified later.

Skipping access and permission mapping

ClickUp spaces, folder-level permissions and guest access do not map one to one onto Plane projects and roles. Document who should see which project before the import, then compare the result with the source workspace. Misplaced access can expose confidential work to the wrong group, so review it with the project owners.

What drives cost and duration of a ClickUp to Plane move

This table lists the factors that change the effort and cost of moving ClickUp work into self-hosted Plane, with the reason each one matters and what to request in a written quote. Read each row as a question to answer for your own workspace before asking for a fixed-scope proposal. The main takeaway is that the Commercial Edition licensing decision and the volume of Docs and attachments often matter more than task count.

Driver	Why it moves cost or effort	What to ask for in a quote
Spaces, folders and lists	Each space and list must be mapped to a Plane project, cycle or module, so many small structures add mapping and validation work.	A mapping table from ClickUp hierarchy to Plane projects, with counts of spaces, folders and lists.
Custom field complexity	Supported custom fields import cleanly, while unsupported types need a manual decision, a conversion or a stored reference.	A field-by-field inventory showing which fields map directly, which convert and which are archived.
Custom task types	Each task type you keep needs a matching work item type or label in Plane, and mismatches can lose structure.	Confirmation of how each custom task type will be represented in the target project.
Attachment volume	Files move with the work items and increase import time, storage needs and checksum or access checks.	Total attachment count and size per space, and the object storage plan (S3-compatible, such as MinIO).
Docs volume	ClickUp Docs are not covered by the task importer and must be exported and re-created separately, which is manual labor per document.	Document count, owners and target format, with a decision on whether pages move to Plane pages or another wiki.
Automation rebuild	ClickUp automations do not transfer, so each rule must be rewritten as a Plane workflow, integration or script, and tested.	A list of active automations with the intended replacement for each one.
Identity integration	SAML and OIDC sit on Pro and above, and LDAP is an Enterprise feature, so the chosen edition and identity setup change the license and configuration work.	The identity protocols required, the Plane plan that supports them and the identity provider integration steps.
Commercial Edition licensing	Importers and paid roles run on the Commercial Edition with a license key, so the edition decision sets the scope of what can be migrated.	Written confirmation of the edition, plan and seat count needed for the import and the ongoing run.
Hosting architecture	Docker Compose suits smaller deployments, while Kubernetes with Helm needs more infrastructure, external PostgreSQL, Redis or Valkey, RabbitMQ and object storage.	The target architecture, the managed or self-run services included, and the backup and upgrade responsibilities.
Validation scope	Reconciling task counts, dates, assignees, comments and attachments against ClickUp takes effort that scales with each project and team.	The validation method, sample size per project, sign-off owners and the acceptance criteria written before work starts.

Questions teams ask before moving from ClickUp to Plane

How much effort does a move from ClickUp to Plane take?

Effort depends mostly on the shape of the ClickUp workspace, not on the number of tasks alone. The main drivers are how many folders, lists and custom task types need to map onto Plane's structure, how many custom fields are in use and whether each one is a supported type, how many automations and dashboards must be rebuilt by hand, and how much history the team expects to carry across. Plane's importer covers the core task data, but automations, views and dashboards are not imported automatically, so plan for rebuilding them. No duration figure is supplied for this work. Ask for a written scope that lists each ClickUp space, list and custom field before agreeing on timing.

Can an internal team run the ClickUp to Plane move alone?

An internal team can run the move alone if it has someone comfortable with Docker or Kubernetes, PostgreSQL, object storage and the Plane administration console, plus a project lead who owns the mapping decisions. The harder parts are usually not the import itself but agreeing on the target structure, cleaning up inconsistent custom fields, and training users on the new work item model. Teams that lack capacity for those tasks often bring in an implementation partner for a fixed-scope piece, such as hosting setup or the import rehearsal. DeployOpen plans, implements and documents self-hosted platforms in the client's own environment and works under written scope, so the split of work can be agreed before anything starts.

What does the work need from our side?

The work needs decisions and access from several people at once. Expect to need:

A business owner who signs off how ClickUp spaces and lists map to Plane projects and modules.
An administrator who can create the ClickUp personal access token and run the import with an account that can see every relevant workspace.
Infrastructure owners who provide the hosting environment, PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, with backups and access controls.
Team leads who check a sample import and agree which history matters.

Confirm these roles with your own environment before scheduling.

Does the Plane ClickUp importer move Docs?

No, the Plane ClickUp importer covers folders, lists, tasks, custom task types and a defined set of custom fields, not ClickUp Docs. Plan Docs as a separate export. ClickUp Docs export one at a time as PDF, HTML or Markdown, so a large Docs library needs an inventory and a decision on where each document goes, such as Plane pages, a wiki or a file store. Confirm the current field and object support list in Plane's ClickUp importer documentation before you finalize the mapping, because supported types can change between releases.

Why does the ClickUp import require the Commercial Edition?

The ClickUp importer is available on Plane Cloud and on the self-hosted Commercial Edition, not on the Community Edition. Plane Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. To use a paid plan on a self-hosted install, the instance must switch to the Commercial Edition, which uses a license key and counts seats by users with paid roles. The Commercial Edition is proprietary, so legal and procurement teams should review its terms alongside the AGPL Community option. Ask Plane which edition and seat count your import will need.

Should we run ClickUp and Plane in parallel before cutover?

Yes, a short parallel period is the usual way to reduce risk, because it lets teams compare imported work items with ClickUp and fix mapping errors before anyone relies on Plane. Plan the parallel period around three steps: a test import into a non-production Plane instance, a review of counts, assignees, dates and custom fields by the teams involved, and a freeze date after which new work is created only in Plane. Decide in advance who can edit in each system during this window, how comments and attachments will be handled, and what rollback looks like if a defect is found. Agree the length of the period in writing with your implementation partner.

How do we check the import before cutover?

Check the import against a written list of what must arrive. Compare work item counts per project, confirm assignees and due dates on a sample of high-priority tasks, verify that each mapped custom field holds the expected value, and confirm that subtasks and relationships appear as intended. Keep the ClickUp CSV export and the importer log as evidence for the change record. Document each exception and who accepted it. Auditors and compliance teams generally expect this kind of reconciliation evidence, but DeployOpen prepares that evidence and does not issue audit reports or certifications.

Official Plane documentation to read before planning

Read the Plane editions and versions documentation before anything else, because the ClickUp importer sits in a different place depending on which edition you run. Plane ships three self-hosted editions, Community, Commercial and Airgapped, each built on a distinct codebase with its own release cycle. The importers are listed among the features of the self-hosted Commercial Edition, so a Community install may not expose the ClickUp importer at all. Confirm which edition your planned deployment uses, and whether a license key is needed, before you schedule any migration work. The Plane editions and versions documentation is the place to check the edition boundary against the feature list.

Next, read the Plane importers overview and the Jira and Linear importer pages. The ClickUp importer steps themselves should be confirmed against the current documentation for your Plane version, because importer screens, field support and token handling change between releases. The Jira and Linear pages are useful as reference for general importer behavior, such as how workspaces, projects and users are mapped and how errors are reported, but they do not describe ClickUp hierarchy. Use the Plane Jira importer documentation and the Plane Linear importer documentation to frame questions for your test run, then confirm the ClickUp specifics with Plane directly.

Finally, read the self-hosting overview and, if you expect high availability, the Kubernetes deployment guide. The overview explains the supported install methods and the services a deployment needs, while the Kubernetes guide covers external PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage. Your importer test should run on a deployment that matches the target architecture, so confirm which services you will host and which you will consume as managed services. Ask your Plane contact or check the Plane self-hosting overview for the current requirements of your chosen method.

How DeployOpen scopes and runs a ClickUp to Plane migration

DeployOpen plans and implements self-hosted Plane inside your own cloud account, data center or air-gapped network, and treats the ClickUp import as one part of a wider move. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the ClickUp workspaces, spaces, folders, lists, custom task types and custom fields in use.
Decide which Docs, views, dashboards and automations are exported separately or rebuilt by hand.
Confirm which Plane edition, seat count and single sign-on approach the written scope covers.
Agree the import sequence, cutover window and acceptance checks before any data moves.

How we build

Deploy Plane with Docker Compose or Kubernetes and Helm in the client's environment.
Connect PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage, or external managed services.
Run test imports with a personal access token and compare task counts, dates and assignees against ClickUp.
Test access controls, backups and restore procedures before any production users are onboarded.

How we hand over

Document the field mapping, unmapped items and manual steps, so the client can repeat or audit the import.
Deliver runbooks for installation, upgrades, backups and restores in the client's own repositories.
Provide a written record of what was exported separately, such as Docs, attachments and dashboards.
Walk administrators through user, workspace and project management in the self-hosted instance.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan Plane version upgrades in your change process, with testing against your configuration first.
Review edition and seat changes with you before moving to a paid Plane plan.
Confirm support boundaries, response expectations and the retainer terms in the written scope.