Executive summary
What this is. A precise reference that does three jobs at once: a capability matrix comparing Atlassian Jira and Plane, a data dictionary translating every Jira term and concept to its Plane equivalent, and a disposition for each capability that tells an evaluator exactly how to read it. It is built to be read by an enterprise architecture and procurement team and to stand up to scrutiny — every claim is checkable against current product documentation.
The thesis. Plane is the cleaner evolution of work management, in one coherent space. Where Jira accumulated concepts and products — boards layered on projects, six configuration schemes layered on issue types, and Confluence, Jira Service Management and Jira Align bolted alongside — Plane keeps a smaller, sharper model: projects and cycles, one issue-type layer that maps types to workflows, a single relationship-based permission graph, with documentation and intake built in. Less to administer, less to learn, nothing to unlearn later.
The agentic shift. The platform that accelerates an enterprise in the agentic era is the one where agents are first-class actors in a single, permissioned, auditable space that people can point them at and steer. Plane runs AI and agents inside the security perimeter, acting on the same work items and the same permission model as the people they work alongside, with the whole API exposed to them through a native protocol. Jira’s AI runs only in Atlassian Cloud, on an estate split across separate products — so the practical ceiling on how much work can be handed to agents is structurally lower. This is the difference that compounds as more work moves to agents.
Why now. Atlassian Data Center — the self-managed, on-premise and air-gapped edition many regulated teams standardised on — reaches full read-only end-of-support in March 2029.1 The deployment model that justified the original Jira choice is the one being withdrawn, which makes this a genuine decision rather than a renewal.
Where it lands. On the capabilities that decide an enterprise review — durable self-hosting, AI inside the security perimeter, a coherent permission model, total cost — Plane is ahead today. On the smaller set of capabilities where Jira currently leads, the work is named on a dated Plane roadmap (Q3–Q4 2026), with the interim approach given in each row. There is no capability for which the recommendation is to stay on Jira.
Strategic context
Atlassian Jira — a winding-down, multi-product estate
Staying is the higher-risk path: a hard end-of-life on the self-managed edition, and the accumulated complexity of running work across several separately-licensed products.
- 16 Dec 2025New Data Center apps no longer accepted to the Atlassian Marketplace.
- 30 Mar 2026End of new Data Center license sales to new customers; feature work narrows to security and maintenance.
- 30 Mar 2028End of renewals, upgrades and expansions for existing Data Center customers.
- 28 Mar 2029Full end of support — Data Center and its Marketplace apps become read-only, with no further security updates.
A roughly 15% Data Center price increase took effect in February 20264 — customers now pay more for a product with a fixed expiry.1 The on-premise routes offered (Atlassian Cloud, Isolated Cloud, Government Cloud) do not preserve true sovereignty: Isolated Cloud (expected 2026) is itself internet-connected and Atlassian-managed, so it does not answer SCIF, classified or air-gapped requirements.4
A full Jira deployment is rarely one product. Work lives in Jira; documentation in Confluence; service management in Jira Service Management; SSO and provisioning at scale in Atlassian Guard; scaled planning in Jira Align — each licensed, integrated and governed separately, with its own timeline.
AI sits outside the boundary on top of all of it: Rovo runs only in Atlassian Cloud, so a self-managed estate cannot use it without syncing data out.3 Pricing compounds the sprawl — per-product, per-agent add-ons and user-band step-ups that raise cost non-linearly with growth.
Inside the product, complexity accumulates: each project is governed by up to six interacting schemes (workflow, issue-type, screen, field-configuration, notification, permission), and split further into team-managed vs company-managed projects with different models to learn and keep aligned.
The vocabulary keeps moving, too: Jira Cloud renamed Projects to Spaces and Issues to Work items — relabels that collide with Confluence Spaces and unsettle established process and training, with no equivalent change on Data Center.2
Because Rovo requires Atlassian Cloud, a Data Center customer must sync its data into Atlassian Cloud through connectors to use AI — so AI is not available inside a self-managed or air-gapped boundary.3 For a regulated, sovereign estate, that is the capability the deadline quietly takes off the table.
Plane — one coherent, agent-native control plane
What the next platform looks like: one place to run the work, open formats so nothing is trapped, and an operating model built for agents.
The strategic bet is consolidation. One platform — Plane Projects for work, Plane Wiki for documentation and Plane Desk for service management — on one model, one instance and one permission graph, rather than a stack of separate products stitched together and separately governed.
Because work, documentation and intake share that model, people and agents act on the same data in the same place. That coherence is what makes the platform legible to run, and what an agentic operating model needs underneath it.
Underneath the surfaces sits the WorkLake: a single, structured store holding all work — items, projects, cycles, documents, relationships and their full history. Every view, board, report and dashboard is derived from it; PQL reads and writes against it; agents act on it.
Because it is one consistent store rather than data scattered across separate products, analytics, AI and automation all see the same complete picture. It is the foundation that makes a single control plane, deterministic PQL and safe agent operation possible.
Large, regulated organisations rarely run a single global instance. Federation lets multiple Plane instances and workspaces — separated by region, business unit or jurisdiction — keep their data local, so residency and sovereignty are preserved, while still coordinating across the boundary through shared Work Links and cross-instance visibility where policy allows.
An institution can therefore meet strict data-residency and air-gap requirements per jurisdiction and still run and report on work as one organisation — rather than choosing between sovereignty and a single view.
“Open” here means open formats and published specifications, not an open-source ideology. Work, projects and configuration are expressed in declared, portable formats — YAML and JSON, project-as-code, and a stable, addressable Work Link for any item — so data and process are inspectable, version-controllable and never trapped.
Declared formats keep migration, automation and interoperability low-risk: anything Plane holds can be read, transformed and moved on terms the institution controls. (See the Work Link section below.)
Three layers, all inside the perimeter under one permission model: an AI assistant available throughout the product; custom agents teams define for their own work; and orchestration that composes multiple agents. Underneath, the Plane Query Language (PQL) gives agents a precise, deterministic way to read and write work.
Alongside them, Plane applets (coming soon) let teams build custom applications directly with AI, or drop in a vetted build from a marketplace. As AI reshapes the interface, the long-standing dependence on marketplace plugins falls away — teams assemble what they need rather than licensing it.
How to read this document
Platform profiles
The two platforms enter from different starting points: Jira as the incumbent with two decades of tooling, Plane as the self-managed-first successor built on a deliberately smaller model. Most rows here are Mapping — orientation for the detail that follows.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Origin & maturity | Atlassian, 2002. 20+ years of development; used by 250,000+ organisations. | 2022. ~2 million users, hundreds of thousands monthly active, and 50K+ GitHub stars. | Mapping MappingMaturity favours Jira; trajectory and a cleaner, fast-growing model favour Plane. MigrationWeigh maturity against the specific capabilities scored below, not as a verdict in itself. |
| Product model | Proprietary and multi-product. Atlassian-hosted Cloud or self-managed Data Center. | Open core: self-host the Community Edition free, or use Plane Cloud and the paid tiers. | Plane advantage DispositionPlane is one coherent, steerable space for people and agents to do the work in, deployable and auditable on the institution’s own terms — not a stack of separate products to integrate. Why it mattersOwn the deployment end to end and standardise teams on a single space. |
| Platform composition | Multiple products — Jira, Confluence, Jira Service Management, Guard and Jira Align — each licensed and integrated separately. | One platform of three products on one model and instance: Plane Projects (work), Plane Wiki (docs) and Plane Desk (service management). | Plane advantage DispositionA single coherent platform means one data model, one permission graph and one thing to run, instead of integrating and governing several separately-licensed products. Why it mattersConsolidate Jira, Confluence and JSM (and Guard, Align) onto Plane Projects, Plane Wiki and Plane Desk. |
| Design philosophy | Concepts accumulate: boards over projects, multiple configuration schemes over issue types, separate products for docs and intake. | A small, sharp, real-time model built with taste: projects and cycles, one issue-type layer, one permission graph, docs and intake built in — with a great deal deliberately eliminated. | Plane advantage DispositionFewer concepts, kept fast and real-time, mean less to administer, less to train, and no abstractions to unwind later. Simplicity that still scales is the through-line of this document. Why it mattersMap Jira’s layered concepts onto Plane’s smaller set during migration; most collapse cleanly. |
| Self-managed status | Data Center is the self-managed edition and is on a published path to read-only status in March 2029. | Self-hosting is first-class and permanent, with no announced end-of-life. | Plane advantage DispositionThe model that justified the original Jira Data Center choice is the one being withdrawn; Plane preserves it indefinitely. Why it mattersAdopt Plane self-hosted to keep on-premise control without a 2029 migration cliff. |
| Cost posture | Per-user subscription, with Confluence, Jira Service Management, Guard and Marketplace apps commonly required for a complete deployment. | Low per-seat pricing; documentation, intake, SSO and AI included rather than separately licensed. | Plane advantage DispositionTotal cost, not list price, is the comparable figure; Plane consolidates what Jira sells as add-ons. Why it mattersSee the cost section for the itemised comparison. |
Deployment, hosting & sovereignty
The decisive section for a regulated, self-managed estate. Jira can still be self-hosted today through Data Center, but that edition is being withdrawn; Plane treats self-hosting, air-gapped included, as a permanent first-class deployment. The disposition here is consistently Plane advantage on sovereign control.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Cloud (SaaS) | Yes — Atlassian Cloud (Standard, Premium, Enterprise). | Yes — Plane Cloud, including a free tier. | Parity DispositionBoth offer a managed cloud; not a differentiator on its own. Why it mattersIf managed cloud is acceptable, decide on the capability and cost rows. |
| Self-hosted / on-premise | Data Center only; about $59,000/yr for 500 users, and sunsetting. | Yes — Community Edition free with all core features; paid self-hosted tiers add SSO and governance. | Plane advantage DispositionA live, supported, non-sunsetting self-hosted option is mandatory here, and Jira no longer provides a durable one. Why it mattersRun Plane self-hosted: no per-seat Data Center license, no forced cloud migration. |
| Air-gapped deployment | Data Center supports air-gapped today, but it is sunsetting and its AI cannot run inside the gap. | Yes — fully air-gapped, with the complete AI feature set available inside the boundary. | Plane advantage DispositionAir-gap capability is non-negotiable for the most sensitive workloads, and AI parity inside the gap is unique to Plane. Why it mattersDeploy Plane in the isolated network; AI runs against an in-network or approved endpoint. |
| Containerised deployment | Data Center supports Docker and Kubernetes. | Docker Compose, Kubernetes, Helm and Podman; a typical install completes in under 20 minutes. | Parity DispositionBoth deploy on standard container infrastructure; Plane adds packaging breadth and a faster install. Why it mattersUse existing Kubernetes tooling for either; Plane ships Helm charts and an off-by-default posture. |
| Cloud marketplace images | No native marketplace listing; Atlassian Cloud is Atlassian-hosted. | AWS and GCP Marketplace listings (Azure coming) — with identical capability on self-hosted and cloud, 100% parity. | Plane advantage DispositionMarketplace procurement simplifies enterprise purchasing, and full feature parity means a self-hosted deployment is never a second-class one. Why it mattersProvision Plane through an approved cloud marketplace, or self-host — the same product either way; build custom agent applications as applets on the fly with AI, or pull a vetted build from a marketplace. |
| Data residency & sovereignty | Cloud residency options exist; full control requires Data Center, which is sunsetting. | Self-hosting gives end-to-end control of data location, network and lifecycle. | Plane advantage DispositionComplete control of where data lives and who can reach it is a primary review criterion; self-hosting satisfies it absolutely. Why it mattersHost Plane in the institution’s own region, account and network boundary. |
| Storage & database substrate | Data Center requires a supported enterprise database and shared filesystem. | PostgreSQL with S3-compatible object storage for attachments. | Mapping MappingBoth rely on standard, supportable infrastructure; the substrate is a planning detail, not a deciding factor. MigrationMap Plane onto existing PostgreSQL and object-storage standards. |
| Upgrade longevity | Data Center reaches full read-only end-of-support on 28 March 2029. | No announced end-of-life; upgrades continue on the self-hosted track. | Plane advantage DispositionA platform with a known shutdown date cannot anchor a multi-year standard. Why it mattersStandardise on Plane self-hosted to remove the migration deadline entirely. |
Security, permissions & compliance
Plane reaches parity on the authentication and certification controls an enterprise screens for, and is ahead on permission architecture: a single relationship-based graph in the model Google uses for planet-scale authorization, rather than Jira’s stack of separate schemes. The two finest-grained controls are arriving fast — both in Q3 2026, on that same graph — and self-hosting moves most compliance boundaries inside the institution’s own controls.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Single sign-on (SAML / OIDC) | SAML on Cloud (Standard+) and Data Center; OIDC via apps. | SAML and OIDC, included on self-hosted Pro. | Parity DispositionBoth integrate with enterprise identity; Plane bundles OIDC where Jira often needs higher tiers or apps. Why it mattersConnect either to the existing IdP; Plane supports OIDC natively for modern providers. |
| SCIM provisioning | Yes — on enterprise identity tiers. | Yes — SCIM user provisioning supported. | Parity DispositionAutomated joiner/mover/leaver provisioning is available in both. Why it mattersDrive lifecycle from the existing IdP for either platform. |
| Permission architecture | Permission schemes layered alongside notification, screen and field-configuration schemes — several models to keep aligned. | A single relationship-based access graph (Zanzibar-style ReBAC, the model behind Google-scale authorization). | Plane advantage DispositionOne coherent permission graph is simpler to reason about, audit and prove correct than a stack of separate schemes — fewer places for a misconfiguration to hide. Why it mattersExpress access as relationships in one place; retire Jira’s parallel schemes during migration. |
| Role-based access control | Mature project roles and permission schemes. | Workspace, project and guest roles (Free); full RBAC, granular access control and audit logs (Business), on the Zanzibar-style graph. | Parity DispositionBoth cover enterprise role models; Plane delivers it through one relationship graph rather than per-project schemes. Why it mattersMap required Jira schemes to Plane roles; the common cases translate directly. |
| Item-level access control | Issue security levels restrict individual issues within a project. | Arriving Q3 2026, built directly on Plane’s permission graph — simple per-item access, no separate scheme to manage. | Roadmap · Q3 2026 PlanPer-item access is added to the existing relationship graph, so it stays one simple model rather than a bolted-on scheme. TodayUntil then, separate sensitive work into access-scoped projects in Plane. |
| Field-level permissions | Field-level security supported. | Arriving Q3 2026 — field-level visibility on the same permission graph, kept deliberately simple. | Roadmap · Q3 2026 PlanField-level rules extend the one relationship graph, so the permission model stays consistent end to end. TodayUntil then, use project segmentation and role scoping where field hiding would be used. |
| Audit logs | Yes — Premium+ and Data Center. | Yes — Business tier and self-hosted deployments. | Parity DispositionBoth produce administrative and security audit trails sufficient for review. Why it mattersShip Plane audit logs to the institution’s SIEM in self-hosted deployments. |
| MFA / 2FA | Yes. | Yes — and the IdP enforces MFA in SSO deployments. | Parity DispositionMulti-factor is standard in both. Why it mattersEnforce MFA at the IdP for either platform. |
| Network controls | IP allowlisting on enterprise tiers. | Self-hosting places the deployment behind the institution’s own network controls. | Parity DispositionBoth restrict network access; self-hosting generalises this to the full enterprise perimeter. Why it mattersApply existing firewall, VPN and zero-trust controls in front of self-hosted Plane. |
| SOC 2 / ISO 27001 / GDPR | Yes — independently audited cloud compliance programme. | Plane Cloud: SOC 2, ISO 27001, GDPR and CCPA, independently audited; self-hosting shifts the boundary into the customer’s own controls. | Parity DispositionBoth meet the baseline certifications; for self-hosted Plane the institution’s own audited controls apply directly. Why it mattersInherit the institution’s own SOC 2 / ISO programme for self-hosted Plane; use Plane Cloud attestations otherwise. |
| HIPAA | BAA available on Cloud and Data Center. | Self-hosting keeps PHI inside the customer-controlled environment; Cloud references HIPAA support. | Parity DispositionBoth can support a HIPAA posture; self-hosting removes the need for a vendor BAA on protected data. Why it mattersKeep regulated data within the self-hosted boundary under the institution’s own agreements. |
| FedRAMP | Government Cloud is building toward higher authorisations; not generally available, and not for Data Center. | No FedRAMP authorisation; self-hosting runs inside the institution’s own authorised boundary. | Parity DispositionNeither vendor holds a general FedRAMP authorisation today, so this does not separate them. Why it mattersWhere FedRAMP is mandated, run self-hosted Plane inside the institution’s own authorised environment rather than relying on the vendor. |
| AI data sovereignty | Rovo requires Atlassian Cloud; Data Center data must be synced out to use AI. | Full AI runs in-perimeter, air-gapped included, with bring-your-own-key and nothing stored by Plane. | Plane advantage DispositionKeeping AI inference inside the security boundary is decisive for a regulated estate; only Plane offers it self-managed. Why it mattersPoint Plane AI at an approved in-network or contracted endpoint; no data leaves the perimeter. |
AI, agents & the agentic shift
This is where the platforms diverge most for the years ahead. It helps to separate two things. AI is the assistant layer — the side panel and inline help that drafts, summarises and searches, available throughout the product. Agents are different: first-class actors you assign work to, @mention and steer, increasingly define yourself (custom agents), and compose into multi-agent orchestration. Plane runs both inside the security perimeter, on the same work items and one permission model, with the whole API exposed through a native MCP server and your own model behind it. Jira’s Rovo is capable but Cloud-bound and bolted onto a multi-product estate.3 Day-to-day capabilities reach broad parity; the agent-operable, in-perimeter, steerable model is the Plane advantage — what lets an enterprise safely hand more of its work to agents.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| AI assistant | Atlassian Intelligence / Rovo — search, chat, agents, studio. | Native, AI-native feature set across work items, cycles, projects and pages. | Plane advantage DispositionBoth ship substantial AI; Plane’s runs under the same sovereignty model as the rest of the platform. Why it mattersAdopt Plane AI on the same self-hosted footprint as the core product. |
| AI deployment locality | Cloud only; a Data Center estate must sync data into Atlassian Cloud to use Rovo. | Self-hosted, air-gapped included, at parity with the cloud feature set. | Plane advantage DispositionFor a self-managed estate this is the deciding AI fact: Jira cannot deliver AI without data leaving the boundary. Why it mattersRun Plane AI entirely inside the perimeter; no cloud round-trip. |
| Bring-your-own model | No — models are Atlassian-managed. | OpenAI, Anthropic, AWS Bedrock, a local model via Ollama, or any OpenAI-compatible endpoint. | Plane advantage DispositionModel choice and key ownership let the institution use contracted or in-house models under its own data terms. Why it mattersConfigure an approved provider or local model; Plane stores no keys, prompts or responses. |
| Natural-language work-item creation | Yes — via Rovo (Cloud). | Yes — create and edit work items from natural language. | Parity DispositionThe capability exists in both; the difference is locality, captured above. Why it mattersUse Plane’s in-perimeter creation in place of cloud-bound Rovo. |
| Summaries & semantic search | Rovo summaries and search across connected content (Cloud). | Summaries across cycles, projects and initiatives; AI and semantic search via OpenSearch, in-perimeter. | Parity DispositionComparable summarisation and semantic search; Plane keeps the index and queries inside the boundary. Why it mattersRun Plane search and summaries against the self-hosted index. |
| AI agents & custom agents | Rovo Agents and Studio — assignable and @mentionable (Cloud). | Assign and @mention AI agents, and increasingly define your own custom agents — actions recorded in the audit trail. | Parity DispositionAgent models are comparable; Plane keeps agent activity inside the same audited, self-hosted environment, and is opening up user-defined agents. Why it mattersOperate Plane agents in-perimeter with full audit capture; define custom agents for recurring work. |
| Agent-operable workspace & orchestration | Rovo agents operate within Atlassian Cloud, across separate products. | Agents act on the same work items as people, under one permission graph, every action audited — one coherent space, in-perimeter, with multi-agent orchestration emerging. | Plane advantage DispositionA single permissioned space agents can act across — and orchestrate within — is what makes large-scale delegation safe and reviewable; a fragmented, cloud-only estate caps how far that can go. Why it mattersPoint agents at real work in Plane through assignment, @mention or MCP, all inside the perimeter; compose multiple agents as orchestration rolls out. |
| Dashboards from a prompt | Rovo-assisted (Cloud). | Generate dashboards from a natural-language prompt. | Parity DispositionComparable in both; locality is the only material difference. Why it mattersBuild Plane dashboards by prompt without cloud dependency. |
| AI commercial model | Bundled with Premium / Enterprise plans; models and agents are Atlassian-managed. | 1,000 pooled AI credits per seat per month (Pro, rollover, beta), plus bring-your-own-key, a full MCP client surface and custom agents — so cost scales with how AI is actually used. | Mapping MappingBoth fold AI into commercial tiers, but Plane’s model lets the institution use its own keys and agents rather than paying only for a managed bundle. MigrationModel AI cost on the chosen mix of credits, own-key usage and agents; compare effective cost in the cost section. |
| Workflow automation | Mature — Automation for Jira with extensive prebuilt rule combinations and conditional branching. | Native workflows, approvals, rule-based automations, intake, recurring work items and custom SLAs (Business). | Roadmap · Q3 2026 PlanNative automation has shipped; the breadth of Jira’s prebuilt recipe library is what the roadmap expands, with a template gallery. TodayBuild required rules in Plane Business now; use webhooks, the API or an iPaaS for any recipe not yet native. |
| Webhooks & API events | Yes — event webhooks and REST API. | Yes — event webhooks and REST API on all tiers. | Parity DispositionBoth expose events for external automation. Why it mattersDrive cross-system automation from Plane events into existing pipelines. |
| MCP server | No native Model Context Protocol server. | Native MCP server exposing the full API as tools for any MCP client. | Plane advantage DispositionNative MCP lets approved AI clients act on work data under existing permissions, on an open standard. Why it mattersConnect Claude, Cursor or any MCP client to Plane in place of bespoke integration. |
Cost & total cost of ownership
The comparable figure is total cost of ownership, not list price — and the point is consolidation, not being the cheapest tool. Jira’s headline rate excludes capabilities Plane includes — documentation, intake, SSO and AI — which arrive in Jira as Confluence, Jira Service Management, Guard, higher tiers and paid apps.5 Folding them into one platform is what makes Plane’s total cost compelling; independent data on Jira contracts and add-on adoption informs the figures below.8
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Entry tier (list) | Standard at roughly $7.91–$8.15 per user / month, annual. | Pro at $6 per seat / month, annual — and Pro already includes AI. | Plane advantage DispositionLike-for-like entry pricing favours Plane, and the gap widens once AI is required. Why it mattersAdopt Plane Pro for the AI-inclusive baseline rather than stepping Jira up to Premium. |
| AI-inclusive tier | AI requires Premium at roughly $14.54–$16 per user / month (Rovo plus Advanced Roadmaps). | AI is included from Pro ($6); Business at $13 adds governance such as workflows, approvals and RBAC. | Plane advantage DispositionTo get AI, Jira must move to Premium; Plane includes AI at its entry paid tier, roughly half the cost. Why it mattersReach AI on Plane Pro; add Business only where governance features are needed. |
| Self-hosted licence | Data Center at about $59,000 / year for 500 users — and rising (a ~15% increase took effect February 2026) even as the product sunsets. | Community Edition is free with all core features; paid self-hosted tiers are per-seat with SSO included. | Plane advantage DispositionThe self-hosted cost difference is large and structural, before add-ons are counted. Why it mattersRun Plane self-hosted with no Data Center licence; pay per seat only for Pro or Business features. |
| Documentation | Requires Confluence, separately licensed at roughly $5–$6 per user / month. | Plane Wiki is built in — no separate documentation product or licence. | Plane advantage DispositionDocumentation is near-universal; Jira meets it only with a second paid product. Why it mattersUse Plane Wiki for the wiki and knowledge base instead of licensing Confluence. |
| Service management (Plane Desk) | Jira Service Management is a separate per-agent product (commonly $20–$45 per agent). | Everyday intake, customer profiles and SLAs sit inside the platform tiers; full service management is Plane Desk, a separately licensed offering. | Parity DispositionBoth treat full service management as a distinct product — Plane Desk is the like-for-like to JSM — while routine intake and SLAs are already included in Plane. Why it mattersUse built-in intake for request capture; license Plane Desk where a full service desk (queues, portals, agent SLAs) is required. |
| Identity & security add-on | Atlassian Guard (about $4 per user / month) for SSO and provisioning at scale. | SAML and OIDC SSO are included with self-hosted Pro. | Plane advantage DispositionEnterprise SSO is table-stakes; Jira often meters it through a separate add-on. Why it mattersUse Plane’s included SSO rather than a separate identity add-on. |
| Marketplace apps | Gaps are frequently closed with paid Marketplace apps, each a recurring per-user cost. | Native breadth reduces dependence on paid third-party apps. | Plane advantage DispositionMarketplace apps add real recurring cost to a Jira estate; Plane covers more in the base product. Why it mattersExtend Plane through the API, webhooks or an iPaaS instead of paid apps. |
| Pricing structure | Band-based: crossing a user-count band can raise the whole contract by 15–25%. | Linear per-seat pricing with no band step-ups. | Plane advantage DispositionBand pricing makes Jira cost jump non-linearly with growth; Plane scales predictably. Why it mattersForecast Plane cost linearly with headcount; no band-crossing surprises. |
| Total cost posture | Independent data places the median Jira contract near $85,600 / year, with real total cost often 2–3x the base subscription once add-ons are included. | A consolidated platform keeps total cost close to the per-seat figure. | Plane advantage DispositionOn total cost of ownership — the figure procurement compares — Plane is materially lower. Why it mattersCompare on fully loaded TCO; request a tailored model for the institution’s seat count. |
Migration & data portability
Migration risk is low and largely one-directional: Plane imports from Jira with high fidelity on every tier, and self-hosting gives the institution direct ownership of its own database. The disposition favours Plane on portability and lock-in.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Import from Jira | Not applicable — Jira is the source system. | Native Jira importer covering Server, Data Center and Cloud, with high-fidelity field mapping. | Plane advantage DispositionA first-class native importer removes the largest single migration risk in this evaluation. Why it mattersRun the Plane Jira importer; map schemes and types during a piloted migration. |
| Import from other tools | Some sources native, others via Marketplace or third-party tooling. | Native importers for Linear, Asana, ClickUp, Notion, Confluence and CSV — on all plans, including Free. | Plane advantage DispositionBroad native import lets the institution consolidate several tools into Plane without paid connectors. Why it mattersConsolidate adjacent tools into Plane using the built-in importers. |
| Export & backup | XML backup on Data Center; CSV and API export. | Full database ownership when self-hosted, plus CSV, Markdown and API export. | Plane advantage DispositionSelf-hosting means the institution already holds the complete datastore; export is not gated by a vendor. Why it mattersBack up the Plane database directly under existing infrastructure policies. |
| Data ownership | Cloud data resides in Atlassian-managed infrastructure. | Self-hosted data resides in the institution’s own database and object store. | Plane advantage DispositionDirect custody of the datastore is a sovereignty requirement satisfied only by self-hosting. Why it mattersKeep all Plane data inside the institution’s accounts and network. |
| Migration API | REST API available for scripted migration. | REST API available on all tiers for scripted migration and reconciliation. | Parity DispositionBoth expose APIs sufficient for programmatic migration and validation. Why it mattersScript reconciliation against Plane’s API during cutover. |
| Format lock-in | Proprietary formats and closed schema. | Portable, documented schema; documents stored as structured data. | Plane advantage DispositionA portable, documented schema and structured data remove long-term lock-in and de-risk any future change of course. Why it mattersAudit and, if ever needed, transform Plane data directly from its documented schema. |
| Phased coexistence | Can run alongside other tools via API and webhooks during transition. | Can run alongside Jira via API and webhooks during a phased migration. | Parity DispositionBoth support a parallel-run cutover; a planning approach rather than a deciding factor. Why it mattersMirror selected projects during a pilot, then cut over team by team. |
Data dictionary — terminology & model mapping
This is the data dictionary: a concept-by-concept translation so migration, training and process docs can be written without ambiguity. It is intentionally complete — if a Jira user looks for a term (board, plan, swimlane, version, Jira Align), it is here, mapped to how Plane does the same job, usually with fewer moving parts. Where Jira recently relabelled core terms — Projects to Spaces, Issues to Work items — the dictionary maps the new names too.2 It also shows where Plane deliberately carries fewer concepts than Jira — no boards, one configuration layer instead of six schemes, no separate scaling product — which is the point, not an omission. Rows are Mapping, with a few marked Plane advantage where the simpler model is the advantage.
| Concept | Jira term | Plane term | Mapping & migration |
|---|---|---|---|
| Top-level container | Site / Instance | Workspace — many per instance | Plane advantage MappingIn Jira a site is the whole instance, so multiple sites mean multiple instances (separate deployments). One Plane instance hosts many workspaces, letting a single deployment carve out regional or business-unit boundaries without standing up new machines. MigrationConsolidate Jira sites into workspaces inside one Plane instance; use workspaces for regional or org boundaries. |
| Project | Space (renamed from Project, 2025) | Project | Mapping MappingJira Cloud renamed Projects to Spaces in 2025 — a label change only, following the rename of Issues to Work items — which now collides with Confluence Spaces, leaving admins to ask which kind is meant. Plane keeps the stable term Project, not typed as Scrum or Kanban (board style is just a view). MigrationJira spaces map one-to-one to Plane projects; the board type becomes a Plane view, and the naming churn stops. |
| Board | Scrum board / Kanban board | (no board object) — Project + Cycle + Views | Plane advantage MappingPlane has no separate board entity to configure. A board is simply a view of a project or cycle, rendered from its states. MigrationDrop board administration entirely; recreate each board as a saved view in Plane. |
| Work item | Work item (renamed from Issue) | Work Item | Mapping MappingThe fundamental unit of work, with status, assignees, priority and custom properties. Jira Cloud recently renamed Issues to Work items — converging on the term Plane already used. MigrationIssues / work items import as Plane work items; issue types map to Plane work-item types. |
| Sub-item | Subtask | Sub-issue | Mapping MappingA child unit nested under a parent work item. MigrationSubtasks import directly as sub-issues with parent links preserved. |
| Iteration | Sprint | Cycle | Mapping MappingA time-boxed iteration; Plane cycles roll incomplete items forward automatically. MigrationSprints map to cycles; carryover behaviour is automatic in Plane. |
| Large body of work | Epic | Epic | Mapping MappingA strategic grouping above individual work items — native in Plane. MigrationEpics import as Plane epics rather than being flattened into labels. |
| Structural grouping | Component | Module | Mapping MappingA grouping mechanism for related work within a project. MigrationJira components map to Plane modules. |
| Portfolio layer | Plans / Advanced Roadmaps (Premium) | Initiative | Mapping MappingThe planning layer above projects and epics. MigrationRoadmap groupings map to Plane initiatives — native, not a paid add-on. |
| Team container | Project roles (no first-class team) | Teamspace | Mapping MappingA container that groups people and their work. MigrationModel Jira teams as Plane teamspaces during onboarding. |
| Status model | Status (workflow) | State (Backlog … Completed / Cancelled) | Mapping MappingThe lifecycle position of a work item; Plane groups states into five categories, with allowed transitions and approvals on Business. MigrationMap workflow statuses to Plane states; rebuild gated transitions as Plane workflows. |
| Configuration model | Issue type, workflow, screen, field-configuration, permission and notification schemes | One issue-type layer (types → workflows + properties) and one permission graph | Plane advantage MappingWhere Jira spreads configuration across six interacting schemes, Plane has a single middle layer mapping issue types to workflows and properties, plus one relationship-based permission graph. MigrationCollapse Jira’s scheme stack into Plane’s issue-type layer and permission graph — far fewer objects to maintain and align. |
| Query | JQL | Filters, saved views, API & MCP | Mapping MappingThe mechanism for expressing and saving complex queries. MigrationTranslate common JQL into Plane saved filters; use the API or MCP for programmatic queries. |
| Documentation | Confluence (separate product) | Plane Wiki (built in) | Plane advantage MappingLong-form docs, wikis and knowledge base. Plane Wiki is its own product within the platform, with Mermaid diagrams and embeds. MigrationMigrate Confluence content into Plane Wiki using the native importer. |
| Backlog | Backlog | Backlog | Mapping MappingThe set of unscheduled work awaiting prioritisation. MigrationBacklog items import directly; triage with Plane intake. |
| Label | Label | Label | Mapping MappingFree-form tags for filtering and grouping work. MigrationLabels import one-to-one. |
| Saved query | Saved filter / Quick filter | Saved view | Mapping MappingA stored query rendered as a reusable view. MigrationRecreate saved filters and quick filters as Plane saved views. |
| Board layout | Column / Swimlane | View grouping | Mapping MappingHow a board groups and splits cards. In Plane this is a property of the view, not of a separate board object. MigrationRecreate columns and swimlanes as grouping on a Plane view. |
| Field presentation | Screen / Field-configuration scheme | Properties on the work-item type (no screen object) | Plane advantage MappingWhich fields appear and how they are arranged. Plane attaches properties to the type instead of maintaining separate screen and field schemes. MigrationDrop screens entirely; configure properties on the Plane work-item type. |
| Version / release | Fix Version / Release | Cycle or module, with a version label | Mapping MappingRelease tracking. Plane tracks releases using cycles, modules and labels rather than a separate version object. MigrationMap fix versions to cycles or modules plus a version label; release burndown follows the reporting roadmap. |
| Dashboard tile | Gadget | Widget | Mapping MappingA configurable reporting tile on a dashboard. MigrationRecreate Jira gadgets as Plane widgets. |
| Scaled / enterprise agile (SAFe) | Jira Align (separate product) | Initiatives, teamspaces & cross-project planning (built in) | Plane advantage MappingPortfolio, program and solution planning for agile-at-scale. Plane handles these planning layers natively, in the same space the work already lives in, rather than in a separate, separately licensed product. MigrationRetire the Jira Align layer: model portfolios as Plane initiatives and programs as teamspaces, so planning, execution and agents share one space — the direction enterprise work is moving, not another tier to maintain. |
| Issue types | Story / Task / Bug / Epic | Work-item types | Mapping MappingThe named kinds of work. In Jira these are issue types governed by schemes; in Plane each is a work-item type carrying its own workflow and properties. MigrationMap Story, Task, Bug and Epic to Plane work-item types one-to-one. |
| Resolution | Resolution | Completion state (Completed / Cancelled) | Mapping MappingHow a closed item ended. Plane carries this in the state category rather than a separate resolution field. MigrationMap Jira resolutions onto Plane completed / cancelled states. |
| Watcher | Watcher | Subscriber | Mapping MappingSomeone following an item for updates without being assigned. MigrationWatchers import as subscribers; notification preferences carry over. |
| Work log | Work log / Log work | Time log | Mapping MappingRecorded time spent on an item. MigrationWorklogs import into Plane time tracking (Pro). |
| Request intake (JSM) | Request type / Customer portal | Plane Desk request types & portal | Mapping MappingHow customers raise and categorise requests. Routine intake is built into Plane; a full customer portal and request catalogue are Plane Desk. MigrationRecreate request types in Plane intake, or in Plane Desk where a full portal is needed. |
| Service queues & SLAs (JSM) | Queue / SLA / Agent | Plane Desk queues, SLAs & agents | Mapping MappingAgent-facing work organisation and service targets. MigrationMap JSM queues, SLAs and agent roles onto Plane Desk. |
| Commit linking | Smart Commits | Git commit linking | Mapping MappingReferencing and transitioning work items from commit messages. MigrationUse Plane’s Git integration to link and move work items from commits. |
| Project type | Team-managed vs Company-managed | One project model (no split) | Plane advantage MappingJira splits projects into team-managed and company-managed, each with a different configuration model. Plane has one model, so there is no team- vs company-managed decision to make or migrate between. MigrationCollapse both Jira project types onto Plane’s single project model. |
| Goals / OKRs | Goals / Atlas / Atlassian Projects (Home) | Initiatives & dashboards | Mapping MappingCompany goals and status reporting. Atlassian spreads these across Goals, Atlas and Atlassian Projects in Atlassian Home; Plane keeps them as initiatives and dashboards in the same space as the work. MigrationTrack goals as Plane initiatives with dashboard rollups rather than a separate goals product. |
| Reporter / creator | Reporter | Created by | Mapping MappingWho raised the item, distinct from who it is assigned to. MigrationJira reporter maps to Plane created-by; assignee maps to assignee. |
| Priority | Priority (P1–P5 or custom) | Priority | Mapping MappingRelative urgency on a work item. MigrationPriority values map directly; tune the scheme to match. |
| Knowledge base | Knowledge base (Confluence-backed) | Plane Wiki | Mapping MappingSelf-service articles and reference content behind a service desk or team. MigrationHold knowledge-base content in Plane Wiki, linked from Plane Desk where used. |
| Project flavor | Software / Work Management projects (separate templates and setups) | One project model | Plane advantage MappingJira splits work projects into separate flavors, each with its own setup. Plane uses a single project model, so there is no flavor to choose or migrate between. MigrationMap Jira work projects onto Plane’s one project model regardless of their original flavor. |
PQL — the Plane Query Language
Plane’s query language is a quiet but defining capability: one language to find work and to change it. Two things make it matter, for migration and for agents alike — it is a superset of JQL, so nothing already built is lost, and it is deterministic, so what an agent does is exact and reviewable. It sits at the end of the data dictionary because it is how the model above is read and written in practice.
JQL only reads. PQL reads and writes — and every JQL query is already valid PQL. Jira’s Query Language finds work items and hands back a list. Plane’s query language, PQL (say it “prequel”), is a superset: the same syntax teams already know, plus the ability to create, update and relate work — all under the caller’s permissions and captured in the audit trail.
100% backward compatible with JQL. Existing filters, boards and saved searches keep working unchanged after migration. PQL only adds; it takes nothing away.
JQL · Jira
- Read-only search over issues.
- Returns a list to act on by hand.
- No way to change work from the query itself.
PQL · Plane
- A superset of JQL — existing queries still run.
- Reads and writes: select, create, update, relate.
- Runs under the caller’s permissions, recorded in the audit trail.
Deterministic vs probabilistic — the distinction that matters for AI and agents. When an agent acts, two different things happen. The probabilistic step is the AI interpreting natural language: flexible, but it can vary from one run to the next. The deterministic step is PQL executing an exact expression: the same input always produces the same result, and every change is auditable. Plane’s pattern is to let AI interpret the intent, then run it as PQL — natural language at the front, exactness underneath.
Probabilistic · AI interprets
- Reads intent from natural language.
- Forgiving of phrasing; good for drafting.
- May pick slightly different results run to run.
Deterministic · PQL executes
- An exact expression over the WorkLake.
- Same input, same result, every time.
- Auditable and reproducible.
Syntax is illustrative; the current grammar lives in the Plane documentation. Because PQL is a superset of JQL, migrated filters and boards keep working unchanged; PQL runs over the same WorkLake as the REST API and MCP server, and the work it returns or creates is addressable by Work Link (next).
The Work Link — an open, addressable link for any work
Every piece of work in Plane has a stable, open address. The Work Link is small but foundational: it is the open reference that ties documents, commits, agents and external systems back to the live work, and it is the addressing half of the open-formats commitment described in the strategic context.
A Work Link is a stable, open, addressable reference to any object in Plane — a work item, project, cycle, page or initiative. It is part of the open-formats story: a published, portable way to point at work that does not depend on a proprietary deep-link scheme.
Why it matters. Work gets referenced everywhere — in documents, commit messages, tickets in other systems, chat, dashboards and by agents. A Work Link makes those references durable and machine-resolvable: anything holding a Work Link can resolve it back to the live object, with access still governed by the relationship permission graph. It is the addressing layer that lets an open, interoperable estate hang together without lock-in.
Jira reference
- Issue keys and URLs bound to the site / instance.
- Deep links tied to Atlassian’s hosting and product split.
Plane Work Link
- Open, documented, portable reference to any object.
- Resolvable by people, automations, PQL and agents alike.
- Access still enforced by the relationship permission graph.
Together with declared YAML / JSON formats and project-as-code, the Work Link is how Plane keeps data and process inspectable, interoperable and never trapped — the practical meaning of “open” here being open formats, not open-source licensing.
Work-item model & properties
On the structure of a work item the two platforms are at parity, and Plane’s configuration is simpler: one issue-type layer maps types to workflows and properties, rather than Jira’s separate type, workflow, screen and field schemes. Several rows the earlier comparison marked as Plane gaps — time tracking, typed work-item types, native epics and initiatives — have shipped.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Issue-type configuration | Issue type scheme, workflow scheme, screen scheme and field-configuration scheme — four schemes to align per project. | One issue-type layer: each type carries its own workflow, properties and icon. | Plane advantage DispositionA single middle layer is far less to configure and keep consistent than four interacting schemes, with the same expressive result. Why it mattersMap Jira issue types to Plane work-item types; the four schemes collapse into one layer. |
| Unique identifier | Issue Key, e.g. ABC-123, stable for the life of the issue. | Work Item ID with project prefix, e.g. PROJ-123, used in Git integrations. | Parity DispositionBoth provide stable, human-readable keys. Why it mattersPreserve key conventions on import for traceability. |
| Assignees | Single assignee in standard projects; multiple via a team field. | Multiple assignees natively, shown on the card. | Parity DispositionBoth cover single and multi-assignee needs; Plane is marginally richer by default. Why it mattersMap Jira assignee plus watchers to Plane assignees as appropriate. |
| Priority, dates & standard fields | Priority levels, due date (start via custom field), and the standard custom-field palette. | Priority, native start and due dates, and the same standard custom-field types. | Parity DispositionThe common property and custom-field set matches. Why it mattersRecreate field schemas in Plane; most map directly. |
| Typed work-item types | Issue types governed by schemes. | Custom work-item types with per-type properties, workflows and icons (Pro). | Parity DispositionBoth support distinct, configurable types; the earlier comparison marking this a Plane gap is out of date. Why it mattersMap Jira issue types to Plane work-item types with their own properties. |
| Dependencies & links | Issue links with typed relationships across projects. | Blocking and blocked-by links plus parent/child relations. | Parity DispositionBoth express dependencies sufficiently for planning. Why it mattersMap Jira link types onto Plane relations on import. |
| Time tracking | Native time tracking and reports. | Native time tracking per work item with reports (Pro). | Parity DispositionTime tracking is now native in both; the earlier comparison is out of date here. Why it mattersEnable Plane time tracking on Pro; export to existing reporting where required. |
| Native epics & initiatives | Native epics; initiatives via Advanced Roadmaps (Premium). | Native epics and native initiatives as a strategic layer above projects (Pro). | Parity DispositionBoth provide first-class epics and a portfolio layer; Plane includes initiatives at a lower tier. Why it mattersImport epics as epics and roadmap structures as initiatives, preserving hierarchy. |
| Formula & rollup fields | Not native — requires a Marketplace app. | Native formula and roll-up fields, plus native epic and initiative progress rollups. | Parity DispositionBoth can compute and roll up values; Plane does it natively where Jira needs a paid app. Why it mattersRecreate calculated and rollup fields natively in Plane — no Marketplace app. |
| Recurring work items | Via automation rules. | Native recurring work items (Business). | Parity DispositionBoth can generate recurring work. Why it mattersRecreate recurring schedules natively in Plane Business. |
Views & visualisation
The core views match, and Plane treats a board as a view rather than a configured object — one less thing to administer. Spreadsheet and calendar views are native Plane advantages; the one view type still on the roadmap is the whiteboard, with an interim path.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| List & board views | List and board views; a board is a configured object with its own filters and column mapping. | List and board views; the board is rendered directly from a project or cycle’s states — no board object to configure. | Plane advantage DispositionRemoving board administration means no separate board config to maintain, while the day-to-day board experience is equivalent. Why it mattersRecreate Jira boards as Plane views; drop the board-configuration overhead. |
| Timeline / Gantt | Timeline on the Premium tier. | Timeline view, not gated behind the top tier. | Parity DispositionBoth provide a timeline; Plane does not reserve it for the highest tier. Why it mattersUse the Plane timeline for scheduling without a premium upgrade. |
| Spreadsheet view | Not native. | Spreadsheet view for bulk editing. | Plane advantage DispositionA built-in spreadsheet view speeds bulk edits without an add-on. Why it mattersUse the Plane spreadsheet view for bulk updates. |
| Calendar view | Not native — requires a Marketplace app. | Native calendar view. | Plane advantage DispositionPlane ships a calendar view natively; Jira needs a Marketplace app for one. Why it mattersUse Plane’s calendar view directly — no add-on required. |
| Workload / capacity | Not native — requires Advanced Roadmaps. | Via advanced dashboard widgets, with velocity and cycle widgets (Business). | Parity DispositionBoth deliver workload insight only at a higher capability tier. Why it mattersBuild capacity views from Plane dashboard widgets on Business. |
| Dashboards & analytics | Dashboards with 20+ gadgets. | Dashboards and analytics with configurable widgets, including from a prompt. | Parity DispositionBoth provide configurable dashboards sufficient for reporting. Why it mattersRecreate key Jira gadgets as Plane widgets. |
| Forms / intake | Jira Forms. | Intake forms, including from email. | Parity DispositionBoth capture structured intake. Why it mattersReplace Jira Forms with Plane intake. |
| Whiteboard | Via Confluence whiteboards. | No native whiteboard today; planned. | Roadmap · Q4 2026 PlanA native whiteboard surface is on the roadmap; meanwhile a dedicated tool integrates alongside Plane. TodayEmbed or integrate a whiteboard tool alongside Plane where needed. |
Agile, cycles & backlog
Agile execution is at parity. Plane’s cycles carry incomplete work forward automatically, so a team keeps its momentum across iterations without manual cleanup at each boundary. The two small surfaces Jira has that Plane does not — a dedicated sprint-goal field and a built-in retrospective — are on the roadmap with simple interim paths.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Native iterations | Sprints (Scrum). | Cycles, with automatic carryover of incomplete work. | Plane advantage DispositionEquivalent iterations, and Plane rolls incomplete items forward automatically rather than by hand. Why it mattersMap sprints to cycles; drop the manual carryover step. |
| Iteration planning & backlog | Sprint planning and a product backlog with refinement. | Cycle planning and a backlog with intake triage. | Parity DispositionEquivalent planning and grooming workflows. Why it mattersCarry backlog items across on import. |
| Velocity, burndown & burnup | Velocity, burndown and burnup reports. | Velocity, burndown and burnup charts. | Parity DispositionComparable delivery measurement. Why it mattersRecreate sprint charts as cycle charts. |
| Iteration report | Sprint report. | Cycle report and insights. | Parity DispositionBoth summarise planned versus completed work. Why it mattersUse Plane cycle insights for review. |
| Estimation | Story points, configurable scales. | Estimate points, configurable scales. | Parity DispositionEquivalent estimation models. Why it mattersMap point scales one-to-one. |
| Iteration goal | Dedicated sprint-goal field. | Cycle goal field is on the roadmap. | Roadmap · Q3 2026 PlanA structured goal field is planned; today the cycle description holds the goal. TodayRecord the cycle goal in the cycle description in Plane. |
| Retrospective | Via Confluence templates. | Built-in retrospective surface is on the roadmap. | Roadmap · Q4 2026 PlanA native retro surface is planned; today a Plane Page or external tool serves the same purpose. TodayRun retros in a Plane Page or external tool for now. |
Reporting & analytics
The core agile and delivery reports match, including cumulative flow, cycle time and specialised named reports. The two reporting features still on the roadmap — scheduled delivery and native PDF/Excel export — have a simple interim path today: the API into the institution’s own BI stack.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Custom dashboards | Dashboards with a broad gadget library. | Dashboards with configurable widgets. | Parity DispositionBoth deliver configurable reporting dashboards. Why it mattersRecreate priority dashboards as Plane widgets. |
| Core agile reports | Burndown, burnup, velocity, cumulative flow, cycle time. | Burndown, burnup, velocity, cumulative flow, cycle time. | Parity DispositionThe standard agile report set is present in both. Why it mattersMap existing agile reports to Plane equivalents. |
| Real-time updates | Yes. | Yes. | Parity DispositionBoth update reporting in real time. Why it mattersNo action required. |
| Scheduled / emailed reports | Scheduled and emailed report delivery. | Scheduled report delivery is on the roadmap. | Roadmap · Q3 2026 PlanScheduled delivery is planned; today the BI tool delivers on a schedule from Plane data. TodaySchedule delivery from the institution’s BI tool, fed by the Plane API. |
| Export to PDF / Excel | Native PDF and Excel export. | CSV export and API today; native PDF/Excel on the roadmap. | Roadmap · Q3 2026 PlanFormatted PDF/Excel export is planned; today CSV and the API feed Excel and BI, and dashboards print to PDF. TodayExport CSV or pull the API into Excel and BI; print dashboards to PDF from the browser. |
| Cross-project data | Cross-project reporting. | Workspace-wide reporting. | Parity DispositionBoth aggregate across projects. Why it mattersBuild cross-project rollups in Plane dashboards. |
| Specialised named reports | Control chart, lead time, release burndown and version reports. | Specialised named reports, alongside configurable dashboards and the API. | Parity DispositionBoth ship named, purpose-built reports; anything bespoke is reproduced via dashboards or the API into BI. Why it mattersMap required Jira reports onto Plane’s named reports and dashboards. |
| BI integration | Via API and exports. | Via API and CSV into the existing BI stack. | Parity DispositionBoth feed external BI; the warehouse becomes the reporting system of record either way. Why it mattersStream Plane data into the existing data platform for enterprise reporting. |
Integrations & extensibility
The developer integrations most teams use daily are at parity — including Microsoft Teams, Bitbucket and CI/CD — and Plane’s extension model (a full API, webhooks and a native MCP server) is more modern and less locked than a proprietary app platform. As AI and applets reshape how work and knowledge are built, the partner ecosystem is growing on MCP rather than on traditional UI plugins.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Git (GitHub / GitLab) | Two-way integration. | Two-way integration. | Parity DispositionBoth integrate bidirectionally with the major Git hosts. Why it mattersConnect existing Git workflows to Plane. |
| Slack | Deep integration. | Native integration (and native Discord). | Parity DispositionBoth integrate richly with Slack; Plane also ships native Discord. Why it mattersConnect Slack to Plane natively. |
| Microsoft Teams | Native integration. | Native Microsoft Teams integration. | Parity DispositionBoth integrate natively with Microsoft Teams. Why it mattersConnect Teams to Plane natively. |
| Bitbucket | Native integration. | Native Bitbucket integration. | Parity DispositionBoth integrate natively with Bitbucket, alongside GitHub and GitLab. Why it mattersConnect Bitbucket to Plane natively. |
| CI/CD connectors | Jenkins, CircleCI and others via Marketplace. | CI/CD connectors, with webhooks and the API for any pipeline. | Parity DispositionBoth connect to CI/CD; Plane covers the common pipelines and wires the rest through events and the API. Why it mattersConnect existing pipelines to Plane via the connectors, webhooks or the API. |
| Error tracking (Sentry) | Native integration. | Native integration. | Parity DispositionBoth integrate with Sentry natively. Why it mattersConnect Sentry to Plane directly. |
| REST API | Yes. | Yes — on all tiers. | Parity DispositionBoth expose a full REST API. Why it mattersBuild integrations against the Plane API. |
| Webhooks & OAuth 2.0 | Yes. | Yes. | Parity DispositionBoth support webhooks and OAuth 2.0. Why it mattersReuse existing OAuth and webhook patterns with Plane. |
| MCP server | No native MCP server. | Native MCP server exposing the full API as tools. | Plane advantage DispositionNative MCP lets approved AI clients act on work data under existing permissions, on an open standard — something Jira has no native equivalent for. Why it mattersConnect Claude, Cursor or any MCP client to Plane in place of custom glue. |
| Extensibility model | Forge and Connect app platforms; many gaps closed by paid Marketplace apps. | Full REST API, webhooks and a native MCP server. | Plane advantage DispositionExtending through a documented API and an open agent protocol is cleaner and less locked than a proprietary app platform plus paid apps — and it lets agents act on the workspace directly. Why it mattersExtend Plane via the API, MCP or an iPaaS; point agents at the workspace through MCP. |
| Partner app ecosystem | Largest in the category — 2,000+ apps, many closing native gaps. | A growing partner ecosystem on the MCP server, plus native breadth. | Parity DispositionJira’s marketplace is the larger legacy catalogue; Plane’s ecosystem is expanding on MCP, and as AI and applets reshape the UI, far fewer traditional plugins are needed in the first place. Why it mattersReach partners and tools through the MCP server and API; build the rest natively or with AI. |
Documentation & knowledge — Plane Wiki
Documentation in Plane is its own product, Plane Wiki, built into the same platform; in Jira it is a separate, separately-licensed product (Confluence). Plane Wiki stores documents as a structured JSON model rather than HTML — cleaner to migrate, automate and operate on with AI — and ships Mermaid diagrams and rich embeds natively. The disposition is Plane advantage on consolidation, the document model and in-perimeter AI.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| Built-in documentation | None in Jira — requires Confluence. | Plane Wiki is built into the platform. | Plane advantage DispositionDocumentation is near-universal; Plane meets it with Plane Wiki, on the same instance, not a second licensed product. Why it mattersUse Plane Wiki instead of licensing Confluence. |
| Document model | HTML-based storage (Confluence). | Structured JSON document model. | Plane advantage DispositionA structured JSON model is clean, portable and programmable — it migrates without lossy HTML round-trips and lets AI and the API read and write content reliably. Why it mattersAuthor in Plane Wiki; treat documents as structured data for automation and AI. |
| Rich text & collaboration | Rich text, real-time collaboration and version history via Confluence. | Rich text and markdown, real-time collaboration and version history. | Parity DispositionComparable editing, co-authoring and history once documentation exists in each. Why it mattersCollaborate and version in Plane Wiki directly. |
| Page nesting & templates | Via Confluence. | Nested pages and templates. | Parity DispositionBoth organise long-form content hierarchically. Why it mattersRecreate Confluence structure in Plane Wiki. |
| AI writing assistance | Via Confluence / Rovo in the cloud. | Write and refine wiki content with AI, in-perimeter. | Plane advantage DispositionPlane brings AI authoring inside the boundary, unlike cloud-bound Confluence AI. Why it mattersUse Plane AI to draft and refine Wiki pages without data leaving the network. |
| Public sharing & export | Via Confluence. | Public sharing and Markdown export. | Parity DispositionBoth publish and export documentation. Why it mattersPublish or export from Plane Wiki as needed. |
| Diagrams & embeds | Via Confluence (diagrams and Smart Links). | Native Mermaid diagrams and rich embeds in Plane Wiki. | Parity DispositionBoth render inline diagrams and embedded content; Plane Wiki does it natively, in-perimeter. Why it mattersAuthor Mermaid diagrams and embeds directly in Plane Wiki. |
Mobile & client applications
Mobile is at parity and well rated, and Plane ships a native desktop application where Jira is browser-only. The two small items still on the roadmap are offline mode and a browser extension.
| Capability | Atlassian Jira | Plane | Disposition |
|---|---|---|---|
| iOS & Android apps | Native apps for both platforms. | Native apps for both platforms. | Parity DispositionBoth ship maintained mobile apps. Why it mattersDeploy Plane mobile apps through existing MDM. |
| Push notifications & mobile editing | Push notifications and rich mobile editing. | Push notifications and rich mobile editing. | Parity DispositionBoth allow full work-item handling on mobile. Why it mattersNo action required. |
| Desktop application | No native desktop app — browser-based. | Native desktop application, plus an installable PWA. | Plane advantage DispositionPlane ships a native desktop app; Jira is browser-only. Why it mattersUse the Plane desktop app, or the PWA where preferred. |
| Offline mode | Supported. | Offline support is on the roadmap. | Roadmap · Q4 2026 PlanPlanned; relevant only for genuinely disconnected use, where the PWA caches today. TodayRely on the responsive web and mobile apps online; cache via the PWA where helpful. |
| Browser extension | Available. | Browser extension is on the roadmap. | Roadmap · Q4 2026 PlanPlanned; a convenience rather than a core requirement. TodayUse the Plane web app or a bookmarklet for quick capture for now. |
| Mobile app rating | Well rated on the app stores. | Highly rated on the app stores. | Parity DispositionBoth ship well-reviewed mobile apps; Plane’s reviews are consistently strong. Informational only. Why it mattersTreat as context, not a deciding factor. |
Distinctive capabilities
The two columns that summarise the matrix: what Plane already does that Jira cannot, and the dated roadmap that closes the remaining gaps. Read together, they show a platform ahead on the capabilities that decide a regulated review, and closing the rest on a known timeline.
Where Plane is ahead today
- One coherent, steerable space — people and agents work the same items under one permission model, in-perimeter, with every action audited; Jira’s AI runs outside the boundary on a fragmented estate.
- Custom agents & native MCP — assign, @mention and define agents, with the full API exposed as tools for any MCP client on an open standard Jira has no native equivalent for.
- Durable self-hosting — free, full-featured, and with no end-of-life, while Jira Data Center reaches read-only support in March 2029.
- Air-gapped with full AI — the complete AI feature set runs inside the gap; Rovo cannot run without syncing data to Atlassian Cloud.
- Bring-your-own model — OpenAI, Anthropic, Bedrock, a local model via Ollama, or any OpenAI-compatible endpoint, with no keys, prompts or responses stored.
- One permission graph — a Zanzibar-style relationship model in place of Jira’s stack of permission, notification and screen schemes.
- A smaller, sharper model — no board object, one issue-type layer instead of six configuration schemes; less to administer, nothing to unlearn.
- Native views & fields Jira needs apps for — calendar and spreadsheet views, plus native formula and roll-up fields.
- Native desktop application — macOS, Windows and Linux, alongside the mobile apps and an installable PWA, where Jira is browser-only.
- Specialised reports & dashboards from a prompt — named delivery reports plus dashboards generated from natural language.
- Microsoft Teams, Bitbucket & CI/CD — the developer and collaboration integrations teams use daily are shipped and native.
- Structured JSON document model — Pages store clean structured content, not HTML, with in-perimeter AI authoring, so docs migrate, automate and work with AI reliably.
- Consolidated by default, 100% parity — docs, intake and SSO built in, not licensed as Confluence, JSM and Guard; identical capability self-hosted or on cloud.
On the Plane roadmap
- Per-item access controlQ3 2026 — item-level restriction on the same relationship graph.
- Field-level visibilityQ3 2026 — field-level rules extending the one permission model.
- Automation libraryQ3 2026 — an expanded gallery of prebuilt rules over native automation.
- Cycle goal fieldQ3 2026 — a structured iteration-goal field.
- Scheduled reports & PDF/Excel exportQ3 2026 — scheduled delivery and formatted export.
- Built-in retrospectiveQ4 2026 — a native retro surface.
- WhiteboardQ4 2026 — a native freeform canvas.
- Offline mode & browser extensionQ4 2026 — disconnected use and quick capture.
What Plane eliminates
A consolidated view of the bloat Plane removes — the concepts an administrator no longer sets up, the many-to-one simplifications, and the separate products and add-ons that become native. It is meant to be extended; add rows as the model proves out. Service management is deliberately not here: it is a like-for-like separate product, Plane Desk, not eliminated bloat.
| Jira concept | What it adds in Jira | What Plane does instead | Kind |
|---|---|---|---|
| The board object | Scrum and Kanban boards are configured entities, each with its own filters, columns and swimlanes to set up and maintain per project. | A board is just a view of a project or cycle, rendered from its states. There is nothing to configure. | Eliminated |
| Configuration schemes | Up to six interacting schemes per project — workflow, issue-type, screen, field-configuration, notification and permission — plus issue-security. | One relationship permission graph; each work-item type carries its own workflow and properties. No scheme stack. | Collapsed |
| Team- vs company-managed split | Two different project models with different capabilities and admin paths that teams must choose between and keep aligned. | One project model for everyone. No split to learn or reconcile. | Collapsed |
| The Resolution field | A separate resolution value layered on top of status — a frequent source of mis-set or empty resolutions and broken reports. | Completion is the state category (Completed / Cancelled). One thing to set, not two. | Eliminated |
| Screen & field-configuration schemes | Screens, screen schemes and field configurations decide which fields appear where, configured and mapped per issue type. | Fields are properties on the work-item type. What you define is what you see. | Collapsed |
| Issue-type & sub-task type schemes | Issue-type schemes and separate sub-task issue types, assigned per project. | One issue-type layer; sub-issues are simply nested work items. | Collapsed |
| Roles, groups & permission schemes | Project roles, global groups and permission schemes interact to decide who can do what — powerful, but hard to reason about and audit. | A single Zanzibar-style relationship graph expresses access directly and consistently. | Collapsed |
| User-count pricing bands | Crossing a user-count band can step the whole contract up by 15–25% at once. | Linear per-seat pricing. Cost scales predictably with headcount. | Collapsed |
| Confluence as a separate product | Documentation is a separate, separately-licensed product to buy, run and integrate. | Plane Wiki is built into the platform on the same model, with native Mermaid diagrams and embeds. | Native |
| Atlassian Guard for SSO | Enterprise SSO and provisioning at scale are metered through a separate add-on. | SAML / OIDC SSO is included with self-hosted Pro. | Native |
| Jira Align for scaling | Portfolio, program and solution planning live in a separate, separately-licensed product on its own timeline. | Initiatives and teamspaces handle scaled planning natively, in the same space as the work. | Native |
| Advanced Roadmaps add-on | Cross-project timeline planning is gated behind the Premium tier as a packaged add-on. | Timeline and initiative planning are native, not reserved for the top tier. | Native |
| Marketplace apps for the basics | Calendar, formula / roll-up fields and time tracking commonly require paid Marketplace apps, each a recurring per-user cost. | All native in Plane — no add-on, no extra line item. | Native |
Selection guidance & recommendation
A decision aid, then the recommendation. The split is honest: what makes Plane the right choice today, and the short list of roadmap-dependent capabilities whose timing an evaluator should confirm against the stated quarters.
Plane fits today when you need…
- One control plane for the organisation — work, structure and operating efficiency in one place, with data co-located.
- One coherent space for people and agents — steerable, in-perimeter and audited.
- Durable self-hosting on-premise or air-gapped, without a 2029 deadline.
- AI inside the perimeter, with your own model and no data leaving the boundary.
- A coherent permission model — one relationship graph, not a scheme stack.
- A smaller model to administer — no boards, one issue-type layer.
- Lower total cost through consolidation, with docs, intake, SSO and AI included.
Confirm timing if you depend on…
- Per-item or field-level access control as a hard day-one requirement Q3 2026.
- A deep prebuilt automation library rather than building rules Q3 2026.
- Scheduled or formatted PDF/Excel reporting from the tool itself Q3 2026.
- A native whiteboard with no interim path Q4 2026.
Adopt Plane as one control plane. The recommendation is to run the organisation’s work, its structure and its operating efficiency on a single platform, with the data in one place. On the criteria that decide an enterprise, self-managed review — durable self-hosting, AI and agents inside the perimeter, a coherent permission model and consolidated total cost — Plane is ahead today, on a deliberately smaller model that is easier to run and to teach. Most importantly, it is one coherent space an enterprise can point agents at and steer, which is where the real acceleration of the next few years will come from — and which a cloud-only, multi-product estate cannot match.
Where Jira currently leads, the difference is timing rather than direction: each item is on a dated Plane roadmap for Q3–Q4 2026 with a usable interim path given in its row. There is no capability in this document for which the recommendation is to remain on Jira — particularly given Data Center’s read-only end-of-support in March 2029.
Suggested next step: a scoped proof of concept — run the native Jira importer on a representative project, validate sovereignty and in-perimeter AI inside the institution’s own environment, and confirm any roadmap-dependent requirement against the stated quarters before committing. Roadmap dates are forward-looking targets; the interim paths make Plane usable today regardless.
Sources & notes
Sources behind the comparison, and the method used to keep it accurate.
- Atlassian — Data Center end-of-support policy and migration timeline (16 Dec 2025; 30 Mar 2026; 30 Mar 2028; 28 Mar 2029), with the Atlassian Ascend programme guiding Data Center customers to Cloud.
- Atlassian — Jira Cloud terminology change renaming “Projects” to “Spaces” (2025; following “Issues” to “Work items”), a label change only, applied to Jira Cloud and not Data Center.
- Atlassian — Rovo and Atlassian Intelligence: AI features run in Atlassian Cloud; Data Center must sync data into Cloud through connectors to use them.
- Independent analysis — the ~15% Data Center price increase effective February 2026, and Isolated Cloud (expected 2026) as an internet-connected, Atlassian-managed offering that does not address SCIF, classified or true air-gapped requirements.
- Atlassian — Jira, Confluence, Jira Service Management and Guard pricing and packaging; Jira Align follows its own separate end-of-life timeline.
- Atlassian — Jira Service Management ITSM model: request types, customer portal, queues, SLAs, and the incident, problem and change work categories.
- Plane — product documentation and pricing at plane.so (deployment, self-hosting and air-gapped support, SSO, RBAC, AI and bring-your-own-model, agents, MCP server and PQL, importers, Plane Projects, Plane Wiki and Plane Desk, calendar and spreadsheet views, formula and roll-up fields, native desktop app, marketplace listings).
- Independent market and total-cost-of-ownership data for Jira contracts and Marketplace add-on adoption.
Comparative statements reflect public product information current as of the date shown. Plane capabilities scored as parity or advantage here — including native time tracking, typed work-item types, native epics and initiatives, native calendar and spreadsheet views, native formula and roll-up fields, specialised named reports, Microsoft Teams, Bitbucket and CI/CD integrations, native Mermaid diagrams and embeds in Plane Wiki, a native desktop application, and Plane Desk as a separately licensed service-management product — reflect the current product. Architectural facts noted here — the Zanzibar-style relationship-based permission model, the single issue-type configuration layer, multiple workspaces per instance, the absence of a separate board object, the structured JSON document model, the Work Link, and the Plane Query Language (PQL) — reflect Plane’s current design and direction. Items marked Roadmap with a quarter (per-item and field-level access control, an expanded automation library, scheduled and formatted reporting, a built-in retrospective, a whiteboard, and offline / browser-extension support) are forward-looking targets for the named quarter of 2026, not contractual commitments; a usable interim path is given in each case. Verify current details against vendor documentation before contractual decisions.