Migrate from Jira to Plane

Migrate from Jira to Plane without losing sprint history

If a renewal, the Data Center end of life or a Cloud pricing change is forcing the decision, know that Plane's Jira importer covers Jira Cloud as well as Jira Server and Data Center, and it maps sprints to cycles, so sprint history can move with the work items and does not have to be rebuilt by hand. Confirm the exact field and history mapping in the Plane Jira importer documentation against a test project before you set a cutover date, because an importer carries over what its mapping defines and little else. The importer runs on Plane Cloud and on all plans of the self-hosted Commercial Edition, which matters if data residency is the driver.

An internal platform or IT team usually owns the move, often with an implementation partner for the deployment, the import runs and the testing. Costs fall into a few groups: the Plane license or subscription for the Commercial Edition (seats are counted by users with paid roles), infrastructure for PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, the staff who validate the imported data, and any partner fee. The license and infrastructure recur, while setup and testing are largely one-time. Effort rises with the number of projects, custom fields, workflows, Jira apps and years of history you keep. Ask any partner for a written, fixed scope that names the test imports, the rebuild work and the cutover steps.

The importer is one step among inventory, rebuild and cutover. Before you run it, list what Jira does for your team, since Jira Cloud's backup excludes automation rules, third-party apps and Assets, and those need separate handling. Choose the edition early: Community Edition is AGPL-3.0 and matches the Plane Cloud Free feature set, while the importer sits in the Commercial Edition, so a self-hosted Community install must switch before importing. Then rebuild workflows, permissions and dashboards in Plane, run at least one full test import, and agree how work created in Jira after the test run will be brought across before Jira is set read-only.

Which Jira capabilities map cleanly to Plane

This table compares the main Jira capabilities with their Plane equivalents and marks each as clean, needs rework or gap. Use it to decide which items the Plane Jira importer should carry across and which you must rebuild by hand. Confirm each row in the Plane importer documentation and in a test project before the full migration, because importer behavior sets the scope of rework.

Jira capability	Plane equivalent	Status	What to confirm
Issues and attachments	Work items with attachments	Needs rework	Confirm titles, descriptions, assignees, priorities and that files copy across in a test import
Sprints and boards	Cycles, with board-style views	Needs rework	Check that sprint dates and issue membership become cycles, and rebuild board filters and swimlanes by hand
Epics	Modules or parent work items	Needs rework	Confirm how the importer maps epic links and whether child issues keep their parent relationship
Workflows and statuses	States within state groups	Needs rework	Map each Jira status to a Plane state and confirm which transition rules, if any, the importer carries
Custom fields	Work item properties	Needs rework	Check which Jira field types convert to Plane property types and which values need manual cleanup
Permissions	Workspace and project roles	Needs rework	Confirm how Jira permission schemes map to roles and how paid roles affect seat counts on the Commercial Edition
Automation rules	No direct equivalent in the importer	Gap	Atlassian's cloud backup excludes automation rules, so inventory each rule and rebuild or replace it
Third-party apps	No marketplace equivalent	Gap	Identify the data each Marketplace app holds and plan a replacement or an integration for each one
Single sign-on	SAML and OIDC on Pro and above, LDAP on Enterprise	Needs rework	Confirm the plan tier you need for your identity provider and plan the sign-in configuration before cutover

What to export and what to rebuild from Jira

Jira Cloud and Jira Server or Data Center sources reach Plane through different routes, and neither route carries everything a team relies on. The cards below separate what the export covers, what it leaves behind, and what must be rebuilt in Plane before the first sprint runs.

Jira Cloud backup scope

Atlassian's backup for Jira Cloud covers work items, board and sprint data, comments, users, and project configuration such as workflows and schemes. For a Cloud source, this export is the starting point for deciding what to bring across. Confirm with the Atlassian export documentation which fields and attachments your backup includes, and compare the result against a sample project before you commit to a full migration.

Excluded from Jira Cloud backup

Automation rules, third-party app data, and Assets are not part of Jira Cloud's backup. Any automation that moves issues between statuses, assigns work, or posts notifications will stop when the project moves, and any data stored by a marketplace app stays in Jira. List every rule and app per project before cutover, and decide whether each one is rebuilt in Plane, replaced by a Plane feature, or retired.

Server and Data Center sources

Jira Server and Data Center sources use Plane's Jira importer directly, so there is no separate Cloud export step for those instances. Plan the import against the source version and the Plane edition your organization runs, and check which Jira projects, users, and custom fields the importer maps before you start. Run a trial import into a non-production Plane workspace first.

Confluence links and page references

Issues in Jira often point to Confluence pages through links, macros, and embedded content. Those references do not become working links in Plane unless you rewrite them to point at the wiki's new location. Inventory the Confluence links that appear in migrated descriptions and comments, and decide whether the pages move in the same window or stay in place with updated URLs.

CI and Git hooks

Build pipelines, commit hooks, and branch naming rules often reference Jira issue keys, such as a project prefix in commit messages that triggers a transition. Those hooks live in your repository host and CI system, not in Jira, so they keep running against a tool that no longer holds the issues. Identify each hook that reads or writes Jira, then update it to reference Plane work item identifiers or remove it.

SSO and user provisioning

Users and their roles should be provisioned in Plane before the import, not created by it. Self-hosted Plane offers SAML and OIDC on Pro and above, while LDAP support is listed as an Enterprise feature. Confirm which sign-in method your identity provider uses, map Jira groups to Plane roles, and check that the users the importer creates match the accounts employees actually use.

Five phases from inventory to decommission

This sequence moves Jira projects into a non-production Plane workspace first, proves the counts and attachments match, and only then cuts over and retires Jira access. Each phase ends with a written record that the next phase depends on.

Inventory projects, workflows and users
Your Jira administrators list every project, board, sprint, workflow, custom field, issue type, screen scheme and permission scheme, then record the owner, open issue count and attachment volume for each project. Identity or IT staff add the user list with account status, so you know which accounts must exist in Plane before import. The output is an inventory register that marks each item as migrate, rebuild or retire. The step is done when the business owner of each project has signed off on that register.
Export and stage Jira data
Decide which extraction route fits each project before you touch the target. The Plane importer reads from Jira directly, but you should still confirm with Plane which Jira product variant and access level its importer needs for your instance, and record any items it does not carry, such as automation rules, third-party app data and Assets. Keep a separate export of project data as a fallback copy. The output is a staging record listing each source project, its export date and the fields known to be out of scope.
Run a pilot import into a non-production workspace
Create a non-production Plane workspace on your chosen deployment, either Plane Cloud or the self-hosted Commercial Edition, and import one or two representative projects. Check how sprints appear as cycles, how statuses and issue types map to Plane states and work item types, and whether comments, attachments and user assignments arrive with the expected owners. Reconcile the results against the inventory. The output is a pilot reconciliation report listing mapping decisions, gaps and the manual rebuild work each gap creates. Do not proceed until the business owners accept the mapping.
Run a parallel reconciliation of counts and attachments
Import the full project set into the production-intended Plane workspace while Jira stays open for daily work. Compare counts of work items, cycles, comments and attachments per project against the inventory, and sample individual items to confirm titles, descriptions, dates and assignees. Track every discrepancy to a cause and a fix, whether a mapping change, a user that did not match or an attachment that failed. The output is a signed reconciliation report per project with the residual differences listed and accepted by each owner. Repeat the import and comparison until the differences are only the known exclusions from phase two.
Cut over under a freeze window
Announce a freeze window in which teams stop creating or editing Jira issues, then run the final incremental import and repeat the reconciliation for changed items. Switch team links, bookmarks, board references and integration endpoints to Plane, and confirm that notifications and sign-in work for each user group. Record who approved the cutover and what was checked. The output is a signed cutover checklist covering the final counts, the approved exclusions, the rollback owner and the time the freeze ended. Confirm the freeze length with your own change process, since none is set by this page.
Decommission Jira access and retain records
After the cutover checklist is signed and the stability period your change process requires has passed, remove write access for regular users and move Jira to read-only use for reference. Export and store the final archive under your records retention policy, then disable integrations and service accounts that still point at Jira. Keep the reconciliation reports and checklist with the archive so auditors can trace how records were moved. The output is a decommission record confirming access removal, archive location and the date each integration was disabled.

How the importer runs on Plane Cloud and self-hosted Commercial Edition

Confirm the edition and plan entitlement for the Jira importer before you start. Plane's Jira importer is available on Plane Cloud and on all plans of the self-hosted Commercial Edition, and it supports Jira Cloud as well as Jira Server and Data Center. The self-hosted Community Edition is licensed under AGPL-3.0 and matches the feature set of the Cloud Free tier, and the supplied documentation does not list the Jira importer as part of that feature set. Ask Plane in writing whether a Community install can run the importer, and if the answer is no, get the Commercial Edition entitlement and plan level confirmed before any environment is built. A Community install that needs to move to a paid plan must first switch to the Commercial Edition and apply a license key, so plan that step into the schedule if it is required.

Two self-hosting methods matter for this decision. Plane documents Docker Compose for small and mid-size teams and Kubernetes with Helm for high availability, and its Kubernetes guide installs the Commercial Edition. For a migration, Docker Compose is usually simpler to stand up and retire, while Helm suits a team that already runs clusters and needs the instance to stay up during the import window. Either way, the platform depends on PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO. The Helm chart can point each of these at an external managed service, so decide early whether your organization will run these components itself or buy them as managed services, because that choice changes who patches them and who answers for backups.

Before the import, check that each dependency is sized, backed up and reachable from the users who will review the imported work. Confirm with your platform team where Jira attachments will be stored in the S3-compatible bucket, who holds the access keys, and how the bucket is replicated and restored. Run a trial import of one non-critical Jira project into a staging instance, then compare work item counts, attachment links and cycle assignments against Jira before you run the full migration. Record the Plane version you tested, because the Community Edition and Commercial Edition ship on separate release cycles and the importer behavior should be checked against the version you deploy.

How the move differs by Jira starting point

Plane's Jira importer supports Jira Cloud, so the main work is not connectivity but deciding what the importer carries and what you rebuild or extract separately. Cloud backups do not cover everything, so plan a second export path for the gaps and treat attachments and history as items to reconcile rather than assume.

Importer scope: Confirm which work items, comments, attachments and sprint data the importer maps in your current Plane version before you run a full test.
Attachments and history: Cloud backup and CSV exports handle attachments and change history differently, so compare file counts and sampled issue histories against the source.
Automation and apps: Automation rules, third-party app data and Assets are outside the cloud backup, so inventory them early and rebuild or export them separately.
Sprint sequencing: Import a single pilot project first, check that sprints appear as cycles with correct dates, then move the remaining projects in batches.
Workflows and permissions: Plane uses its own states and roles, so map Jira workflow statuses and project permissions to Plane equivalents before the production import.

Before cutover, ask your Plane contact and your Atlassian administrator to confirm in writing which artifacts each route covers, and sign off a reconciliation sheet for each project.

What usually goes wrong in a Jira to Plane move

Most Jira to Plane problems surface after the first import, when counts, states and people no longer match the source. The cards below cover the risks we see most often and the checks that catch them before cutover, so each one can be signed off rather than discovered by the team.

Unmapped workflow states

Jira workflows carry custom statuses, and each one must land on a Plane state group. A status with no clear target can end up in the wrong group, which distorts cycle progress and any reporting built on it. Before a full run, list every Jira status per project, decide its Plane state, and get the product owner to sign off the mapping in writing. Re-check the mapping after any workflow change made during the migration window.

Lost automation logic

Jira automation rules are not part of what Jira Cloud backup covers, and automation rules will not be recreated by an importer. Teams that relied on auto-assignment, transitions on pull request merge or notifications will find those behaviors silently absent in Plane. Inventory every rule and integration in Jira, mark each as rebuild, replace or retire, and test the replacements against a sample project before the cutover date.

User identity mismatches

Assignees, reporters and watchers are matched to Plane members by identity, and accounts that differ in email address or were never invited will not line up. The result is unassigned work or tasks attributed to the wrong person. Export the Jira user list, match it against the Plane workspace members before importing, and confirm with each team lead which accounts are active. Plan who creates the Plane accounts and in which order.

Attachment size and completeness gaps

Attachments are a common source of silent loss, particularly large files and files linked from comments. Jira Cloud backup has its own data limit and interval, so do not assume a backup export holds every file. Sample issues with large attachments in a test import, open them in Plane, and compare file counts per issue against Jira. Record any issue whose attachments did not arrive and decide whether to retrieve them manually.

Duplicate imports

Running the importer twice into the same workspace creates a second copy of every work item, and the duplicates look legitimate until someone compares totals. This happens when a run stalls and is restarted, or when two people start the import. Designate one operator, use a dedicated test workspace for rehearsals, and clear it before each full run. Keep a log of run dates and item counts so a repeat run is visible immediately.

Cycles that miss the sprint cadence

Jira sprints become Plane cycles, but sprint start and end dates, and sprints that overlap or were never closed, may not map cleanly. Teams can end up with cycles whose dates do not reflect how work was actually done. Before the full import, compare a sample of sprints with their dates in Jira. Agree with each team whether historical sprints move as cycles or are archived, and reconcile work item counts per sprint after the run.

What drives the cost and duration of the move

This table lists the factors that change the effort and cost of moving from Jira to self-hosted Plane, and whether each one is paid once or recurs. Use it to see which inputs a quote needs before any work is scoped. The main takeaway is that the Commercial Edition licensing and seat count are the only recurring cost that depends directly on the Plane edition you choose.

Driver	Why it changes cost or effort	One-time or recurring	How to keep it down
Projects and work items	Each project, sprint and work item must be mapped and checked after import, so volume drives validation time.	One-time	Archive closed projects in Jira and migrate only active work with a defined cutoff.
Workflows and custom fields	Jira statuses, transitions and custom fields need equivalent states and properties in Plane before records import cleanly.	One-time	Simplify workflows before the move and document which custom fields the team still uses.
Sprints as cycles	Sprint history is brought across as cycles, so teams that rely on velocity reports or carry-over rules need extra mapping and checks.	One-time	Decide which sprint history matters and confirm how cycles appear after import on a test project.
Users and seat count	Paid Plane plans count seats by users with paid roles, so the number of active users sets the recurring license cost.	Recurring	Remove inactive Jira accounts first and confirm which users need paid roles versus guest access.
SSO and identity integration	SAML or OIDC on Pro and above, and LDAP on Enterprise, require configuration against your identity provider and testing of sign-in.	One-time setup, recurring plan cost	Confirm the identity provider and edition needed before scoping, and test sign-in with a pilot group.
Integration rebuilds	Jira automation rules, third-party apps and connected tools are not carried over and must be rebuilt or replaced by hand.	One-time	Inventory every connected app and automation rule in Jira and rank them by business use.
Hosting choice	Docker Compose suits small and mid-size teams, while Kubernetes with Helm adds cluster, PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage to run and back up.	Recurring	Ask whether managed services can replace parts of the stack and confirm backup and restore responsibilities in writing.
Upgrades and maintenance	Each Plane edition has its own release cycle, so upgrades, patching and testing repeat for the life of the deployment.	Recurring	Agree on a regular upgrade window and assign an owner for release notes and rollback plans.
Internal team's Plane experience	A team new to Plane needs time to configure projects, cycles and permissions and to train users, which adds effort on both sides of the move.	One-time, with some ongoing support	Run a pilot project first and ask the implementation partner to document the configuration for your team.

How to run Jira and Plane in parallel without split records

Run Jira and Plane in parallel only for a short, dated window, and give every project exactly one authoritative system at any moment. Split records happen when a team keeps creating and editing issues in both tools with no rule for which copy is current. The safer pattern has three parts: a read-only Jira period for closed or historical projects, a single system of record per active project, and a dated freeze after which Jira stops accepting changes for that project. Before the freeze, run an initial import to Plane, then a final delta import of anything changed in Jira since that first pass, and check item counts, statuses and sprint assignments against the source.

Plan these dates now because Atlassian's Data Center timeline sets a hard ceiling. Atlassian's announcement states that new Data Center subscriptions for new customers end on March 30, 2026, that licenses and expansions for existing customers stop after March 30, 2028, and that Data Center licenses expire and become read-only on March 28, 2029. Work backward from those dates to schedule waves of projects, and assign an owner for each wave. Confirm current licensing terms, renewal rules and any changes with Atlassian directly, since the timeline can affect your contract and your own renewal window. Record each project's freeze date in a shared register so teams can see which system is authoritative at any point.

Set the rules for the overlap period in writing. Decide who may create work items in Plane for a project that is still open in Jira, whether Jira comments on frozen projects are allowed, and who approves exceptions. In Plane, confirm which roles and seats your team needs before you invite users, since the seat model depends on your edition. Also note what Plane's Jira importer does not carry over, such as automation rules, third-party app data and Assets, and rebuild those in Plane or document them as retired before the freeze. Keep the final Jira export and import logs as evidence of the cutover for your records.

Questions teams ask before moving from Jira to Plane

How long does a migration from Jira to Plane take?

No researched figure for a Jira to Plane migration duration is available, so plan from your own data. Duration is driven by the number of projects and work items, how many attachments and comments must come across, how many workflows and custom fields need to be mapped to Plane states and properties, and how many people must validate the result. Run a test import of one representative project first, then time it and check the output with the people who use it daily. Ask any implementation partner for a duration tied to a written scope, and confirm import limits for your Jira edition with Plane before you start.

What does moving from Jira to Plane cost, and which parts are paid?

The importer itself is included with Plane Cloud and with all plans of the self-hosted Commercial Edition, so the software cost depends on the plan and seat count you choose. 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, which Plane publishes as a reference point for the subscription line. The Community Edition is free to run, but moving to a paid plan requires switching to the Commercial Edition. Other costs are infrastructure, including PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, plus the staff time for data preparation, testing and training. Ask for a quote that separates one-time migration work from recurring hosting and support.

Can our team migrate from Jira to Plane without outside help?

A small team with admin rights in both systems can often run the importer itself, provided the data set is simple. The work becomes harder when you have many custom fields, complex workflows, multiple Jira instances, or strict requirements for audit evidence. Before you begin, confirm which Jira export route applies to your edition, since Plane's importer covers Jira Cloud as well as Server and Data Center. Teams that want a fixed-scope engagement can ask DeployOpen to plan, implement and document the migration in their own infrastructure, with the scope and deliverables agreed in writing before work starts.

What do Jira and Plane admins need to prepare before the import?

Jira admins need to confirm which projects, boards and users are in scope, export or back up the data, and document the workflows, schemes and permissions that will need rebuilding. Plane admins need a workspace, the target projects, and a decision on how Jira users map to Plane members and roles. On a self-hosted install, the platform team must also have the database, cache, message queue and object storage running before the importer is used. Agree a list of owners who will check imported work items, sprints and attachments against the source, and keep a record of who approved each step.

Do sprints, comments and attachments come across from Jira to Plane?

Plane's importer documentation covers Jira data as a supported import source, and sprints correspond to Plane cycles in this migration path. Before relying on any specific field, check the Jira importer documentation at Plane's docs site, because mapping coverage can change between releases. Test with one project that contains comments, attachments and sprint history, then compare counts and sample items in both systems. Attachments depend on file size, storage configuration and permissions, so verify them in the object storage you chose. Anything you cannot confirm in the test should be treated as a manual rebuild item.

What stays behind when moving from Jira to Plane?

Items that depend on Jira-specific features usually need to be rebuilt or archived rather than carried across automatically. Confirm each of these in your test import: Jira automation rules, third-party app data, dashboards and filters, and custom workflow logic. Atlassian's own cloud backup excludes automation rules, third-party apps and Assets, so plan for those separately. Keep a read-only copy of the Jira export for audit and reference, and list every item left behind with an owner and a replacement, if one exists.

Does moving to Plane Cloud or self-hosting change how the Jira importer works?

The importer is available on Plane Cloud and on the self-hosted Commercial Edition, so the core import path is the same in both cases, but the surrounding responsibilities differ. On Plane Cloud, Plane runs the infrastructure. On self-hosted Plane, your team runs the database, cache, queue, object storage and upgrades, and must confirm that the edition and license you use include the importer. The Community Edition is licensed under AGPL-3.0 and does not change the importer's availability on paid editions, so check the current edition terms with Plane before you choose. Ask your vendor to confirm the import path for your exact edition and Jira deployment type.

How DeployOpen scopes and runs the Jira to Plane move

DeployOpen plans and implements self-hosted Plane inside your own cloud account, data center or air-gapped network, and prepares the Jira export, import and rebuild work around it. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any migration work starts.

How we scope

Inventory the Jira sites, projects, workflows, schemes and apps in use, and confirm whether the source is Jira Cloud or Data Center.
Agree which Plane edition and deployment method fit your hosting, including whether a paid plan needs the Commercial Edition.
Document what will not move, such as automation rules, third-party apps and Assets, and agree how each gap is handled.

How we build

Stand up Plane on your infrastructure with PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage, using your chosen install method.
Run test imports with the Plane Jira importer, then reconcile work item counts, attachments, users and sprints as cycles against the source.
Rebuild workflow states, labels, modules and permissions in Plane according to the agreed mapping, and set up SSO where your plan supports it.

How we hand over

Provide written runbooks for the installation, import steps, mapping decisions and known gaps, so your team can repeat or audit the work.
Walk your administrators through cycles, modules, roles and seat counting so the post-migration setup is understood in-house.
Deliver a cutover checklist and a record of what was migrated, what was rebuilt by hand and what was left in the Jira archive.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial migration closes.
Plan backups for the Plane database and object storage, and confirm restore steps before the Jira source is retired.
Ask us to quote upgrades for new Plane releases, and confirm each release's changes in your own test environment first.

Migrate from Jira to Plane