Migrate from Azure DevOps to Gitea: what the move involves
Git history moves easily, but pull requests and Azure-specific features need planned rework. Gitea has no Azure DevOps importer, so a mirror of each repository carries commits, branches and tags across, while pull requests, review comments, work item links and branch policies stay behind. Teams usually reach this decision during an Azure DevOps Server renewal, a licensing change, a data residency review or a lock-in concern, and the first task is an inventory: which repositories are active, which hold TFVC history that must be converted to Git first, and which pull requests need to be kept as records. Platform engineering normally leads the work, with security reviewing access, secrets and audit needs, and an implementation partner often carrying the scripting and cut-over rehearsal. Confirm with your own environment how much of the repository set is active and how long the rehearsal window can be.
Gitea replaces Azure Repos and part of Azure Pipelines. Its built-in Gitea Actions is designed to be compatible with GitHub Actions, so pipeline definitions written in azure-pipelines.yml will need translation rather than a direct import, and service connections, variable groups and approval gates must be rebuilt with their Gitea equivalents. Gitea does not cover Azure Boards or the Artifacts feeds, so those need separate decisions: Boards work items may move to a dedicated planning tool, and Artifacts feeds may move to a package registry in Gitea or to another repository manager. Gitea's repository migration documentation is the starting point for confirming which importers apply to your sources before you commit to a plan.
Which Azure DevOps capabilities map to Gitea, and which need rework
This table maps each Azure DevOps capability to its Gitea counterpart and labels it clean, needs rework or gap. Read it as a migration checklist: clean rows move with little change, rework rows need conversion or rebuilding, and gap rows have no Gitea equivalent and need another tool or a decision to retire the function.
| Azure DevOps capability | Gitea equivalent | Status and what to do |
|---|---|---|
| Azure Repos Git repositories | Git repositories hosted by Gitea | Clean. Mirror each repository with its full history and branches. Confirm tags and LFS objects separately. |
| Pull requests and comments | Gitea pull requests | Needs rework. Gitea has no Azure DevOps importer, so open pull requests and review threads do not transfer. Close or record them before cut-over. |
| Branch policies | Gitea branch protection rules | Needs rework. Recreate required reviewers, status checks and push restrictions by hand per branch. Organization-level inheritance is an Enterprise feature. |
| TFVC version control | Git (no direct TFVC support) | Needs rework. Convert TFVC history to Git before import, as Gitea reads Git only. Plan the conversion as a separate step with its own validation. |
| Azure Pipelines YAML | Gitea Actions workflows | Needs rework. Gitea Actions is designed to be compatible with GitHub Actions, so workflow syntax and task usage differ from azure-pipelines.yml. Confirm each task and runner before relying on it. |
| Azure Pipelines classic and variable groups | Gitea Actions secrets and variables | Gap. Classic release definitions have no direct Gitea counterpart. Secret variables cannot be read back from Azure DevOps, so re-enter them in Gitea. |
| Azure Artifacts feeds | Gitea package registries | Needs rework. Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. Confirm NuGet and Universal Packages support in your version before planning. |
| Azure Boards work items | No Gitea counterpart (issues and labels only) | Gap. Gitea issues and milestones do not model work item types, backlogs or sprints. Use a separate planning tool and export Boards data first. |
| Azure Test Plans | No Gitea counterpart | Gap. Test cases, test runs and manual testing have no Gitea equivalent. Keep Test Plans in place or move test management to a separate self-hosted tool. |
How Git history and TFVC move to Gitea
Git history moves between any two forges with a clone or mirror, but review records do not. A mirror carries branches, tags and commit history, so the code itself is not at risk. Issues, pull requests, reviews, comments and wikis are a different matter. Gitea's documented migration paths cover GitHub, AWS CodeCommit and GitLab through a non-affiliated third-party tool, and its migration code includes importers for Gitea, Gogs, OneDev, GitBucket and Codebase as well. Azure DevOps is not on either list. Before the cut-over, the team has to pick one of three routes: a plain Git mirror that leaves Azure Repos pull requests and review threads in Azure DevOps for reference, an intermediate export from the Azure DevOps REST API into a neutral format that a script can read, or a rebuilt review record in which key pull requests are recreated by hand in Gitea with a link back to the original. Confirm which route your audit and records rules accept before anyone runs a script.
TFVC repositories must be converted to Git before any mirror step. A Git mirror cannot read Team Foundation Version Control changesets, so a TFVC source has to be migrated first. Confirm with your own Azure DevOps administrator which folders are TFVC and which are already Git, because an Azure DevOps project can hold both. Decide how much changeset history must survive. Converting the full history preserves blame and audit trails but takes longer and can surface oddities such as large binaries and branched paths. Keeping only the current tip as the starting point is simpler, but the earlier history then lives only in the TFVC archive, which should be kept read-only. Whichever approach you choose, verify the converted repository with a fresh clone and compare branch and tag lists against the source before any developer relies on it.
Check repository size and API limits before you plan the export. Large repositories and bulk API reads both extend the work. Azure DevOps delays users above 200 throughput units in a five-minute window, so a scripted export of work items and pull request threads should run under a service identity with its own pacing and retries. Ask whether the export will be run by your staff or by DeployOpen as part of a fixed-scope engagement, and get the list of repositories, the chosen history depth and the review-record approach written down before the export begins.
What to export from Azure DevOps and what to rebuild in Gitea
Azure DevOps keeps some of what a Gitea migration needs in exportable form and some only in the platform. Each item below has a different export path, a different rebuild effort, and a different risk of losing data if it is left until the cut-over.
Git repositories and history
Git history moves with a clone or mirror, so every branch and tag can be copied to Gitea without a platform importer. Gitea's documented repository migration covers GitHub, AWS CodeCommit and GitLab, but lists no Azure DevOps importer, so repositories arrive as plain Git. Check that every branch, tag and LFS object is present after the mirror, and confirm which repositories still use TFVC, since those need conversion before they can be mirrored.
Pull request history
Pull requests, reviews and comments do not come across through Gitea's importer. Azure DevOps exposes them through its REST API, so teams that need the record for audit or traceability should export them to a file before the cut-over. Decide which open pull requests are finished in Azure Repos and which are re-opened in Gitea as new reviews, and record the decision for each one.
Branch policies and required reviewers
Azure DevOps branch policies, minimum reviewer counts, build validation and required reviewers are configuration, not Git data, so none of them move with a mirror. Record each policy per branch from the Azure DevOps settings screens or API, then re-create the equivalent protected branch rules in Gitea. Confirm how Gitea enforces required approvals and status checks on your version, because the rules do not map one to one.
Service connections and pipeline definitions
Pipeline definitions in azure-pipelines.yml are plain files in the repository and move with it, but classic pipelines live only in the Azure DevOps database. Service connections hold credentials that cannot be copied out, so each one must be re-created in the new CI system with newly issued credentials. Gitea Actions is designed to be compatible with GitHub Actions, so YAML steps need rewriting rather than a direct copy.
Secret variables
Secret pipeline variables cannot be read back through the Azure DevOps interface or API, so their values are lost at export and must be obtained from the system that owns each credential. Build an inventory of every secret, its owner and the job that uses it, then load the values into the Gitea secret store or a dedicated secrets manager. Plan for a rotation of each credential at the cut-over.
Artifacts feeds and bulk export limits
Artifacts feeds hold NuGet, npm, Maven, Python and Universal Packages that must be exported or re-published to a Gitea package registry, which supports more than 20 registry types. Bulk export through the REST API is constrained by Azure DevOps throughput limits: requests are delayed above 200 throughput units in a five-minute window, so large exports should be scheduled and paced. Confirm which feed types you use before choosing a target.
Migration sequence from inventory to decommission
This sequence moves Azure Repos Git history to self-hosted Gitea in controlled stages, so each repository is verified before its consumers switch. It ends with a retained archive of Azure DevOps data that stays available after Azure Repos is decommissioned.
Inventory repositories, identities and integrations
List every Git repository in each Azure DevOps project, noting default branches, branch policies, size, LFS use, and whether any repository started as TFVC and needs conversion first. Record each user and group that holds access, every service connection, and each webhook, build trigger and external tool that reads from Azure Repos. The output is a repository inventory and an integration register, which your team signs off before any data moves. Ask your Azure DevOps administrator to confirm the export permissions your account holds, since bulk reads are subject to the service's throughput limits.
Convert TFVC and prepare the target instance
Repositories still on Team Foundation Version Control need conversion to Git before they can be mirrored, so decide per history whether to convert full history or start a fresh Git repository from the latest version. In parallel, install and harden the Gitea instance, configure its database, SSO and two-factor policy, and set up backups. The output is a converted Git history for each TFVC source and a Gitea instance that passes your internal build and access review.
Pilot one low-risk repository end to end
Choose a repository with a small history, few contributors and a non-critical pipeline. Mirror it with git clone --mirror, push the mirror to Gitea, then rebuild its branch protections, Gitea Actions workflows and access groups by hand. Ask the owning team to run a normal change through a pull request. The output is a pilot sign-off record that lists the commit count, branch and tag counts, the checks that passed, and the gaps found, including pull requests and comments that stayed in Azure DevOps.
Run the parallel migration
Migrate the remaining repositories in batches using the same mirror procedure, keeping Azure Repos open for reading only so teams can look up history and old reviews. For each repository, compare refs and object counts between source and target, then record the result in a mirror verification log. Export pull request and issue text separately where you need it for reference, since Gitea's repository migration documentation lists no Azure DevOps importer. The output is a verification log showing matching refs and commit counts for every repository.
Cut over remotes and CI triggers
On an agreed date, update each local clone remote, reconfigure CI triggers and webhooks to point at Gitea, and switch the Azure Pipelines or Gitea Actions workflows that build those repositories. Set Azure Repos to read-only, confirm that a test commit triggers the expected build on Gitea, and watch the first build cycle for failures tied to credentials or paths. The output is a cutover checklist signed by each product owner, with every integration on the register marked as moved or retired.
Decommission Azure Repos and retain the archive
After the agreed reference period, remove write access and retire Azure Repos projects that no longer serve builds. Before deletion, export and store an archive of Azure DevOps data that your records policy requires, such as repository mirrors, work item exports, pipeline definitions and Artifacts feeds, in storage you control. Confirm the archive can be read and restored by someone outside the original team. The output is a retained archive with an index and a decommission record that names the owner who approved removal.
Running both platforms in parallel and cutting over safely
The safest cutover keeps Azure Repos as the read-only system of record until Gitea has been verified against it. Set the Azure DevOps repository permissions so that only the migration account and a small group of administrators can push, and tell developers in writing that merges stop happening in Azure Repos on the agreed date. During the parallel period, mirror pushes from Azure Repos to Gitea on a schedule, and check each mirror for matching branch heads, tags and commit counts before you trust it. Pull requests, reviews and work item links do not come across through Gitea's importers, so record the open pull requests in Azure Repos now and decide whether each one is merged, closed or re-opened in Gitea as a new request.
Repoint consumers in batches, not all at once. Group repositories by owning team and by how many clones, submodules and build triggers depend on them, then start with low-traffic repositories. For each batch, update git remote URLs on developer machines, change service connections and pipeline repository references, and move webhook-driven triggers to Gitea Actions or to the CI system you chose. Keep a register that lists each repository, its new remote, the pipeline that depends on it and the person who signed off the change. Gitea Actions is designed to be compatible with GitHub Actions, but compatibility is not the same as identical behavior. Check every workflow file against the GitHub Actions syntax your team uses, paying attention to expression functions, runs-on labels, secrets handling and reusable workflow references, and run each one on a branch before you rely on it.
Freeze merges for the final sync, then run one last mirror and verify it before anyone resumes work. The freeze should cover branch policies in Azure Repos (set so no pull request can complete), and it should stop pipelines that push to protected branches. After the final sync, compare the refs and the most recent commit on each protected branch in both systems, then re-create the branch protection rules, required reviewers and status checks in Gitea before lifting the freeze. Confirm the freeze window with the people who own release and hotfix processes, since a delayed freeze is a common source of divergent history. Keep Azure Repos read-only for a defined retention period so anyone who needs an old pull request or a blame history can still reach it, and ask your implementation partner to document the rollback path in writing before the cutover date.
How the migration changes by team size and starting point
Teams that keep most of their work in Git repositories, use a few pipelines and do not rely on Boards or Artifacts usually have the smallest migration. The repositories can be mirrored to Gitea with a plain Git clone or mirror, and the pipeline definitions are rewritten for Gitea Actions, which is designed to be compatible with GitHub Actions. The main gap is the pull request history. Gitea's documented migration paths cover GitHub, AWS CodeCommit and GitLab, and do not include an Azure DevOps importer, so open pull requests, review comments and work item links stay in Azure DevOps unless they are exported and recorded by hand.
- Repository scope: Mirror each active repository and confirm default branches, tags and LFS content, if used.
- Pull request history: Decide whether to archive closed pull requests as read-only exports or simply keep the Azure DevOps project available for reference.
- Pipeline rewrite: Convert
azure-pipelines.ymlfiles to Gitea Actions workflows, then test each one on a branch. - Access: Re-create users, teams and repository permissions directly in Gitea.
- Cut-over: Freeze pushes to the old repository for a short window, mirror again and update remotes.
Before starting, ask your team which repositories changed in the last few months, since those are the ones that need the most care at cut-over.
Teams that still use Team Foundation Version Control, or that depend on long-lived branch policies, face extra work before any Git mirror is made. TFVC is not Git, so its history has to be converted into Git first, and the conversion decides how much version history survives and how branches map to Git branches. Branch policies in Azure Repos, such as required reviewers, build validation and comment resolution, do not transfer automatically. They must be re-created as branch protection rules and status checks in Gitea, and the review rules must be written down so the new configuration matches what the team expects.
- TFVC conversion: Choose a conversion tool and test it on one folder with a representative history before converting everything.
- Branch mapping: List the long-lived branches, such as release or environment branches, and decide which become Git branches and which are retired.
- Branch protection: Re-create required approvals, status checks and push restrictions in Gitea, and confirm who may override them.
- Policy evidence: Keep a record of the old policy settings, since auditors often ask how a change was approved before and after the move.
- Tooling: Check whether build and deployment scripts depend on TFVC paths or workspace commands.
Ask the team to list every branch policy and the business reason behind it, because the conversion is simpler when the rules are known before the first test run.
Teams that use Azure Boards for work items or Azure Artifacts for package feeds should treat Gitea as one part of a larger change, not a complete replacement. Gitea covers Git hosting, code review, CI/CD and more than 20 package registry types, so Artifacts feeds may have a natural home there, but the decision depends on which feed formats and upstream sources the team depends on. Boards has no direct equivalent in Gitea. Work items, backlogs and sprint plans need a separate tool, and links between commits and work items must be re-established in that tool.
- Boards: Pick a separate work tracking system and map work item types, states and links before exporting data.
- Artifacts feeds: Inventory each feed, its upstream sources and its consumers, then decide between Gitea and another repository manager.
- Build dependencies: Pipelines that pull packages from Azure Artifacts must be updated with new feed URLs and credentials.
- Sequencing: Move repositories first, then Artifacts, then Boards, so each step can be tested on its own.
- Traceability: Record which commits and builds reference work items so that audit trails remain readable after the move.
Confirm with each team which Boards and Artifacts features it uses today, since the amount of rework depends on that list more than on the number of repositories.
What drives the cost and duration of the move
This table lists the factors that set how long the Azure DevOps to Gitea move takes and what it costs to run afterwards. Read each row as a driver: what it changes, and what you can do to keep it manageable. The main takeaway is that Gitea itself is free to license, so most of the effort comes from history conversion, pull request handling, pipeline rework and staff time.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Repository count and total size | Hosted Git services point to keeping a repository's .git folder under 10 GB (GitHub guidance), a useful size reference for spotting outliers that need extra planning during mirroring. | Inventory every repository with its size before the cut-over, split or archive oversized ones, and move large binaries to object storage or an artifact store. |
| TFVC history length | TFVC is not Git, so long TFVC histories must be converted before mirroring to Gitea, and conversion time grows with the number of changesets. | Decide per project whether to keep full history, start Git from a recent label, or archive the TFVC server read-only. |
| Pull requests to preserve | Gitea has no Azure DevOps importer, so pull requests, reviews and comments do not move automatically and must be exported or recorded by hand. | Limit preservation to open and recently merged pull requests, and export the rest to a read-only archive that links to commit hashes. |
| Branch policy complexity | Azure DevOps branch policies such as required reviewers, build validation and status checks must be re-created as Gitea branch protection rules, and each rule needs testing. | Document current policies per branch, reduce them to a standard set, and test each protected branch with a dummy pull request before go-live. |
| Pipelines and service connections | YAML pipelines need translation to Gitea Actions workflows, and service connections, variable groups and secret values cannot be read back from Azure DevOps and must be re-entered. | Start with the pipelines that still run, retire unused ones, and plan secret re-entry with the owners of each service connection. |
| Artifacts feeds | Packages in Azure Artifacts are not moved by a Git mirror, so each feed needs its own registry in Gitea or another repository manager, plus updated client configuration. | List feeds and package types, confirm which ones Gitea supports, and move only packages still in use. |
| Identity mapping | Azure DevOps users, groups and Entra ID links must map to Gitea accounts, teams and commit author emails so history and access stay correct. | Export the user list, match it to your identity source, and decide whether to use SSO or local accounts. Confirm SAML support needs the Gitea Enterprise tier. |
| Number of integrations | Webhooks, build status badges, Boards links, chat notifications and deployment tools each point at Azure DevOps URLs and must be repointed. | Build a list of every system that calls Azure DevOps APIs or webhooks, and cut them over in one change window with a rollback plan. |
| Self-hosting: one-time costs | Setup covers servers or virtual machines, database and storage, TLS, the migration tooling and the staff hours to plan, test and document. Ask your implementation partner for a fixed-scope quote. | Reuse existing virtualization and backup platforms, use a standard template, and set acceptance criteria in writing before work starts. |
| Self-hosting: recurring costs | Recurring costs include compute, storage growth, backups and restore tests, upgrades between Gitea versions, monitoring, and staff time or a support contract for CommitGo or a partner. | Size storage with growth in mind, schedule upgrades on a fixed cadence, test restores quarterly, and compare a support contract with internal on-call time. |
What usually goes wrong when moving from Azure Repos to Gitea
Moving Azure Repos to Gitea is mostly a Git mirror, but the work around it is not. Pull requests, branch policies, secrets, pipelines, identities and mirror integrity are where teams most often lose information without noticing. Each card below names one risk and the check that catches it before cut-over.
Lost pull request context
Gitea has no Azure DevOps importer, so a mirror carries commits and branches but not the pull requests, reviewers, comment threads or approval history attached to them. Teams that need that history for audit or for open work should export it from the Azure DevOps REST API before cut-over and store it as a read-only archive. Confirm with the team which open pull requests must be finished in Azure Repos and which will be recreated as new Gitea pull requests.
Branch policies not re-created
Azure Repos branch policies for required reviewers, build validation and merge types do not transfer with a Git mirror. A repository can look complete in Gitea while accepting direct pushes to main that the old policy would have blocked. Write down every policy per branch in Azure DevOps, rebuild each one as Gitea branch protection, and test it by attempting a direct push and an unreviewed merge from a non-admin account.
Secret variables that must be reissued
Secret pipeline variables and secure files in Azure DevOps cannot be read back through the API or the portal, so they cannot be exported. Deployment credentials, signing keys and service tokens must be generated again in the new system and stored in the Gitea Actions secrets store or an external secrets manager. Build a list of every secret variable, its owner and the system it authenticates to, and rotate each one as part of the cut-over rather than copying old values.
CI workflows that break on syntax
Azure Pipelines YAML and Gitea Actions use different keys, task names and variable syntax, even though Gitea Actions is designed to be compatible with GitHub Actions. Azure-specific tasks have no direct equivalent, and hosted agent images differ from Gitea runners. Convert one pipeline at a time, run each converted workflow against a non-production branch, and confirm that artifacts, environment variables and deployment approvals behave as they did before.
Identity and permission mapping errors
Azure DevOps grants access through Entra ID groups, project-level security groups and area paths, and those roles rarely map one to one onto Gitea organizations, teams and repository permissions. Users may be created with the wrong email, admins may not carry over, and bulk-added teams may gain write access they never had. Map each Azure DevOps group to a named Gitea team in a written table, then compare effective permissions for a sample of users in both systems before inviting the full organization.
Unverified mirrors
A mirror that finishes without errors can still be incomplete, for example when large files exceed size limits, LFS objects are not fetched, or tags and some refs are skipped. Teams often discover the gap weeks later when a build fails on an old release. Compare the commit hash of every branch and tag between Azure Repos and Gitea, check LFS object counts, and keep the original Azure Repos repositories read-only for a defined period so they remain a fallback.
Questions teams ask before moving from Azure DevOps to Gitea
Does Gitea import Azure DevOps pull requests?
No. Gitea's repository migration documentation lists importers for GitHub, AWS CodeCommit and, through a non-affiliated third-party tool, GitLab, and it lists no Bitbucket or Azure DevOps importer. Repositories from Azure Repos arrive as plain Git history, so pull requests, comments, reviews and work item links stay in Azure DevOps. Teams usually archive the old pull request threads in a read-only export or keep Azure Repos read-only for a period, and they should confirm that approach with their auditors if reviews are retained as evidence. See the Gitea repository migration documentation for the supported sources.
How long does a move from Azure DevOps to Gitea take?
No general duration can be given without the inventory. The main drivers are the number of repositories, total repository size, how many TFVC codebases need conversion, how many branch policies and pipeline definitions must be rebuilt, the number of users who need accounts, and how many integrations depend on Azure DevOps service hooks. Repository mirroring is usually the quick part. Re-creating access control, CI pipelines and package feeds takes the most time. Ask for a timeline built from a written inventory, not from a repository count alone.
Can our own team migrate from Azure DevOps to Gitea without outside help?
Often yes for a small number of Git repositories with simple branch rules. Teams with an engineer who runs Linux servers, manages TLS and backups, and understands Git history rewriting can mirror repositories and install Gitea themselves. The work becomes harder when there are many TFVC codebases, regulated audit evidence to preserve, single sign-on to integrate, or pipelines to convert from Azure Pipelines YAML to Gitea Actions. Decide early which parts your staff will own and which need a fixed-scope engagement with written deliverables.
What does the migration require from our engineers and administrators?
The work needs named owners for repositories, identity, CI and access control. Repository owners confirm which branches and tags matter and which history must be kept. Identity administrators decide how users map to Gitea accounts and whether single sign-on is required. Platform engineers run the server, database, storage and backups. Pipeline owners re-create build and deploy steps and test them in parallel with Azure Pipelines. Security and compliance staff review how branch protection, approvals and access reviews are evidenced after the cut-over.
Does Gitea Enterprise or Gitea Cloud change the migration plan?
They can change the support and feature set, but not the core import steps. Gitea Enterprise, sold by CommitGo, Inc., adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Those features matter if your Azure DevOps controls depend on them. Gitea Cloud is a managed service alongside self-hosted installs, so it changes who runs the server. Either way, pull requests still do not import from Azure DevOps. Confirm feature availability and support terms directly with CommitGo and the Gitea Cloud documentation before writing the plan.
Can Boards and Artifacts stay in Azure DevOps while we move repositories to Gitea?
Yes, and many teams do this in phases. Gitea covers Git hosting, code review, package management and CI/CD, but it does not replace Azure Boards work items, backlogs and sprints. Those can stay in Azure DevOps while repositories move, with commit links updated to point at the new host. Azure Artifacts feeds can also remain until package consumers are moved to Gitea's package registries, which support more than 20 types. Plan the links between Boards, commits and builds so that traceability is not lost during the split.
What should we check before deciding between Gitea and a larger platform?
Check the features your teams use daily against what Gitea provides. Confirm whether you need work item tracking, test plans, fine-grained permissions across many projects, or enterprise identity controls. Check your database choice, since Gitea supports MySQL, PostgreSQL, SQLite and MSSQL, and your operating system support. Ask a provider for a written scope that lists repositories, identity, pipelines, storage, backups and handover, and compare that scope with the GitLab and Forgejo alternatives before you commit.
Choosing Gitea for its license and support model
Choosing Gitea is first a choice of software and support model. Gitea is MIT licensed, so the code can be run, modified and redistributed without a copyleft obligation, and the project does not gate core features behind a paid edition. Commercial support comes from CommitGo, Inc., which provides leadership and support for Gitea and sells Gitea Enterprise. Gitea Enterprise adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. If your Azure DevOps estate relies on Entra ID sign-on or on audit evidence for branch policy changes, confirm in writing whether those needs are met by the community edition or require the Enterprise subscription.
Gitea is also offered as Gitea Cloud, a managed service, alongside self-hosted installs. That option changes who operates the server, backups and upgrades, but it also changes where repositories and pull request data reside. Before treating it as a fallback for a team without operations capacity, ask CommitGo for the hosting location, backup and restore commitments, and the upgrade policy, and compare those answers with the data residency requirements that apply to your Azure DevOps organization. A self-hosted Gitea instance inside your own network keeps those decisions with you, at the cost of running it.
Before committing, compare Gitea with Forgejo, a community fork of Gitea. Forgejo is licensed GPL-3.0-or-later from v9.0 onward, with earlier versions under MIT, and its domains are owned by Codeberg e.V. while project governance stays independent. Forgejo documents transparent upgrades from Gitea installations up to Gitea v1.22. If copyleft terms, governance independence or a non-profit steward matter to your legal or procurement team, Forgejo may fit better, and that choice should be made before the migration plan is written. Confirm the license text and the current version compatibility with the project's own documentation before you decide.
How DeployOpen scopes and runs the Gitea migration
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the move from Azure Repos to Gitea. We start with a written scope that separates Git history, pull request records, branch policies and the Boards, Pipelines and Artifacts work that Gitea will not replace.
How we scope
- Inventory Azure Repos projects, Git repositories, TFVC histories and the branch policies each team depends on.
- Decide which pull request, review and work item records must be archived, since Gitea has no Azure DevOps importer.
- Agree in writing which Boards, Pipelines and Artifacts workloads move, stay or are replaced by other platforms.
- Engagements are fixed-scope, so deliverables and timelines are agreed before work starts.
How we build
- Install and harden the Gitea server, database and storage in your cloud account, data center or air-gapped network.
- Mirror Git history and convert any TFVC repositories to Git before cut-over, then verify commit counts and tags.
- Recreate branch protection and review rules in Gitea, and test them with representative pull requests.
- Connect Gitea Actions runners and package registries, and test pipeline behavior against your existing builds.
How we hand over
- Document the architecture, access model, backup procedures and the migration runbook for your own team.
- Provide an archive of exported pull requests, reviews and work items in a format your staff can search.
- Run a joint cut-over rehearsal and record the results, including any repositories that required manual fixes.
- Walk your engineers through daily operations, upgrades and how to restore from backup.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Upgrade paths are planned against the Gitea release line you run, with test environments before each change.
- Security testing of the Gitea deployment and its CI runners can be scheduled as part of a retainer.
- Ask any supplier, including DeployOpen, to confirm support terms and response commitments in the written quote.
