Context — end of sales and Jira Data Center EOL
Atlassian officially stopped selling new Jira Data Center licenses to new customers on March 30, 2026. Existing Data Center customers retain the ability to purchase license expansions and renewals until March 30, 2028, after which those options also disappear. The final milestone is the EOL on March 28, 2029: on that date, Data Center products enter read-only mode. Your data remains accessible for viewing, but any creation or modification of tickets, projects or configuration becomes impossible.
This timeline may appear to leave room. In practice, a project management migration requires weeks of preparation: inventory of active projects, archiving of obsolete tickets, workflow reconfiguration, team training, and a parallel-run period to validate continuity. Waiting until 2028 means running the migration under pressure of the deadline, with a high risk of data loss or production disruption.
Five reasons to migrate now rather than under pressure
- Per-seat Data Center licensing costs — the Data Center pricing model charges per active user, with annual tiers whose revisions by Atlassian are outside your control. Leaving now allows you to calmly calculate the TCO of the new solution.
- Locked-in timeline, no surprises — the March 28, 2029 date is final. A migration completed in 2026 or 2027 leaves time for a parallel run and a potential rollback; a migration completed in 2028 leaves neither.
- Risk of read-only at EOL — if your Data Center instance is not migrated by March 28, 2029, your teams lose the ability to create or modify tickets. A blocking incident during the freeze period is a scenario to eliminate in advance.
- Control over data and backups — on a root-access VPS, you choose backup frequency, encryption, retention and data location. No third party decides the retention period on your behalf.
- Opportunity for cleanup — a migration is the ideal moment to archive inactive projects, harmonize statuses and ticket types, and start fresh rather than transferring years of accumulated artifacts.
- Integration stability — Jira connectors (CI/CD, Confluence, Slack, third-party plugins) will have to be rebuilt regardless when moving to a new platform. Doing it today means choosing open integrations based on standard APIs, with no dependency on a proprietary ecosystem.
- Plugins not carried forward — Atlassian has indicated that certain Data Center plugins will not be ported beyond 2028; features that depend on them must be identified and replaced before EOL.
Measured prerequisites before you start
Before choosing between OpenProject and Plane, verify that your VPS meets the minimum requirements of each tool. OpenProject requires a quad-core processor at least 2 GHz and 4 GB of RAM to support up to 200 total users — this is the configuration the publisher recommends for stable production use. Below that, background operations (notifications, calculated attribute updates) slow down. Plane requires at minimum 2 vCPU, 4 GB of RAM and 20 GB of storage for its AIO (All-In-One) Docker deployment.
On the common prerequisites side: a complete XML export of your Jira Data Center instance must be produced and verified before touching anything on the target environment. Export project by project for large instances — Jira imposes size limits on global exports that silently truncate oversized archives. Have a complete backup of all your projects, including attachments. The target VPS must be accessible via SSH with root access, and Docker with docker compose v2 must be installed or freely installable. Also plan for a domain or subdomain (e.g. pm.yourcompany.com) and the corresponding DNS records before generating TLS certificates.
OpenProject vs Plane — key criteria comparison
| Criterion | OpenProject | Plane |
|---|---|---|
| License | GPL-3.0 | AGPL-3.0 |
| GitHub stars | ~15,900 | ~56,000 |
| Minimum RAM (production) | 4 GB — quad-core ≥ 2 GHz (up to 200 users) | 4 GB — 2 vCPU, 20 GB storage |
| Native Jira Migrator | Yes — Beta (since OpenProject 17.4, May 2026) | Native import from Jira XML export |
| Interface | Close to Jira — work packages, roadmaps, built-in Gantt | Modern and streamlined — issues, cycles, modules |
| Learning curve | Moderate — vocabulary and concepts close to Jira | Light for teams accustomed to modern agile tools |
| Federated authentication | LDAP and SAML included in the Community version | LDAP included in self-hosted; SAML available in self-hosted |
OpenProject — migration via the official Jira Migrator
Export data from Jira Data Center
In the Jira administration, navigate to System → Backup and export. Run a per-project XML export for large instances rather than a global export — Jira Data Center imposes size limits that silently truncate oversized global exports. Include attachments in the export. Verify the size of the produced archive and compare the number of exported tickets with the database counter before proceeding.
Deploy OpenProject via Docker
On the VPS, create a working directory and retrieve the official OpenProject docker-compose.yml. Set the mandatory environment variables: SECRET_KEY_BASE (generate a 64-character random string), OPENPROJECT_HOST__NAME (your domain), OPENPROJECT_HTTPS=true. Start the stack with docker compose up -d and wait for the database migrations to complete (visible in the web container logs).
Configure and enable the Jira Migrator
The OpenProject Jira Migrator has been available in Beta since version 17.4 (May 2026). In the OpenProject administration, go to Modules → Jira Migration. The tool asks for the Jira XML archive exported in the previous step. Before running, read the known limitations documented at openproject.org/docs/installation-and-operations/jira-migration/ — certain custom field types or workflow configurations may require manual handling after import.
Run the migration and monitor progress
Start the import from the Jira Migrator interface. For large instances (tens of thousands of tickets), the process can take several hours. Monitor the OpenProject worker container logs in parallel: import errors appear there before being aggregated in the end-of-migration report. Do not stop the Docker stack during the import.
Validate work packages, attachments and custom fields
Once the import completes, the Jira Migrator displays a report with the number of imported items and any errors. Check a representative sample of work packages: title, description, status, type, attachments, comment history. Verify custom fields of type text, number, date and select list — these are the four types migrated by the Beta. Formula or cascade field types are not automatically migrated.
Configure users and permissions
The Jira Migrator creates OpenProject user accounts matching Jira accounts by email address. Users whose email does not match any existing OpenProject account are created as inactive. Activate them manually, assign them to the appropriate groups and projects, and configure roles. If you use LDAP or SAML, connect the directory before this step so accounts are linked to centralized authentication from the first login.
Configure notifications and mail server
In Administration → Email settings, enter your SMTP server details. OpenProject sends notifications for mentions, status changes and due dates. Send a test email before validating the configuration. Set default notification preferences for new users to avoid an email avalanche when you open the platform to the teams.
Plane — native import from a Jira XML export
Export data from Jira Data Center
Proceed the same way as for OpenProject: per-project XML export from the Jira administration, attachments included. If your Jira instance exceeds the global export limits, split by project and import them sequentially into Plane. Keep the original XML archives until the migration is fully validated.
Deploy Plane in AIO mode via Docker
Plane offers an AIO (All-In-One) Docker deployment that bundles all services in a simplified configuration. Clone the official repository, copy .env.example to .env and set at minimum WEB_URL (your domain), SECRET_KEY and the database parameters. Start with docker compose -f docker-compose.yml up -d. The services that start include the Next.js frontend, the Django API, the Celery worker, PostgreSQL and Redis.
Import from Jira XML in the Plane interface
Once Plane is accessible, create a workspace. Go to workspace settings → Importers → Jira. Plane asks you to upload the XML archive exported from Jira. The import creates a Plane project for each Jira project contained in the archive, with issues, descriptions, attachments and comments. Jira statuses are mapped to Plane states that you can rename after the import.
Validate issues and attachments
After the import, browse a sample of issues per project: title, description in Markdown, attachments, historical comments. Check that custom statuses have been correctly mapped. Issues whose attachments exceed the size allowed by the Jira export may appear without their attached file — check the import report in the workspace settings.
Configure cycles, modules and members
Plane organizes work into cycles (the equivalent of Jira sprints) and modules (thematic groupings). These structures are not automatically imported from Jira — they must be recreated according to the desired organization for the new platform. Invite team members by email or configure SAML SSO in the workspace settings before opening access to all users.
What neither tool migrates
Before announcing the migration to your teams, explicitly document what will not be transferred — this is the primary source of disappointment and resistance to change.
Jira automations and rules (status change triggers, automatic reassignment, conditional transitions) are not migrated. OpenProject and Plane each have their own automation systems, but these must be reconfigured from scratch. Plan a workshop with the teams to map existing automations before the migration.
Third-party integrations — Confluence connectors, Slack bots, webhooks to CI/CD systems, Jira Marketplace plugins — will need to be rebuilt on the OpenProject or Plane APIs. Both tools expose documented REST APIs, but the integration logic must be rewritten.
Project workflows with complex conditions (role-based permissions on each transition, validation constraints) are not migrated by the Jira Migrator Beta. OpenProject allows complete workflow reconfiguration, but only through its administration interface — not automatically at import.
Historical sprint data — velocity, burndown, planned vs. actual capacity — is not transferred. Issue history and comments are preserved, but aggregated agile metrics remain in Jira. If this data has value for the team, export it as CSV from Jira before closing the instance.
Finally, Jira Service Management ticket types (incidents, service requests, ITSM-sense problems) do not map directly to issue types in either tool. If you use Jira for both development and ITSM support, assess whether OpenProject or Plane cover your ITSM needs, or whether a dedicated solution (Zammad, Mattermost, self-hosted Freshdesk) should be deployed alongside.
Always create a local administrator account before enabling SSO authentication (SAML or LDAP). If the SSO configuration contains an error — wrong entity ID, expired certificate, incorrect attribute mapping — you will be permanently locked out of the interface on the first SSO login attempt. The local account allows you to correct the configuration without server-side intervention. On OpenProject, this account must be created before enabling the LDAP module in settings; on Plane, disable SSO while validating the admin connection. Also take a full Jira XML export and a complete backup of all projects before any operation on the target environment.
Troubleshooting — common migration errors
Several errors appear in the vast majority of Jira migrations to OpenProject or Plane.
Unmapped identifiers. The Jira Migrator (and the Plane importer) associate Jira users with accounts on the target platform via email address. If a Jira user has a different email address from their OpenProject or Plane account, their tickets appear unassigned or with a generic assignee. Solution: pre-create all user accounts with the same email addresses as in Jira before running the import.
Missing attachments. Jira Data Center exports include attachments in the ZIP archive, but Jira may impose a global size limit on exports. If the archive is truncated, attachments for the most recent tickets are absent. Check the size of the exported archive and compare it with the actual disk space of your Jira attachments directory. For large instances, export by project and verify project by project.
Timeout on large exports. For projects with tens of thousands of tickets, the global Jira XML export may time out server-side. Use the per-project partial export feature available in the Jira DC administration interface. Then import each archive sequentially into OpenProject or Plane.
Character encoding issues in XML. Jira exports that contain special characters (typographic quotes, accented characters in certain locales, emoji inserted in descriptions) can produce malformed XML files. Validate the XML archive with a tool such as xmllint before import. If encoding errors appear, open the file in an editor with encoding detection and fix the invalid sequences.
OpenProject Jira Migrator Beta errors. The Jira Migrator has been in Beta since version 17.4 (May 2026) and its behavior may change between minor versions. In case of a blocking error, consult the known limitations page at openproject.org/docs/installation-and-operations/jira-migration/ before opening a support ticket. Most Beta errors are documented with a workaround.
Root-access VPS + OpenProject or Plane — a clean exit from Jira Data Center
Migrating from Jira Data Center is not a multi-month project if approached methodically. A clean XML export, a VPS sized to the chosen tool's requirements, and a working day are enough to transfer issues, attachments, essential custom fields and comment history to OpenProject or Plane.
The choice between the two depends on your context: OpenProject is closer to Jira in its concepts (work packages, roadmaps, Gantt) and has an official Jira Migrator, making it the lower-risk migration for teams accustomed to Atlassian vocabulary. Plane is more modern in its approach and more widely adopted by development teams who want to start fresh on lighter foundations.
In both cases, you regain full control: root access to the server, managed backups, no per-seat pricing that a vendor can revise unilaterally, and data hosted in the infrastructure of your choice. Leaving Jira Data Center stops being a constraint and becomes an opportunity to clean up your project tooling.
