Self-hosted project tracking in 2026: revisit Plane, OpenProject and Redmine before you move another backlog off Jira

Many Indian software teams did not choose Jira so much as inherit it. Somebody set up a Jira Server licence in 2016, it moved to Data Center when Server ended, and ten years later it holds every bug, every sprint, every customer escalation and half the reasons behind old design decisions. Nobody loves the workflow schemes, but everybody depends on them. Then a renewal mail comes, or a customer asks where their defect data is stored, and the question starts: should we move the backlog to something we host ourselves?

This year the question has a deadline attached. Atlassian has announced that its Data Center products, including Jira Software Data Center, Jira Service Management Data Center and Confluence Data Center, reach end of life on 28 March 2029. New customers could no longer buy Data Center subscriptions after 30 March 2026. Existing customers can still buy new subscriptions, apps and expansions until 30 March 2028. On the end-of-life date, Atlassian says, licences and Marketplace apps expire and the products become read-only, with extended maintenance only by exception. Bitbucket and Bamboo Data Center are excluded from this. Atlassian’s answer is to move to its cloud. For many companies that is a fine answer. For some, because of contracts, data location, cost or simple preference, it is not.

We revisit three open-source trackers that people actually move to: Plane (a modern tracker with cycles, modules and pages, whose Community Edition is under AGPL-3.0), OpenProject (a broad project management suite with work packages, Gantt charts, backlogs, time and cost tracking, under GPL-3.0) and Redmine (the twenty-year-old Ruby on Rails issue tracker, under GPL-2.0, which many long-running IT teams still run quietly). They are not three versions of the same product. Each makes a different bet about what a tracker is for.

There is real news this autumn. OpenProject 17.9.0 came out on 30 September 2026 with a faster Jira Migrator that runs concurrent import jobs, and the 17.9 line reached 17.9.6 on 30 October. Plane Community Edition v1.4.3 was published on GitHub on 29 October 2026 (Indian time) with a long list of access control fixes and a recommendation that self-hosted instances upgrade. Redmine released 7.0.3, 6.1.6 and 6.0.12 together on 1 November 2026, all three with security fixes, and the 7.0 line itself, released at the end of June, marks twenty years since Redmine’s first commit.

This post stays with project and issue tracking. For the pieces around a tracker, see self-hosted git forges in 2026 because commits and merge requests should link to work items, self-hosted wikis in 2026 because Confluence usually leaves with Jira, and Keycloak and its alternatives for sign-in.

A scenario to keep us honest

We will use one invented company through the post. Subarnarekha Plant Systems is an invented example, not a real business: a Jamshedpur company that builds maintenance management and shop-floor software for steel ancillary units, forging shops and small rolling mills in the Adityapur and Gamharia industrial areas and in Odisha. It has about 130 people. About 50 are developers and testers in five product teams, about 25 are implementation engineers who roll the software out at customer plants, about 20 are in customer support, and the rest are in sales, accounts and HR. Infrastructure is a team of three, led by Ritika, with most systems on VMs in a Mumbai cloud region and a Proxmox host in the Bistupur office.

What they use today:

  • Jira Software Data Center 10.x on one VM, bought as Server in 2017 and moved to Data Center later, with about 140 named users, 38 projects and a little over 90,000 issues. Six Marketplace apps, of which two matter: a time tracking app the implementation team uses for billing, and a Gantt app the project managers use for plant rollouts.
  • Confluence Data Center for specifications and rollout runbooks.
  • A self-hosted GitLab for code, with Jira issue keys in commit messages.
  • An OpenLDAP directory that IT runs for VPN and Wi-Fi accounts, and a Keycloak instance in front of it for newer internal tools.
  • Support tickets arrive by email to a shared mailbox, and a support engineer copies the serious ones into Jira by hand.

What triggered the review: the Data Center renewal quote arrived with the end-of-life notice attached. Atlassian’s cloud quote, for the same users and the two apps, was a number the finance head wanted explained. In the same quarter, a large customer’s IT security team asked, in a vendor questionnaire, where defect reports containing their plant names, equipment tags and screenshots of their HMI screens are stored, and who outside the vendor can access them. The project managers also complained, again, that sprints live in Jira but plant rollout plans live in a spreadsheet because nobody trusts the Gantt app.

Ritika’s questions: which tracker, what moves automatically and what does not, how people sign in, how much server it needs, how backups and upgrades work, and whether three people can own it for the next five years. She also wants to know whether there is any hurry, given that the end-of-life date is in 2029.

The short version

  • There is a deadline, but not an emergency. Jira Data Center keeps working with support and critical security fixes until 28 March 2029. Existing customers can renew, but Atlassian prorates renewals so they end on that date. That is enough time to migrate carefully, and not enough time to keep postponing the decision.
  • OpenProject is the broadest of the three and the one most clearly aimed at Jira Data Center users in 2026. It has backlogs with dedicated sprint objects, all board types in the free Community edition, Gantt charts, time and cost tracking, meetings, a wiki, and a Jira Migrator in beta that reads from Jira Data Center 10.x and 11.x. LDAP sign-in is in Community; OpenID Connect and SAML single sign-on are Enterprise add-ons.
  • Plane is the closest to the feel of a modern product team tool: fast, keyboard friendly, with cycles, modules, pages and an intake queue. The Community Edition is AGPL-3.0 and matches the Free tier of Plane Cloud. OIDC and SAML need a paid plan on the separate, closed-source Commercial Edition, LDAP needs the Enterprise Grid plan, and Plane’s documented Jira importer is offered on Cloud and on the Commercial Edition, not on Community.
  • Redmine is the simplest and the most stable in shape. It does issues, trackers, workflows, roadmaps, time tracking, wikis, email-to-issue and repository links, with LDAP in core and nothing held back for a paid edition because there is none. It has no Jira importer in core and no Scrum board without plugins.
  • For Subarnarekha we recommend a structured pilot of OpenProject Community, with LDAP against the existing directory, test runs of the Jira Migrator on representative projects, and a budget line for the Enterprise add-on only if Keycloak SSO turns out to be a must-have. Details later.
  • Do not migrate configuration. Migrate work. The value in Jira is the issues, comments, attachments and history. Most workflow schemes, screen schemes and custom fields are accumulated habits. Every tool in this post works better when you redesign the process first and import data into the new design.

Where things stand on 2 November 2026

Plane

  • Current release: Community Edition v1.4.3, published on GitHub on 29 October 2026 (Indian time; 28 October in UTC), after two release candidates in October. Before it came v1.4.2 on 23 August, v1.4.1 on 7 August and v1.4.0 on 31 July 2026. Community Edition v1.0.0 was published on 10 September 2025.
  • What is in 1.4.3: bug fixes, plus a security section that the notes summarise as “a set of access control issues”, with the advice that self-hosted instances should upgrade. Among them: publishing a project now needs project membership (earlier, any workspace member could publish a project they did not belong to, including a secret one); comments, reactions and votes on published boards are now bound to that board’s project; the sub-work-items endpoint is scoped to the project in the URL; and draft conversion is limited to the draft’s owner. The bundled object storage moved from the MinIO image to pgsty/silo pinned to a release tag, because the minio organisation was removed from Docker Hub, and the install scripts were fixed for a change in GitHub’s API output.
  • What came just before: v1.4.0 added lighter list endpoints in the REST API, webhook payloads with the workspace slug, OTLP metrics for self-hosted telemetry and instance logs kept only in PostgreSQL with per-type retention. v1.3.1 in May 2026 fixed three advisories (an analytics field injection, missing workspace checks on asset endpoints, and filename path traversal) and replaced an older toggle with a WEBHOOK_ALLOWED_IPS allowlist that blocks private addresses by default.
  • Editions: Community (AGPL-3.0, own codebase and release cycle, parity with the Cloud Free tier), Commercial (closed source, a built-in Free plan with 12 seats per workspace, paid plans unlocked by a licence key bound to one workspace and one machine) and Airgapped (Commercial for offline networks, Enterprise Grid only). Plane’s docs say new features reach Cloud first, then Commercial, then Community.
  • Requirements: the Docker Compose page lists 2 CPU cores and 4 GB of RAM, with 8 GB recommended for production.
  • Licence: AGPL-3.0 for the Community Edition repository.

OpenProject

  • Current release: 17.9.6 on 30 October 2026. The 17.9 line started with 17.9.0 on 30 September 2026 and had six maintenance releases in October; 17.9.5 on 30 October fixed an advisory where users without permission to view budgets could see budget subjects linked to a work package.
  • What is in 17.9: date alerts moved into the Community edition, creating work packages directly from documents, the first version of filters in Backlogs, an “Observed in versions” field for bugs, more MCP server capabilities, a password login policy for SSO users with a break-glass allowlist, configurable SAML clock drift, and a Jira Migrator that runs concurrent jobs with real-time progress and can be aborted, resumed or reverted during the import stage.
  • The year’s direction: 17.0 in January 2026 brought real-time collaborative documents and moved Docker and packaged installs to PostgreSQL 17 by default. 17.2 in March put a Jira importer behind a feature flag. 17.3 in April introduced dedicated sprint objects and made all action board types available in Community. 17.4 in April made the Jira Migrator available without a feature flag, in beta, with basic custom field support. 17.5 in June added optional project-based work package identifiers, so Jira keys like MES-1234 can be kept, and moved sprint sharing across projects to the Corporate plan. 17.6 in July added an XWiki integration as an Enterprise add-on. 17.8 in September made relation columns in the work package table available in Community.
  • Requirements: minimum hardware for up to 200 total users is a quad-core CPU, 4 GB of RAM and 20 GB of disk. PostgreSQL 16 or newer is officially supported. Docker is the recommended installation, and the docs say packages will not be provided for newer distributions such as Ubuntu 24.04.
  • Licence: GPL-3.0. The FAQ states that the Enterprise edition is also open source; Enterprise features are unlocked with a subscription token.

Redmine

  • Current releases: 7.0.3, 6.1.6 and 6.0.12, all dated 1 November 2026 on the download page. The announcement lists security fixes common to all three (a ReDoS in wiki macro argument parsing, a reflected XSS through an unvalidated back_url, and a URL validation bypass) plus two OAuth token scope fixes in 7.0.3 and 6.1.6. The project also said it will now release updates for the legacy 6.0 branch whenever High or Critical vulnerabilities are fixed.
  • 7.0: released at the end of June 2026, with webhooks on events (off by default, enabled from a new Integration tab), Rails 8, Ruby 4.0 support, a redesigned header and user menu, better right-to-left support, ZIP export of all wiki pages, inline previews of office documents and PDFs, and sudo mode enabled by default. 7.0.1 came on 26 August and 7.0.2 at the start of October.
  • Support policy: 7.0.x is fully supported, 6.1.x gets bug and security fixes, 6.0.x gets important security fixes only, and 5.1 and older are unsupported. The stated rhythm, on a best-effort basis, is a minor release every three months and a major release once a year.
  • Requirements: Redmine 7.0 supports Ruby 3.2 to 4.0 on Rails 8.1, with PostgreSQL 14, MySQL 8.0 to 8.4, SQL Server 2012 or newer, or SQLite (not for multi-user production). The project recommends Ruby 4.0.4 or later for 7.0 because Ruby 4.0.0 to 4.0.3 have a wiki rendering slowdown.
  • Licence: GPL-2.0, as stated on redmine.org and in the doc/COPYING file.

The first questions to ask

  1. Who uses the tracker, and for what? Developers running sprints, project managers planning dated rollouts, support logging customer problems, management reading reports. Count people in each group. A tool that delights one group and annoys three is a failed migration.
  2. What must move, and what can be archived? Open issues and the last two years of closed ones usually matter. Ten-year-old closed bugs may be fine as a read-only archive. Decide this before you look at importers.
  3. Which Jira deployment do you have? Data Center, Server or Cloud, and which version. Importers differ sharply on this.
  4. Which Marketplace apps hold data? Time logs, test cases, Gantt baselines and custom fields owned by apps often do not travel with the core issues.
  5. How do people sign in today, and how must they sign in tomorrow? LDAP, OIDC through Keycloak, SAML through Entra ID, or local passwords. This one question often decides between a free edition and a paid one.
  6. Who outside the company needs access? Customer users, contractors, auditors. Guest roles and per-project visibility matter here.
  7. What links into the tracker? Commit messages, merge requests, wiki pages, emails and chat messages full of issue keys. Broken links are the most common complaint after a move.
  8. Who owns it in year three? Upgrades every month or two, backups that are restored and tested, permission reviews, and the person who answers “why can’t I see this ticket?”

How each one works

Plane: a containerised web app with several services

Plane’s self-hosting guide describes eight application services: a Next.js web app, Space for public pages and intake forms, an admin console that Plane calls God mode, a Live server for real-time collaboration, a Django REST API, Celery workers, a Celery beat scheduler and a one-shot migrator that runs database migrations on each upgrade. Under them sit PostgreSQL, Redis (the v1.4.3 compose file uses a Valkey image), RabbitMQ as the message broker, S3-compatible object storage for attachments, and optional OpenSearch for full-text search, falling back to PostgreSQL search without it.

The compose file in the v1.4.3 release pins postgres:15.7-alpine, valkey/valkey:7.2.11-alpine, rabbitmq:3.13.6-management-alpine and the pgsty/silo object storage image, with the Plane images tagged v1.4.3 and a proxy container in front that publishes ports 80 and 443.

That is a lot of moving parts for a tracker, but each is standard. If your team already runs PostgreSQL, Redis and an S3-compatible store, Plane’s docs recommend pointing it at those rather than running everything inside one compose project. The same docs call running PostgreSQL inside the Plane stack in production an anti-pattern.

OpenProject: one Rails application with workers

OpenProject is a Ruby on Rails application served by Puma, with background workers for email, exports and heavy jobs, a PostgreSQL database, attachment storage on disk or S3, and Memcached in multi-server setups. Since 17.0 there is also a Hocuspocus service for real-time document collaboration. By default it runs 4 web workers and 1 background worker.

You can install it in three ways: Docker Compose (recommended), an all-in-one container for small or test setups, or DEB/RPM packages on Ubuntu 22.04, Debian 12, RHEL 9 and SLES 15. The packages come with a configuration wizard and an openproject command for backups, consoles and configuration. Kubernetes users get Helm charts.

Redmine: a classic Rails app you can read in an afternoon

Redmine is one Rails application, one database and a files directory for attachments. You install it from a tarball or Subversion checkout, run bundle install, set a session secret, run migrations and load default data. Behind a reverse proxy, it runs on Puma or Passenger. Its source tree is small enough that many teams patch it themselves, which is both its strength and its trap.

Most Redmine features beyond core come from plugins, which are Rails engines dropped into plugins/. Agile boards, OpenID Connect sign-in, advanced reporting and many importers live there, maintained by third parties at different speeds.

Data model and workflows

Plane

  • Structure: workspace, then projects, then work items. Work items have states, priorities, labels, assignees, estimates, parent and child links, relations and attachments.
  • States belong to fixed groups (backlog, unstarted, started, completed, cancelled), so reports can reason about progress even when each project names its states differently.
  • Cycles are Plane’s sprints. Modules group work items into features or epics across cycles. Views save filtered lists. Pages hold documents next to the work, and Intake collects requests from outside the team for triage.
  • Workflows: Plane keeps the state model simple. Plane’s importer documentation notes that work item types are a paid-plan feature, and the Community Edition is equal to the Cloud Free tier, so do not expect Jira-style per-type workflows in it.
  • What feels different from Jira: there are fewer configuration layers. A team that wants Jira’s schemes will feel limited. A team that hated Jira’s schemes will feel relief.

OpenProject

  • Structure: projects in a hierarchy, with programs and portfolios as an Enterprise add-on since 17.0. Work happens in work packages, each with a type (task, bug, feature, milestone and your own), a status and fields.
  • Workflows are configured per role and type, so a tester and a developer can be allowed different status changes on the same bug. Since 17.3 there is better workflow configuration for administrators, and 17.5 added multi-selection of roles.
  • Agile: the Backlogs module now uses dedicated sprint objects (since 17.3, replacing versions as a workaround), backlog buckets, sprint goals and filters (17.9). All board types (Basic, Kanban, Assignee, Version, Subproject, Parent-child) are in Community since 17.3.
  • Classic planning: Gantt charts with dependencies and milestones, time tracking, labour and unit costs, and budgets. This is where OpenProject is clearly stronger than the other two.
  • Around the work: meetings with agendas that can turn items into work packages, a project wiki, real-time documents, and integrations with GitLab, GitHub, Nextcloud and (Enterprise) XWiki and SharePoint.

Redmine

  • Structure: projects with subprojects, issues with trackers (Bug, Feature, Support and your own), statuses, priorities, categories, target versions, custom fields, watchers and relations.
  • Workflows are set per tracker and per role, as a grid of allowed status transitions and field permissions. It is plain and powerful, and many organisations have run the same workflow for fifteen years.
  • Planning: a roadmap by version, a Gantt chart and a calendar, time tracking with activities and custom fields. There is no sprint object or Scrum board in core.
  • Around the work: per-project wikis, forums, news, documents, file releases, repository browsing for Git, Subversion and Mercurial, and issue creation and replies by email. Since 7.0, outgoing webhooks on events.
  • What feels different from Jira: everything is a form and a list. Users who live in Jira’s boards will feel the age. Users who mostly file and search issues will not notice much.

Security, sign-in and permissions

Who can sign in, and how

  • Plane Community: email with password, one-time codes by email, and OAuth sign-in with Google, GitHub, GitLab and Gitea, configured once in God mode for every workspace. Plane’s own academy page says OIDC and SAML need a paid plan (one workspace on Pro or Business makes them available across the instance), and LDAP needs Enterprise Grid. All of these require moving from Community to the Commercial Edition. Plane also notes that “allow anyone to sign up” is on for a new instance, so anyone who reaches your domain can create an account and a workspace until you turn it off.
  • OpenProject Community: internal accounts, LDAP authentication against Active Directory or OpenLDAP, Kerberos through Apache, two-factor authentication with TOTP or WebAuthn, and OpenProject itself as an OAuth server for other tools. The authentication overview marks OpenID Connect SSO, SAML SSO, SCIM provisioning and LDAP group synchronisation as Enterprise add-ons.
  • Redmine: local accounts, multiple LDAP sources in core, two-factor authentication with TOTP, and since 6.1 Redmine can act as an OAuth2 provider for API clients. OpenID Connect and SAML sign-in come only from third-party plugins.

For Subarnarekha this is the deciding detail. Their directory is OpenLDAP, so OpenProject Community and Redmine can use it directly. If they insist on Keycloak with OIDC, OpenProject needs the Enterprise add-on and Plane needs a paid Commercial plan. With Redmine they would depend on a third-party plugin.

Permissions

  • Plane has two independent layers: workspace roles and project roles. A person can be a workspace Member and a project Admin. Custom roles and granular permission schemes belong to Enterprise Grid.
  • OpenProject has global roles and project roles with a long permission list, nested groups since 17.3, and options introduced in 17.0 to hide users who do not share a project.
  • Redmine has roles with per-project membership, a grid of permissions per role and per tracker, private issues, and visibility settings for issues (“all”, “non private”, “created by or assigned to the user”). Public projects are visible to anonymous users unless you disable that, which is a classic mistake on internet-facing installs.

The advisory record

All three projects publish security fixes regularly, and the volume this year is a reminder to plan upgrades as routine work, not events.

  • Plane fixed several access control and isolation bugs in v1.4.3 and three advisories in v1.3.1.
  • OpenProject listed security fixes in many 2026 releases, including a path traversal in the BCF import (CVE-2026-30234), a blind SSRF through webhooks (CVE-2026-31974), missing rate limiting on 2FA codes (CVE-2026-33667) and, in 17.4, a Docker issue where containers started with a default SECRET_KEY_BASE that could allow code execution. Since 17.4 the containers refuse to start without a proper value. OpenProject runs a bug bounty on YesWeHack sponsored by the European Commission, which partly explains the number of reports.
  • Redmine published security fixes in every maintenance release this year, from LDAP injection and stored XSS fixes in early 2026 to the three fixes of 1 November.

Defect data is business data

Bug reports often contain more than people think: customer names, server addresses, screenshots with personal data, log extracts with phone numbers, sometimes credentials pasted in a hurry. Before you move a backlog, decide who can see which projects, whether customer users get access, how long closed issues are kept and how you handle a deletion request. If your issues contain personal data of Indian users, the Digital Personal Data Protection Act, 2023 is relevant to purpose, retention and deletion. This is not legal advice; ask your counsel what applies to you.

Performance and capacity

Only one project publishes sizing guidance with numbers, so this section is short. We did not run load tests.

  • OpenProject’s own guidance: up to 200 active users, 4 cores, 4 GB of RAM, 2 web workers, 1 background worker and 20 GB of disk; about 500 users, 8 cores, 8 GB, 4 web workers, 2 background workers and 40 GB; about 1,500 users, 16 cores, 16 GB, 8 web workers, 4 background workers and 80 GB. The docs also give per-500-user scaling parameters from their SaaS (2 database CPUs and 8 GiB per about 500 users, 4 to 6 CPUs, 6 to 8 GiB RAM, 4 more web workers). They stress that concurrent users matter more than total users, and that even 5 users should get 2 web workers because a page makes several requests at once. These are the project’s own guidelines, not independent measurements.
  • Plane’s own guidance: 2 cores and 4 GB of RAM as the minimum for Docker Compose, 8 GB recommended for production. The self-hosting guide also gives a time budget: 1 to 3 days of one engineer to stand up Docker Compose, 3 to 5 more days in the first month for hardening, and 0.1 to 0.25 of an engineer’s time per year at small scale. That is Plane’s estimate.
  • Redmine publishes no sizing table. It is a single Rails application, and its weight depends mostly on the database, attachments and plugins. The 7.0 notes mention performance work such as an index for @mention lookups that previously caused full table scans on large instances like redmine.org.

For Subarnarekha, with about 140 users and perhaps 40 at the same time, any of the three fits on one modest VM plus a database. Capacity is not the deciding factor here. Attachments are: years of screenshots and log files can be larger than the database, so measure the Jira attachment directory before you size disks or object storage.

Licences and editions

  • Plane Community Edition is AGPL-3.0. Plane’s own guide puts it plainly: internal use and internal modification are fine; hosting it as a service for external customers requires you to publish your modifications; embedding it in a commercial product means complying with the AGPL or buying a commercial licence. The Commercial Edition is a different, closed-source codebase. Plane’s public pricing, as stated on its own self-hosting whitepaper, lists Free for up to 12 users, Pro at $6 per seat per month, Business at $13 per seat per month (annual) and Enterprise Grid by quote. Check the current page before you budget.
  • OpenProject is GPL-3.0, and the Enterprise features are in the same open-source code, unlocked with a token. Enterprise plans are sold per user, with names such as Basic and Corporate appearing in the release notes when a feature moves between plans; for example, cross-project sprint sharing moved to the Corporate plan in 17.5. The direction this year has mostly been the other way: action boards, date alerts and relation columns all moved into Community.
  • Redmine is GPL-2.0 with no paid edition. Plugins carry their own licences, and some popular ones are sold commercially by third parties. Check each plugin’s licence and update history before depending on it.

The practical difference: with Redmine and OpenProject Community you can run forever without a commercial relationship, and the code you run is the code you can read. With Plane, the open edition is a real product, but sign-in beyond OAuth, the Jira importer and advanced workflows sit in a closed edition. That is a legitimate business model; just know which side of the line your requirements fall on before you commit.

Operations and day two

Install

  • Plane Community: download setup.sh from the latest GitHub release, choose Install, edit plane.env (domain, WEB_URL, CORS_ALLOWED_ORIGINS, ports), then Start. The default install path on Plane’s docs page now installs the Commercial Edition through prime.plane.so; the Community steps are in a collapsed section further down, so read carefully which edition you are installing.
  • OpenProject: the Docker Compose repository, the all-in-one container (openproject/openproject:17) for tests, or packages with a configuration wizard. You must set SECRET_KEY_BASE; since 17.4 the containers will not boot without it.
  • Redmine: tarball plus Ruby, Bundler and a database, or a container image. Configure database.yml, configuration.yml (SMTP, attachment path, and a database_cipher_key so LDAP and SCM passwords are encrypted in the database, with the redmine:ciphering:encrypt task), generate the secret, migrate.

Upgrades

  • Plane ships minor releases every 4 to 8 weeks by its own description. The migrator runs on each upgrade. Plane warns that skipping upgrades for six months or more increases risk and suggests a quarterly minimum.
  • OpenProject releases a feature version monthly and maintenance releases in between, as you can see from six 17.9.x releases in one month. Watch the “Important updates and breaking changes” section of each release note. PostgreSQL major upgrades are a separate step; 17.0 changed the default to PostgreSQL 17 without upgrading existing clusters automatically.
  • Redmine upgrades are a new tarball, copying config, files and plugins, bundle install, rake db:migrate and plugin migrations. The work is in the plugins: a major Rails change, like the move to Rails 8 in Redmine 7.0, often breaks plugins that are not actively maintained.

Backups

  • Plane: setup.sh has a Backup Data action. In the v1.4.3 script it copies the data directories of the running PostgreSQL, object storage, RabbitMQ and Redis containers with docker cp and compresses them. A file-level copy of a running PostgreSQL data directory is not guaranteed to be consistent. We would add a nightly pg_dump (or use a managed database with its own backups) and copy the object storage bucket separately. See PostgreSQL backups in 2026.
  • OpenProject: packaged installs have openproject run backup, which writes a PostgreSQL dump, attachments, configuration and repositories to /var/db/openproject/backup. For Docker, the docs show pg_dump from the database container and backing up the volumes.
  • Redmine: the database and the files directory, as the install guide says. Add config/ and your plugins so you can rebuild the same instance.

For all three: back up before every upgrade, restore to a test VM within the first month, and then once a quarter. A tracker that loses a week of tickets loses a week of memory.

Migration from Jira

OpenProject’s Jira Migrator

  • Status: beta. The documentation says to use it only in test setups for now. It reached general availability as a beta in 17.4 and gained concurrent jobs, abort, resume and revert in 17.9.
  • Source: Jira Data Center 10.x and 11.x only. Jira Cloud is not supported, and Jira Server is not supported yet.
  • What it imports today: projects and project identifiers, versions, issues with identifiers, descriptions, history, comments and attachments, a subset of custom fields (text, number, date, list, checkbox, URL, user, labels and cascading select, per the FAQ), users and groups involved, statuses and types. Jira wiki markup is converted to Markdown during import.
  • Coming soon: relations between issues and sprint assignments. Coming later: project-level workflows, permissions and schemes.
  • How it works: you need project-based identifiers enabled, a Jira personal access token with admin permission, and, if Jira is on a private network, an addition to OPENPROJECT_SSRF__PROTECTION__IP__ALLOWLIST because OpenProject blocks outbound requests to private addresses by default. Each run lands in review mode, where you can approve or revert it. New users stay locked until approval, and Jira users who were disabled come in as locked users that do not count towards Enterprise seats.
  • What does not move: data owned by Marketplace apps (time logs in a Tempo-style app, test cases in Xray or Zephyr), boards, filters, dashboards, schemes and Confluence content. OpenProject says plainly that it has no Confluence migrator and suggests XWiki for that part.

Plane’s Jira importer

  • Edition: Plane’s documentation says the Jira importer is available on Plane Cloud and on all plans of the Commercial Edition for self-hosted instances. It is not part of the Community Edition. The Commercial Free plan (12 seats per workspace) can run it, but that plan is closed source.
  • Source: Jira Cloud, and Jira Server or Data Center through one connector. You can filter issues with JQL.
  • What maps, per Plane’s own documentation: labels, statuses to states, priorities, issues to work items, parent-child links, comments, attachments, reporter, created date, assignees, images in descriptions, linked issues as links, and sprints to cycles with dates. Issue types become work item types only on paid plans with that feature enabled. Users come through a CSV export from Jira Cloud, or are invited later.
  • What to watch: seats. Plane notes that invited Admin and Member users count towards billed seats as soon as they are invited.

Redmine: CSV, scripts and patience

  • Core: Redmine has imported issues from CSV since 3.2, with field mapping, parent tasks through a unique ID column and relations mapping. The import creates new issues only and cannot update existing ones. Redmine core also ships migration tasks for Trac and Mantis, but none for Jira; we checked the lib/tasks folder in the 7.0.3 tarball.
  • What you lose with CSV: comments as separate journal entries, change history, attachments and inline images, unless you write a script against both REST APIs. Several community scripts and paid plugins exist; test any of them on a copy, and expect to fix things.

What does not move, whichever tool you choose

  • Workflow schemes, screen schemes, permission schemes and notification schemes. Redesign them.
  • Automation rules and ScriptRunner scripts. Inventory and decide one by one.
  • Dashboards and saved filters. Rebuild the few that people actually open.
  • Links from commits, wikis and emails to Jira URLs. Keep the old Jira read-only for a while, or put a small redirect service in front of the old hostname that maps issue keys to new URLs. OpenProject’s project-based identifiers help here because keys like MES-1234 stay the same.

Side by side

Best fit

  • Plane: software product teams who want a fast, modern tracker with cycles and docs, and who are fine with OAuth sign-in or with paying for the Commercial Edition.
  • OpenProject: mixed organisations where developers run sprints and project managers run dated plans, budgets and time sheets, and where staying fully open source matters.
  • Redmine: teams who need a stable, simple issue tracker with email intake and LDAP, and who value low change over modern UI.

What you get free

  • Plane Community: work items, cycles, modules, views, pages, intake, OAuth sign-in, REST API and webhooks. No OIDC, SAML, LDAP or Jira importer.
  • OpenProject Community: work packages, workflows, backlogs and sprints, all boards, Gantt, time and cost tracking, meetings, wiki, documents, LDAP, 2FA. OIDC, SAML, SCIM, LDAP group sync, portfolios and some meeting and export features are Enterprise.
  • Redmine: everything in the product, because there is no paid edition. Agile boards and SSO beyond LDAP come from plugins.

Sign-in

  • Plane: password, email codes and Google, GitHub, GitLab or Gitea OAuth in Community; OIDC and SAML on paid Commercial plans; LDAP on Enterprise Grid.
  • OpenProject: local, LDAP, Kerberos and 2FA in Community; OIDC and SAML as Enterprise add-ons.
  • Redmine: local, LDAP and 2FA in core; OIDC or SAML through plugins.

Jira migration

  • Plane: documented importer for Cloud, Server and Data Center, on Commercial plans only.
  • OpenProject: beta Jira Migrator for Data Center 10.x and 11.x, with review and revert.
  • Redmine: CSV import in core, scripts or plugins for anything richer.

Operations

  • Plane: eight application services plus PostgreSQL, Redis or Valkey, RabbitMQ and object storage; Docker Compose or Kubernetes.
  • OpenProject: one Rails app with workers and PostgreSQL, plus Hocuspocus for documents; Docker, packages or Helm.
  • Redmine: one Rails app, a database and a files directory, plus whatever plugins you add.

Licence

  • Plane: AGPL-3.0 Community; closed-source Commercial.
  • OpenProject: GPL-3.0 for Community and Enterprise code.
  • Redmine: GPL-2.0.

A worked plan for Subarnarekha

Month 1: inventory and design. Export the list of Jira projects with issue counts, attachment size, custom fields actually filled in the last year, workflows, boards and the six apps. Mark each project as migrate, archive read-only, or retire. Interview two people from each group (developers, implementation, support, managers) about the three reports they open every week. Write the target design on two pages: work package types, statuses, who may change what, and which fields survive. Decide the time tracking rule for billing first, because that is the app data that will not move by itself.

Month 2: a test OpenProject. One VM in the Mumbai region with 4 cores and 8 GB, Docker Compose, OpenProject 17.9 with SECRET_KEY_BASE set from a secret store, PostgreSQL on a separate managed instance or at least its own volume with nightly pg_dump, attachments on S3-compatible storage. LDAP authentication against OpenLDAP, limited by a filter to staff accounts. Turn on project-based identifiers. Add the Jira host to the SSRF allowlist only on this test instance. Run the Jira Migrator on four representative projects, as OpenProject’s own FAQ suggests: one ordinary, one heavily customised, one large and one that depends on an app. Record duration, warnings, rejected items and manual fixes.

Month 3: a real pilot. One product team runs two sprints in OpenProject Backlogs, and one implementation team plans a plant rollout in the Gantt chart with time logged against it. Connect GitLab so merge requests appear on work packages. Restore the whole instance from backup onto a second VM and log in. Ask both teams one question at the end: would you go back?

Months 4 to 9: migrate in batches. Move projects team by team, each in its own import run, approved only after a team lead checks it. Set each Jira project to read-only as it moves. Rebuild the few dashboards people actually use. Put a small redirect on the old Jira hostname for issue keys. Keep Jira Data Center running read-only until the current subscription ends, and take a full Jira XML backup plus attachments as a cold archive.

The SSO question. If, after the pilot, management insists on Keycloak OIDC instead of LDAP, buy the OpenProject Enterprise plan that includes it for the number of active users, not the Jira head count. If not, stay on Community.

Support tickets. Leave customer support in its current mailbox for now. Moving support into a tracker is a separate project with SLAs, portals and customer accounts, and OpenProject’s own FAQ says it does not yet cover the full Jira Service Management feature set.

Confluence. Out of scope for this project. Plan it separately; see our post on self-hosted wikis.

Why not Plane for them? Their product teams would probably enjoy Plane more. But the project managers’ Gantt and time-tracking needs, LDAP sign-in in the free edition, and a Jira importer in the open-source edition all point to OpenProject. Why not Redmine? It would run happily for ten years, but without plugins it gives the product teams no sprint board and the migration would rely on scripts.

When not to adopt each

  • Do not pick Plane Community if you need OIDC, SAML or LDAP sign-in without paying, a Jira importer in an open-source edition, or detailed per-role workflows. Also not if you cannot run and back up a multi-service container stack properly.
  • Do not pick OpenProject if your teams want a minimal tracker and will resent Gantt charts, budgets and meetings in the menu, or if you need a production-ready Jira import next month; the migrator is still beta and Data Center only.
  • Do not pick Redmine if your developers expect a modern board-first experience, or if you will end up depending on five plugins whose maintainers you cannot name. Plugins are where Redmine installations age badly.
  • Do not self-host at all if nobody can own upgrades every month or two, nobody will test restores, or the only reason is a vague wish to leave Atlassian. Jira Cloud, or a hosted edition of any of these three, may cost less than the people time.

A short history

  • Redmine: Jean-Philippe Lang made the first commit on 28 June 2006. It grew into one of the most widely deployed open-source trackers, and its 7.0 release in 2026 marks twenty years of continuous maintenance.
  • OpenProject: its copyright file records the lineage. Redmine was forked as ChiliProject around 2010 to 2011, and OpenProject was derived from ChiliProject; the OpenProject repository was created in November 2012. Over the years it rewrote much of its interface and moved far beyond Redmine’s scope, into planning, budgets, meetings and documents.
  • Plane: the repository was created in November 2022, and the project quickly became one of the most watched open-source trackers on GitHub. The Community Edition reached v1.0.0 in September 2025, alongside a separate Commercial Edition.
  • Jira Data Center: Atlassian ended Server products in February 2024 and announced in September 2025 that Data Center would follow, with end of life on 28 March 2029.

A simple decision guide

  • Do you need Gantt charts, budgets and time tracking next to sprints, and free LDAP sign-in? Choose OpenProject.
  • Is it a software product team that wants speed and a modern feel, and can you accept OAuth sign-in or pay for SSO? Choose Plane.
  • Do you need a plain, stable issue tracker with email intake, and does nobody care about boards? Choose Redmine.
  • Must you import from Jira Cloud? Only Plane’s Commercial Edition documents that today; plan for scripts or vendor help otherwise.
  • Can nobody own monthly upgrades and tested restores? Use a hosted service.

Checklist before go-live

  • Inventory of Jira projects, issue counts, attachment size, custom fields in use and Marketplace apps with data.
  • A two-page target design: types, statuses, transitions, fields, roles.
  • Sign-in decided (LDAP, OIDC, SAML or local) and tested with a disabled account to confirm it cannot log in.
  • Open sign-up turned off; anonymous access to public projects turned off unless you mean it.
  • Secrets set: SECRET_KEY_BASE for OpenProject, SECRET_KEY, LIVE_SERVER_SECRET_KEY and database, RabbitMQ and storage passwords for Plane, the session secret and database_cipher_key for Redmine.
  • TLS on the public name, and the tracker behind a reverse proxy you already manage.
  • SMTP configured and tested, including notification volume on a busy day.
  • Database dumps and attachment backups running, copied off the host, and one restore tested.
  • A test import approved by a team lead, with a list of what was fixed by hand.
  • Git integration tested: a merge request with an issue key shows up on the work item.
  • Old Jira set to read-only per migrated project, with a redirect plan for links.
  • Upgrade owner and cadence written down, and the security advisories feed subscribed.

Common mistakes

  • Copying Jira’s configuration. Thirty custom fields and nine workflows recreated by hand in the new tool bring the old pain with them.
  • Migrating everything. Ten years of closed issues slow down imports and searches. Archive what nobody reads.
  • Forgetting app data. Time logs and test cases in Marketplace apps are often the data finance and auditors care about most.
  • Choosing the edition by habit. Plane’s default install docs now lead to the Commercial Edition, and OIDC in OpenProject is Enterprise. Check which edition your must-have features live in.
  • Leaving defaults. Plane’s sample environment file ships placeholder secrets and passwords such as change-this-key-on-deployment, and OpenProject’s Docker images once shipped a default secret. Replace every placeholder before the first user logs in.
  • Trusting a file copy of a live database. Use pg_dump or proper PostgreSQL backups and test the restore.
  • Ignoring links. Issue keys in commits and wikis are your institutional memory. Keep keys stable where you can and redirect the rest.
  • Upgrading once a year. All three projects fixed security issues several times this year. Small, regular upgrades are safer than big jumps.

Hands-on check: what we ran and what we did not

We kept this check small, user-level and inside /workspace/revisit/drill106 on our shared Linux box, on 2 November 2026 at about 2:22 PM IST. The box has no Ruby and no Docker daemon we may use, so we did not start Plane, OpenProject or Redmine. Plane and OpenProject need Docker or system packages, and Redmine needs a Ruby toolchain and a database. Nothing was installed system-wide and no server process was started.

What we did:

  • Downloaded redmine-7.0.3.tar.gz (4,266,418 bytes). Its SHA-256 matched the value on the Redmine download page.
  • Read the tarball: lib/redmine/version.rb reports 7.0.3, the Gemfile requires Ruby >= 3.2.0, < 4.1.0 and Rails 8.1.4, and there are 327 database migration files. lib/tasks contains migrate_from_mantis.rake and migrate_from_trac.rake but no Jira task, which confirms that a Jira move to Redmine needs CSV or outside scripts. configuration.yml.example has the database_cipher_key setting and ciphering.rake has tasks to encrypt and decrypt SCM and LDAP passwords.
  • Downloaded docker-compose.yml, setup.sh, variables.env and restore.sh from the Plane v1.4.3 release. All four SHA-256 values matched the digests GitHub lists for the release assets.
  • Read the Plane compose file: 13 services (web, space, admin, live, api, worker, beat-worker, migrator, PostgreSQL 15.7, Valkey 7.2.11, RabbitMQ 3.13.6, pgsty/silo object storage and the proxy).
  • Read variables.env: it ships SECRET_KEY=change-this-key-on-deployment, the same placeholder for LIVE_SERVER_SECRET_KEY, plane as the PostgreSQL and RabbitMQ password, placeholder storage keys and TRUSTED_PROXIES=0.0.0.0/0. We found no code in setup.sh that generates these values, so treat changing them as your job.
  • Read the Backup Data function in setup.sh: it uses docker cp on the running containers’ data directories for PostgreSQL, object storage, RabbitMQ and Redis, then makes a tar.gz of each. That is why we recommend pg_dump in addition.

What we did not do: run any of the three applications, test sign-in, import Jira data or measure performance. Those need a proper VM with Docker or Ruby and a test copy of Jira.

Unlearn and re-learn

  • Unlearn: “We need a Jira replacement.” Re-learn: you need a home for your work and your history; the replacement should be simpler than what you had.
  • Unlearn: “The importer will move everything.” Re-learn: importers move issues, comments and attachments; people move processes.
  • Unlearn: “Open source means every feature is free.” Re-learn: check which edition holds SSO, importers and workflows before you choose.
  • Unlearn: “2029 is far away.” Re-learn: a careful migration with pilots and batches takes most of a year; starting in 2027 is comfortable, starting in 2028 is not.

Sources

comments powered by Disqus

Releted Posts

Self-hosted wikis in 2026: revisit BookStack, Wiki.js and Outline before you write another runbook in a shared drive

Ask any support engineer in a growing Indian company where the runbook for a failed nightly job lives, and you will usually get three answers.

Read more

Workflow automation in 2026: revisit n8n, Node-RED and Activepieces before you wire another business process to a webhook

Most teams first meet workflow automation as a shortcut: draw a few boxes, point a webhook at a SaaS, and declare the process automated.

Read more

Static code analysis in 2026: revisit Semgrep, Opengrep and SonarQube Community Build before you add another code scanner to CI

Most teams add a code scanner to CI in an afternoon. A YAML job, a default rule pack, a green tick.

Read more