Jira to Plane Migration: Step-by-Step Plan for Teams up to 100

Moving from Jira to Plane became a routine task in 2026: Atlassian has stopped selling Data Center, and cloud plans keep getting more expensive. Plane has a built-in importer for Jira Cloud and Jira Server/Data Center that migrates projects, issues, comments, attachments and users. But a good migration doesn’t move everything. It moves what the team needs to get work done and leaves behind the complexity that has piled up over the years.

This is a practical migration guide for teams of up to 100 people. The plan is based on Plane’s documentation and our implementation experience, adjusted for Kazakhstan specifics: self-hosted deployment on in-country servers and responsibility for the infrastructure. We explained why the move has become relevant in our article on the end of Jira Data Center, and compared the tools in Plane vs Jira.

The full migration path

Stage	What we do	Outcome
1. Scope	Decide which projects and issues move	List of projects to migrate and to archive
2. Audit	Inventory Jira across 25 areas	Table of dependencies, scripts and apps
3. Preparation	Set up the Plane workspace and Jira access	Workspace, API token, JQL filter
4. Pilot	Import one project, verify with real users	Go/no-go decision for full migration
5. Waves	Migrate remaining projects, reconnect integrations	All teams in Plane
6. Cutover	Switch Jira to read-only, set the rules	Plane as the single system of record
7. Stabilization	Adoption review after 2–4 weeks, Jira shutdown	Atlassian contract closed

Step 1. Decide what moves

The first question isn’t “how do we migrate” but “what don’t we migrate.” In a typical three-to-five-year-old Jira, half the projects are closed and a third of the statuses aren’t used. Moving all that into a new system pollutes it from day one.

The rules we apply:

• active projects move in full, with history;
• closed projects move only if they are referenced by policies, contracts or audits; the rest are exported to an archive;
• closed issues older than a year are migrated at the project owner’s discretion and usually go to the archive;
• several small projects belonging to one team are merged into a single Plane project with modules.

For each project, we record who decides its fate. Without that, the migration gets stuck in approvals.

Step 2. Audit Jira

Plane suggests checking Jira across roughly 25 areas, either manually or with the Jira Discovery script, which collects an inventory into a spreadsheet. The key items:

1. Number of active users over 90 days and their roles.
2. Projects, workflow schemes and statuses, with usage frequency.
3. Issue types and custom fields; for each field, whether it is used in filters and reports.
4. Issue links and sub-tasks.
5. Sprints, versions, components, epics.
6. Jira Automation rules.
7. ScriptRunner and Groovy scripts, post-functions.
8. Marketplace apps and the data they store.
9. Integrations: GitHub, GitLab, Bitbucket, CI/CD, Slack, Sentry, CRM.
10. Dashboards and JQL filters that managers actually use.
11. Attachments: total volume and the largest files.
12. Permission schemes and user groups.

The audit output is a table where every entity is assigned one of three decisions: migrates automatically, gets rebuilt in Plane, or doesn’t migrate.

Step 3. Prepare Plane and access

On the Plane side: the workspace is created, an administrator is assigned, and the deployment model is chosen. For companies in Kazakhstan with data storage requirements, that means a self-hosted installation via Docker or Kubernetes on a server with a local hosting provider or in your own data center. Before importing, test backup and restore: the migration will be the first serious volume of data in the system.

Kazakhstan context. Self-hosted Plane on a Kazakhstan hosting provider’s server keeps data in the country, if that matters to the company. But responsibility for the server, updates and backups shifts to you. Before the migration starts, assign an engineer or contractor who will maintain the system after launch.

On the Jira side: an administrator API token, the instance URL, the user’s email and, if needed, a JQL filter to limit the import. For Jira Server and Data Center, keep the active seat limit in mind: users beyond the limit are imported in a suspended state and activated later.

Step 4. How the importer works

Plane’s importer lives in the workspace settings. The process for Jira Cloud and for Server/Data Center differs in connection details, but the logic is the same: you specify the source, select projects, map states and users, and run the import. It can take anywhere from a few minutes to a few hours depending on the volume of attachments.

When it finishes, an Import Summary report is available: what was imported, what was skipped and where errors occurred. This report becomes the basis for verifying the pilot. All migrated work items are tagged with the JIRA IMPORTED label.

The import can be re-run for all deployment types. For Server and Data Center, an interrupted import can be resumed within about seven days.

Step 5. Mapping: what becomes what

Jira entity	In Plane	Decision
Project	Project	Automatic, consolidation possible
Issue	Work item	Automatic
Issue type	Work item type	Automatic, redundant types merged
Status and workflow	States in state groups	Mapped manually during import
Priority, labels	Priority, labels	Automatic
Sprint	Cycle	Automatic
Component, Version	Module	Automatic
Epic	Work item type “Epic,” not Plane Epics	Decided after import
Sub-task	Sub-work item	Automatic
Issue links	Relations	Automatic
Comments, attachments	Comments, attachments	Automatic
Users	Members	Matched by email
Custom fields	Work item type properties	Partial, depends on field type
Jira Automation	Automations, Runner	Rebuilt
ScriptRunner, Groovy	No equivalent	Rebuilt or not migrated
Dashboards, JQL filters	Dashboards, PQL, Views	Rebuilt
Permission schemes	Roles, Granular Access Control	Rebuilt
Confluence	Pages, Wiki	Separate import or manual transfer
Marketplace apps	No equivalent	Assessed app by app

The most expensive part of any migration is at the bottom of the table: automations, scripts and reports. Their volume determines whether the move takes six weeks or six months.

Step 6. The pilot and how to verify it

We pick the pilot project this way: 10–20 active users, a live flow of work, not the most complex workflow scheme, but with fields and links typical for the company. We import it, then verify with the team against a checklist:

• the number of issues in Jira and Plane matches, accounting for the filter;
• in a random sample of 20 issues, the description, comments, attachments, assignee and status are all in place;
• issue links and sub-tasks are preserved;
• sprints have become cycles with the correct dates;
• users are matched and no one has lost authorship;
• the Git repository integration is rebuilt and commits link to work items;
• the team has worked in Plane for a week and logged its questions.

The pilot is a decision gate. If it doesn’t pass, the full migration isn’t ready. Go back to the mapping instead of moving forward with the plan.

Step 7. Week-by-week plan for 100 people

Week	Activities	Who’s involved
1	Migration scope, Jira audit, decision table	Process owner, Jira administrator, contractor
2	Plane deployment, backups, access, SSO	Infrastructure engineer
3	Pilot project import, checklist verification	Pilot team
4	Pilot team works in Plane, feedback collected, fine-tuning	Pilot team, process owner
5	First wave: 40–50% of projects, integrations reconnected	Wave teams, engineer
6	Second wave, automations and dashboards rebuilt	Remaining teams
7	Cutover: Jira to read-only, policy, training	Whole company

The timeline assumes a well-prepared Jira and a dedicated process owner. If the audit reveals hundreds of projects and dozens of scripts, the plan is recalculated after the first week.

Cutover checklist

• All projects on the list are migrated and the Import Summary reports are checked.
• Integrations with Git, CI/CD, the messenger and CRM work from Plane.
• Automations and management dashboards are rebuilt.
• Jira is switched to read-only and creating new issues is disabled.
• Teams know the rule: new work items go into Plane only.
• An internal Plane owner and an infrastructure contractor are assigned.
• A Jira export is saved to the archive in case of disputes.

Stabilization

Two to four weeks after cutover, we run a review: are all teams working in Plane, is there any parallel tracking in chats or in the old Jira, do the integrations work? Partial use of Jira during this period is the main risk: two systems of record mean neither can be trusted. After the review, Jira is shut down and the Atlassian subscription is not renewed.

We handle Jira-to-Plane migrations end to end: audit, deployment on servers in Kazakhstan, import, rebuilding automations and team training. Learn more on our Jira and Plane task tracker implementation service page.

---

Sources. Plane importer documentation and the Jira migration guide on Plane’s blog, August 2026. Atlassian Data Center timeline: atlassian.com/enterprise/data-center.

Terms in plain words

Importer

A built-in Plane tool that migrates data from Jira. Every migrated work item gets the JIRA IMPORTED label, so it is easy to find and check.

Mapping

A table of correspondences showing what each Jira object becomes in Plane. For example, a sprint becomes a cycle, and a component or version becomes a module.

API token

A secret key that lets one program access another program’s data. The import requires a Jira administrator token.

JQL filter

A query in Jira’s search language that selects specific issues. You can use it to limit exactly what gets imported.

ScriptRunner

A Jira add-on for custom scripts written in Groovy. Plane has no equivalent, so that logic is rewritten with other tools or dropped.

Adoption

How much the team actually uses the new system. A review after two to four weeks checks that work isn’t still being tracked in chats or in the old Jira.

Self-hosted

Plane runs on the company’s own server or with a Kazakhstan hosting provider. Data stays in the country, but updates and backups become your responsibility.

Docker and Kubernetes

Standard tools for installing and running software on servers as ready-made containers. They are used to deploy Plane on your own server.