Which open-source alternative to Azure Boards fits your team
If a renewal, a licensing change or a data residency requirement is forcing a decision about Azure Boards, the self-hosted options are OpenProject, Plane and Redmine. The right one depends on three things: how deep your work hierarchy needs to go, how much of your process is agile (backlogs, sprints and boards), and how tightly work items must link to commits and merge requests in your Git host. Before comparing tools, confirm which of these three your teams actually use today, because Boards is often configured far less than it could be.
Azure Boards is one module of Azure DevOps, alongside Azure Repos, Pipelines and Artifacts. Replacing Boards does not require moving the rest of the suite on the same day. Many teams keep Azure Repos and Pipelines running while they test a tracker in parallel, and only retire Boards once work items, links and sprint history have been exported and checked. Ask your Azure DevOps administrators which Boards features are in use, such as custom work item types, area paths, queries and dashboards, since each one changes how much effort a move will take.
Plan the decision as a short evaluation rather than a single switch. Run a pilot with one real team, import a copy of its backlog, and check that epics, features and user stories land in the hierarchy you expect. Confirm the chosen tool's authentication options with your identity team, and confirm how links to commits will work once the Git host changes. Ask each vendor or community for written answers on these points before you commit, and treat any gap you find during the pilot as an input to the scope of a fixed-scope implementation.
How Azure Boards capabilities map to OpenProject, Plane and Redmine
This table compares the Azure Boards capabilities that most teams use with OpenProject, Plane and Redmine. Read each row as a question to confirm in a pilot, since product behavior and edition boundaries change between releases. The main takeaway is that all three cover core tracking, but hierarchy, Enterprise-only identity features and Test Plans need explicit checks before you choose.
| Capability | OpenProject | Plane | Redmine |
|---|---|---|---|
| Work items, epics and user stories | Work package types such as epic, feature and user story can be configured per project, so confirm the hierarchy in your instance | Work items with states, priorities and parent relationships; confirm how epics and features are modeled in the edition you run | Trackers and custom fields replace a fixed work item hierarchy; parent-child issues exist, but types must be designed by your team |
| Backlogs, sprints and boards | Agile boards and sprint-style planning are in the Community edition; confirm backlog ranking and sprint reporting | Cycles and modules support sprint-style planning; confirm board views and backlog ordering in your edition | No native Scrum backlog or board; teams usually add plugins or use versions and filters, so confirm plugin choice and maintenance |
| Queries and dashboards | Work package views and dashboards are included; confirm saved filters match your Azure Boards queries | Views and filters are available; confirm that saved views can be shared with the teams that need them | Saved queries and custom dashboards depend on configuration and plugins; test complex queries before migrating |
| Delivery plans and Gantt charts | Gantt charts are included in the Community edition, so confirm dependency and baseline needs | Timeline views are available; confirm dependency handling against your Azure Boards plans | Gantt charts and calendars are built in; confirm dependency behavior for your project structure |
| Wiki and documentation | Project wiki is included; confirm access rules and attachments against your current wiki content | Pages cover project documentation; confirm whether Azure DevOps wiki content will be migrated or kept separately | Wikis per project are built in; confirm formatting and attachment migration |
| REST API for integrations | Full API is available; confirm the endpoints your pipelines and reports use | API is available for self-hosted instances; confirm rate and scope limits for bulk exports | REST API must be enabled by an administrator and covers issues, projects, users and time entries |
| SSO and LDAP | SAML, OIDC and LDAP group sync are Enterprise features; the Community edition does not include them | SAML and OIDC are on Pro and above; LDAP is an Enterprise feature on self-hosted Plane | Multiple LDAP authentication sources are built in; confirm SSO options through your web server or plugins |
| Attachments and file storage | Attachments are supported; confirm storage location and size limits on your install | Attachments use S3-compatible object storage such as MinIO; plan capacity and backups for that store | Files are stored on the server; plan backup of the uploaded files directory as part of upgrades |
| Test Plans and test management | Not included; a test management tool or plugin must be added | Not included in Plane; plan a separate test tool | Not included; test management requires a separate tool or plugin |
When OpenProject, Plane or Redmine fits best
Each of these tools covers part of what Azure Boards does, but they differ in license, edition model and how much of the work tracking your team can keep. The cards below set out the trade-off for each, so you can match the tool to your backlog, your integration needs and the in-house effort you can sustain.
OpenProject for hierarchical planning
OpenProject is licensed under GPL-3.0 and developed by OpenProject GmbH. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. The Enterprise on-premises edition is priced per named user per month and adds single sign-on and LDAP group synchronization. The trade-off is that identity integration sits behind a paid tier, so confirm early whether your directory requirements force an Enterprise subscription. Ask the vendor for a quote based on your named user count.
Plane for a modern Boards replacement
Plane offers Community, Commercial and Airgapped self-hosted editions, each built on a distinct codebase. Community is licensed under AGPL-3.0 and matches the Free cloud feature set. A self-hosted Community install must switch to the Commercial edition before it can use a paid plan, and paid plans count seats by users with paid roles. The trade-off is an edition migration step and a proprietary Commercial codebase. Check whether your Azure Boards users need SAML or OIDC, which Plane lists from Pro upward.
Redmine for issue tracking with SCM links
Redmine is written in Ruby on Rails and released under GPL v2. It has no paid edition, so cost comes from hosting, plugins, upgrades and the staff who maintain it. Its issue tracking, role-based access control and SCM integration with Git are mature, which suits teams that link work items to commits directly. The trade-off is that Redmine has no supported Azure Boards importer, so plan for scripted migration and test it. Only the 7.0.x line receives new features, so budget for regular upgrades.
Upgrade and support effort
Community editions of all three tools are free to download, so the recurring cost is the people and infrastructure that run them. OpenProject Community relies on community support, while Plane and Redmine maintenance depends on your own staff or a partner retainer. Ask each vendor what support tier covers production incidents, and estimate the upgrade effort for each release cycle. A tool with frequent releases needs a planned upgrade window, not an occasional one.
Integration and access controls
Check how each candidate handles identity before you commit. OpenProject lists SAML, OIDC, CAS, Kerberos and Okta under Enterprise, with LDAP group synchronization. Plane lists SAML and OIDC from Pro, and LDAP and API audit logs under Enterprise. Redmine supports multiple LDAP authentication sources in its base software. Map your directory groups to project roles before the pilot, because role mapping errors are hard to fix after users have migrated.
How epics, features and user stories map to self-hosted tools
The mapping decision comes before any export, because each target tool models the Azure Boards hierarchy differently and a wrong guess is costly to undo. Azure Boards organizes work as Epics containing Features, which contain User Stories, which in turn hold Tasks, while Bugs usually sit alongside stories. OpenProject can model this chain with work package types: your team defines which types exist and which may be children of which, so Epic, Feature and User Story can each become a distinct type in one hierarchy. Plane is flatter. Its issues can be grouped into modules, so an Epic often becomes a module while Features or Stories become issues, but confirm how your Plane edition represents parent and child issues before you commit to that shape. Redmine uses trackers, each with its own workflow, and parent tasks for nesting, so Epic, Feature and Story can be separate trackers linked through parent tasks, with Task and Bug as further trackers.
Three things rarely map cleanly and must be rebuilt by hand or by script. The first is state. Azure work item states come from the process template your organization uses, and each target has its own statuses or workflow transitions, so a state with no direct equivalent must be assigned to the nearest existing status. The second is custom fields. Priority, area path and iteration path each need a home: area paths often become projects or subprojects, iterations often become versions, cycles or modules, and every custom field needs a matching field type in the target. The third is links. Parent and child relationships carry over most cleanly once the hierarchy is settled, while predecessor, successor and related links depend on what the importer or API supports, which the team should test. Work item history and attachments may not transfer in full, so decide in advance which history must be kept as a note on the migrated item.
Agree the mapping in writing before any data leaves Azure DevOps. A short mapping sheet should list each Azure type, state and field, the target type, status or field it maps to, and a named owner who signs off on each row. Include decisions for items that are closed, duplicated or orphaned, since these are where teams most often disagree later. Test the sheet on a sample export loaded into a non-production instance, then check that a story still sits under its feature, that its state reads correctly on the board and that its history note is present. Ask each tool owner or importer maintainer to confirm in writing which fields and links their import supports. Confirm whether any importer covers Azure Boards at all: the OpenProject migrator documented on its site targets Jira, and Redmine's built-in importers are marked obsolete. Keep the signed mapping with the migration record, since auditors and new team members will need it later.
Linking work items to commits when Repos stays in place or moves
Work item linking depends on where the code lives and which tracker holds the work. Each option below keeps commit history and work items connected in a different way, so the choice should follow from whether Azure Repos stays, moves to GitLab, moves to Gitea or Forgejo, or pairs Redmine with Git repositories.
Keep Azure Repos and link from Boards
If Azure Repos stays in place, Azure Boards can keep its existing AB# style links to commits and pull requests while the tracker moves. Any replacement tracker then loses those automatic links, so teams usually record the new work item ID in the commit message or pull request description during the transition. Check whether the replacement tracker can read external references, and confirm the exact reference syntax in your chosen tool before relying on it. Keep the old Boards IDs in an export so history stays searchable.
Move repositories to GitLab
GitLab can import projects from Azure Repos-adjacent sources and Git repositories by URL, and it keeps issues and merge requests in the same instance as the code. Issue references in commit messages and merge requests close or link work items when the project's issue tracker is used, so most teams move code and issues together. Confirm that the import covers the work items you need, since Azure Boards work item types and fields do not map one to one. Plan a parallel period where both trackers stay readable.
Move to Gitea or Forgejo
Gitea and Forgejo link commits to issues and pull requests through issue numbers in commit messages, but they do not provide Azure Boards hierarchy, so epics and features stay in the tracker you pick. Forgejo's dump-repo and restore-repo commands carry issues, pull requests, labels, milestones and comments between forges. Gitea has no Azure DevOps importer, so keep Azure Repos history as a Git mirror and confirm which work item fields survive the move before you cut over.
Use Redmine's SCM integration with Git
Redmine's SCM integration can read Git repositories and associate commits with issues, so a team that keeps Git hosting elsewhere can still see commit activity beside its tickets. Redmine is a good fit when the tracker must hold the project history and roles, but it does not host Git repositories or pull requests. Confirm the reference syntax for commits and the repository configuration on a test project before you map your Azure Boards queues to Redmine trackers.
Exporting Boards data and cutting over without losing history
This sequence moves work items, queries and iteration structure out of Azure Boards and into a tested OpenProject, Plane or Redmine instance, with counts reconciled and a frozen copy kept as the record of what was exported.
Inventory types, queries, areas and iterations
Before exporting anything, list every work item type in use, including any custom types and inherited process fields, along with the saved queries your teams rely on, the area paths that define ownership, and the iteration paths that define sprints and releases. Product owners and a Boards administrator should sign off the list, because anything missing here will not appear in the export. The step is done when the inventory is a written document with a count per work item type and an owner for each area path.
Export work items through queries and the REST API
Run the saved queries and use the Azure DevOps REST API for work item retrieval, fetching fields, relations, comments and attachments in batches. Azure DevOps limits throughput, and the rate-limits documentation describes delays for clients that exceed the allowed usage in a short window, so build the script to back off and resume rather than fail. Confirm current limits in the Azure DevOps rate-limits documentation for your organization before scheduling a large run. The step is done when every query returns a complete, timestamped JSON or CSV set stored outside the production tenant.
Map fields, states and link types
Build a mapping table that connects each Azure Boards work item type to the target tool's type (for example, epic, feature and user story to OpenProject work package types, Plane issue types or Redmine trackers), each Boards state to a target status, and each Boards link type such as parent, child and related to a target relation. Note where the target has no equivalent, such as a custom field with no matching attribute, and decide whether to store it as a custom field or as text in the description. The step is done when the mapping has been reviewed by a person who uses the Boards process daily and each unmapped field has a recorded decision.
Load into a test instance
Stand up a non-production OpenProject, Plane or Redmine instance and load the export through your own import script or a supported importer. OpenProject's Jira Migrator is in beta and its documentation advises use only in test setups, and it imports from Jira Data Center rather than Azure DevOps, so it is not a Boards path. Redmine's built-in importers for other tools are marked obsolete and not working, and its third-party migration scripts are described as neither tested nor supported, so expect to write or maintain the transform yourself. The step is done when a full load completes on the test instance without manual edits to the data.
Reconcile counts and spot-check history
Compare record counts per work item type, per area and per iteration between Azure Boards and the test instance, and investigate every difference. Then sample items across the age range of the backlog, checking titles, descriptions, assignees, states, comments and parent-child links against the source. Record the reconciliation as a table that a product owner and an engineering lead both sign. The step is done when counts match or each gap has a documented reason, and the sampled items show the expected history.
Freeze Boards writes and run the final export
Announce a write freeze date to teams, then restrict work item creation and editing in the Azure DevOps project for the duration of the final export. Run the export again, load it into the production target, and repeat the reconciliation against the frozen source. Any work item changed after the first export must be captured by this final run, which is why the freeze matters. The step is done when the final counts match the frozen source and the freeze has been lifted only after the reconciliation is signed off.
Cut over users and integrations
Switch users to the new tool, update single sign-on or LDAP group mappings, and repoint integrations such as commit links, pipeline notifications and reporting dashboards. For commit linking, the Git side is handled separately in GitLab or Gitea, so confirm that the issue keys used in commit messages resolve to the new work item identifiers. Keep a short list of integrations and who owns each one. The step is done when a pilot team has created, updated and closed work items in production and every integration has been tested by its owner.
Archive the export and retire the old access path
Store the final export, the mapping table, the reconciliation records and the import scripts in a retained, access-controlled location that you control, with checksums recorded. Confirm with your compliance owner how long the records must be kept, and keep read-only access to Azure Boards for the period your retention policy requires before removing licences. The step is done when the archive can be restored or read without Azure DevOps and the retention decision is written down.
Questions buyers ask before replacing Azure Boards
What drives the cost of replacing Azure Boards with open source?
The cost has five parts: hosting, implementation, plugins, upgrades and the staff who run the platform. The software itself is free in all three candidates, since OpenProject Community, Plane Community and Redmine carry no license fee, although OpenProject Enterprise and Plane's Commercial Edition are paid. Hosting and staff time recur every year, while export, field mapping and initial setup are largely one-time. Costs rise with user count, the number of custom fields and plugins, and the number of integrations with source control and CI. Ask any provider for a written, fixed-scope quote that lists each component separately.
How long does a migration from Azure Boards usually take?
The timeline depends on how much history must move, how many work item types and custom fields exist, and how many people must be trained before the cut-over. Export volume is limited by the Azure DevOps throughput rules, which delay users above 200 throughput units in a five-minute window, so large backlogs take longer to pull. Plan a test migration into a non-production instance before the live move. Ask for the timeline in the written scope, with milestones for export, mapping, test import and cut-over.
What must our team provide before an implementation starts?
Your team needs to supply a full export of work items, decisions on which fields and states carry over, and a user mapping from Azure DevOps identities to the new platform's accounts. You also need to name the owners who approve the target process, such as how epics, features and user stories map to the new hierarchy. Keep a record of linked commits and pull requests, since those links should be re-established in GitLab or Gitea. Missing field decisions are the most common reason for rework, so settle them early in writing.
Can our own engineers migrate Azure Boards without outside help?
Yes, a capable internal team can run the export, a test import and the cut-over, especially for a small backlog with few custom fields. The risk lies in the parts that are less obvious: the Redmine built-in importers for Trac and Mantis are marked obsolete and not working, and the Jira importer for OpenProject is in beta. Your team also takes on upgrades, backups and security patching after go-live. Many organizations split the work, keeping mapping and training in-house while bringing in an implementation partner for hardening and runbooks. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and works from a written, fixed scope.
Do we need enterprise single sign-on for a self-hosted work tracker?
It depends on your identity policy, but for most regulated organizations it is a requirement for access control and offboarding. OpenProject lists SAML, OIDC, CAS, Kerberos and Okta single sign-on, along with LDAP group synchronization, as Enterprise features. Plane lists SAML and OIDC on its Pro plan and above on self-hosted installs, with LDAP and API-enabled audit logs on Enterprise. Redmine supports multiple LDAP authentication sources in its core. Confirm each feature against the current edition and version in your environment before you choose.
How do we choose between OpenProject, Plane and Redmine?
Choose by the work model your teams use and by the license terms you can accept. OpenProject, under GPL-3.0, offers work packages, Gantt charts and agile boards in its free Community edition, and its Enterprise features are priced per named user. Plane is closest to modern agile tracking, but its Community edition is AGPL-3.0 and paid features require the Commercial Edition with a license key. Redmine is GPL v2 with no paid edition, strong role-based access and issue tracking, but it has a steeper customization and plugin workload. Run a short pilot with a representative backlog on two candidates before you decide.
How do we keep work items linked to commits after leaving Azure Boards?
Git history moves with a clone or mirror, but the links from work items to commits and pull requests need a platform importer or a scripted re-link step. GitLab can import projects from several forges and Gitea has importers for GitHub, GitLab and others, but neither ships an Azure Boards importer. Plan to store the old work item ID alongside each new issue, so commit messages and comments can be matched during the import. Ask the implementation scope to specify exactly which links are preserved and which are only referenced in text.
Which parts of Azure Boards data are hardest to move?
The hardest data is usually the process model: custom work item types, field rules, states with transitions, and portfolio hierarchies built on epics, features and user stories. Attachments, history and the connection to Azure Pipelines run results also need explicit decisions, since not every target keeps them in the same form. Azure DevOps lets you read work items through queries and the REST API, but secret variables cannot be read back, and that limit matters for any linked automation. Document what will be archived rather than migrated, so stakeholders agree before the cut-over.
What changes for planners, developers and administrators
Product owners and scrum masters see the largest change in how they plan, because the Boards hierarchy, backlog ordering and sprint views are rebuilt in the new tool and do not carry across automatically. Before anyone sees the new navigation, run a pilot with one real backlog and confirm that epics, features, user stories and sprint boards behave as the team expects. OpenProject's Community edition includes work packages, agile boards, Gantt charts and dashboards, so planners will learn new terms for the objects they already manage. Plane and Redmine organize work differently, so a Boards work item type may not map to the same object in each tool. Azure Boards dashboard widgets, such as burndown or query tiles, do not transfer either. Planners should list every widget and report they rely on, then decide whether to rebuild it, replace it with a saved query or retire it, and name an owner for each report.
Developers keep their daily Git workflow only if the repositories also move to GitLab, Gitea or Forgejo, so the code host and the tracker are separate decisions that must be sequenced together. Commit messages and branch names are how code links back to work items in Azure Boards, and after cut-over that linking convention has to be written into the team's contribution guide and tested on a copy of one project. Confirm which reference syntax the chosen tracker and forge recognize, and check whether any editor or pipeline integration that the team uses today has an equivalent. Teams that script work item creation from build results will need the Redmine REST API, which an administrator must enable first. Each user then authenticates with a personal API key sent in the X-Redmine-API-Key header, so scripts should run under service accounts that the team can rotate.
Administrators take on duties that Microsoft carried for Azure Boards: they own the database, file storage, backups, upgrades and patching. OpenProject requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, and uploaded attachments must be backed up together with the database so that restores stay consistent. Redmine's upgrade procedure follows the same logic: back up the database and uploaded files, copy configuration, uploads and third-party plugins to the new installation, then run the migration tasks and restart. Check plugin compatibility before each upgrade, not after. Plane's self-hosted stack adds Redis or Valkey, RabbitMQ and S3-compatible object storage, which multiplies the components to back up. Write down who holds database credentials and storage keys after cut-over, whether the client team or DeployOpen under the agreed scope, and schedule a restore test in the runbook.
Risks to plan for before the cut-over
Moving work items out of Azure Boards fails less often on the software than on the data and the people around it. The cards below cover the risks that most often surprise teams moving to OpenProject, Plane or Redmine, each paired with the check that keeps it contained before the cut-over date.
Lost history from unmapped fields
Azure Boards work items carry area paths, iteration paths, custom fields, tags and state transitions that have no direct equivalent in every target tool. If the field mapping is not agreed up front, values are dropped or flattened into descriptions without anyone noticing. Build a written mapping table for each work item type, run it against a sample of closed and open items, and check that comments, attachments and parent-child links survive. Keep an export of the original items in read-only storage for the retention period your records policy requires.
API rate limits slow bulk export
Work item extraction runs through the Azure DevOps REST API, which applies throughput limits. Large backlogs therefore take far longer to export than the migration plan assumes, and a script that retries without backoff can stall a full run. Measure the throughput on a representative project, schedule the bulk pull outside working hours, and keep the export resumable so a failed batch restarts from its last checkpoint. Confirm current limits with Microsoft before you size the window.
Users working in two systems
During overlap, some teams keep updating Azure Boards while others create items in the new tool, so status, sprint scope and ownership diverge. Decide which system is the record for each project and freeze writes to the old one on a named date. Publish a short guide that maps old states to new statuses, and have the product owner confirm the backlog in the target tool before sprint planning moves across. Remove the old project's write permissions once the freeze takes effect.
Plugin and upgrade drift in Redmine
Redmine plugins are often installed on the first deployment and then left behind during upgrades, which can break issue views or custom field behavior after a Rails or Ruby change. Keep an inventory of every plugin with its version and source, and test each one against the target Redmine release in a staging copy. Follow the upgrade order in the official guide: back up the database and uploaded files, copy configuration and plugins, then run the migration tasks before restarting. Confirm the support window of the line you choose before you commit.
PostgreSQL version requirements for OpenProject
OpenProject officially supports PostgreSQL 16 or later and requires specific extensions, so an existing database server on an older major version can block the install or the upgrade. Check the database version and the availability of the pg_trgm, btree_gist and unaccent extensions before you provision the target. If your standard platform runs an older PostgreSQL, plan a separate database instance instead of changing the shared one. Confirm the sizing guidance against your expected user count.
License scope when moving to paid tiers
Both Plane and OpenProject offer free community editions, but several features teams expect, such as SAML or OIDC single sign-on, LDAP group sync and audit logs, sit in paid tiers. On Plane, a self-hosted Community install must switch to the Commercial Edition before a paid plan can be applied, which changes the install path. Map each required feature to its tier, count seats the way the vendor counts them, and get the quote in writing before the cut-over date.
How DeployOpen scopes and delivers a Boards replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Boards replacement, that means agreeing in writing which work item types, boards, integrations and exports are in scope before any migration work starts.
How we scope
- Inventory the Azure Boards projects, work item types, process customizations, queries and dashboards that the written scope will cover.
- Record which teams link work items to commits, pull requests and pipelines, so the integration scope is explicit before build begins.
- Agree the target platform, whether OpenProject, Plane or Redmine, and the hosting model, with engagements agreed as fixed-scope documents.
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network, with its database, storage and identity settings defined.
- Map epics, features and user stories to the target's hierarchy, and test the mapping on a sample export before the full data set moves.
- Configure work item linking to GitLab or Gitea commits and merge requests, and test each link with your own repositories.
How we hand over
- Document the mapping rules, field conversions, user mappings and access roles, so your team can audit how each Boards item landed.
- Run a rehearsal cut-over with reconciliation reports comparing item counts, attachments and history against the Azure Boards export.
- Hand over backup, restore and upgrade procedures, and confirm which steps your staff will run and which the retainer will cover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the cut-over is complete.
- Plan upgrades against each platform's release notes and lifecycle documentation, so version changes are tested before they reach production.
- Ask any delivery partner to confirm in writing which Azure Boards features will not have a direct equivalent in your chosen platform.
