When Azure DevOps or Forgejo is the right fit for your Azure DevOps alternative
Azure DevOps fits teams that need Boards, Test Plans and Microsoft-managed services, and Forgejo fits teams whose core need is Git hosting, pull requests and CI on infrastructure they control. The decision turns on three questions: whether your organization depends on Boards work items and Test Plans, how much your builds and package feeds matter to daily delivery, and who will operate the server after cut-over. A renewal or licensing change alone rarely settles the question, so start by listing which Azure DevOps services your teams open every day.
Check Boards and Test Plans first. Forgejo has no equivalent for either, so if product managers run sprints in Boards or QA runs manual test suites in Test Plans, you will need a second tool for those workflows, and the cost of that tool belongs in the comparison. Next, measure how heavily your pipelines and feeds are used. Forgejo Actions is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions, so existing YAML needs rework. Ask your team to count active pipelines, runners and package feeds, and confirm which Forgejo package registries cover the formats you use.
Be honest about who runs the platform. A self-hosted forge needs owners for upgrades, backups, runner capacity, security patches and user administration, and those tasks recur for as long as you run it. Forgejo's upgrade path from Gitea installations and its published support windows, documented in the Forgejo upgrade guide, help you plan that work, but only if an internal team or a partner is named for it. If no one can own that role, a managed Azure DevOps subscription or a different self-managed option may fit better.
Which option fits which scenario
This table matches common Azure DevOps situations to the option that usually fits better, with the condition that tips the decision. Read each row against your own usage: a team that depends on Boards or Test Plans will weigh the gaps differently from one that mainly needs Git hosting and reviews. Use it to decide where to start the scoping conversation, not as a final verdict.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Mainly Git, branches and pull requests on our own servers | Forgejo | Repos, pull requests and reviews are the core use, and you can host the server in your own data center or cloud account. |
| Heavy use of Azure Boards work items and sprints | Azure DevOps (or a separate work tracker) | Forgejo has no Boards equivalent, so you would need to plan a separate tool such as OpenProject, Plane or Redmine and link work to commits. |
| Heavy use of Azure Test Plans | Azure DevOps (or a separate test tool) | Test Plans has no Forgejo counterpart, so manual test management must be covered elsewhere before any move. |
| Strict residency for tokens, SSH keys and build data | Forgejo on your own infrastructure | Azure DevOps Services keeps tokens and SSH keys in a US datacenter, so an in-region self-hosted server gives you control over where they sit. |
| Small team with limited operations capacity | Azure DevOps Services, or a managed Git host | Someone must patch, back up, upgrade and monitor a self-hosted forge; if no one owns that work, a hosted service is usually the safer choice. |
| Azure DevOps Server approaching end of support | Forgejo, or upgrade Azure DevOps Server | Compare the Modern Lifecycle Policy upgrade path with a move; a move needs a Git migration plan and a rebuild of pipelines and permissions. |
| CI that should look like GitHub Actions | Forgejo Actions | Workflows are familiar to GitHub Actions users, but Forgejo Actions is not compatible with GitHub Actions, so pipelines must be rewritten and tested. |
| Large packages or Artifacts feeds to keep | Azure DevOps, or a separate package registry | Confirm which package formats and feed volumes Forgejo registries must handle before committing, since Artifacts feeds need their own migration plan. |
| Need for long-term patch support on a stable release | Forgejo LTS release | Choose the LTS line, which the Forgejo releases page lists as supported into 2027, and confirm the support window before standardizing. |
What Forgejo covers from Azure Repos and Pipelines
Forgejo covers the Git hosting core of Azure DevOps: repositories, branches, pull requests, code reviews, releases and wikis map to Forgejo features with few conceptual changes for developers. The gap is in the pipeline layer. Forgejo Actions is a built-in CI system that hands workflows to separate runners, and it is designed to be familiar to GitHub Actions users but is not compatible with GitHub Actions. Azure Pipelines YAML therefore cannot be pointed at Forgejo unchanged. Every azure-pipelines.yml file, its service connections and its variable groups need to be rewritten as Forgejo workflows, and each runner environment has to be provisioned and secured separately.
Repository content can move with Forgejo's own tooling. The dump-repo command exports a repository with issues, pull requests, releases, labels, milestones, comments and wiki, and restore-repo loads it into Forgejo, according to the Forgejo command-line documentation. Azure DevOps is not among the platform importers listed in Gitea's migration code, so do not assume that work items, pull requests and reviews from Azure Repos will arrive automatically. Confirm the export path with a test project first, and check what Azure DevOps returns through its API before deciding which history must be preserved.
Plan for the parts that do not transfer. Azure Boards work items, Test Plans and Azure Artifacts feeds have no direct Forgejo equivalent, so they need their own replacements or an archive. Branch policies and required reviewers must be re-created by hand in Forgejo's branch protection settings and checked against the policies you actually enforce today. Ask your Forgejo implementation partner to write a cut-over runbook that lists every pipeline, service connection, policy and integration, with an owner and a verification step for each one.
Capabilities side by side: Repos, pipelines, packages, Boards and Test Plans
This table sets Azure DevOps services against the built-in features of Forgejo, row by row, so you can see where Forgejo covers the same job and where it has no equivalent. Read the gap rows as the decisions that need a second tool or a different plan, and confirm package format coverage in the Forgejo version you intend to run. The main takeaway is that Forgejo can replace Azure Repos and much of Pipelines, but Boards and Test Plans need separate tools.
| Capability | Azure DevOps | Forgejo |
|---|---|---|
| Git repositories | Azure Repos hosts Git repositories with branch and path policies in each project | Git repositories with branch protection and organization-level access; Git history moves with a clone or mirror |
| Pull requests and code review | Pull requests with required reviewers, build validation and branch policies | Pull requests and reviews with branch protection rules; confirm the policy options you need in your version |
| Continuous integration | Azure Pipelines, defined in azure-pipelines.yml or the classic editor | Forgejo Actions, familiar to GitHub Actions users but not compatible with GitHub Actions; workflows run on separate runners |
| Package registries | Azure Artifacts feeds for NuGet, npm, Maven, Python and Universal Packages | Forgejo package registries; confirm which package formats your version supports before planning feed moves |
| Work items and Boards | Azure Boards work items, backlogs, sprints and queries | Not applicable |
| Test Plans | Manual and exploratory test plans and test case management | Not applicable |
| License and governance | Proprietary Microsoft service, with an on-premises Azure DevOps Server edition | GPL-3.0-or-later from v9.0, with earlier versions under MIT; domains held by Codeberg e.V. and governance kept independent |
Where your code, tokens and logs live under each model
Azure DevOps Services is operated by Microsoft, and customer data is stored in the geography selected for the organization. That geography setting covers most project content, but it does not cover everything. Per Microsoft's data location documentation, tokens and SSH keys are stored in a US datacenter regardless of the organization's geography, so a reviewer assessing EU data residency needs to read that detail rather than rely on the region label alone.
- Data placement: Repositories, work items and pipeline data follow the chosen geography, which you should verify against the current data location documentation for your organization.
- Credentials: Personal access tokens and SSH keys sit in a US datacenter, which matters for residency and for access reviews of who can hold them.
- Identity: Sign-in is typically through Microsoft Entra ID, so conditional access and offboarding follow your directory configuration.
- Audit logs: Audit records are retained by the service, and retention, export and access to them are governed by Microsoft's terms and your plan.
- Operations: Microsoft patches and runs the service, so your team does not hold the database, backups or hosting controls.
Before relying on this model for a regulated workload, confirm with Microsoft in writing where each data class is stored, how long audit logs are kept, and what evidence the service can export for an assessor.
Azure DevOps Server runs on infrastructure you control, so code, tokens, logs and databases sit in your data center or private cloud. Microsoft announced on October 7, 2025 that the product drops the year from its name and moves from the Fixed Lifecycle Policy to the Modern Lifecycle Policy, under which customers who stay current receive continuous support. The lifecycle change makes version currency a governance matter, not only a feature question.
- Data placement: The SQL Server databases and file storage live where you install them, so residency follows your own infrastructure decisions.
- Identity: Active Directory integration is the usual pattern, which keeps sign-in and group membership under your existing controls.
- Lifecycle: Under the Modern Lifecycle Policy, staying on a current release is the condition for continuous support, so budget for regular upgrades.
- Audit logs: Audit data is stored in your own database, so retention and export are your responsibility and must be configured deliberately.
- Operations: Your team owns patching, backups, certificates, disaster recovery and the SQL tier beneath the server.
Confirm the exact upgrade path and support terms for your current version with Microsoft's Azure DevOps Server documentation before you commit to a multi-year plan.
Self-hosted Forgejo keeps repositories, tokens, runner configuration and logs inside your cloud account or data center. The Forgejo FAQ states that the project is GPL-3.0-or-later from v9.0 onward, with a non-profit association holding its domains, so the software and its governance are separate from any single vendor's hosting. Choosing Forgejo is a choice of software and support model, not only of location: you take on operation and support, or contract them from a provider.
- Data placement: Repositories, databases, attachments and secrets stay where you deploy them, including air-gapped networks if your design requires it.
- Identity: Forgejo supports external authentication sources, which you should test against your directory and MFA policy before go-live.
- Audit logs: Logging and retention are configured by your team, and you decide where they are forwarded and how long they are kept.
- Upgrades: Forgejo documents an upgrade path from Gitea up to Gitea v1.22 and then to later versions, and release support windows are published per release, so plan upgrades as recurring work.
- Support: Support comes from your staff, a retained provider, or both, and the contract defines response expectations.
Ask your auditor which controls they expect to see as system evidence, such as access reviews, backup restore tests and change records. DeployOpen can prepare those systems and evidence for an assessment, but it does not issue audit reports, attestations or certifications, which only independent auditors and certification bodies provide.
How Forgejo's GPL license and governance affect your decision
The license question for Forgejo is narrower than it first appears. Forgejo is licensed under GPL-3.0-or-later from v9.0 onward, and earlier versions remain under MIT, according to the Forgejo FAQ. Running Forgejo internally, without distributing it, does not trigger the GPL's obligations to share source code of modified versions. Those obligations apply when you distribute modified binaries to people outside your organization, for example to customers, subsidiaries or contractors who receive the software. Ask counsel to confirm whether any such distribution is planned, and whether a managed service provider that operates your instance on your behalf changes that picture.
Governance is a separate question from the license. Codeberg e.V., a non-profit association registered in Berlin, owns the Forgejo domains, while project governance stays independent, according to the Forgejo FAQ. For a procurement file, record the domain and project ownership and check whether your risk team is comfortable with a volunteer-led project that offers no commercial support contract of its own. Gitea, the project Forgejo forked, is MIT licensed, and commercial support for it is offered by CommitGo through Gitea Enterprise. If your organization needs a contracted support party, that difference matters more than the license text.
Federation is the feature to discount in the decision. Forgejo's federation is experimental and under active development using the ForgeFed protocol, which is based on ActivityPub, per the Forgejo FAQ. Do not plan any cross-instance collaboration or identity model around it. If you need federated workflows, confirm the current status with the Forgejo project before committing, and keep the requirement out of the migration acceptance criteria until it is stable.
What each option costs to run, by component
What do Azure DevOps seats and parallel jobs cost to run over time?
Azure DevOps charges recurring fees per user seat and per parallel pipeline job, and those fees repeat for as long as the subscription runs. The main drivers are how many users need Basic or Basic plus Test Plans access, how many concurrent builds your teams need, and whether you add Advanced Security per committer. Check the current rates on the Microsoft pricing page for your region before you budget, and ask your Microsoft partner or account team to confirm which access levels your users need. Seat counts and parallel job counts are the two levers that move the bill most, so review both at each renewal.
How do Azure Artifacts storage charges change the total cost?
Azure Artifacts includes a free storage allowance, and storage above that allowance is billed per GiB each month. The bill grows with the size and retention of your package feeds, including old versions that nobody installs but that remain stored. To estimate your own exposure, export a current storage report from your organization and measure how fast it grows. When you move to Forgejo package registries or another self-hosted repository manager, the storage cost becomes a disk and backup cost you control, and it grows with the same package history.
What does Azure DevOps Server licensing cost compared with Forgejo?
Azure DevOps Server is licensed on-premises through Microsoft volume licensing, which combines a server license with client access licenses per user, and it carries its own support and lifecycle terms. Forgejo is GPL-3.0-or-later software with no per-user license fee, so your cost moves into infrastructure, support and staff time. Ask Microsoft or a licensing partner to quote your exact server and client access license counts, and confirm how the Modern Lifecycle Policy applies to the version you run. Compare that quote with the Forgejo infrastructure and support costs in the same spreadsheet.
What server costs should I plan for when running Forgejo?
Forgejo's software cost is zero, but you pay for the servers that host it, the storage for repositories and package data, and the network capacity that serves clones and CI traffic. Compute grows with the number of active users and the volume of Forgejo Actions jobs, and runners often need separate machines from the forge itself. Ask your infrastructure team to size the hosts, storage tier and backup target, and to price them on your own cloud account or data center. These costs recur monthly or annually, and they are the first place a Forgejo budget changes as usage grows.
Which costs of running Forgejo are one-time and which recur?
Setup work is mostly one-time: installation, migrating repositories and pull request history, configuring Forgejo Actions runners, and writing the backup and restore procedure. Recurring costs include hosting, storage, backups, Forgejo upgrade work, security monitoring, and support, whether internal or from an external provider. Plan for the recurring costs first, because they continue after the migration is finished. Ask any implementation partner to separate the fixed-scope setup fee from any ongoing retainer for upgrades and support, and to state what each one covers.
What should I ask for in a quote for a Forgejo implementation?
Ask for a written scope that lists each deliverable: the target hosts, the migration of repositories and issues, the Forgejo Actions runner setup, backup and restore testing, and handover documentation. Request the fixed-scope fee separately from any optional retainer for upgrades, support or continuous testing. Confirm which items are excluded, such as Boards replacement, Test Plans, or data cleanup, and who pays for infrastructure and third-party tools. DeployOpen issues quotes only after the scope is agreed in writing, so ask for the scope first.
Who pays for staff time and support when moving off Azure DevOps?
Your organization pays for internal staff time in every option, including the platform engineers who run Forgejo, the developers who update pipelines, and the administrators who manage access. Support costs depend on whether you keep it internal, buy a vendor support contract, or hire an implementation partner for upgrades and incident response. Forgejo's community releases, LTS schedule and support windows are documented on the Forgejo releases page, so review that schedule before setting your support model. Ask each option for a named owner for upgrades, security patching and on-call coverage, because that owner is usually the largest hidden cost.
How a move from Azure Repos to Forgejo is structured
The sequence turns an Azure Repos estate into a Forgejo instance that holds the same Git history, the pull request record you choose to keep, and build and protection rules that work on the new platform before anyone is cut over.
Inventory repositories, pipelines and dependencies
Your team lists every Azure Repos Git repository, notes any TFVC repositories, and catalogs each pipeline definition with its triggers, service connections, variable groups and agent requirements. Azure Pipelines and Azure Repos users are often on different teams, so the inventory should name an owner for each repository and pipeline. The step is done when every repository and pipeline has an owner, a migration decision (move, archive or retire) and a list of external systems that call it.
Convert TFVC repositories before migrating
Any repository still stored in Team Foundation Version Control must be converted to Git before it can be mirrored, because Forgejo hosts Git repositories only. Your team, or the partner doing the work, decides how much TFVC history to carry forward and records the branch mapping. The step is done when each converted repository has a Git history that a developer has cloned and checked against a known changeset.
Mirror Git history into Forgejo
Each Git repository is cloned with its full history and pushed to a Forgejo repository, including tags and all branches that remain in use. Forgejo's dump-repo and restore-repo commands can carry issues, releases, labels and wiki content when those exist in a supported source, but Azure Repos pull requests and work items are not part of a plain Git mirror and need a separate export. The step is done when commit counts, tags and default branches match between the source and the Forgejo copy for a sample of repositories.
Export or recreate pull requests and work items
Your team decides which pull request discussions and linked work items must stay searchable. Open pull requests are usually recreated as Forgejo pull requests on the migrated branches, and closed history is exported to a file archive or wiki if auditors need it. Work items are exported through queries and the REST API within Azure DevOps rate limits, then mapped to the issue tracker your organization chooses. The step is done when the decision register lists what was recreated, what was archived and where each archive is stored.
Rewrite pipelines for Forgejo Actions
Azure Pipelines YAML is translated into Forgejo Actions workflows that run on separate runners. Forgejo Actions is designed to feel familiar to GitHub Actions users but is not compatible with GitHub Actions, so reusable tasks and marketplace extensions must be replaced or rebuilt rather than copied. Secret variables cannot be read back from Azure DevOps, so every secret is re-entered in Forgejo by its owner. The step is done when each migrated pipeline runs on a Forgejo runner and produces the same artifacts as its Azure DevOps predecessor on a test branch.
Rebuild branch protection and access rules
Azure DevOps branch policies, required reviewers, build validation and permission groups are re-created as Forgejo branch protection rules and team permissions. Because policy behavior differs between the two platforms, each rule is tested with a dummy pull request that should be blocked and one that should pass. The step is done when a written checklist shows every protected branch, the reviewers it requires and the test result for each rule.
Run a pilot with one team
One team works on its migrated repositories in Forgejo for a defined period, with pipelines, merges and releases running in parallel with Azure Repos. Problems with runners, webhooks, authentication or large repositories are logged and fixed before the wider cut-over. The step is done when the pilot team has completed its normal release cycle on Forgejo and the open issues are assigned and accepted by the owners.
Cut over and retire Azure Repos
Remaining repositories are moved in a final mirror, Azure Repos is set to read-only for those repositories, and developers are pointed to the new remotes. Azure DevOps data needed for audit is kept under its retention arrangements, and the Forgejo instance is backed up and monitored from day one. If Gitea is already in use, the upgrade path Forgejo documents from Gitea installations up to Gitea v1.22 applies before this cut-over. The step is done when no active development remains in Azure Repos, the archive is verified and the retirement date is recorded in writing.
Questions buyers ask before choosing Forgejo over Azure DevOps
What does it cost to run Forgejo compared with Azure DevOps?
Azure DevOps charges per user for Basic and Test Plans seats, per parallel job for pipelines, and per GiB for Artifacts above its free allowance, while Forgejo carries no license fee because it is GPL-3.0-or-later software. The cost of Forgejo is the infrastructure you run it on, storage, backups, runner capacity, upgrades, support and staff time. Azure DevOps Server adds its own licensing if you stay on-premises. Ask any quote to split one-time work (planning, import, pipeline conversion, hardening) from recurring work (hosting, patching, upgrades, on-call), and to show what drives each line: user count, runner count, repository size and how many Azure Pipelines definitions need rewriting.
How long does a Forgejo migration from Azure DevOps take?
The duration depends on the scope you agree in writing, not on a fixed number. The main drivers are how many repositories and pull requests carry review history that must move, how many Azure Pipelines definitions need rewriting as Forgejo Actions workflows, how many Artifacts feeds your builds depend on, and how much Boards data you export and keep elsewhere. Forgejo's dump-repo and restore-repo commands can carry issues, pull requests and wiki content from Gitea-family sources, but Azure Repos pull requests need a separate plan. Ask for the timeline as a list of phases tied to those counts.
What does the migration need from our own team?
Your team needs to supply knowledge and access, not only approvals. Expect to name owners for each repository and pipeline, provide read access to Azure DevOps projects and an export account with enough API throughput, confirm which branch policies and required reviewers must be recreated, and decide which users and groups map to Forgejo accounts. Security and identity staff must agree on how sign-in works and where secrets are stored. Development teams need time for cutover testing. The more undocumented pipelines and variable groups you have, the more of their time the work takes.
Can our internal team run the Forgejo migration without outside help?
Yes, a capable platform team can do it, provided it has someone who knows Git hosting administration, CI runners, backup and identity integration. The harder parts are rewriting pipelines, reconciling pull request history, and building runbooks that survive staff changes. Teams often underestimate post-cutover work: runner fleet sizing, backup restore tests and the upgrade calendar. Ask whether your team has capacity for those for at least the first few release cycles. If not, a fixed-scope engagement can cover planning, implementation, hardening and documentation, while your staff keep ownership.
Can Forgejo replace Azure Boards and Azure Test Plans?
Forgejo covers Git hosting, pull requests, issues, labels, milestones and packages, but it has no equivalent of Azure Boards work item types, hierarchies and sprint planning, and no Azure Test Plans for manual test management. Teams usually either move backlog work to a dedicated tool such as OpenProject, Plane or Redmine, or keep Boards in Azure DevOps during a transition. Test Plans often move to a separate test management tool or to automated tests in CI. Confirm the exact feature list you use before scoping, because gaps depend on how your team works.
How long are Forgejo releases supported?
Forgejo publishes stable releases and LTS releases. According to the Forgejo releases page, v17.0.0 was released on October 15, 2026 with support until January 28, 2027, and v15 is the LTS release supported until July 15, 2027. Per the Forgejo upgrade documentation, stable releases receive full support for three months plus a two-week window, and LTS releases receive critical bugfixes and security support for one year and three months. For production, plan around the LTS line and check the releases page for the current schedule before you commit to a version.
Can DeployOpen run the Forgejo migration under a fixed-scope agreement?
Yes. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps evaluate, implement and migrate to Forgejo
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Azure DevOps vs Forgejo, we start with a written scope that separates the Git and pull request work Forgejo can cover from the Boards and Test Plans work it cannot, so the decision rests on your actual workloads.
How we scope
- Inventory of Azure Repos, branch policies, pipelines and Artifacts feeds in use today
- Written list of which Boards and Test Plans workflows need a separate tool or stay out of scope
- Fixed-scope agreement covering deliverables, timelines and hosting location before work starts
How we build
- Forgejo deployment in your cloud account, data center or air-gapped network, configured to your standards
- Forgejo Actions runners built and tested against the pipeline patterns your teams actually use
- Security testing of the deployment and integrations, with results documented for your review
How we hand over
- Migration runbook covering Git mirroring, repository history and the pull request content that must be exported separately
- Operational documentation for backups, upgrades, runner management and access control
- Evidence and control records prepared for your compliance assessment, which independent auditors then review
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Upgrade planning that follows the Forgejo release and support windows, with each change tested first
- Retainer scope agreed in writing, so you know which Forgejo versions and tasks are covered
