Azure DevOps Server lifecycle: upgrade or replace

Azure DevOps Server lifecycle: what changes when you renew

If your Azure DevOps Server renewal or support date is forcing a decision, the short answer is this: the next release of the on-premises product moves to the Modern Lifecycle Policy, which rewards customers who stay current, so the question is no longer only whether to renew. You have three paths: upgrade the server on your own infrastructure, move to Azure DevOps Services in the cloud, or replace the server with a self-hosted forge such as GitLab or Gitea. Each path changes a different part of your cost and risk.

Azure DevOps Server 2022 has mainstream support until January 2028. Microsoft announced on October 7, 2025 that the on-premises 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, according to the Azure DevOps blog. Practically, this means a server that falls several releases behind may no longer be covered in the way your current support contract assumes. Confirm with your Microsoft account team or licensing partner exactly what your agreement covers after January 2028 and which update cadence the new policy requires for your version.

Choosing open source changes the software and support model, not only where the server runs. GitLab, Gitea and Forgejo are self-hosted in your data center or cloud account just as Azure DevOps Server is, but the vendor, release train, upgrade path and support contract all differ. Before you commit, list who will patch the server, who will handle upgrade stops and restores, and which support contract you will buy for each option. Those answers, rather than the hosting location alone, determine whether replacement lowers your total effort.

What the lifecycle decision must satisfy

A renewal decision has to keep the server supported, keep code and records where your rules allow, carry Git history and metadata across cleanly, and fit the staff time you can spare. The cards below set out each requirement and the check to run before you commit to a path.

Continuous currency under the policy

Microsoft announced on October 7, 2025 that Azure DevOps Server moves from the Fixed Lifecycle Policy to the Modern Lifecycle Policy, under which customers who stay current receive continuous support. Under this model, falling behind the current release can end the support you rely on, so the upgrade cadence becomes a standing operational duty. Confirm with Microsoft exactly which versions count as current and how long you have to move between them.

Data on infrastructure you control

Each commercial Git host sells a self-managed edition, so staying on premises keeps code on your servers, but it does not change the software vendor or the support contract. An open-source forge changes both the software and the support model. Map which repositories, build logs, packages and secrets must stay in a specific location, then check each option against that map.

Git history and metadata migration

A clone or mirror moves Git history between any two forges, but issues, pull requests, reviews and wikis need a platform importer. Gitea's migration code includes importers for GitHub, GitLab, Gitea, Gogs, OneDev, GitBucket, Codebase and AWS CodeCommit, and it has no Azure DevOps importer. Inventory which metadata your teams depend on and test the path on a copy before the cut-over.

Operational load of running a server

A self-hosted forge shifts patching, backups, storage growth and on-call duties to your team or a partner. GitLab ships a minor release monthly and requires upgrades to pass through required upgrade stops, so the upgrade plan needs named owners and a test environment. Ask any vendor or partner for a written statement of who performs each recurring task and how often.

Licensing and governance of the forge

The open-source options differ in license and governance. GitLab is open core, with MIT-licensed code outside its ee/ directory and paid features in the proprietary ee/ directory. Gitea is MIT licensed with commercial support from CommitGo, and Forgejo is GPL-3.0-or-later from v9.0. Check which features your process needs fall under a paid tier, and who controls the project's direction over the period you plan to run it.

Upgrade, move to Azure DevOps Services or replace: which path fits

Staying on Azure DevOps Server suits organizations whose policies, integrations and staff skills are built around the on-premises product and who need code to stay inside their own network. Microsoft announced on October 7, 2025 that the server drops the year from its name and moves to the Modern Lifecycle Policy, under which customers who stay current receive continuous support. That turns the upgrade from an occasional project into a recurring duty.

Lifecycle model: Under the Modern Lifecycle Policy, support depends on running a current release, so plan a regular upgrade cadence instead of waiting for an end-of-support date.
Current support date: Azure DevOps Server 2022 has mainstream support until January 2028. Confirm the date for your installed version in Microsoft's lifecycle documentation.
Extensions and templates: Test each marketplace extension, custom process template and integration against the target release in a staging instance restored from a recent backup.
Recurring cost: Licenses, server or virtual machine capacity, database and operating system licenses, and staff hours for each upgrade recur. Ask the vendor or partner for renewal terms in writing.

Before choosing this path, check which release your contract references and whether it includes upgrade rights.

How GitLab, Gitea and Forgejo compare for a server replacement

This table compares the three self-hosted forges on license, built-in CI, package registries, commercial support and upgrade paths for teams leaving Azure DevOps Server. Read each row against your own lifecycle deadline, then confirm the gaps that matter for your Boards and Test Plans usage before choosing.

Capability	GitLab	Gitea	Forgejo
License and governance	Open core: MIT Expat outside the ee/ directory, GitLab Enterprise Edition license inside it	MIT licensed, with leadership and commercial support from CommitGo, Inc.	GPL-3.0-or-later from v9.0, earlier versions under MIT; Codeberg e.V. holds the domains
Built-in CI	GitLab CI/CD with .gitlab-ci.yml; the pipeline syntax differs from azure-pipelines.yml	Gitea Actions, designed to be compatible with GitHub Actions	Forgejo Actions with separate runners, familiar to GitHub Actions users but not compatible with them
Package registries	Built into the platform; confirm the formats your Azure Artifacts feeds use	More than 20 registry types, including npm, PyPI, Maven, container images and Helm charts	Confirm registry types against the current Forgejo documentation for your feed formats
Commercial support tiers	Free, Premium and Ultimate, all available for self-managed installations; feature lists differ by tier	Community edition plus Gitea Enterprise with SAML 2.0, audit logging and IP allowlisting; Gitea Cloud is also offered	Community-supported; confirm any commercial support options with the Forgejo community or a third-party provider
Upgrade path from Azure DevOps Server	Migration through GitLab import tools; upgrades must stop at required upgrade stops such as 18.2, 18.5 and 19.2	Importers exist for GitHub, GitLab, Gitea and others; confirm current Azure DevOps handling for your repositories	Dump and restore commands cover issues, pull requests and wikis from Gitea, GitHub and GitLab sources
Release cadence and support window	Major release yearly, monthly minor releases, security backports to the previous two monthly releases	Versioned releases on the v1.27 and v28 lines; confirm the support window for your chosen version	Stable releases get three months of full support; LTS releases get one year and three months of critical fixes
Azure Boards equivalent	Issues, epics and boards exist but do not map one to one to work item types; confirm gaps	No built-in work item tracking equivalent to Boards; plan a separate tool	No built-in work item tracking equivalent to Boards; plan a separate tool
Test Plans equivalent	Confirm test case and test plan coverage against your Ultimate or Premium needs	No direct equivalent to Azure Test Plans; confirm with your QA team	No direct equivalent to Azure Test Plans; confirm with your QA team

How to replace the server without breaking builds

This sequence moves repositories, pipelines, packages and review history from Azure DevOps Server to a self-hosted forge in a controlled order, so teams keep building throughout and can roll back until the cut-over is verified.

Inventory repositories, pipelines and packages
Your team lists every Git repository, TFVC branch to convert, pipeline definition, agent pool, service connection, variable group, package feed and external integration that depends on the server. Name an owner for each item and note which ones are YAML and which are classic. The output is a written inventory with a target for each item, reviewed by the build and release leads. Confirm early which items the target platform cannot import, such as secret variables, which cannot be read back from Azure DevOps.
Choose the target and deployment method
Decide whether the target is GitLab, Gitea or Forgejo, based on the features your inventory actually uses. For GitLab, pick an installation method: the Linux package, the Helm chart, the GitLab Operator, Docker or source. GitLab's installation methods page describes the Linux package as the most mature and scalable option. Record the choice, the operating model and the support arrangement in a decision note signed off by the platform owner. Check that the chosen method supports your offline or air-gapped requirements if you have them.
Size the instance for your user count
Compare your number of active users and expected API load with GitLab's reference architectures, which run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second. The documentation generally recommends a high availability strategy at 3,000 or more users, which affects storage, database and Redis design. Keep stateful components such as PostgreSQL and Redis on VMs or managed services, because running them inside Kubernetes is not supported in the reference architectures. The output is a sizing sheet that your infrastructure team has reviewed.
Run a parallel instance and mirror Git history
Stand up the target next to the existing Azure DevOps Server, with the same identity provider integration planned for production. Mirror each Git repository with a clone or mirror push so commit history, branches and tags arrive intact. Pull requests, reviews, comments and issues do not travel with a mirror, so import them with the platform importer. GitLab can import from Bitbucket Server and other sources, but Azure DevOps is not in its list of importers, so confirm the current options with the vendor before you plan the data path. Verify that a sample of repositories matches commit for commit.
Import issues and pull requests with the platform importer
Run the platform's importer for the work items and review history your inventory marked as required, starting with a pilot project. Compare counts of issues, pull requests, comments and attachments against the source and record any records that failed to map. For Forgejo, the dump-repo and restore-repo commands can move a repository with issues, pull requests, releases, labels, milestones and wiki content when the source is a supported forge, so check your starting point against the Forgejo command-line documentation. Sign off each project with the team that owns it.
Rebuild pipelines and verify backups and restores
Convert YAML pipelines to the target's CI format and re-create secrets, runners and branch protection rules, since these do not migrate automatically. Run each pipeline on the parallel instance and compare artifacts and test results with the Azure DevOps builds. Then perform a full backup and restore test on a separate host, using the platform's backup and restore documentation, and confirm that repositories, database and object storage return intact. The output is a passing rehearsal log that the operations team accepts.
Plan upgrade paths before go-live
Record the upgrade path the target will need over its life before you go live. GitLab requires upgrades to pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11 and 19.2. If you choose Forgejo as a replacement for an existing Gitea installation, Forgejo documents transparent upgrades from Gitea up to v1.22, first to Forgejo v10.0.x and then to later Forgejo versions. Put these stops on the operations calendar and confirm them against the current upgrade documentation.
Cut over and keep the old server read-only
Schedule the cut-over window with the build and release owners, freeze pushes to Azure DevOps Server, run a final mirror and import delta, update remote URLs, service hooks and agent configuration, and switch pipelines to the new instance. Keep the Azure DevOps Server available in read-only mode and retain its backups for a period your compliance owner sets. The step is complete when the first production builds and deployments succeed on the new platform and the rollback plan has been tested.

What each path costs to run, by component

Start by separating the cost of each path into the parts someone is paid for. On the renew-and-upgrade path, the main line items are the Azure DevOps Server license or subscription, the labor to run each in-place upgrade, and the test environment needed to rehearse it. Staying on Azure DevOps Services shifts cost to per-user seats for Basic and Basic plus Test Plans access, parallel jobs for pipelines, and Artifacts storage above the included allowance. Ask Microsoft or your reseller for a written quote that lists each meter for your user count and build volume, because the list of billable items is what decides the comparison. Do not rely on a single headline number. For the self-hosted paths, the recurring items are servers or virtual machines, storage, backup retention, a support subscription if you buy one, and the staff hours spent on patching and monitoring. GitLab publishes its Premium tier at 29 US dollars per user per month billed annually on its pricing page, with Free at 0 dollars and Ultimate custom priced, and that list price is a starting point for a quote, not a total cost. Gitea and Forgejo carry no list license fee for the community editions, but Gitea Enterprise and any managed Gitea Cloud arrangement are separately priced, so request those quotes directly.

Most of the one-time cost sits in migration work, and it is easy to underestimate. Moving repositories is cheap, but moving issues, pull requests, reviews, pipeline definitions and package feeds takes importer runs, rehearsals, rewrites of pipeline YAML and rebuilt branch policies. Pipeline rewrites are often the largest effort item for teams with many classic release pipelines. Secret variables cannot be read back from Azure DevOps, so each one has to be re-entered in the new platform by someone who holds the source value, which adds an approval step to the project plan. Budget for a parallel run period in which both systems are paid for, since keeping the old server available for read access during cut-over is a common safeguard. On the recurring side, the most consequential items for a self-managed server are patching and upgrade stops. GitLab requires passing through named upgrade stops, and its maintenance policy backports security fixes to only the current and previous two monthly releases, so a deployment that falls behind creates unplanned upgrade work. Forgejo LTS releases carry support for one year and three months, so the upgrade calendar is a recurring cost as well.

Ask each vendor to state the assumptions behind its estimate: user count, number of active committers, parallel jobs, storage per repository and the number of environments you need. Then price the operating model, not just the license. Who is on call for the forge, who restores from backup in a test, and who signs off on upgrades? Those roles are the largest drivers of cost on any self-hosted path, and they are often absent from a first comparison. If you need data kept in a specific region or on your own network, add the cost of the infrastructure that makes that possible, including any air-gapped setup. GitLab documents offline and air-gapped operation, and Azure DevOps Server runs on your infrastructure, so both can meet that need, but the hardware and administration effort differ. For an illustrative case, a team with a few hundred users and a small number of pipelines will see a different balance between seats and staff hours than an organization running thousands of parallel jobs, so model both before deciding. DeployOpen can scope and quote the implementation, hardening, backup and upgrade work for any of these paths as a fixed-scope engagement, but the figures must come from a written scope that reflects your environment.

Questions buyers ask before choosing a path

How much effort does replacing Azure DevOps Server take?

Effort depends mostly on what you move. Git history can be mirrored with a clone, but issues, pull requests, reviews and wikis need a platform importer, and Azure DevOps Server work items, pipelines and Artifacts feeds each need their own mapping. Teams with many repositories, long TFVC history, or many pipeline definitions should expect more work than teams with a small Git estate. Each replacement component adds design, testing and cut-over work, so scope the components separately in any quote. Ask the vendor or integrator to inventory repositories, pipelines, feeds, service connections and users before pricing.

Can our team migrate without outside help?

A capable platform team can do it, provided it has time, a test environment and someone who owns the cut-over decision. The work includes installing and hardening the new forge, configuring identity and backups, rebuilding branch protections and CI definitions, and training developers. Outside help is most useful where the team lacks recent experience with the target platform, has a tight deadline, or needs documented evidence for an assessment. Ask whether the skills gap, or the cost of pulling engineers off product work, makes an outside engagement cheaper overall.

How long does the cut-over window take?

The window is driven by repository count and size, the number of pipelines that must be rewritten, how many users must switch identity or credentials, and how much history must come across. Teams often reduce downtime by mirroring repositories ahead of time and freezing writes only for a final sync. Hosted and self-managed sources also impose export limits, so bulk exports can be paced by API throughput. Ask for a written cut-over plan with a rollback step, and do not accept a duration that is not tied to your inventory.

What does a fixed-scope engagement need from our side?

A fixed-scope engagement needs a written scope that names the repositories, pipelines, feeds, identity sources, compliance evidence and acceptance tests in play. The client typically provides infrastructure access in its own cloud account, data center or air-gapped network, a named technical owner, access to the current Azure DevOps Server configuration, and decisions on retention, data residency and single sign-on. Timelines and deliverables are agreed before work starts, so changes in scope should be raised in writing. DeployOpen does not publish prices, and a quote follows from the written scope.

Can Boards and Test Plans be replaced?

Only partly, and the answer depends on the tool. GitLab covers issues, epics and merge requests, and its tiers differ in what planning and security features they include, so compare the GitLab pricing page against the Boards features you use. Gitea and Forgejo focus on Git hosting, code review, packages and CI, and do not offer a Boards or Test Plans equivalent. Teams that depend on Boards often pair the forge with a dedicated work management tool, and Test Plans usually need a separate test management product. Export work items through the REST API within throughput limits before deciding.

How should we choose between GitLab, Gitea and Forgejo?

Choose based on license, governance, support model and the CI features your teams already use. GitLab is open core: its Community Edition code outside the ee/ directory is MIT licensed, and features in the ee/ directory require a paid subscription. Gitea is MIT licensed with commercial support from CommitGo. Forgejo is GPL-3.0-or-later from v9.0, with domains held by Codeberg e.V. Consider upgrade paths too: Forgejo documents transparent upgrades from Gitea up to v1.22, while GitLab requires upgrade stops. Confirm each feature you depend on against the vendor documentation before you decide.

Does a self-managed Azure DevOps Server upgrade still count as a lifecycle decision?

Yes. Microsoft announced that the on-premises product drops the year from its name and moves to the Modern Lifecycle Policy, under which customers who stay current receive continuous support. Staying on an older release means you may fall outside the support model that new releases follow, so plan upgrades as recurring work rather than a one-time event. Ask Microsoft or your reseller which versions remain supported on your current release train, and whether a replacement project would reduce upgrade effort over the next several years.

Evidence to keep for the lifecycle decision

Whichever path you take, the same set of records will be requested by your CISO, internal auditors and the business sponsor. Keeping them together lets you show why you chose a version or platform, what was moved, and how you know it works. DeployOpen can prepare this evidence, but independent auditors and certification bodies are the ones who issue any assessment.

Version and support record

Record the chosen Azure DevOps Server or target platform version, the support dates that apply to it, and the lifecycle policy under which you are covered. For on-premises Azure DevOps Server, the Modern Lifecycle Policy means continuous support depends on staying current, so note the upgrade cadence you commit to. Confirm the dates directly with Microsoft or your reseller at the time of decision, and file the source you used.

Written decision record

A short decision record states the options considered (upgrade, move to Azure DevOps Services, or replace with self-hosted GitLab, Gitea or Forgejo), the criteria used, the risks accepted and the named approver. Include the data residency, licensing and lock-in reasons that triggered the review. Auditors look for a dated, approved rationale rather than a discussion held in a meeting.

Migration inventory

List every repository, pull request history, work item query, pipeline definition, package feed and service connection in scope, with an owner and a target. Mark what is out of scope, such as Boards or Artifacts if Gitea replaces only Repos and Pipelines. The inventory is the baseline against which every later importer result is checked, so it should be frozen before the first import run.

Importer and export logs

Keep the raw logs from every clone, mirror, importer and export run, including failed items and the reason for each. Note which artifacts did not transfer, such as pull request reviews where the target platform has no Azure DevOps importer, and which were rebuilt by hand. Logs are the only proof of what moved and what did not, and they are needed when a team asks why a pull request is missing.

Backup and restore test results

Record a full backup of the source and the target, a restore into a separate environment, and the checks performed on the restored data, such as commit counts, branch heads and sample issues. Keep the date, the operator and the result. A backup that has never been restored is an assumption, and this record turns it into evidence for the continuity review.

Access and branch policy exports

Export user and group memberships, permission assignments, branch protection and required review rules from Azure DevOps before cut-over, and export the equivalent settings from the target. Compare the two exports and sign off each difference. Auditors commonly test whether approval rules on protected branches survived the move, so the comparison should show the exact rules, not a summary.

Signed scope and acceptance

Keep the written scope, deliverables, acceptance criteria and sign-off for any implementation partner, including what was accepted, what was deferred and who accepted each item. Fixed-scope engagements make this straightforward because the scope is agreed in writing before work starts. Ask any partner to confirm which records they prepare and which remain your responsibility.

How DeployOpen runs a Git server replacement

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so the lifecycle decision for Azure DevOps Server becomes a written plan with clear deliverables. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We confirm which Azure DevOps Server components you use: Repos, Pipelines, Boards, Artifacts and Test Plans.
We inventory repositories, pull requests, pipelines, service connections and integrations that must survive the decision.
We record your data residency, air-gap and identity requirements before comparing upgrade, Services or GitLab or Gitea options.
We agree deliverables, timelines and acceptance criteria in writing before any build work starts.

How we build

We stand up the chosen target, such as a self-hosted GitLab instance or Gitea, in your cloud account, data center or air-gapped network.
We set up single sign-on, branch protection, pipeline runners and backup jobs against your own policies.
We run test migrations of sample repositories and pull requests and check history, permissions and CI results.
We document the upgrade stops, configuration and rollback steps so your team can repeat them later.

How we hand over

We deliver runbooks for installation, upgrades, backup and restore, and access administration in your environment.
We provide evidence for controls you need to show an assessor, while independent auditors and certification bodies issue any reports.
We walk your administrators and developers through the cut-over plan, including how Azure Boards data is exported.
We agree a documented decommissioning plan for the old Azure DevOps Server once teams have moved over.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can plan upgrades along the vendor's required upgrade path and test each step before production.
We can run security testing of the new forge and its CI runners as part of a separate written scope.
Ask any provider to confirm the upgrade calendar, support window and backup restore test cadence in writing.

Azure DevOps Server lifecycle: renew, upgrade or replace