Migrate from Linear to Plane

How to migrate from Linear to Plane without losing issue history

If a renewal, a data residency requirement or lock-in has pushed you toward self-hosting Plane, the good news is that Plane's Linear importer covers most team data. The migration is mainly a decision about how records should land in Plane. The real effort lies in mapping workflow states, cycles and parent-child links, and in running Linear and Plane side by side long enough to prove that the imported data matches what teams see. In most organizations, an internal platform or IT team owns this work, sometimes supported by an implementation partner for the self-hosted infrastructure and the cutover plan. Start by taking one pilot team through the Linear importer documentation before you commit to a full migration.

Run the importer on Plane Cloud or on the self-hosted Commercial Edition. Plane's importers are offered on those two, and the Community Edition, licensed under AGPL-3.0, matches the feature set of the Cloud Free tier. Decide this before you install anything, because a team that starts on Community will need to switch to the Commercial Edition later, which uses a license key and counts seats by users with paid roles. The Commercial Edition's Free plan includes 12 seats and needs no license key, but confirm with Plane whether the Linear importer is available on that plan before you rely on it for a team of that size. Also decide early whether the imported data will sit in Plane Cloud or in your own cluster, since that choice shapes the data residency answer you give your auditors.

Budget effort by component: a mapping sheet for states, labels and cycles, a test import into a sandbox workspace, a parallel run where both tools stay open, and a cutover where Linear is set to read-only. Infrastructure is the recurring cost. A self-hosted Plane deployment needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO, and those services keep running after the importer work is finished. Ask any implementation partner for a fixed-scope quote that names who maps states, who checks issue counts per team, and who owns the cutover date. The main risks are attachments and links that break when a parent issue moves, so verify both in a test import before the parallel run begins.

Which Linear features map cleanly to Plane and which need rework

This table shows how each Linear object is expected to land in Plane through the Linear importer, team by team. Clean means the object should carry over with little review, needs rework means it maps but requires decisions or cleanup, and gap means it may not transfer. Confirm each row against the Plane Linear importer docs before you run a live import.

Linear feature	Plane equivalent	Status	What to confirm
Teams	Plane projects, one per team	Needs rework	Confirm how team keys and identifiers map, and where importer access applies to your edition.
Issues	Work items	Clean	Confirm field-level coverage for titles, descriptions, priority and dates in the importer docs.
States	Work item states	Needs rework	Map each Linear workflow state to a Plane state group and review the mapping before import.
Labels	Labels	Clean	Confirm that names, colors and label assignments carry over on issues.
Cycles	Cycles	Needs rework	Confirm how team-level cycles, dates and completed items map to project-scoped cycles in Plane.
Projects	Modules	Needs rework	Confirm which project fields such as status, lead and target dates carry over to modules.
Comments and attachments	Comments and file attachments	Gap	Confirm whether attachment files transfer or only links, and check for missing files at the Linear source.
Parent-child links	Sub-work items	Needs rework	Confirm parent links import when parent and child sit in different teams or import batches.
Members	Workspace members with roles	Needs rework	Seats count users with paid roles on the Commercial Edition, so confirm role mapping and seat count first.

Why the Linear importer runs on Plane Cloud or the Commercial Edition

Plane's Linear importer is not part of the Community Edition. It runs on Plane Cloud and on the self-hosted Commercial Edition, so a team that plans to self-host Plane for its Linear migration must plan for the Commercial Edition at some point in the process. Plane documents three self-hosted editions, Community, Commercial and Airgapped, and each is built on a distinct codebase with its own release cycle. The Community Edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier, while the Commercial and Airgapped editions are proprietary. This split affects licensing review, because the proprietary edition carries its own terms that your legal and procurement teams should read before any install.

Moving from Community to Commercial is a switch of edition, not a reinstall from scratch. A self-hosted Community install must first switch to the Commercial Edition, which then unlocks paid plans through a license key and counts seats by users with paid roles. Plane's Kubernetes guide installs the Commercial Edition, and its Free plan includes 12 seats and the Free feature set without a license key. Ask Plane which edition and key your importer run requires, and confirm in writing whether the Linear importer is included in the plan you intend to buy, because importer entitlement can differ by plan. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request, so the seat count and role mix you need will drive the recurring cost.

Build the schedule around this dependency. Confirm the importer entitlement for your plan, obtain the license key, and install or upgrade the Commercial Edition in a staging environment before you book any migration window. Then test one team's import end to end, including seat assignment for every user who will hold a paid role after cutover. If your organization needs SAML or OIDC on self-hosted Plane, note that these sit on Pro and above, while LDAP support and API-enabled audit logs are listed as Enterprise features. Those identity requirements may push you to a higher tier than the importer alone would require, so resolve them before the import starts.

What to export, import and rebuild from Linear

Most of the move runs through Plane's Linear importer, which carries issues and structure across team by team. The Linear exports and API are the fallback for anything the importer leaves behind, and integrations are the part no importer moves for you. Plan all three before you start the first team.

Plane's Linear importer

Run the importer team by team, starting with a single pilot team, and confirm which Linear objects it maps before you commit. Check states, labels, cycles, projects, comments, attachments and parent-child links against a sample workspace. Confirm that the importer is available on your deployment, since it runs on Plane Cloud or the Commercial Edition. Record the mapping results so reviewers can see what landed where.

Commercial Edition access for import

The importer is not part of the Community Edition, so a self-hosted Community install cannot run it directly. Decide early whether the import runs on Plane Cloud or on a Commercial Edition install, and confirm the license terms that apply to that choice. Keep the imported data on your own infrastructure afterward if that is your requirement, and confirm how the license and seat count are handled after import.

Linear CSV exports as fallback

Use Linear's CSV exports for issues, projects and members as a second copy of the data you can check the import against. Note the per-role row limits before you rely on them for large teams, and plan a separate pass for any rows that exceed them. CSV does not carry attachment files, so keep a file-level export for those.

GraphQL API for a complete extract

Use Linear's GraphQL API when you need a complete, scripted extract of issues, comments, relations and project data. Build the script with a service credential, paginate through every object type, and store the raw output before any transformation. This extract is the record you reconcile against if an importer run is incomplete.

GitHub links and branch references

Linear issues often carry GitHub pull request links and branch names that engineers rely on. Plane does not inherit these links from the import, so list every repository connection and decide how each issue reference will be recreated. Confirm the GitHub integration and webhook setup in your own environment before cutover.

Slack notifications and Linear automations

Slack alerts, Linear-side automations and triage rules do not transfer with issues. Inventory each one, then rebuild it in Plane, in your chat tool or in your own automation layer. Assign an owner to every rebuilt rule and test it with a sample issue before the team switches over.

The migration sequence from inventory to decommission

This sequence moves one Linear team at a time into Plane, proving the mapping on a pilot before any production cutover. Each step ends with a written artifact, so the decommission of Linear rests on evidence rather than assumption.

Inventory teams, workflows and integrations
List every Linear team, workflow state, label set, cycle pattern, project and template, plus every integration that reads or writes issues, such as Slack, GitHub, GitLab or custom API scripts. Name an owner for each team and note which teams are active, which are archived and which hold open cycles. The output is a mapping sheet that lists each Linear state and label beside the Plane state or label it will become, with unmapped items flagged for a decision. The step is done when each team owner has signed off on their rows.
Run a pilot team import
Choose one low-risk team and run Plane's Linear importer against it in a non-production Plane workspace, using a Plane Cloud account or a Commercial Edition install, since the importer is not part of Community. Import its issues, cycles, projects as modules, comments, attachments and parent-child links, then record what arrived. The output is a validated pilot report with counts of issues, comments and attachments compared against Linear, and a list of every field that did not carry over. The pilot is complete when the team owner confirms the items they rely on are present and readable.
Confirm gaps and adjust the mapping
Review the pilot report with the team and decide how each gap will be handled, for example by recreating a custom view manually, moving an automation to a new integration, or accepting that a historical field stays only in the archive. Update the mapping sheet and re-run the pilot import if the changes affect structure. The output is an approved mapping sheet and a short list of accepted gaps, which later becomes part of the cutover checklist. Confirm with the team owner, and with your security or compliance lead if any gap affects audit evidence.
Operate a parallel run with both tools open
Keep Linear open for read and write access while the pilot team works in Plane, and set a rule for which tool is the record of truth during this period. Check that integrations, notifications and branch naming still work against the Plane workspace where they were rebuilt. The output is a parallel run log that records duplicate work, missed notifications and open issues that need attention. The run ends when the log shows no unresolved integration failures for the pilot team and the owner agrees that Plane is the working system.
Cut over each remaining team
Move the remaining teams in batches, using the approved mapping sheet for each one. For each team, freeze new work in Linear, run a final incremental import or manual copy of anything created after the pilot, switch integrations to Plane, and announce the change to members. The output is a cutover checklist signed per team, with the date the team went live in Plane and the date its Linear write access was removed. Do not start the next team until the previous checklist is closed.
Export and archive Linear data before decommission
Before closing the Linear workspace, export issues, projects, members and attachments using Linear's CSV exports and its GraphQL API, since the CSV exports have row limits and do not include every attachment file. Store the export in your own retention location, with the same access controls as your other records, and confirm your records policy for how long it must be kept. The output is an archived export with a manifest listing what it contains and where it is stored, and a test that a sample of archived issues can be opened. Ask Linear to confirm its current export options before you rely on them.
Decommission Linear and retain the archive
Remove Linear integrations and member access, revoke API keys and webhooks, and record the date Linear was closed for each workspace. Keep the archived export readable and accessible to the people who may need it for audit, legal or historical questions, and review it on your records schedule. The output is a decommission record that names the archive location, the retention period set by your policy, the people with access and the date the Linear workspace was closed. Confirm the subscription end date and any data deletion terms with Linear in writing before you cancel.

How the migration changes by team count and starting point

A single team with one Linear workspace and few projects is the simplest starting point. The importer maps one team's states, labels, cycles and issues in one pass, so the main work is confirming that the mapped structure reads correctly before the team relies on it. Most of the effort sits in a short trial run on a copy of the data and a final import on the day you stop using Linear.

One pilot round: Import into a scratch Plane project first, check states, labels and cycle dates, then repeat once for the final cut-over.
Community is often enough: If the team stays within the Free feature set and seat limit, a self-hosted Community install needs no license key.
Importer access: Confirm whether the Linear importer is available on your install path, since it runs on Plane Cloud and the Commercial Edition rather than Community.
Attachments and links: Check a sample of issues with attachments and parent-child links, because these are the items most often missed by a quick review.
Freeze window: Agree a short period when no one edits Linear issues during the final import.

Before starting, ask Plane which importer path applies to your edition and confirm the current seat rules on the Free plan.

What drives the cost and duration of a Linear to Plane move

This table lists the main factors that change the cost and time of moving from Linear to self-hosted Plane, and how to keep each one manageable. Read it as a checklist to scope a quote, since most of the effort sits in volume, workflow complexity and hosting choices rather than in the importer itself. Items marked with a cross or check depend on the edition you select.

Driver	Why it changes cost or effort	How to keep it down
Number of teams and issues	Each Linear team maps to a Plane project, and issue volume drives import run time, validation work and the number of records people must check after the move.	Migrate team by team, start with a low-volume team as a trial, and archive closed issues you do not need to carry over.
Depth of custom workflows	Linear workflow states must be matched to Plane states, and irregular state naming across teams adds mapping decisions and rework.	Standardize state names before importing and agree the mapping with team leads in writing.
Attachment volume	Attachments are often the largest data set, and they need object storage capacity, transfer time and checks that every file arrived.	Confirm which attachments are in scope, size the S3-compatible store before import, and spot-check files after each batch.
Integrations and automations	Linear integrations with Git, Slack or other tools are not carried over by the importer, so each one needs a replacement or a rebuild.	Inventory every integration and webhook first, then decide which ones Plane will support and which to retire.
Plane edition and plan	The Linear importer runs on Plane Cloud or the Commercial Edition, so a Community install needs a switch to a plan with a license key, and seat counts follow paid roles.	Confirm with Plane which plan and edition the importer requires, and ask for the seat count by role in your quote.
Hosting model	Docker Compose suits small and mid-size teams, while Kubernetes with Helm adds cluster, high availability and operations work. External PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage each add setup and monitoring.	Decide the hosting model before scoping, reuse existing managed database and storage services where your policy allows, and document the sizing assumptions.
Parallel run length	Running Linear and Plane side by side keeps two tools licensed and staffed, and it extends the period of dual data entry and reconciliation.	Set a fixed cutover date per team, define the freeze point for Linear edits, and close the parallel run as each team is verified.
Staff time and implementation fees	Internal staff time for mapping, testing, training and sign-off is usually the largest cost. A DeployOpen fixed-scope engagement adds a written fee for the work you agree to.	Name owners for each team, reserve review time in advance, and ask any implementation partner for deliverables and timelines in writing before work starts.

What usually goes wrong in a Linear to Plane migration

Most failed Linear to Plane moves come from a few predictable gaps: mapping decisions made too late, attachments that never arrived, and edition choices made before the importer was checked. Each card below names one risk, why it matters for the team cutover, and the check to run before anyone relies on the new workspace.

State mapping mismatches

Linear workflow states such as Triage, Backlog, Todo, In Progress and Done do not always line up with Plane's state groups, so issues can land in a wrong group and distort cycle and dashboard counts. Decide the mapping per team before the first test import, and write it down. Then compare a sample of issues from each Linear state against their Plane state, including cancelled and duplicate issues, which are easy to miss.

Lost attachments and missing files

Attachments are the item most likely to be incomplete after an import, and a re-run may not restore files that failed the first time. Linear's own export does not include every file, so confirm with the importer's documentation which attachment types arrive. Keep the original Linear workspace readable until every linked file has been opened in Plane, and record the count of issues with attachments on both sides.

Broken parent-child and cycle links

Sub-issues, relations and cycle assignments are where a migration quietly loses structure. An issue can arrive without its parent, or a cycle can be created without the issues that belonged to it, which breaks velocity history. Pick a sample of epics with several children and one completed cycle, then check each link and cycle total in Plane against Linear before accepting the import.

Users not mapped to Plane accounts

Assignees, creators and commenters must match a Plane member, or their work shows up unassigned or under an import placeholder. People who have left the company, contractors using personal emails and guest accounts are the usual gaps. Export the member list from Linear, match each person to a Plane account with the same email address, and invite everyone before the import so ownership survives the move.

Community Edition chosen without importer access

The Linear importer runs on Plane Cloud and on the paid Commercial Edition, not on Community. A team that installs Community first and plans to import later may find the importer unavailable, which forces a late switch of editions. Confirm the edition in writing with the vendor and your own environment before procurement, and test the import on a non-production instance first.

Cutover before validation

Teams often switch on a Monday and discover missing history on Wednesday, when Linear is already closed to new work. Run at least one full dry run per team, sign off counts, mappings and sampled issues with the team lead, and keep Linear read-only for an agreed overlap period. Cut over one team at a time so each validation step stays small and reversible.

Questions teams ask before moving from Linear to Plane

How much effort and cost should we expect to move from Linear to Plane?

The cost has three parts: the software license, the infrastructure you run Plane on, and the internal and partner time for the move. Plane Community Edition is licensed under AGPL-3.0 and has no license fee, so the main recurring costs are hosting and the staff who operate it. If you want a paid Plane plan, Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid priced on request. The one-time cost depends on how many teams you migrate, how much history you keep, and how much cleanup your data needs. Ask for a quote built from a written scope that lists the teams, the data types and the environment, so the figures can be compared line by line.

How long does a Linear to Plane migration take?

The pace is set by the number of teams, the volume of issues and attachments, the state of your workspace, and how many approval steps your process needs. Teams are usually easier to move one at a time, because each team's states, labels and cycles can be checked before the next team starts. Before you commit to a timeline, run a trial import of one team into a test instance and measure how long validation takes. Ask any partner to put the timeline, the deliverables and the acceptance checks into the written scope before work starts.

What does the migration need from our internal team?

Plan for time from three groups. A workspace owner needs to decide which teams, projects and history move, and who signs off on the result. Engineers or platform staff need to deploy and operate Plane, including its PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage dependencies. Team leads need to review their imported states, labels, cycles and modules and confirm that they match how the team actually works. Agree on a cutover date for each team, and decide in advance whether Linear stays read-only for a period so that no new issues land in the old system during the move.

Can our own team run the Linear to Plane migration without a partner?

Yes, a capable team can run the move alone, provided it has the platform skills and time to do it. Plane documents Docker Compose for small and mid-size teams and Kubernetes with Helm for high availability, so you can choose the deployment that fits your operations model. The risks are mostly in the details: confirming what the importer maps, checking attachments and parent-child links after import, and keeping backups and upgrades on schedule. If your team has not run a multi-service application before, consider a fixed-scope engagement for the deployment and cutover, and keep ownership of the data and the final sign-off in-house.

What happens to attachments and links when we import from Linear?

Attachments and links need checking after every import, because not every type of content survives the trip intact. Confirm what the Plane Linear importer carries over for attachments, comments and parent-child relationships by running a test import of one team and comparing a sample of issues against the source. Pay particular attention to links that point back to Linear issue URLs, since those will break once Linear is retired unless you rewrite them. Keep a copy of the Linear export for the same period you keep other project records, and confirm your retention rules with your compliance lead.

Does the Linear importer require a paid Plane plan?

The importer runs on Plane Cloud and on the self-hosted Commercial Edition, so a Community Edition install cannot use it directly. Plane's documentation says a self-hosted Community install must first switch to the Commercial Edition before moving to a paid plan, and that the Commercial Edition uses a license key with seats counted by users with paid roles. The Free plan on the Commercial Edition includes 12 seats with no license key, according to Plane's Kubernetes documentation. Confirm with Plane which edition, plan and seat count your team needs for the import window, and whether the importer is available on the plan you choose before you sign anything.

Which Plane features need a paid plan, and how does that affect the move?

Single sign-on and provisioning features are the main items to check. On self-hosted Plane, SAML and OIDC are available on Pro and above, while LDAP support and API-enabled audit logs are listed as Enterprise features. If your Linear setup depends on SAML or SCIM provisioning, confirm that the Plane edition you deploy supports the same identity flow before you move users. Ask Plane to confirm the current plan matrix in writing, because feature availability changes between releases.

What should we verify after the import is complete?

Run a structured check on each team before users start working in Plane. Compare issue counts, workflow states, labels, cycles and projects against the Linear source, and sample issues for comments, attachments and parent-child links. Confirm that user accounts map to the correct people and roles, and that notifications and integrations you still need are reconfigured. Record the results so that the team lead, the workspace owner and any auditors can see what was checked and who approved the cutover.

What DeployOpen contributes to a Plane migration

DeployOpen's contribution starts with a written scope that names the Linear teams in play, the Plane deployment method, the edition (Community, Commercial or Airgapped), the number of seats and the systems the install must reach, such as identity, email and object storage. Agree in writing which Linear data is in scope, including attachments, archived teams and the workspace export route described in the Linear export guide. Deliverables and timelines are fixed in that document before work starts, and a quote follows from the written scope. Ask for the scope to state who owns each open decision, such as whether the Commercial Edition is licensed for the importer and how Linear user accounts will map to Plane members.

The typical first phase is a pilot on one team. DeployOpen runs the Linear importer against a non-production Plane instance, then checks the results against the source: state names and categories, label assignments, cycle dates, the projects that became modules, comments, attachments and parent-child links. Each check should produce a short record of what mapped, what was recreated by hand and what was left behind. The pilot also tests the install itself, including PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, so that attachment uploads and notifications work before any production data arrives. Ask for the pilot exit criteria in writing so that the full team-by-team cutover has a clear go or no-go decision.

Hardening and documentation cover the self-hosted Plane install after cutover. This includes access controls for administrators, TLS, backup and restore tests for the database and object storage, upgrade procedures tied to the Plane release channel you choose, and runbooks for the people who will operate it. If your organization needs SAML or OIDC sign-in, confirm with Plane which plan includes it, because the pricing page lists those features on Pro and above, and that affects the edition decision. DeployOpen can also deliver the retainer options for ongoing upgrades, patching and support, which are priced from the agreed scope and cover work that recurs after go-live.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Plane inside your own infrastructure, including the Linear migration work. Engagements are fixed-scope, so the team, the Linear workspaces and the Plane edition are agreed in writing before any data moves.

How we scope

Inventory every Linear team, its states, labels, cycles, projects and attachment volumes before choosing an import order.
Confirm which Plane edition and plan the importer needs, and whether Plane Cloud or the Commercial Edition will host it.
Record in the written scope which items will not map, such as custom views and unsupported fields, and how each gap is handled.

How we build

Deploy Plane in your cloud account, data center or air-gapped network with PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage.
Run a trial import for one team into a non-production workspace, then compare counts, states, cycle dates and parent-child links.
Harden the install, configure SSO and access rules, and test attachment access and permissions before the cutover date is set.

How we hand over

Deliver a runbook covering the import steps, the field mapping decisions and the reconciliation checks performed for each team.
Document the Linear exports kept as the archive copy, including the items the importer did not carry across.
Train the named administrators on Plane roles, seat counting and how to add users after the migration is complete.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Plan Plane upgrades against each release, testing the importer and integrations in staging before production changes.
Ask for a quote built from the written scope, covering the Plane edition, infrastructure, migration hours and any retainer.