Open-source alternative to GitHub Issues and Projects

Open-source alternative to GitHub Issues and Projects: the short answer

When code leaves GitHub, the issue tracker and project boards have to move with it, and the first decision is which system takes each job. Gitea or Forgejo's built-in issue tracker covers day-to-day issues for most engineering teams, because issues, labels, milestones and pull request links stay next to the code they describe. OpenProject fits teams that need Gantt charts, portfolio planning across several projects, or the Enterprise identity features such as SAML, OIDC and LDAP group synchronization. This is a split by purpose, not a ranking of two tools, and the right answer depends on what your boards must do in practice.

Start by listing the planning functions your current GitHub Projects boards actually serve. If the boards track bugs and feature requests that engineers close through merged pull requests, the forge's tracker is usually enough and keeps one place of record for code and work. If product managers need dependencies, schedules, resource views or time tracking across non-engineering work, a separate planning tool becomes necessary, and you will run two systems with a link between them. Confirm the exact feature set you need against the current release notes for each product, since capabilities change between versions.

Identity requirements can settle the question earlier than feature lists. Check whether your security policy requires single sign-on or group-based access for planning tools, and whether the forge and the planning tool can share one identity provider. Gitea Enterprise, sold by CommitGo, adds SAML 2.0 support and mandatory two-factor authentication, while OpenProject lists SSO and LDAP group synchronization among its Enterprise features. Ask each vendor to confirm these capabilities for your edition and deployment model before you commit to a design.

Which GitHub Issues and Projects capabilities map to which open-source option

This table maps each GitHub Issues and Projects capability to the closest option in Gitea or Forgejo, OpenProject and Plane. Read each row as a fit check: where a forge tracker is enough, where a dedicated planning tool adds value, and where you must confirm behavior against the current release before migrating.

Capability	Gitea or Forgejo	OpenProject	Plane
Issues, labels and milestones	Native issue tracker with labels and milestones; the Forgejo dump-repo command carries them over	Work packages with types, statuses and versions; confirm how GitHub labels map to its types	Work items with states and labels; confirm how GitHub milestones map
Comments and discussion	Issue comments travel with the repository in the Gitea and Forgejo importers	Comments and activity history on work packages	Comments on work items; confirm whether imported comments keep original authors
Boards and project views	Basic project boards; confirm they cover the GitHub Projects views your teams use	Boards, Gantt charts and agile boards in the Community edition	Board and list views; confirm against the current release
Custom project fields	Limited compared with GitHub Projects fields; plan to model extra data with labels	Configurable attributes on work packages; confirm the field types you need	Configurable properties; confirm field types and whether GitHub Projects fields migrate
Cross-links to pull requests and commits	Issues and pull requests share one tracker; confirm commit keywords close issues on your version	Linked through integrations; confirm which code hosts it links to natively	Integrations with Git hosts; confirm two-way linking of commits and pull requests
Roadmap and timeline views	Confirm whether your version offers timeline or roadmap views	Gantt charts in the Community edition	Confirm timeline or roadmap views in your release
Time tracking	Confirm whether time entries on issues are included in your version	Time tracking included in the Community edition	Confirm time entry and reporting capabilities
SSO and audit logging	Gitea Enterprise adds SAML 2.0 support and audit logging; confirm the Forgejo equivalent	Single sign-on such as SAML and OIDC is an Enterprise feature; confirm the audit log scope	Confirm SSO and audit logging in the edition you plan to deploy

Gitea or Forgejo tracker versus OpenProject or Plane: when each fits

Once code leaves GitHub, the issue tracker and project board need a home. The four options below split into forge-native trackers that keep work next to the code and dedicated planning tools that handle portfolios, schedules and non-engineering teams. Each card names the situation where the option fits and the trade-off to check before committing.

Gitea issue tracker

Gitea's built-in tracker keeps issues, labels, milestones and pull requests on the same server as the repositories, so one permission model and one backup cover both. It fits teams whose planning is mostly engineering work tied to commits. The trade-off is that the tracker is a forge feature, not a portfolio tool, so cross-project roadmaps and resource views need checking against your needs. Gitea's GitHub migration carries issues over, but confirm how it handles comments, attachments and users before you rely on it.

Forgejo issue tracker

Forgejo offers the same kind of forge-native tracker under a GPL-3.0-or-later license, with governance kept independent and Codeberg e.V. holding the domains. It fits organizations that want copyleft terms or a community-governed project alongside their repositories. The trade-off is that its release cadence and LTS windows differ from Gitea's, so pick the release line that matches your upgrade policy. The dump-repo and restore-repo commands can carry issues and milestones across, which makes a later move between the two forges more practical.

OpenProject for planning

OpenProject is a GPL-3.0 project management tool from OpenProject GmbH, with work packages, Gantt charts, agile boards and time tracking in the Community edition. It fits teams that plan across several projects or need schedules and non-engineering participants. Enterprise on-premises is priced per named user per month, with a 25-user minimum on Professional and a 100-user minimum on Premium, so model the cost by named user count before you compare it with a forge. SSO and LDAP group sync sit in the Enterprise tier. The Jira Migrator is beta and suited only to test setups, so plan a separate manual import for production data.

Plane for agile teams

Plane is an open-source project tracker built around issues, cycles and modules, and it suits product teams that run sprints outside the code host. It fits groups that want a lighter tool for backlog work while keeping repositories in Gitea or Forgejo. The trade-off is that commits and pull requests are linked by convention rather than by one shared database, so you must confirm which integrations, licensing terms and enterprise features you need, and how the tool is deployed and backed up in your own environment before you adopt it.

What Gitea's GitHub migration carries over and what it leaves behind

Gitea's built-in migration form includes an importer for GitHub, and it is the first path to test for issues, pull requests, reviews and wikis. Gitea's migration code covers these objects for the platforms it supports, but the exact set carried over, including attachments, reactions and labels, can change between releases, so confirm the behavior against the Gitea version you plan to run. Forgejo takes a different route. Its dump-repo and restore-repo commands export and load issues, pull requests, releases, labels, milestones, comments and the wiki, which is a documented list you can check line by line. Pick the path your team can verify, and read the Forgejo command-line reference before running either one.

GitHub Projects boards do not come across in a repository export. Board layouts, custom field values such as status, priority or iteration, saved views and project automations are stored at the project level, not inside the repository's issues. Plan to record those fields before the move, then either recreate the boards in your new planning tool or map each field to a label or milestone. Also confirm how the importer handles assignees and mentions when usernames do not match accounts on the new server, how closing keywords in commit messages link to issues, and whether issue timeline events survive. Each of these affects how readable the migrated history will be, even when the raw counts match.

Test with one representative repository that has open and closed issues, pull requests with review threads, labels, milestones and a wiki. Record counts for each object type on the GitHub side, then run the same counts on the target and compare them, along with a manual check of a sample of cross-references, attachments and comment authors. Write down each mismatch and decide, per object type, whether to accept it, correct it by hand or keep the GitHub archive as the reference. Only after that check passes should the team migrate the remaining repositories, and the source repositories should stay read-only and archived until the new forge has run through a full planning cycle.

How to link commits and pull requests to work items after the move

When issues stay in the same forge as the code, closing keywords and issue numbers in commit messages and pull requests work much as they did on GitHub. A reference such as #42 in a commit or pull request links to the issue in the same repository, and merging a pull request that carries a closing keyword can close the issue it names. Confirm the exact keyword set and cross-repository behavior in the version you deploy, since these behaviors are set by the forge and not by Git.

Imported numbers change: Issues created during the migration receive new numbers in the destination repository, so an old GitHub #42 may point to a different issue or to nothing. Build a table that maps old numbers to new ones before rewriting anything.
Commit history stays as written: Past commit messages are not rewritten by the import, so old references remain in history and need a mapping table, not an edit to the commits.
Changelogs and docs need rewriting: Release notes, README links and wiki pages that cite GitHub issue URLs will break or point to the wrong item unless you update them.
Labels and milestones carry over: Teams can keep their planning vocabulary, which reduces the number of new conventions people must learn.

Before cutover, ask the forge vendor or your own test instance to confirm how closing keywords behave for issues imported from GitHub.

Questions teams ask before moving GitHub issues and boards

What does moving GitHub issues and boards actually cost?

The cost is mostly staff time and a server you run, with the software itself free to download in the Gitea, Forgejo and OpenProject Community editions. The recurring items are the server, storage, backups, upgrades and any support contract you choose. The one-time items are the migration work, board mapping and cutover testing. The OpenProject Community edition is free and includes work packages, Gantt charts, agile boards and dashboards, but it has community support only. OpenProject Enterprise on-premises is priced per named user per month, and the list starts at 5.95 euros per user with a 25-user minimum on the Basic tier (OpenProject pricing). Ask any provider for a written quote that separates one-time work from annual support, and for the server sizing they assume.

How long does a GitHub issues migration take?

The duration depends on how many repositories, issues, comments and attachments you move, how many boards you need to rebuild, and how much of the mapping must be decided by people rather than scripts. Moving the issue tracker itself with a platform importer is usually the quick part, while agreeing on labels, milestones and project fields takes longer. API rate limits also affect bulk exports: GitHub allows 5,000 REST requests per hour for personal access tokens, so large exports run in batches. No migration duration is set here, so ask the provider for a timeline tied to your repository count and a written list of what is excluded.

What does our team need to provide before a migration starts?

You need four things before work begins: administrator access to the target forge or planning tool, a GitHub token with permission to read the repositories you are moving, a named owner who can approve decisions, and a written board mapping. The mapping covers how GitHub labels, milestones and project columns become Gitea or Forgejo labels and milestones, or OpenProject work package types, statuses and versions. Gitea's migration form uses a GitHub token, and the Forgejo dump-repo command exports issues, pull requests, releases, labels, milestones, comments and wikis. Confirm the token scopes and the export window with whoever runs your GitHub organization.

Can our own engineers run the migration without an outside partner?

Yes, a capable internal team can do it, especially for a small number of repositories. Gitea and Forgejo include built-in migration paths, and OpenProject installs with Docker, .deb or .rpm packages. The harder parts are the decisions and the repeatable checks: confirming that comment authors, timestamps and attachments came across, rebuilding boards, and running the cutover without losing work in flight. Consider an outside partner if you have many repositories, strict compliance evidence requirements, or no one with time to own the work after go-live. DeployOpen plans and implements these migrations under a fixed written scope, so ask for the deliverables listed in that scope.

Do GitHub issue links and commit references still work after migration?

Links inside migrated content are not guaranteed to keep working, and you should test them before cutover. Issue numbers often change when items are recreated, so a reference like #42 in an old commit can point to a different item or nothing at all. Ask the importer for its behavior on issue numbering, and plan a redirect or a link-rewrite step for the most important external references. Commit messages stay in Git history, so linking commits to work items usually means agreeing on a reference format, such as a key in the commit message, and checking that the new forge or planning tool recognizes it. Test this on a copy of one repository first.

What operational work continues after the move?

The new system needs ongoing care that GitHub previously handled for you. The main recurring tasks are:

Applying upgrades, since Gitea v1.27.3 shipped on August 29, 2026 and newer lines follow, and OpenProject ships regular point releases such as 17.9.2 on October 15, 2026.
Running backups of the database and repository data, and testing restores.
Maintaining the PostgreSQL version required by OpenProject, which officially supports PostgreSQL 16 or later.
Managing user accounts and single sign-on, which the Enterprise tier of OpenProject covers with SAML, OIDC and LDAP group synchronization.

Ask the provider who owns each task after go-live and what response times, if any, are included in a support contract.

Which security and licensing questions should we ask before choosing a tool?

Check the license and the features you need before you commit. Gitea is MIT licensed, Forgejo is GPL-3.0-or-later from v9.0, and OpenProject is GPL-3.0. Gitea Enterprise adds SAML 2.0 service provider support, audit logging, IP allowlisting and mandatory two-factor authentication, and OpenProject Enterprise adds single sign-on and LDAP group synchronization. If your controls require these features, confirm whether they sit in the free edition or in a paid tier, and get that in writing from the vendor. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit report.

Migration sequence for issues, boards and commit links

This sequence moves issues, labels, milestones and planning boards out of GitHub with a tested import, a verified count and link check, and a documented cutover. The result is a planning system that a team can trust and a record of what was carried over.

Inventory issues, labels, milestones and boards
Before any import, the platform owner and a team lead export a list of open and closed issues, pull requests, labels, milestones and project boards for each repository in scope. Record which GitHub Projects boards hold work that has no issue behind it, because those cards may not carry over as issues. Note any issue templates, saved views and automation rules that teams rely on. The step is done when the inventory is stored with the migration record and each board has a named owner who confirms what it must preserve.
Choose the destination for planning
The engineering lead decides whether issues stay in the forge's own tracker, such as Gitea or Forgejo issues, or whether planning moves to OpenProject or Plane. Gitea's migration code and Forgejo's dump-repo and restore-repo commands carry issues, labels and milestones into the forge, but project boards are a separate concern. Confirm with the team which views they use daily before choosing, and record the decision with the reasons. The step closes when the destination is written down and approved by the people who will use it.
Test the import on one repository
Run the import against a single low-risk repository in a staging instance of the chosen forge. Use Gitea's built-in GitHub migration form with a token that has the scopes needed for issues and pull requests, or the Forgejo dump and restore commands if that path fits. Watch for attachments, user mentions and comments that did not import. The step is done when a test run completes without errors and the engineer who ran it can list the known gaps in writing.
Compare counts and links
Compare the number of open and closed issues, pull requests, comments, labels and milestones in GitHub with the counts in the destination. Spot-check a sample of issues for correct assignees, status, timestamps and cross-references to other issues or pull requests. Check that links to commits and external URLs still resolve. Document every mismatch and whether it is accepted or fixed. The step is complete when a reviewer signs off on a short reconciliation report, with any accepted gaps listed by name.
Cut over and freeze GitHub
Schedule the production import during a quiet window agreed with the teams. Run the final import, then set the GitHub repositories to read-only or archived, and post a pointer to the new location in the old README and open issues. Remove or disable issue creation paths such as webhooks, bots and chat notifications that still point to GitHub. The step is done when the new tracker is the only place where new work is created, which the platform owner confirms by checking that no new GitHub issues appear over the next working cycle.
Update commit reference conventions and integrations
Agree a commit message convention, such as an issue number prefix in the subject line, and publish it in the contributing guide. Update CI pipelines, chat notifications, release scripts and any tools that parse commit messages to read the new issue references. Confirm that the forge links commit references to work items in the way the team expects. The step is done when a test commit referencing a migrated issue appears linked in the new tracker and the integration owners have signed off.
Archive the export and record the migration
Store the raw export, the reconciliation report, the token scope used, and the list of known gaps in a restricted repository or document store. Keep the record with the decision on the destination and the cutover date. Retain it according to the organization's records policy, which should be confirmed with the compliance lead. The step is complete when the archive is indexed, the owners know where it lives, and the open gaps have named owners for follow-up.

What changes for developers, product owners and the rest of the suite

Developers feel the change first, in the commit and branch habits they already have. Once issues live in Gitea or Forgejo's tracker, a commit message that references an issue number only creates a link if the forge's keyword and cross-reference rules match the way the team writes them, so developers should test a closing keyword on a throwaway repository before the cutover. Imported GitHub issue numbers may not match the numbers in historical commit messages, so teams should check how the migrated references resolve. Forgejo Actions is familiar to GitHub Actions users but is not compatible with GitHub Actions, so pipelines that reference issues from workflow steps need their own review, and the Gitea and Forgejo sections of this page cover the migration details.

Product owners will notice that boards, labels and milestones are rebuilt rather than carried into a new tool. If the team keeps the built-in tracker, boards stay close to the code but offer less planning depth than a dedicated work management product. If planning moves to OpenProject, work packages, Gantt charts and agile boards become a separate system, and every cross-link back to commits needs a documented convention. OpenProject's Community edition is free with community support, while its Enterprise on-premises tiers are priced per named user per month, so the number of people who need planning access drives that cost. Ask the vendor to confirm the current tier thresholds before comparing totals.

The security or compliance team inherits access control and audit evidence that GitHub previously handled in its own administration console. Role mapping, branch protection, two-factor enforcement, single sign-on and audit logging must be configured on the new forge and on the planning tool, and each system needs its own access review. Gitea Enterprise adds SAML 2.0 support, audit logging, organization-level branch protection inheritance and mandatory two-factor authentication, while OpenProject's Enterprise features include SSO and LDAP group synchronization. Confirm the release line before choosing: Forgejo documents transparent upgrades from Gitea only up to Gitea v1.22, so a team on a newer Gitea line should verify the upgrade path with the Forgejo project before committing.

How DeployOpen scopes and delivers the move

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For issue tracking and project planning, we start from a written scope that decides which tracker keeps your work items and how commits link to them.

How we scope

Inventory the GitHub issues, pull requests, labels, milestones and project boards that must move, and which ones can be archived.
Decide whether issues stay in Gitea or Forgejo's tracker or planning moves to OpenProject or Plane, with the reasons recorded.
Agree in writing the deliverables, timelines and acceptance checks before work starts, since most engagements are fixed-scope.

How we build

Run a test migration with the Gitea or Forgejo importer against a copy of selected repositories and review what arrived.
Configure the chosen planning tool in your environment, including authentication, database and backup settings for its data.
Set up commit-to-issue linking conventions and test them on sample branches before rolling them out to every team.

How we hand over

Document the target architecture, migration runbook, mapping of old issue references and admin procedures for your staff.
Provide the test results, known gaps such as fields or attachments that did not carry over, and a list of actions for your owners.
Walk your platform and planning teams through daily operation so the tracker can be run without outside help.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the project.
Plan upgrades of the forge and planning tool against each project's published release and support policy.
Ask any quote to separate one-time migration work from recurring hosting, upgrade and support effort.

Open-source alternative to GitHub Issues and Projects