Migrate from Linear to Plane

A self-hosted Plane target for a Linear migration has to run the Commercial Edition from the start. Plane documents its Linear importer as available on Plane Cloud and on the self-hosted Commercial Edition, and the Community Edition is not on that list. If your plan is to move Linear work items, cycles, and states into your own infrastructure, the target edition is a prerequisite that belongs in the scope, the architecture review, and the procurement request before anyone runs an import.

Plane ships three self-hosted editions: Community, Commercial, and Airgapped. The 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 each edition is built on its own codebase with its own release cycle. Your team should confirm which edition and version the deployment method installs, because the importer's behavior, upgrade path, and release timing follow the edition you run, not the version number alone.

Some teams start on Community to evaluate Plane and plan to move to a paid plan later. Under Plane's documented path, a self-hosted Community install must first switch to the Commercial Edition before it can move to a paid plan, and that switch uses a license key. Ask Plane to confirm in writing whether the switch preserves existing data, configuration, and integrations, and whether any import run on Community would need to be repeated. Planning the edition choice up front avoids a mid-project switch during cutover.

Seats are counted by users with paid roles, so the Linear member list does not translate directly into a seat count. Before import, decide which Linear members become Plane users, which roles they receive, and which accounts are service or former-employee accounts that should not be created. Plane's pricing page lists per-user monthly prices for its paid plans and Enterprise Grid on request. Subscription seats recur monthly, while the migration effort is largely one-time. A quote follows from the written scope, so the scope should state the user list, roles, and editions involved.

Before kickoff, confirm four items: the edition and version your deployment method installs, whether a license key is required on day one, the number of Linear members who will hold paid roles in Plane, and who approves the role mapping. Record each answer in the scope document. These checks are inexpensive to run early and expensive to correct after users have been imported and notified, so they should be closed before any Linear export or API token is used against the production workspace.

The Linear importer sets the boundary of what moves automatically, so the first step is to find out where that boundary sits for your workspace. Three areas need attention before the pilot: relations between issues, the activity history attached to each issue, and attachments or links that point to systems outside Linear. Each area may arrive in full, in part or not at all, and the import summary alone will not show which items fell into which group. The exact limits must be confirmed in the Linear importer documentation for the Plane version you deploy. Do not infer them from the Jira or Asana importers, whose documented behavior differs.

Start the inventory with a complete count, not a sample. Export or query the Linear issues that carry relations, then group them by relation type, such as blocking, blocked-by, related and duplicate links, so the team can see which types matter for planning. For history, identify the issues where comments, status changes or edits are relied on by auditors, customer teams or engineers. For attachments and links, separate uploaded files from URLs and record the destination of each external link, including design files, code repositories and shared documents. Assign one owner per area and keep the working list in a spreadsheet with the Linear identifier, project, item type, current state and a decision column. Run the pilot import into a non-production Plane workspace and compare the results against this list line by line.

Once the inventory exists, decide what to rebuild by hand. Use two filters: whether the work is still active, and whether the missing item affects how work is scheduled or approved. An open issue that depends on another open issue needs its dependency visible in Plane, either as a relation the importer carried over in full or as a manual link plus a comment that names the blocker. Closed work rarely justifies rebuilding relations by hand. For history, decide whether a read-only export from Linear, stored in a records system your organization controls, meets the audit or support need. Keep that export as the reference and do not try to reproduce full timelines inside Plane. For external links, confirm that each one stays reachable after cutover and that the new users have access. Record each decision with a named owner before the production run.

Record every exception in one register that stakeholders can read. Each row should state the item, its category, what the importer did, the decision taken, the person who accepted the gap and the date of acceptance. Share the register with project leads, the records or security owner and the people who will run Plane after cutover, because a gap nobody accepted tends to surface later as a complaint. Link each exception to a post-migration check, such as confirming that a dependent issue shows its blocker in Plane or that a stored export opens for the audit team. Revisit the register when the Linear importer documentation changes or when you move to a newer Plane release, since the limits you recorded may no longer apply.

Do not retire Linear until the migrated Plane workspace has passed a documented set of checks and each affected team has signed off on the result. The first check is a count reconciliation. For each project, compare the number of work items in Plane with the number in the Linear export you used for the import, then repeat the comparison for states, comments, attachments and members. Run the comparison against that frozen export. Live Linear keeps changing after cutover, so it cannot serve as a stable reference. Any difference should be explained in writing before the team moves on. Keep the reconciliation output in the migration record so a reviewer can see what was compared and when.

Counts show volume, and spot checks show fidelity. Pick a sample of issues from every team, including old closed work, issues with long comment threads, issues with attachments of different types, and issues that sit in more than one cycle or module. For each one, check that the title, description, state, priority, assignee and dates match the source. Confirm that comments keep their authors and timestamps and that every attachment opens and is linked to the correct issue. Then verify cycles and modules against the mapping document the teams agreed before the import. Each Linear cycle should land in the agreed Plane cycle, and each agreed module should contain the issues it is meant to hold. Record every mismatch with its issue identifier.

Confirm user access before anyone depends on the new workspace. Compare the Linear member list with the Plane members, and check that each person was imported or invited with the role the team agreed. Confirm that departed users and external collaborators are handled as your access policy requires. Check that people who need administrator rights hold them and that no one holds more access than their role requires. Next, review the relation exceptions log. Every blocked link, dependency or parent-child relation that could not be carried over needs an owner and a documented decision: recreate it manually, accept the loss, or record it as known history in the archive. Finally, collect a written sign-off from each team lead covering counts, spot checks, cycles and modules, access and exceptions. A missing sign-off should block decommissioning.

Keep a copy of the Linear export as a reference record before you decommission the source. Store it in a location covered by your retention policy, and record the export date, its scope, the Linear workspace it came from and the importer run it fed. Calculate a checksum so later copies can be verified against the original. Restrict access to the archive, because issue data often contains customer details and internal discussion. Confirm the retention period with your legal and compliance owners, since the archive may need to be produced for audit or reference. Then verify the Plane side. Confirm that PostgreSQL backups run on schedule and that a restore has been tested in a separate environment. Confirm that the S3-compatible object storage holding attachments is backed up or replicated and reachable from the application. Confirm that the Commercial Edition license covers the seats in use before go-live.