Why GitHub Enterprise Server 3.19 forces a decision before December 9, 2026
The choice is between another GitHub Enterprise Server appliance upgrade and a move to a self-hosted forge, and the right answer depends on your upgrade path, hardware checks, maintenance downtime and your team's capacity to run the result. If your appliance is on the 3.19 feature release, the decision has a fixed date: the release closes on December 9, 2026, and each feature release is supported for about a year. Check the GitHub Enterprise Server release history for the support window of your current and target versions. An upgrade buys another cycle of the same appliance model, which means another yearly deadline to plan for.
Choosing open source changes the software and support model as much as it changes where the code runs. GitHub Enterprise Server, Bitbucket Data Center and Azure DevOps Server are all self-managed editions that run on customer infrastructure, so hosting location alone does not separate them from a self-hosted forge. What changes is who ships fixes, on what schedule, and who answers when something breaks. GitLab backports bug fixes only to its current stable release and backports security fixes to the previous two monthly releases, so your team must keep pace with that cadence. Gitea offers commercial support through CommitGo, and Forgejo publishes LTS releases with critical bugfix and security support for one year and three months. Each option needs a named owner for upgrades, backups and incident response before you commit.
Make the decision with lead time to spare, because each path has its own preparation work. An appliance upgrade requires a confirmed upgrade route, hardware that meets the target version's requirements, and a maintenance window your developers will accept. A forge move requires an inventory of repositories, issues, pull requests, reviews and wikis, since Git history moves with a clone or mirror while collaboration data needs a platform importer. GitLab, Gitea and Forgejo all include tools for bringing in GitHub content, so test one repository end to end before you plan the full cutover. Ask for a written scope that covers data import, CI pipeline rework and a rollback plan, and confirm the support terms for the platform you choose.
What the end-of-support deadline requires from your team
The December 9, 2026 close date for GitHub Enterprise Server 3.19 turns into a short list of concrete work: a supported target, a confirmed upgrade path, hardware checks, data migration planning, a support model and a license review. Each card below is one item your team has to settle before the appliance stops receiving fixes.
Choose a supported target release
Pick the release you will run after 3.19 closes, and confirm its support window in GitHub's release documentation before committing. Feature releases are supported for about a year, so a release that ships late in the cycle leaves less runway before the next upgrade. Record the chosen version, its end of support date and the date you plan to move to it.
Confirm the upgrade path from your version
Appliances usually cannot jump several feature releases in one step, so map every hop between your current version and the target. Check the required intermediate versions and any pre-upgrade steps for your exact version in GitHub's upgrade documentation. A path that looks short on paper can add a full maintenance window per hop, which should be in your plan.
Check hardware and storage for the target
Newer appliance releases can change CPU, memory and disk requirements, and storage for Git data and Actions artifacts often grows faster than expected. Compare the target's published requirements with your current virtual machine, and confirm free space for the upgrade itself, which needs room for a backup and a rollback snapshot. Confirm these figures with GitHub for your license count before you schedule downtime.
Plan migration of issues and reviews
A plain clone moves Git history but not issues, pull requests, reviews, labels or wikis. If you move to GitLab, Gitea or Forgejo, list which platform objects your teams depend on and test an import of one representative repository. Forgejo's dump-repo and restore-repo commands and Gitea's importers cover GitHub sources, but confirm each object type survives before you rely on it.
Decide the self-managed support model
Staying on GitHub Enterprise Server means a per-user license, appliance operations and in-house upgrade work. Moving to GitLab, Gitea or Forgejo changes who provides support, whether that is a vendor subscription, a commercial partner or your own engineers. Decide which model your organization will fund and who owns patching, backup and incident response on the new platform.
Review license and governance for open source
The open-source forges differ in license and governance. GitLab is open core, with its ee/ directory under a proprietary license, Gitea is MIT licensed with commercial support available, and Forgejo is GPL-3.0-or-later from v9.0. Have legal review which features your teams need, whether they fall in a paid tier, and how the project's governance could affect your roadmap over the years you plan to run it.
How GitHub Enterprise Server upgrade, GitLab, Gitea and Forgejo each meet the constraint
This table compares each path on license and governance, release support, and CI, with the main trade-off for each. Code stays on your own infrastructure in all four options, so the decision turns on license terms, support model and the effort to operate each platform. Confirm the GitHub Enterprise Server upgrade path and its hardware requirements with GitHub before you decide.
| Option | License and governance | Release support | CI and main trade-off |
|---|---|---|---|
| GitHub Enterprise Server, upgraded in place | Proprietary appliance licensed per user under GitHub Enterprise. Confirm renewal terms with GitHub. | Feature releases are supported for about one year. Version 3.19 closes December 9, 2026. Confirm the supported upgrade path from your current version. | GitHub Actions on the appliance. Trade-off: each upgrade brings downtime and hardware checks. |
| Self-hosted GitLab | Open core. Code outside the ee/ directory is MIT licensed. Ee/ features need a paid subscription. | Monthly minor releases and a yearly major release. Required upgrade stops fall at x.2, x.5, x.8 and x.11. Versions 19.3 to 19.5 are maintained. | GitLab CI/CD with GitLab Runner. Trade-off: upgrade stops and high availability planning for larger user counts. |
| Self-hosted Gitea | MIT licensed. CommitGo, Inc. provides commercial support and sells Gitea Enterprise. | Release line v1.27, then v28.0.0 (September 29, 2026) and v28.1.0 (October 6, 2026). Confirm the support window for your version. | Gitea Actions, designed to be compatible with GitHub Actions. Trade-off: enterprise controls such as SAML and audit logging sit in the paid edition. |
| Self-hosted Forgejo | GPL-3.0-or-later from v9.0, earlier versions MIT. Codeberg e.V. holds the domains and governance stays independent. | Stable releases get three months of full support plus two weeks. LTS releases get one year and three months of security support. Version 15 LTS runs to July 15, 2027. | Forgejo Actions, familiar to GitHub Actions users but not compatible. Trade-off: workflows need rework, and federation is still experimental. |
What an appliance upgrade asks of your team before you stay on GitHub
Staying on GitHub Enterprise Server starts with the upgrade path itself. Confirm the release you run today, the target feature release, and every intermediate version the vendor requires, using the GitHub Enterprise Server releases documentation as the reference for version support dates. Treat that page as the authority for when your current line stops receiving fixes, because the date that matters for planning is the one printed there, not the one your team remembers. Then check the virtual appliance itself: vCPU, memory, root and data volume sizes, and the storage backend must meet the requirements of the target release. Hardware that passed the last review can fall short after a jump of several versions, so compare the current sizing table against your actual license count, Actions usage and repository footprint, and ask the vendor to confirm the figures for your exact deployment.
Next, plan the maintenance window and the rollback path. Upgrades on the appliance require a backup taken with the vendor's backup tooling, a verified restore on a staging instance, and a written decision on how long users can be without the service. Ask your account team to state the expected downtime for each hop in your path, and record which components restart during the upgrade, including the database, search indexes, Git storage and Actions runners. Remember that self-managed support still applies after the upgrade: you remain responsible for the appliance, its operating system, network, certificates and backups, and the vendor's support scope should be confirmed in writing before you schedule work.
Finally, test what depends on the instance. Run a representative set of Actions workflows on the target release with your self-hosted runners, including the runner version, labels, secrets and any custom actions pulled from internal repositories. Exercise every integration that calls the REST or GraphQL API, single sign-on, webhooks, deployment tooling and security scanners, because deprecated endpoints and changed authentication behavior are a common reason an upgrade fails after the maintenance window closes. Record the results, the owners who signed off and the rollback criteria. These tests give you a measured estimate of the effort, which you can then compare with the scope of a migration to a self-hosted forge.
How to migrate off GitHub Enterprise Server under the deadline
This sequence moves repositories, history, users, integrations and CI from the GitHub Enterprise Server appliance to a self-hosted forge in a controlled order, ending with a verified backup of the old appliance before it is switched off.
Freeze scope and inventory repositories and users
Export the list of organizations, repositories, teams, users, SSO bindings, webhooks, GitHub Apps, OAuth applications, Actions workflows and self-hosted runners from the appliance. Record repository sizes and any large or binary files, since these affect transfer time and storage on the target. Owners confirm which repositories are active, archived or scheduled for deletion. The output is a signed inventory that becomes the migration baseline, and any repository not on it is out of scope until the owner adds it.
Choose the target forge and deployment method
Select GitLab, Gitea or Forgejo based on the feature needs and support model captured in the inventory. For GitLab, pick the installation method (Linux package, Helm chart, GitLab Operator, Docker or source) and confirm the reference architecture for your user count. For air-gapped sites, review GitLab's offline environments guidance and confirm which scanners and AI features work offline. Written sign-off from the platform owner records the decision and the upgrade path you will follow.
Stand up a non-production instance and test core services
Build the target in a separate environment that matches the planned production topology, including database, storage and backup tooling. Test SSO against your identity provider, register a pilot set of CI runners, and run a full backup followed by a restore into a clean instance. Confirm that a restore reproduces repositories, users and permissions. The output is a test report listing each failed check and its fix.
Move Git history and platform data
Mirror each repository with git clone --mirror to carry full Git history, branches and tags. For issues, pull requests, reviews, labels, milestones and wikis, use the target platform importer: GitLab's import tools for GitHub sources or Forgejo's dump-repo and restore-repo commands where Forgejo is the target. Expect API rate limits on bulk exports and schedule runs accordingly. Verify by comparing commit counts, branch lists, open item counts and a sample of pull request discussions against the source.
Rebuild CI workflows on the target runners
Translate each GitHub Actions workflow to the target CI: GitLab CI/CD pipelines, Forgejo Actions workflows (familiar to GitHub Actions users but not compatible with them), or Gitea Actions, which is designed to be compatible. Register runners, move secrets into the target's secret store, and confirm artifact and package locations. Run each pipeline on a test branch and compare outputs with the GitHub results. The check is a passing pipeline for every production workflow.
Run a parallel period with read-only GitHub access
Set the appliance repositories to read-only for teams that have moved, and keep the target as the system of record for new work. Agree a short window in which developers push to both sides only if a team needs it, and log any divergence. Review open items, branch protection rules and access groups with each team lead. The output is a sign-off from each repository owner that the target matches the source for their work.
Cut over DNS, credentials and developer tooling
Point the forge hostname to the new instance, update Git remotes in IDE and CI configuration, rotate tokens and deploy keys, and update webhooks and integrations to the new endpoints. Publish a short guide for developers covering credential reset and remote changes. Confirm that clone, push, pull request and pipeline flows work for a pilot group before opening access to all teams. Record the cutover time and the list of changed endpoints.
Verify backups and decommission the appliance
Take a final backup of the GitHub Enterprise Server appliance and store it under your retention policy, then test restoring a sample of repositories from that backup. Only after the restore check passes, shut down the appliance and remove its access and licenses according to your contract terms. Keep the archive available for audit and records requests. The closing evidence is the backup checksum, the restore test result and the decommission record.
How each target handles the migration of issues, pull requests and CI
GitLab's import tooling can bring projects from GitHub into a self-managed instance, and the GitLab import and migrate documentation lists the supported sources. Repository history comes across with the project, but review threads, approvals, labels and user mappings need checks after each run. CI is a separate project, because pipelines are written as .gitlab-ci.yml files and are not read from GitHub workflow files.
- Importer coverage: Use the GitHub source in the project import flow of your self-managed instance, and confirm which issue, pull request and review objects your installed version maps.
- Manual work: Recreate branch protection rules, code owner assignments, group membership and integrations, and compare issue and pull request counts against GitHub.
- CI conversion: Translate each workflow in
.github/workflowsinto a pipeline, then map jobs, secrets and runner tags to GitLab Runner. - API limits: GitHub allows 5,000 REST requests per hour for personal access tokens, so a bulk run across a large organization needs a schedule that stays under that cap.
- Repository size: GitHub recommends keeping a repository's
.gitfolder under 10 GB, enforces a 100 MB file limit and a 2 GB push limit, so move large binaries out before the cutover.
Before scheduling the cutover, confirm the GitLab version you deploy against its upgrade stops and the import behavior documented for that release.
Gitea's migration code includes a GitHub importer, so a Gitea run can carry more than the Git history, but the exact set of objects depends on the release you run. Gitea's CI, Gitea Actions, is designed to be compatible with GitHub Actions, which makes it the target where existing workflow files are most likely to need the fewest edits. The work that remains is checking that the workflows behave the same way, not rewriting them from scratch.
- Importer coverage: The GitHub importer lives in the migration services of the Gitea repository; confirm the objects it maps in the version you install.
- Manual work: Spot-check imported comments, labels, milestones, attachments and pull request state against GitHub, and recreate permissions and team settings by hand.
- CI compatibility: Gitea Actions aims at GitHub Actions compatibility, but actions that call GitHub-hosted services, secrets and runner labels still need testing on your own runners.
- API limits: The same GitHub cap of 5,000 REST requests per hour for personal access tokens applies to the source side, so plan bulk runs around it.
- Repository size and storage: Apply GitHub's guidance of a
.gitfolder under 10 GB, a 100 MB file limit and a 2 GB push limit, then confirm disk space for attachments and the database you run, since Gitea supports MySQL, PostgreSQL, SQLite and MSSQL.
For the CI check, run each imported workflow on a test repository and compare its job logs with the GitHub Actions runs before you retire the source.
Forgejo handles the move through its command line rather than a web importer. The dump-repo command exports a repository from GitHub with issues, pull requests, releases, labels, milestones, comments and wiki, and restore-repo loads it into Forgejo. Because each repository is a separate export, this path suits scripted, repository-by-repository migrations. The Forgejo command-line documentation lists the flags for each source and should be the reference for your run.
- Export and restore: Run
dump-repoagainst GitHub, thenrestore-repoon the Forgejo host, and test one repository end to end before batching the rest. - Manual work: The documented list of exported items does not name pull request reviews, team structures or webhooks, so confirm those in a test restore and rebuild any that are missing.
- CI rewrite: Forgejo Actions is familiar to GitHub Actions users but is not compatible with it, so each workflow needs edits, and runners must be registered and labeled separately.
- API limits: Exports read from GitHub's API, so the 5,000 REST requests per hour cap for personal access tokens applies; spread large batches across time.
- Repository size and disk: Apply GitHub's repository limits to each export, and confirm free disk space on the staging host for the dump files as well as the restored data.
Confirm the flags and supported source types for the Forgejo release you deploy, and keep each dump until the restored repository has passed your checks.
Evidence to keep for the upgrade or the migration
Whichever path the organization chooses, the change will be reviewed later by internal audit, security and its own assessors. The cards below list the records that connect the decision to the final state of the platform, so each one can be traced without rebuilding the story from chat logs and tickets.
Approved decision and its date
Keep the signed decision record that states whether the organization upgrades GitHub Enterprise Server or moves to self-hosted GitLab, Gitea or Forgejo, with the named approvers and the date of approval. Record the options considered, the reason each was accepted or rejected, and the end of support date for the current release line that drove the timing. Assessors will check that the decision came before the work started, so date it and store it with the change plan.
Upgrade or migration plan and rollback steps
Document each step in order, with the owner, the window and the entry and exit checks for every stage. For an appliance upgrade, record the required upgrade path and the backup taken before it starts. For a move to a new forge, record the rollback point for each cutover stage, including how the source instance is kept read-only and how long it stays available. Test the rollback path before production, not only the forward path.
Backup and restore test results
A backup that has never been restored is not evidence of recovery. Keep the restore test record that shows which backup was restored, into which environment, who ran it, which repositories and metadata were checked, and what failed and how it was fixed. For a migration, include the export or dump output for issues, pull requests and wikis, not only the Git history. Retain the results alongside the plan so the reviewer can see the test preceded the cutover.
Access and SSO configuration
Record the identity provider configuration, group-to-role mappings, administrator accounts and service accounts on both the old and new platforms. Export the settings as they stand at cutover, including the SAML or OIDC metadata versions, two-factor enforcement and who holds the break-glass administrator credentials. Compare the access lists before and after the change, and note every account removed or changed. Assessors often ask for this comparison first.
Repository inventory and final locations
Maintain a register listing every repository, its owner, its source location, its destination location and the date it was moved or archived. Include the status of issues, pull requests, releases, labels and wikis, since Git history alone does not carry them between platforms. Mark repositories that were deliberately retired or left on the old instance so no code is lost without a recorded decision. The register becomes the reference for any later question about where a project lives.
Runner and integration cutover records
Keep the change records for each CI runner, webhook, deploy key, token and integration that pointed at the old platform, with the date it was repointed and the test that confirmed it. Record the runners retired, the secrets rotated and the external systems updated, such as deployment tools and package registries. Where a workflow depended on GitHub Actions behavior, note the compatibility check performed, because Forgejo Actions is not compatible with GitHub Actions, while Gitea Actions is designed to be.
What buyers ask before choosing an upgrade or a migration
How much does staying on GitHub Enterprise Server cost compared with moving to GitLab, Gitea or Forgejo?
Staying on GitHub Enterprise Server means paying the per-user Enterprise license, the appliance hardware and storage, and the staff time for each upgrade, plus the downtime each upgrade window causes. Moving to an open-source forge replaces the license with a software cost of zero for the Community or self-managed open-source tiers, but adds infrastructure, migration work, and the people who run the platform. Ask for each path's one-time costs (migration, data export, CI rework) and recurring costs (infrastructure, support subscriptions, staff hours) side by side, and confirm the appliance hardware checks for your current version with the vendor before comparing.
How long does an appliance upgrade or a platform migration take?
The duration depends on your instance size, the number of repositories and CI workflows, the data volume, the number of integrations, and how many upgrade steps your current version needs. No supplied source gives a duration for either path, so ask for a timeline in the written scope rather than relying on general estimates. For the upgrade path, check the GitHub Enterprise Server release notes and the upgrade requirements for your version. For the migration path, the largest drivers are repository and issue volume, API rate limits during bulk export, and how many pipelines must be rewritten.
What does the client's team need to provide for a migration?
A migration needs owners who can decide and sign off, not just engineers who run the export. Expect to provide an inventory of repositories, users, teams and permissions, a list of integrations (CI, chat, ticketing, deployment), and the business rules for branch protection and access. Your security team must approve the target hosting model, identity integration and backup approach. Your platform team owns the target infrastructure and access to it. Git history can be moved with a clone or mirror, but issues, pull requests and reviews need a platform importer, so your team should confirm which of those artifacts matter and plan a cutover window.
Can our own team migrate off GitHub Enterprise Server without outside help?
Many teams with strong platform engineering can run a small migration in-house, especially when the repository count is modest and the CI estate is simple. The work is more demanding when you need high availability, air-gapped operation, SSO and audit controls, and CI rewrites across many pipelines. Gitea and Forgejo are lighter to run than a multi-component GitLab deployment, and GitLab documents offline and high-availability architectures that add operational load. Before deciding, ask your team to test an import of a representative repository, measure how long the export takes under API rate limits, and confirm who will patch the platform each month.
What do the GitLab license tiers cost per user?
GitLab Free costs 0 US dollars, and GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually, with all three tiers available for self-managed installations. Ultimate is custom priced, so you will need a quote for it. The Premium tier adds advanced CI/CD and priority support, while Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. Before buying, confirm which features your security and compliance controls actually need, because the license tier decides which of them you get. Note that the Free tier is a valid self-managed option, so you can start there and add subscriptions only when a specific need appears.
Does Gitea Enterprise or Forgejo LTS change the support answer?
Yes, both change who you call when something breaks, but in different ways. Gitea is MIT licensed, and CommitGo, Inc. provides leadership and commercial support and sells Gitea Enterprise, which adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Forgejo is GPL-3.0-or-later from v9.0, and its LTS releases, published in the first quarter of each year, receive critical bugfixes and security support for one year and three months. Forgejo has no commercial vendor in the same sense, so your support depends on your own staff, a service provider, or the community. Ask each option for its written support terms before deciding.
Can DeployOpen run the migration under a fixed-scope written agreement?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ongoing support and upgrades are available as retainers. DeployOpen does not issue audit reports or certifications, but it can prepare systems and evidence for compliance assessments that independent auditors perform. To scope the work, share your repository inventory, integration list and target platform, and ask for a written scope that names deliverables and the exit criteria.
How DeployOpen plans and runs a move off GitHub Enterprise Server
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so an upgrade or migration off GitHub Enterprise Server is handled as a written, fixed-scope engagement. We run the work in the same order whichever path you choose: scope first, then build, then handover and ongoing support.
How we scope
- Inventory your GitHub Enterprise Server instance, its repositories, users, Actions runners and integrations before any target is chosen
- Compare the in-place appliance upgrade with a move to GitLab, Gitea or Forgejo against your own requirements and timeline
- Record the scope, deliverables and milestones in writing before work starts, since most engagements are fixed-scope
- Confirm with your vendors which release dates, support terms and license conditions apply to your contract
How we build
- Stand up the chosen platform in your environment with its hardening, authentication and backup configured from the start
- Test repository, pull request and CI migrations on sample projects, and check that pipelines run as expected on the target
- Run a dry-run import of issues, reviews and wikis with the platform importer, then compare counts and content against the source
- Document the cutover plan, including the freeze window and rollback steps, and agree it with your team before go-live
How we hand over
- Deliver runbooks for installation, upgrades, backups, restores and user onboarding in your own documentation set
- Walk your platform and security engineers through administration, runner management and the upgrade path for the platform you choose
- Provide evidence of configuration and test results that your compliance team and independent auditors can review
- Transfer administrative access so your team owns the platform after the engagement closes
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build
- Plan platform upgrades around the vendor's own release and upgrade-stop schedule so your team has time to review changes
- Keep backup and restore procedures tested on a schedule agreed with you, not only documented
- Confirm with your procurement team which support arrangements, such as a vendor subscription, will sit alongside a retainer
