The Plane Self-Hosting Guide

Plane is a work management platform that combines projects and work items, a workspace wiki, intake, workflows, approvals, automation, analytics, and AI in one product. It runs as a managed cloud service, a connected self-hosted deployment, or a fully disconnected air-gapped deployment.

This guide is about running Plane yourself, and running it well.

It covers the full lifecycle of a self-hosted Plane deployment: product fit, architecture, deployment models, high availability, day-two operations, air-gapped supply chains, identity, network and AI boundaries, compliance, and economics.

Some readers will arrive here from Jira Data Center, which is reaching end of life. Part 04 is written for them: the transition timeline, an honest parity assessment, and a complete migration program. The rest of the guide stands on its own: it describes how to run Plane on your infrastructure, whatever you run today.

The guide makes four claims.

• Self-hosting is a product requirement, not a packaging option. The Commercial Edition is designed to run on customer infrastructure with the same product model as Plane Cloud, and the Airgapped Edition runs with no runtime egress at all.
• The architecture is conventional enough to operate. Plane runs on containers, PostgreSQL, Redis or Valkey, RabbitMQ, S3-compatible object storage, and optional OpenSearch. Enterprise platform teams already know every one of these components.
• The platform is complete. Projects, work items, portfolio planning, documentation, intake, approvals, automation, analytics, and extensibility live in one system, under one identity and governance model.
• The economics rest on control and consolidation. A self-hosted buyer pays for the product and owns the infrastructure and operations. The case is control, tool consolidation, and predictable architecture, not a claim that servers cost nothing.

The rest of this document is the evidence for those claims, and the working plan for acting on them.

How to use this guide

Before deploying production infrastructure, prove three things: Plane fits the organization’s non-negotiable deployment boundary, the correct edition and plan are commercially understood, and the product covers the work patterns that matter.

Define the deployment control boundary

“Self-hosted” and “air-gapped” are not synonyms.

Plane supports both. The distinction belongs in the architecture decision record.

On connected self-hosted Plane, license and seat synchronization are the only required outbound calls. Telemetry can be disabled from instance administration. Integrations, email, and AI can add network paths, depending on how you configure them.

On Plane Airgapped, application services, backing services, licensing, and integrations operate without public-internet connectivity. Images and charts are staged into an internal registry. License activation uses a file. Internal GitHub Enterprise or GitLab endpoints stay inside the isolated network.

This produces a simple decision.

• If tightly governed outbound access is acceptable, use Commercial Edition.
• If the approved outbound allowlist must be empty, use Airgapped Edition.

Do not leave this choice until procurement. It changes licensing, artifact movement, updates, AI configuration, integration design, and operational runbooks.

Select the edition and commercial plan

The Community Edition is AGPL-3.0, which lets security and engineering teams inspect the open-source core. The Commercial and Airgapped editions add the licensed product, governance features, and support model used for enterprise production.

Public annual pricing lists four plans: Free at $0 for up to 12 users, Pro at $6 per seat per month, Business at $13 per seat per month, and Enterprise Grid by quote.

Self-hosting should not be justified as “free infrastructure.” A self-hosted buyer pays for Plane and also owns the infrastructure and the operating work. The business case is stronger when it rests on control, consolidation, and predictable architecture, not on a claim that servers cost nothing.

An enterprise work platform is not “issues plus a board.”

An evaluation should cover the full operating footprint an organization runs on it.

The product is progressively complex. Teams start with work items and states, then enable cycles, modules, initiatives, workflows, approvals, automation, and governance when those controls are needed.

That matters at enterprise scale. Complexity should arrive when a team asks for it, not before the team creates its first work item.

Define proof criteria before deploying

A credible evaluation is run against your own work, not against a feature checklist.

Before committing to production, do four things:

• Name the top 20 workflows the organization cannot operate without, and the outcome each one must produce.
• Define acceptance criteria per workflow: who acts, what is enforced, what is reported, what is audited.
• Run those workflows end to end in a pilot workspace with real teams and real work.
• Record every gap with an owner and a decision: reproduce, redesign, or retire.

Gaps found this way are not a concession. They are the difference between a platform decision and a demo impression.

Plane is a multi-service application with stateless application workloads and stateful backing services. The stack is built from familiar infrastructure rather than a proprietary runtime.

That one sentence carries most of the operational argument. Your platform team will not learn a new database, a new queue, or a new deployment model to run Plane.

The principal services

The backing services

• PostgreSQL is the primary transactional store
• Redis or Valkey provides caching, sessions, and real-time state
• RabbitMQ queues asynchronous work
• MinIO or S3-compatible storage holds attachments and exports
• OpenSearch enables advanced and semantic search

For an evaluation, Plane can deploy these dependencies locally.

For production, the documentation recommends external database and object-storage services. For high availability, every stateful service should be replaced by a replicated or managed equivalent.

Plane publishes multiple installation methods, including Docker Compose, Kubernetes with Helm, Docker Swarm, an all-in-one container for evaluation, Podman Quadlets, managed platforms, and an AWS Marketplace path.

Use the method that matches the stage.

For Docker deployments, plan for at least 4 CPU cores and 16 GB of RAM across all required services. Treat this minimum footprint as a starting point for evaluation, not a production sizing promise.

Production sizing should be driven by your real workload: active and peak concurrent users, work-item and activity-history volume, attachment size and retention, import and automation throughput, real-time collaboration load, search index size, AI indexing and inference behavior, and your availability, RPO, and RTO targets.

The documented Kubernetes high-availability model is single-region, multi-availability-zone. It is designed to survive a node or availability-zone failure. It is not an active-active multi-region architecture.

That sentence should appear in every production design review.

The workload model has three tiers.

A strong reference topology includes:

• Worker nodes across at least 3 availability zones for quorum-based services
• A cross-zone load balancer with redundant ingress controllers
• Anti-affinity rules so replicas never share one node
• Managed multi-AZ PostgreSQL with automated failover, and Redis or Valkey with replica failover
• RabbitMQ quorum queues across at least 3 nodes
• OpenSearch master and data nodes distributed across zones, plus multi-AZ object storage
• PodDisruptionBudgets for stateless workloads and HorizontalPodAutoscalers for user-facing and worker services

The current high-availability guide notes that native rendering of topology-spread constraints, PodDisruptionBudgets, and HorizontalPodAutoscalers is still planned. Operators apply those controls separately today.

Plan for that in the production design. Helm support does not remove the platform team’s responsibility to finish it.

For Docker installations created with the Prime CLI, the CLI handles the common lifecycle tasks: start, stop, restart, configuration, health checks, repair, upgrades, backups, and restores.

For Kubernetes, pin explicit image and chart versions. Promote releases through development, staging, and production instead of following a floating tag.

The minimum operating model has four parts.

Service health and traffic management

Commercial Edition exposes separate liveness, readiness, and detailed health endpoints. Liveness tests the process. Readiness verifies critical dependencies. Detailed health returns diagnostic state.

Data protection and recovery

Prime CLI can create and restore Docker backups, and the documentation calls out backing up the environment file separately. Kubernetes deployments should back up each durable layer according to the organization’s database, object-storage, search, and secrets standards.

A backup is not complete until a restore has been tested. Define and rehearse:

• PostgreSQL point-in-time recovery
• Object-store versioning and retention
• Redis or Valkey recovery expectations
• RabbitMQ durability and queue recreation
• OpenSearch index rebuild or snapshot recovery
• Encryption-key, secret, configuration, and license recovery
• Restore into an isolated environment, with measured RPO and RTO

Observability and operational telemetry

Collect, retain, and alert on four layers of signal.

• Traffic: ingress latency and error rate, API saturation and tail latency, WebSocket connection health
• State: database connection, query, replication, and storage health; cache hit rate and memory pressure; object-store errors; search cluster health and indexing lag
• Work: RabbitMQ queue depth and consumer lag; worker failures and retry volume; import, webhook, automation, and AI job failures
• Licensing: license synchronization and entitlement state

Release and change management

Every Plane release should pass the same gate:

1. 01Release-note and schema-change review
2. 02Vulnerability and artifact review
3. 03Backup verification
4. 04Staging upgrade with application smoke tests
5. 05Identity and permission tests
6. 06Representative workflow and automation tests
7. 07Rollback decision and documented recovery path
8. 08Production deployment during an approved window
9. 09Post-deployment validation

An air gap is not just a firewall rule.

It is a controlled process for moving software, licenses, updates, and evidence across a trust boundary.

The Airgapped Edition supports Docker and Kubernetes. The documented model uses pre-packaged images, an internal registry, offline license files, internal certificate authorities, and internal integrations. Once artifacts are staged, Plane runs without external APIs, CDNs, telemetry, or license calls.

The operating runbook should define:

• Who can retrieve a Plane release, and which signatures and hashes must be verified
• How images and charts are scanned before transfer
• How the internal registry is populated
• How the offline license file is approved and stored
• How internal CA certificates are distributed
• How emergency security updates cross the boundary
• How rollbacks preserve data compatibility
• How an auditor can reconstruct the artifact chain of custody

Do not describe this as “connected build, disconnected run forever.” Air-gapped environments still need controlled updates.

The more accurate principle:

The security advantage of self-hosting is control. The security cost of self-hosting is responsibility.

Plane supplies application controls. The customer remains responsible for the infrastructure, configuration, keys, monitoring, backups, and operational evidence around them.

Everything in this part follows from that split.

Identity and access management

Plane supports SAML and OIDC for single sign-on. Enterprise Grid adds LDAP, SCIM, IdP group synchronization, custom roles, granular access control, and API-enabled audit logs.

The access model spans two layers.

• Workspace roles control what a person can do across a workspace.
• Project roles control what that person can do inside a specific project.

Those roles are independent. A user can be a workspace Member and a project Admin. Enterprise permission schemes package reusable permissions into custom roles, which makes access design easier to review and audit.

An enterprise rollout should define, at minimum:

• The authoritative identity source, with provisioning and deprovisioning paths
• Group-to-role mappings and workspace and project ownership rules
• Break-glass instance administrators and a service-account policy
• Guest and external-collaborator boundaries
• API-key creation, rotation, and expiry
• Periodic access review, with separation of duties for configuration, licensing, and audit

Use an explicit egress register. Every destination gets an owner.

Plane documents the telemetry it collects from connected self-hosted instances: instance metadata, usage counts, interaction events, performance information, and the instance administrator’s contact details. It also documents how to disable telemetry.

That is materially different from zero egress. Say which posture you are adopting.

Plane AI supports natural-language chat, duplicate detection, and search across work items, pages, projects, and cycles. Self-hosted Plane can connect to OpenAI, Anthropic, AWS Bedrock, Ollama, Groq, LiteLLM, or another OpenAI-compatible endpoint.

The architecture includes a dedicated Plane AI database, read access to the primary Plane database, OpenSearch for indexed and semantic retrieval, and one or more configured model endpoints.

The model endpoint determines the data boundary.

If Plane calls a public OpenAI or Anthropic API, relevant prompts and context leave your network under that provider’s contract and controls. If Plane calls a private Bedrock, Azure OpenAI, LiteLLM, or local Ollama endpoint inside your approved boundary, the traffic follows that private architecture.

Therefore:

For a zero-egress AI posture, use an internal model endpoint and mirror every required model and embedding dependency into the environment.

Plane’s public security material states SOC 2 Type II and ISO 27001:2022 compliance and describes GDPR, CCPA, and HIPAA support. It also states AES-256 encryption at rest and TLS 1.3 in transit.

Those are useful procurement inputs. They are not a substitute for a system-level control assessment.

For self-hosted Plane, validate how each control is implemented in your environment.

This is the level a security review should work at: specific controls, clear ownership, testable evidence.

This part is for organizations that run Jira Data Center today. It covers the transition constraint, an honest parity assessment, and a complete migration program.

Atlassian has announced the end of life of the affected Data Center products. New Data Center sales ended on 30 March 2026. Existing customers can continue buying expansions and renewals until 30 March 2028. On 28 March 2029, affected Data Center subscriptions and associated Marketplace apps are scheduled to expire and become read-only.

The affected portfolio includes Jira Software, Jira Service Management, Confluence, Bamboo, and Crowd. Bitbucket Data Center is treated differently through Atlassian’s hybrid-license path. Atlassian also says that multi-year extensions beyond March 2029 may be available to some customers by exception.

Those details matter. They turn a broad market announcement into a concrete planning constraint.

Behind the timeline sits the real question:

For many organizations, Atlassian Cloud is the natural destination.

For others, it is not an acceptable destination at all.

That second group includes organizations with one or more hard constraints:

• Regulated or classified data must remain inside a controlled network.
• Data residency must be tied to a specific jurisdiction or facility.
• The application must keep operating without public-internet access.
• Security teams must control keys, network paths, logs, backups, and change windows.
• Internal Git, identity, observability, and AI systems must remain private.
• Platform continuity cannot depend on a vendor’s hosted control plane.

These are not preferences. They are architecture requirements.

Plane belongs on that shortlist because it treats deployment choice as part of the product, not as a packaging tier.

The evaluation asks two separate questions.

• Fidelity. Can Plane preserve the data, controls, and outcomes the organization depends on?
• Simplification. Can Plane deliver those outcomes with a more coherent product and operating model?

Parts 02 and 03 answer the simplification question: the platform and the controls you land on. The rest of this part answers the fidelity question, starting with parity in section 4.2 and ending with a data integrity contract in section 4.6.

Evaluate Plane as a successor to Jira Data Center, not as a pixel-for-pixel clone.

A clone would preserve the same screens, schemes, administrative sprawl, and app dependency tree that many enterprises want to leave behind. A successor keeps the control that made Data Center the default choice in demanding environments, and sheds that accumulated weight.

Core work management maps well: projects, work items, states, sprints to cycles, components to modules, epics, users, comments, attachments, and links all have direct destinations, and section 4.4 covers the importer that moves them. The honest evaluation happens at the edges of the estate.

Platform comparison

Platform comparison of Jira Data Center and Plane Commercial or Airgapped

Dimension	Data Center	Plane
Product horizon	Affected products reach end of life in March 2029, with limited exceptions possible	Actively developed self-hosted product line
Deployment	Customer-managed Data Center	Cloud, connected self-hosted, or fully air-gapped
HA model	Mature clustered deployment	Documented single-region, multi-AZ Kubernetes pattern
Core work model	Deep and highly configurable	Progressive hierarchy from work items to initiatives
Knowledge	Confluence is a separate product	Project Pages and workspace Wiki built in
Service workflows	Jira Service Management is a mature dedicated product	Intake, forms, email, SLAs, workflows, approvals; validate depth
Workflow automation	Native rules plus a large Marketplace ecosystem	Native automation, workflows, approvals, Plane Runner, API, webhooks
Marketplace breadth	Very large and mature	Smaller ecosystem, more built into the core product
Identity and governance	Mature enterprise controls	SAML, OIDC, LDAP, SCIM, custom roles, granular access, audit by plan
AI	Atlassian Cloud direction	Customer-selected model endpoints, local and private models supported
Extensibility	REST APIs and Marketplace apps	180+ REST endpoints, webhooks, apps, native integrations, MCP
Migration	Source system	Native Jira Cloud, Server, and Data Center importer plus migration support

Pressure-test these before declaring parity

A credible evaluation names the areas where a one-to-one replacement is least likely:

• Jira Service Management portals, queues, knowledge linkage, and service-specific reporting
• Marketplace dependencies such as Xray, Zephyr, Tempo, ScriptRunner, Advanced Roadmaps, and Assets
• Change-history fidelity and audit retention requirements
• Custom field types, calculated fields, scripted fields, and field contexts
• JQL filters, subscriptions, dashboards, and saved-search ownership
• Workflow validators, post-functions, conditions, and automation rules
• BI, resource planning, capacity planning, budgeting, and chargeback workflows
• Multi-region active-active and geographic disaster-recovery requirements
• Direct database integrations, custom plugins, and internal applications built against Jira-specific APIs

Naming these gaps is not a concession. It is the work that separates a successful migration from a sales-led import.

The cost baseline

The economics of the decision start from what the Jira estate actually costs. The Jira Data Center baseline includes the Data Center subscription until exit, Jira Service Management, Confluence, Marketplace apps, infrastructure and database operations, Jira administration, upgrades and testing, backup, DR, monitoring, and security, and the migration or exception cost that arrives after 2029.

Weigh that baseline against the Plane self-hosted cost model in section 5.3, on your own estate’s numbers.

Plane supports imports from Jira Cloud, Jira Server, and Jira Data Center. The importer is available on Plane Cloud and across Commercial Edition plans for self-hosted instances.

The importer is necessary. It is not the whole migration.

A Jira estate is three things layered on top of each other: data, configuration, and behavior. Each layer migrates differently, and each layer is verified differently.

Data fidelity can be measured with counts and hashes. Configuration fidelity requires scenario testing. Behavioral fidelity requires users to complete real work.

Plan all three from the start.

The Jira importer documentation explicitly lists these mappings.

The public Jira comparison page also advertises custom-field migration and a controlled cutover with Jira held read-only.

The documentation and marketing page do not define every custom-field type, history event, app-owned object, or edge case. Validate those against your own instance.

Configuration mapping and reimplementation

Do not assume automatic conversion for:

• Workflow conditions, validators, post-functions, and transition screens
• Jira Automation rules, ScriptRunner scripts, and listeners
• JQL filters, subscriptions, and dashboard gadgets
• Tempo accounts, worklogs, plans, and cost models
• Xray or Zephyr test plans, executions, evidence, and traceability
• Assets schemas and Advanced Roadmaps configuration
• Custom Marketplace app data and direct database integrations
• Confluence macros and app content
• Outbound webhooks and incoming integration contracts
• Historical permission and audit events

Plane has native destinations for many of the underlying outcomes.

• JQL-style filtering can be redesigned in PQL, which supports structured expressions, AND and OR, parentheses, custom properties, and saved views.
• Workflow control can move to Plane workflows, approvals, pre-validation, and post-action scripts.
• Scripted automation can move to Plane Runner using JavaScript or TypeScript.
• Portfolio rollups can move to Initiatives.
• Confluence-like knowledge can move to project Pages and the workspace Wiki.
• Request capture can move to Intake, forms, and email.

The goal is not to translate every Jira object mechanically. The goal is to preserve the business intent with fewer moving parts.

Run the migration as five phases. Each phase produces evidence the next phase depends on.

Phase 1, estate discovery

Inventory the estate before touching it:

• Projects, users, groups, roles, and permissions
• Issues by project, age, status, and type
• Attachments and total object-store volume
• Custom fields, field types, workflows, and transition logic
• JQL filters, subscriptions, boards, and dashboards
• Automations, scripts, webhooks, integrations, and Marketplace apps
• Confluence spaces linked to Jira work
• Regulatory retention and audit requirements
• Performance hotspots and peak usage

Then classify every object: migrate, rebuild, replace, archive, or retire.

Phase 2, target-state modeling

Define the target Plane model before importing production data. Map:

• Jira projects to Plane workspaces and projects
• Issue types to work-item types, and fields to custom properties
• Statuses to states, sprints to cycles, and components to modules
• Epics and portfolio objects to Plane hierarchy and Initiatives
• Confluence spaces to project Pages, Wiki collections, and nested pages
• Groups and roles to workspace and project roles and permission schemes
• Workflows and automation to Plane workflows, approvals, automations, Runner, API, or webhooks

Simplify intentionally. If 5 Jira workflows express one real process, design one target workflow.

Phase 3, representative pilot

Choose a representative slice, not the easiest project.

Include one of each: a large project, a workflow-heavy project, a project with custom fields, a project with heavy attachments and history, a cross-functional project, an integration-heavy project, and a regulated or access-sensitive project.

Run the import. Let real users work in Plane. Record every difference.

Phase 4, reconciliation and acceptance

Validate with evidence.

Resolve every discrepancy as a defect, an accepted design change, or an archived limitation.

Phase 5, production cutover

Use a controlled freeze:

1. 01Announce the cutover and the support path
2. 02Complete the last incremental Jira-to-Plane synchronization
3. 03Place Jira in read-only mode
4. 04Reconcile final counts and exceptions
5. 05Switch SSO launch points, integrations, and internal links
6. 06Execute role-based smoke tests
7. 07Open Plane as the system of record
8. 08Keep Jira read-only for the approved retention window
9. 09Monitor adoption, errors, and support demand
10. 10Decommission only after legal, audit, and business sign-off

Public guidance says that many teams complete a first dry run in under 3 hours, and that larger workspaces may migrate over 3 to 7 days.

Treat that as a vendor planning reference, not a contractual estimate. Your duration will be driven by data volume, customizations, apps, validation depth, network throughput, and change-management scope.

“No data loss” is not a marketing sentence. It is an acceptance contract.

Define exactly what it includes:

• Every issue, sub-task, comment, and attachment
• Every author, timestamp, field, and field value
• Every relationship, external link, and status transition
• Every worklog, automation execution record, and audit event
• Every app-owned object and permission state
• Every deleted or archived record
• Every Confluence page and macro

If a category cannot migrate natively, decide where it lives instead: in Plane, in an archive, in a data warehouse, or in the read-only Jira system.

That is how a migration becomes defensible.

Standardizing on a work platform is a rare event.

It is the one chance most organizations get to consolidate a fragmented operating stack into a platform that stays coherent as they grow.

A common work model

Enterprise Grid
└── Workspaces
    ├── Teamspaces
    ├── Initiatives
    │   └── Projects and epics
    └── Projects
        ├── Work-item types
        ├── Work items and sub-work items
        ├── Cycles
        ├── Modules
        ├── Milestones and releases
        └── Pages

This lets an enterprise create boundaries for business units, regions, or legal entities while retaining a shared governance layer. Initiatives aggregate progress across projects. Teamspaces create focused collaboration surfaces. Projects keep their own execution detail.

Integrated knowledge and execution

Jira and Confluence can work well together. They remain separate products, with separate structures, permissions, administration, and cost.

Plane includes project Pages for specifications, decisions, runbooks, and reports; a workspace Wiki for cross-project knowledge; collections and nested pages for information architecture; private and shared pages; and inline collaboration with links back to work.

The benefit is not merely license consolidation.

Reusable governance standards

Enterprise Grid adds the controls required to standardize without forcing every team into the same project:

• Unlimited workspaces with a centralized policy layer
• Custom roles, permission schemes, and granular access control
• LDAP, SCIM, and IdP group sync
• Multiple workflows scoped to work-item types
• Approval flows and transition conditions
• API-enabled audit logs
• Enterprise support and migration services

Build reusable standards for workspace creation, project templates, work-item types and properties, workflow and approval patterns, role and permission schemes, intake forms, dashboards, retention and audit, integration registration, and API and automation ownership.

Then let teams vary where variation is useful.

Plane offers several layers of extensibility.

More than 180 REST endpoints are documented. API keys use the X-API-Key header, and the API supports cursor-based pagination, selective fields, and relation expansion.

Webhooks cover project, work-item, cycle, module, and comment events. Payloads carry delivery and event identifiers and an HMAC-SHA256 signature, with retries after failed delivery.

The open-source Plane MCP server supports remote OAuth, token-based HTTP, and local stdio for self-hosted instances. The current documentation labels MCP as beta, which should be reflected in production risk assessments.

This is a strong platform surface. Governance still matters.

For every automation and integration, require a named owner, scoped credentials, secrets in an approved store, idempotent handlers, retry and dead-letter behavior, rate-limit handling, audit and execution history, staging tests, and a retirement plan.

Avoid generic savings percentages. Model the real system.

The Plane self-hosted cost model has four parts: the plan and edition, including Enterprise Grid where required; infrastructure, meaning compute and Kubernetes or Docker operations plus PostgreSQL, cache, queue, object storage, and search; operations, meaning backup, DR, monitoring, security, and upgrades; and adoption, meaning implementation, integration and automation ownership, change management, enablement, and support.

The consolidation value comes from replacing separate tools for project and portfolio management, knowledge management, request intake and forms, workflow and approvals, automation and scripting, and dashboards and reporting.

The strongest business case is usually control + consolidation + operational simplicity + a supported future, not a single headline percentage.

Where Plane fits best

The case for Plane does not rest on a corresponding button for every screen in the tool it replaces. It is strongest when an organization values:

• Self-hosting as a permanent product commitment, with a true zero-egress option
• A familiar, containerized architecture on customer-controlled infrastructure
• Work and knowledge in one system
• Progressive complexity instead of configuration-first complexity
• Enterprise identity, workflow, access, and audit controls
• A modern API, webhook, automation, and agent surface
• An adoption path that can be proven project by project

If the system being replaced is Jira Data Center, the cost baseline should also carry the exit constraint. Part 04 covers that baseline, the platform comparison, and the migration cost drivers.

Ninety days is enough to move from interest to a defensible decision. Run it in five stages.

Days 0–15, confirm the control boundary

Confirm connected self-hosted or air-gapped. Select the edition and plan. Define security and compliance owners. Choose pilot teams and agree acceptance criteria. If you are migrating from Jira Data Center, run the estate discovery from Part 04 here.

Days 16–30, establish the platform

Deploy non-production Plane. Connect identity, SMTP, storage, and observability. Configure backups and restore tests. Establish roles and permission schemes, create the target work model, and configure AI only if its data boundary is approved.

Days 31–60, validate with real work

Bring representative work into Plane, built natively or imported from the system you run today. Map types, properties, states, users, cycles, and modules. Build workflows and critical automations. Validate comments, attachments, links, dates, and identity. Test integrations, API, mobile, search, and performance. Capture every exception. Migrating from Jira, this is where the pilot import and reconciliation from Part 04 run.

Days 61–75, validate operational readiness

Run node and dependency failure tests. Test readiness and liveness behavior. Rehearse backup and restore. Test an upgrade and a rollback decision. Validate telemetry and egress. Complete the security and architecture review.

Days 76–90, complete the enterprise decision

Run real work with pilot teams. Compare user outcomes and administrative effort. Finalize the migration wave plan and the estate-specific TCO. Sign off gaps, mitigations, and exit criteria. Decide whether to scale, remediate, or stop.

Decision gates and exit criteria

Move from proof to program only when all of these are true:

• Critical workflows pass end-to-end
• Access and audit controls meet policy
• The network and AI boundaries are documented
• Backups restore successfully
• The production HA design meets the agreed failure model
• Integration and automation gaps have owners and plans
• The economics are based on the real estate, not a generic calculator

Migrating from Jira Data Center adds three gates:

• Migration reconciliation is signed off
• Jira retention and decommissioning are approved
• Users can complete their work without hidden dependency on Jira

A work platform decision is one an organization lives with for a decade. Make it deliberately.

The organizations with the most to protect need a platform that respects one hard constraint: control over infrastructure, data, change, and risk.

Plane is designed around that constraint.

It runs on infrastructure the customer controls. Its production architecture uses systems platform teams already operate. It supports connected and fully air-gapped environments. It brings projects, knowledge, intake, governance, automation, and AI into one product. And it can be proven in small, reversible steps before the enterprise commits.

The decision standard is the one this guide has applied throughout: prove the control boundary, prove the platform, prove the controls, and prove the economics, all against your own estate.

For Jira Data Center customers, end of life adds urgency. It should not add haste. Part 04 exists so the move can be run as a deliberate transformation, not a rushed import.

This guide is grounded in public Plane product pages, pricing, product documentation, developer documentation, and Atlassian’s official Data Center end-of-life notice, as available on 10 July 2026. Figures that cannot be publicly evidenced are excluded by design.

1. 01

   Atlassian Data Center End of Life

2. 02

   Plane Self-hosted Plane

3. 03

   Plane Developer Docs Understanding Plane’s editions

4. 04

   Plane Pricing

5. 05

   Plane Project management

6. 06

   Plane Developer Docs Plane self-hosted architecture

7. 07

   Plane Developer Docs Kubernetes deployment

8. 08

   Plane Developer Docs High Availability on Kubernetes

9. 09

   Plane Developer Docs Command line tools

10. 10

    Plane Developer Docs Health checks

11. 11

    Plane Developer Docs Backup and restore data

12. 12

    Plane Developer Docs Airgapped deployment architecture

13. 13

    Plane Developer Docs Deploy Plane Commercial in an Airgapped Kubernetes Environment

14. 14

    Plane Developer Docs Data collection and usage

15. 15

    Plane Developer Docs Configure Plane AI

16. 16

    Plane Security

17. 17

    Plane Enterprise Grid

18. 18

    Plane Docs Permission schemes and the permissions matrix

19. 19

    Plane Docs Jira importer for Cloud, Server, and Data Center

20. 20

    Plane Plane vs Jira

21. 21

    Plane Docs Plane Query Language

22. 22

    Plane Docs Workflows and Approvals

23. 23

    Plane Docs Initiatives

24. 24

    Plane Docs Wiki

25. 25

    Plane Developer Docs API introduction

26. 26

    Plane Developer Docs Webhooks

27. 27

    Plane Developer Docs MCP server