Why a self-hosted Jira alternative needs a plan before March 2029
If your organization must keep project data on its own infrastructure, the deadline that matters is March 28, 2029, when Jira Data Center licenses expire and become read-only. Atlassian ends new Data Center subscriptions for new customers on March 30, 2026, and stops licenses and expansions for existing customers after March 30, 2028, so the window for a controlled move closes well before the read-only date. Atlassian's Ascend announcement sets out this timeline, and it should be the first document your steering group reads. The short answer is that OpenProject and Plane are the main self-hosted options, with Redmine as a narrower choice for teams whose needs are mostly issue tracking and wikis. Each depends on two things you must check early: the version limits of the importer you plan to use, and the edition you will run.
The importers do not cover the same sources. OpenProject's Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, so a team on another version or on Jira Cloud cannot use it as its main route. Plane's Jira importer supports Jira Cloud as well as Server and Data Center, but it runs on Plane Cloud or the self-hosted Commercial Edition, not the Community Edition. Start by confirming your exact Jira version, the number of projects, attachments and custom fields, and whether you must avoid any hosted component. Those answers decide the edition, the importer and whether you need a paid license before you install anything.
Plan the decision with a fixed date. Work backward from the last Data Center renewal you may sign, and schedule a pilot import into a test instance, a review of workflows and permissions, and a cutover rehearsal before the final window. Ask each vendor or partner to confirm in writing which Jira versions their importer covers at the time of the move, because beta tools and version support change between releases. A written scope with named owners for data cleanup, identity integration and parallel running is the difference between a planned exit and a rushed one.
What keeping project data on your own infrastructure requires
Moving off Jira Data Center is less a single migration than a set of ongoing custody decisions. The cards below cover where data lives after the read-only date, which Jira version the importer can read, how users sign in, what enterprise features cost, who patches the stack and how backups reach attachments and configuration.
Data custody after the read-only date
Atlassian's Data Center licenses expire and become read-only on March 28, 2029, so a Jira Data Center instance can still be read but no longer updated once that date passes. Decide before then where the authoritative copy of issues, comments and attachments will live, and who holds the database and file store. Confirm whether your own archive of the instance must remain readable for records purposes after the platform is retired.
Export path matched to importer versions
OpenProject's Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, not Jira Cloud. Plane's Jira importer covers Jira Cloud as well as Server and Data Center. Check your exact Jira version before choosing a route, and plan a test import into a non-production instance, because the OpenProject documentation advises beta use only in test setups.
Identity through SSO or LDAP
Confirm how users will authenticate before go-live. OpenProject lists SAML, OIDC, CAS, Kerberos and Okta single sign-on, and LDAP group synchronization among its Enterprise features. On self-hosted Plane, SAML and OIDC start at the Pro plan, and LDAP is an Enterprise feature. Map each group in your directory to project roles in the target tool so permissions carry over without manual setup.
Paid features for enterprise sign-in
Community editions do not include the directory and provisioning features many regulated organizations require. Ask vendors and partners to list which features each required control depends on, such as SSO, LDAP synchronization, SCIM provisioning and audit logs. Budget for the edition that includes them, and compare the per-user cost of OpenProject Enterprise on-premises with Plane's paid self-hosted plans using your own seat count.
Operating and patch work
A self-hosted deployment runs as a service you own. OpenProject expects PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plane uses PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage. Someone must apply upgrades, watch capacity against the sizing guide and rehearse restores. Agree on who performs these tasks, how often, and who is on call before the source instance is retired.
Backup scope for attachments and configuration
Cloud backup from Atlassian does not include automation rules, third-party apps or Assets, so those components must be recreated or exported separately. Your own backup plan should cover the database, attachment storage, workflow and permission configuration and the search index rebuild. Test a full restore into a clean environment and record how long it takes, so the recovery process is evidence you can show an assessor.
Which self-hosted option meets the constraint, and where each falls short
This table compares OpenProject Community and Enterprise, Plane's Community, Commercial and Airgapped editions, and Redmine on data residency, Jira importer scope, paid-tier features and trade-offs. Check the importer row against your exact Data Center version before you plan any migration path.
| Capability | OpenProject | Plane | Redmine |
|---|---|---|---|
| Data stays on your servers | Yes, when self-hosted with Docker, packages or Kubernetes in your own environment | Yes, when self-hosted with Docker Compose, Kubernetes, Podman or air-gapped installs | Yes, self-hosted web application under GPL v2 |
| Jira importer covers Data Center 10.x and 11.x | Beta Jira Migrator for Data Center 10.x and 11.x only, test setups advised | Jira importer supports Jira Server and Data Center, confirm your exact version | No built-in Jira importer; third-party scripts are neither tested nor supported by Redmine |
| Jira Cloud as migration source | Not supported by the Jira Migrator | Supported on Plane Cloud and the self-hosted Commercial Edition | Not covered by a built-in route |
| Paid tier features | SSO, LDAP group sync, custom branding and the Jira Migrator sit in Enterprise plans from Basic upward | SAML and OIDC from Pro, LDAP and API-enabled audit logs in Enterprise; Community matches Cloud Free | No paid edition; sign-in options depend on built-in LDAP and plugins for SAML or OIDC |
| Airgapped or offline installs | Packaged installs and Docker images; confirm update delivery for disconnected networks | Airgapped edition is proprietary and requires a commercial route; confirm terms with the vendor | Suitable for offline use; confirm your own patch process |
| Main trade-off | Strong Jira-style planning, but the beta importer limits what moves from Data Center | Modern work items and cycles, but a proprietary edition is needed for the importer and some features | Mature and free, but a different model from Jira boards and needs more manual rebuilding |
How OpenProject, Plane and Redmine differ for a Data Center exit
OpenProject is licensed under GPL-3.0 and developed by OpenProject GmbH. Its free Community edition covers work packages, Gantt charts, agile boards, time tracking and dashboards, with community support only. Its Jira Migrator is in beta and reads Jira Data Center 10.x and 11.x only, so Jira Cloud and older Server or Data Center versions need another route. The Migrator sits under the Enterprise plans from Basic upward, and its documentation advises using it only in test setups.
- License: GPL-3.0 for the codebase, with commercial Enterprise plans for on-premises and cloud use.
- Jira import: Beta Migrator, limited to Data Center 10.x and 11.x, bringing projects, versions, issues with history, comments, attachments, basic custom fields, users, statuses and types.
- Paid features: SSO, LDAP group synchronization, SCIM provisioning and portfolio and resource management require Enterprise plans.
- Deployment: Docker-based installation (recommended), .deb and .rpm packages for 64-bit Linux, and Kubernetes with Helm charts for horizontal scaling.
- Database: PostgreSQL 16 or later, with the pg_trgm, btree_gist and unaccent extensions.
Confirm with OpenProject which Enterprise tier your identity and reporting requirements need, and test the Migrator against a copy of your own Data Center instance before relying on it.
Plane offers three self-hosted editions: Community, Commercial and Airgapped. The Community edition is licensed under AGPL-3.0 and matches the feature set of the Plane Cloud Free tier. Its Jira importer works with Jira Cloud as well as Jira Server and Data Center, but it is available on Plane Cloud and on the self-hosted Commercial Edition, not on Community. Moving to a paid plan means switching a Community install to the Commercial Edition, which uses a license key and counts seats by users with paid roles.
- License: AGPL-3.0 for Community, with the Commercial and Airgapped editions proprietary.
- Jira import: Importer for Jira Cloud, Server and Data Center, available on Plane Cloud and the Commercial Edition.
- Paid features: SAML and OIDC start at the Pro plan, while LDAP support and API-enabled audit logs are Enterprise features.
- Deployment: Docker Compose for small and mid-size teams, Kubernetes with Helm for high availability, plus Podman and air-gapped installs. The Kubernetes guide installs the Commercial Edition.
- Dependencies: PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible object storage such as MinIO, any of which the Helm chart can point to an external managed service.
Confirm with Plane which edition supports your Jira import path, since the import route is not available on Community, and confirm your seat count before choosing a plan.
Redmine is a self-hosted project management application built on Ruby on Rails and licensed under GPL v2. It has no paid edition, so every feature is available in the open-source release, with plugins extending it. It provides issue tracking, Gantt charts, wikis, time tracking, LDAP authentication and Git and Subversion integration. Its Jira route is a CSV export from Jira followed by Redmine's built-in CSV issue import, and Redmine describes third-party Jira migration scripts as neither tested nor supported.
- License: GPL v2, with no commercial edition to purchase.
- Jira import: Manual route through Jira CSV export and Redmine CSV issue import, with trackers, statuses, users and custom fields created in advance.
- Paid features: None are sold by the project itself. Identity features such as SAML or OIDC sign-in depend on plugins you select and maintain.
- Deployment: Self-hosted installation on your own servers, with the deployment method for your Ruby and Rails environment documented on the Redmine site.
- Version: Version 7.0.2 was released on September 30, 2026.
Confirm which plugins you need for SSO and reporting, and who will maintain them and apply security updates, because that work falls to your own team.
Deploying the chosen option before March 28, 2029
This sequence takes a team from the current Jira Data Center version to a tested, backed-up, self-hosted replacement with a retained archive of the source data. Each step ends with a check you can record before the next one starts.
Confirm your Jira Data Center version
Record the exact Jira Data Center version your instance runs, then compare it with the range the importer supports. OpenProject's Jira Migrator supports only Jira Data Center 10.x and 11.x, and does not support Jira Cloud, so an instance outside that range needs a different route or an upgrade decision first. Your Atlassian administrator can read the version from the system information page. Done when the version, the instance owner and the importer compatibility result are written into the project record.
Choose the edition and licensing model
Decide between OpenProject Community, which is free, and the Enterprise on-premises plans if you need single sign-on, LDAP group synchronization, SCIM provisioning or the Jira Migrator, which OpenProject lists from its Basic plan upward. For Plane, decide whether the Community Edition under AGPL-3.0 covers your needs or whether you need the Commercial Edition, which carries the Jira importer and paid roles. Ask each vendor to confirm in writing which features your scale requires. Done when the edition, seat count and feature list are approved by the budget owner.
Build the environment with the documented install method
Your platform or infrastructure team installs the chosen product inside your own cloud account, data center or network using the vendor's documented method. For OpenProject, Docker is the recommended route, with packaged installs on supported Linux distributions and PostgreSQL 16 or later with the required extensions. For Plane, Docker Compose suits small and mid-size teams, while Kubernetes with Helm suits high availability. Size the hosts against the vendor's sizing guidance for your user count. Done when the stack starts, the health checks pass and the backup target is attached.
Test the migration in a non-production setup
Run the importer against a copy of your Jira data in a test environment, never in production. The OpenProject documentation advises using its beta Jira Migrator only in test setups. Compare record counts, issue histories, comments, attachments, users, statuses and custom fields with the source, and log every item that did not carry over, including workflows, permission schemes, automation rules and apps. Done when a signed-off gap list exists and the business owners accept what must be rebuilt by hand.
Configure identity and access
Connect the platform to your identity provider using the single sign-on method your plan includes, such as SAML or OIDC, and set up group-based roles that mirror your Jira project permissions. Confirm which users must be provisioned or deprovisioned automatically and whether that requires an Enterprise feature such as SCIM provisioning or LDAP synchronization. Test sign-in with an account from each role and a disabled account. Done when each test role reaches only its intended projects and disabled accounts are refused.
Run a backup and restore test
Back up the test environment, including database, attachments and object storage, then restore it to a clean host and confirm the data opens correctly. Repeat the restore on a schedule you set before go-live. Note that Jira Cloud backup excludes automation rules, apps and Assets, so your own export must capture anything the importer skips. Done when a restore has been completed and checked against a recorded list of sample items, and the restore time is written into the operations runbook.
Cut over the team
Freeze edits in Jira Data Center for the agreed window, run the final import into production, verify the same checks used in testing, and then announce the new location with links, access instructions and a short support path. Keep Jira in read-only mode for the agreed period so that questions can be checked against the source. Done when the team confirms it can create, update and find work items in the new system and the cutover log is signed by the project owner.
Keep a read-only archive of the Jira export
Store a full export of the Jira projects, with attachments and a record of the configuration, in an access-controlled archive on your own infrastructure, and set retention and access rules that match your compliance obligations. Ask your compliance lead which records must be kept and for how long, and confirm the archive can be read without the Jira license. Done when the archive has been opened and searched by someone outside the migration team and the retention decision is documented.
When to start: working back from the Data Center dates
Start from the dates, then work backward. Atlassian ended new Data Center subscriptions for new customers on March 30, 2026, stops licenses and expansions for existing customers after March 30, 2028, and on March 28, 2029 Data Center licenses expire and become read-only. The last date is the hard stop for a running Jira Data Center instance, so the planning question is how much lead time your own migration, validation and rollout need before it. Confirm your contract's term end, renewal date and expansion rules directly with Atlassian, because your dates may differ from the general schedule and an expansion window can close earlier than the read-only date.
Several factors set the start date, and none of them is a fixed duration. The first is importer fit: OpenProject's Jira Migrator is in beta and covers only Jira Data Center 10.x and 11.x, so confirm your exact version early. The second is test cycles, which need enough runs to compare issue counts, history, attachments and user mappings against the source. The third is identity setup, since single sign-on and directory synchronization in the target must work before users move. The fourth is user training and procurement approval, which often take longer than the technical work in large organizations. Ask any vendor or implementation partner for a written schedule tied to these items rather than a single estimate.
Put the decision on a calendar. Record your contract dates, your current Jira version, and a list of the workflows, permissions, automation rules and apps that must be rebuilt. Assign an owner for the go or no-go decision and set a date for it well before the expiry, so a failed test cycle still leaves time to extend a contract or change course. Treat the read-only date as the point where the target system must already be your system of record, not the point where you begin planning.
Evidence to keep for data residency and audit reviews
Once project data sits on your own servers, the proof that it is controlled, recoverable and correctly configured becomes your responsibility. The six records below connect deployment, migration, access, recovery, change decisions and the archived Jira source, so that an auditor can trace each claim back to evidence. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.
Deployment inventory and versions
Record every running component with its exact version, host, database and storage location, including the OpenProject or Plane release and the PostgreSQL version. Keep it current for each environment, since test, staging and production often drift apart. Reviewers ask first where data lives and which build is serving it, so a dated inventory answers both questions. Confirm the release notes for each version you run, such as the OpenProject 17.9.2 release published on October 15, 2026.
Migration test records
Keep a written record of each test import, the source export used, the counts of projects, work items, comments and attachments before and after, and every field that did not map. The OpenProject Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, so record which source version you tested against. Store the reconciliation report with the sign-off that accepted the result.
SSO, LDAP and access role configuration
Export and version-control the settings for single sign-on, directory synchronization and project roles, with the date each change was approved. Check that group-to-role mappings match the access model signed off by the data owner. On OpenProject, SSO and LDAP group synchronization sit in Enterprise plans, so confirm the licensed feature is active. Store screenshots or exports that show who can reach which projects.
Backup and restore test results
A backup is evidence only after a restore has been tested. Log each restore drill with the backup timestamp, the target environment, the time taken, and whether attachments and database content matched. Cover the database, attachment storage and configuration files, because each one fails differently. Cloud backups from Atlassian do not include automation rules, third-party apps or Assets, so list those separately if you migrate from Jira Cloud.
Update and release decision log
Record each decision to upgrade, delay or skip a release, with the reason, the risk assessment and the test evidence behind it. Plane Community Edition is AGPL-3.0 and Plane Commercial Edition is a separate codebase with its own release cycle, so the edition in use must be written down. Keep the advisory or release note that prompted each decision, so an auditor can see that patching was deliberate rather than neglected.
Archived Jira export
Keep a read-only archive of the final Jira export, including the export format, the date, the project list and a hash or checksum of each file. This copy is the reference if a migrated record is questioned after Jira licenses are read-only. Confirm with Atlassian which export option covers your deployment type and what it omits, and store that limitation statement alongside the archive.
Questions teams ask before moving off Jira Data Center
What drives the cost of moving off Jira Data Center to self-hosted OpenProject or Plane?
The cost depends mostly on which edition you pick, where it runs, how much history you migrate, and who operates it. OpenProject Community is free to download, but SSO, LDAP group synchronization and the Jira Migrator sit in paid Enterprise plans, which OpenProject prices per named user per month. Plane's Commercial Edition is needed for its Jira importer on self-hosted installs, and paid Plane plans are priced per user per month. Hosting, storage, backup, your staff time and any services work are separate lines. Ask for a quote that lists each component, the user count you expect, and which features you need, so the editions can be compared on the same basis. Scope is agreed in writing before work starts.
Can our team migrate from Jira Data Center without outside help?
Some teams can, especially if they already run Linux, Docker or Kubernetes and have clear rules for projects, workflows and permissions. The harder parts are usually not the install. They are the migration mapping, rebuilding workflows and permissions, testing with real users, and setting up single sign-on, backups and upgrades. OpenProject's Jira Migrator is in beta and its documentation advises using it only in test setups, so a production move will need careful validation either way. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Compare doing it in-house with a written scope before you decide.
How long does a Jira Data Center migration take?
No supplied figure gives a standard duration, so treat any number you hear with caution. The length is set by the number of projects and issues with history, attachments, custom fields, integrations that must be replaced, how many workflows and permission schemes need rebuilding, the number of users to onboard, and how many rounds of test migration your team wants before cutover. Plane's Jira importer and OpenProject's migrator have different supported scopes, so the mapping work differs. Ask your implementation partner for a written timeline tied to a defined scope, and confirm which of your data types each importer actually handles before you start.
What does our staff need to run a self-hosted Jira alternative?
Plan for people who can operate the chosen platform after go-live, not only people who perform the migration. OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Packaged installs support Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15, and OpenProject requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plane needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage. Your team will need skills for upgrades, backups, monitoring, certificates and identity integration on a recurring basis.
Do Jira Cloud users need a different route than Data Center users?
Yes. OpenProject's Jira Migrator does not support Jira Cloud, and it supports only Jira Data Center 10.x and 11.x. Plane's Jira importer works with Jira Cloud as well as Jira Server and Data Center, but it runs on Plane Cloud or the self-hosted Commercial Edition. For Jira Cloud exports, Atlassian's backup covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes, but not automation rules, third-party apps or Assets. Confirm exactly what each route brings over and rebuild anything outside that list before cutover.
What happens to our Jira data on the read-only date?
Atlassian's timeline says Data Center licenses expire and become read-only on March 28, 2029, after new Data Center subscriptions for new customers end on March 30, 2026, and licenses and expansions for existing customers stop after March 30, 2028. Read-only access means you should plan your export and migration well before that date rather than at it. Keep an archived copy of projects, attachments and audit-relevant history on your own infrastructure, and confirm with Atlassian what your contract allows during the read-only period. Your compliance team should decide how long the archive must be retained.
How DeployOpen plans and runs a Jira exit inside your environment
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted OpenProject or Plane inside your own cloud accounts, data centers or air-gapped networks. For Jira Data Center customers, the work starts with a written scope that fixes the data to move, the systems to connect and the controls to evidence before the March 28, 2029 read-only date.
How we scope
- Inventory the Jira Data Center version, projects, workflows, custom fields, apps and integrations in use today
- Decide between OpenProject and Plane against your importer version limits and required single sign-on
- Agree deliverables, timelines and responsibilities in writing before any work starts, as every engagement is fixed-scope
How we build
- Deploy the chosen platform in your environment using the Docker, package or Kubernetes method your team already operates
- Connect identity, database, object storage and backup services, and confirm the paid edition features you depend on
- Run a test migration on a copy of your data and record what imports, what is rebuilt and what is excluded
How we hand over
- Document the installation, configuration, upgrade path and the rebuilt workflows, permissions and automation rules
- Provide runbooks for backup, restore testing and version updates, including how security patches reach air-gapped hosts
- Train administrators and project leads, and deliver the evidence pack your internal or external auditors will request
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after cutover
- Schedule upgrades ahead of Jira Data Center's end-of-life milestones so your team is not working against a deadline
- Ask any provider, including us, to confirm each feature, license and migration limit against current vendor documentation
