Bitbucket Data Center after the end of sale

What the Data Center end of sale means for your Bitbucket Data Center alternative decision

If you run Bitbucket Data Center today, the short answer is this: Atlassian stopped selling new Data Center subscriptions on March 30, 2026, but existing customers can move onto a Hybrid License that covers both Data Center and Bitbucket Cloud. If neither path fits your constraints, the open-source options are self-hosted GitLab, Gitea or Forgejo, each run in your own infrastructure. The decision turns on which constraint is binding: a fixed end date, a data location rule, an air-gapped network or the cost of staying on a vendor product. Atlassian's cloud transformation options page describes the Hybrid License path in its own terms.

The dates matter, but the binding constraint matters more. Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products by March 28, 2029, while its journey-to-cloud page states that Bitbucket Data Center continues beyond 2029. These two statements cover different points in time and different product scopes, so plan around neither one alone. Ask Atlassian in writing which Data Center version, support window and license term apply to your contract, and what happens to your instance on the sunset date. If your binding requirement is an in-region or air-gapped deployment, Data Center and self-hosted open source both keep code on hardware you control. If it is a predictable end date, weigh the release and support policy of each open-source forge heavily.

Before you sign anything, collect the facts that will shape your timeline. Confirm the expiry date of your current subscription, whether the Hybrid License offer covers the seats and instances you run today, and whether the cloud route is a project you run yourself or one Atlassian supports. Then list everything that depends on Data Center: Jira links, build integrations, webhooks, branch permissions and any tools that call its REST API. Those dependencies set how long a move takes and how much staff time it consumes, so measure them before you compare license figures. Also check which target can import your pull request history, since Git history moves with a clone or mirror while reviews and comments need a platform importer. Start this inventory now, while your current contract still leaves room to choose.

Which requirements decide between renewing, moving to Cloud and self-hosting

Five constraints decide whether a Bitbucket Data Center team renews, moves to Bitbucket Cloud or replaces the server with a self-hosted forge. Work through them in order, because the first one that fails narrows the options before cost is compared.

Where code must be stored

Bitbucket Cloud does not offer the regional data storage that some hosted Git services provide, so EU or sector rules on where source code lives can rule it out. Ask Atlassian in writing which hosting location applies to your workspace, and compare it with the data location options your regulator or customer contracts accept. If code must stay in your own datacenter, the choice narrows to Data Center or a self-hosted forge.

Who operates the servers

Bitbucket Data Center, GitHub Enterprise Server and Azure DevOps Server all run on your infrastructure, so self-managed does not automatically mean open source. Count who patches the application, runs database and storage backups, and handles upgrades under each option. Self-hosted GitLab, Gitea and Forgejo move that work to your own team or a partner, and the operating model should be settled before the platform.

Licensing and cost ownership

Data Center and Hybrid License renewals are a recurring commercial line, while open-source forges shift cost to infrastructure, storage, support and staff time. Ask for the renewal quote, the Hybrid License terms and the Cloud seat count, then price the self-hosted side by component. Check each license file, because GitLab's ee/ directory is proprietary and Forgejo is GPL-3.0-or-later from v9.0.

Repository and LFS size limits

Bitbucket Cloud enforces a 4 GB repository limit and a 1 GB total storage limit on Free workspaces, so large monorepos and binary-heavy histories may not fit a plan without changes. Self-hosted servers have no equivalent platform cap, but disk, Git LFS storage and backup size become your limits. Measure the largest repositories and their LFS footprint before choosing a target.

Air-gapped operation and offline installs

If repositories, CI runners and package sources must work with no outbound internet access, Bitbucket Cloud is excluded, and any target must install and update from offline media. GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners. Confirm offline update paths, container image mirroring and runner dependencies for Gitea or Forgejo in your own test environment.

Migration effort for pull requests and issues

Git history moves with a clone or mirror, but pull requests, reviews, issues and wikis need a platform importer. GitLab imports from Bitbucket Cloud and Bitbucket Server, while Gitea's migration code has no Bitbucket importer, so Bitbucket pull request history may need an export and a rebuild. Ask each target which objects its importer carries across, and plan how Bitbucket API limits of 1,000 requests per hour will affect bulk exports.

How renewing, Bitbucket Cloud and self-hosted forges each meet the constraint

Renewing keeps Bitbucket on servers you run. Atlassian stopped selling new Data Center subscriptions on March 30, 2026, so this path depends on an existing agreement, and existing customers can move to a Bitbucket Hybrid License that covers Data Center and Cloud.

Data location: Repositories, pull request data and the database stay in your datacenter or cloud account, so your team controls where the data sits.
Operator: Your platform team, or a services partner you contract, runs the application, database, storage, backups and upgrades.
License model: The Hybrid License is the route for existing customers. Ask Atlassian how it counts users and instances and how it renews.
Lifetime risk: Atlassian's September 8, 2025 announcement says Data Center products are sunset by March 28, 2029, while its journey-to-cloud page says Bitbucket Data Center continues beyond 2029. Get that position in writing for your contract term.

Check the end date of your current term, the Hybrid License terms and whether the license covers every instance and user group you run.

Which open-source forge fits which Data Center requirement

This table compares GitLab, Gitea and Forgejo on license and governance, built-in CI, migration importers and support model, the four questions that usually decide a Bitbucket Data Center replacement. Read each row against your own requirements, and treat the gap rows as items to confirm with the vendor before you commit to a migration plan.

Requirement	GitLab	Gitea	Forgejo
License and governance	Open core: code outside the ee/ directory is MIT, while ee/ needs a paid subscription	MIT licensed, with leadership and commercial support from CommitGo, Inc.	GPL-3.0-or-later from v9.0, earlier versions MIT; Codeberg e.V. holds the domains and governance stays independent
Built-in CI	GitLab CI/CD with GitLab Runner, a different pipeline syntax from Bitbucket Pipelines	Gitea Actions, designed to be compatible with GitHub Actions	Forgejo Actions, familiar to GitHub Actions users but not compatible with it
Bitbucket importer	Imports from Bitbucket Cloud and Bitbucket Server, plus Git repositories by URL	No Bitbucket importer in its migration code; plan Git mirror plus manual or scripted metadata	dump-repo does not list Bitbucket; plan a Git mirror and rebuild issues and pull requests separately
Pull requests and review data	Merge requests with imported project data where the importer supports it; confirm which review comments carry over	Pull requests supported; confirm how Bitbucket comment threads and approvals map after a manual migration	Pull requests supported; confirm how Bitbucket review history is represented after migration
Support model	Free, Premium and Ultimate tiers all available for self-managed installs; confirm support scope per tier	Community support plus CommitGo commercial support and Gitea Enterprise; confirm contract terms	Community governance without a commercial vendor; confirm support options with a partner you contract directly
Air-gapped deployment	Documented offline and air-gapped guidance; confirm the scanner and Duo components you need	Self-hosted single binary; confirm package registry and Actions behavior offline	Self-hosted; confirm Actions runner and package behavior offline
Upgrade path from your installed version	Required upgrade stops documented for each release line; plan a staged path	Upgrade path depends on your version; confirm with the release notes for your target	Transparent upgrades from Gitea up to v1.22 in two steps; later Forgejo upgrades documented
Main gap to plan for	Heavier footprint at scale; high availability needs Gitaly Cluster, PostgreSQL and Redis planning	Pull request and review history from Bitbucket needs a custom import plan	Federation is experimental; Bitbucket import needs a Git mirror plus separate metadata work

How to move Bitbucket repositories, pull requests and LFS objects to a self-hosted forge

Git history moves with a clone or mirror, but everything around it needs its own plan. Commits, branches and tags can be copied to any target forge with a mirror clone, and that step is the easy part. Pull requests, review comments, issues and wikis are stored by Bitbucket as platform data, so they only move through a platform importer or an export you script yourself. GitLab documents importers for Bitbucket Cloud and Bitbucket Server, which covers more of that data than Gitea's migration code does, since Gitea's importers list does not include Bitbucket. Forgejo's dump-repo command does not list Bitbucket as a source either. Before you choose a target, confirm which importer version handles your Data Center release and which objects it carries across, and run a test import on one busy repository. LFS objects are the item most often missed. A mirror of the Git refs does not automatically include the large files held in Git LFS, so clone with LFS enabled and confirm the object count and total size on the target before you decommission anything. Branch permissions also do not travel with the code. Record the restrictions on each protected branch, the required reviewers and the merge checks, and recreate them by hand or through the target's API. Pipelines variables are a separate risk: secured variables cannot be read back through the API, so you must obtain the values from their owners and rotate any credential that you cannot account for.

API rate limits decide how long a bulk export takes. Bitbucket Cloud allows 1,000 requests per hour for most API resources, so pull request and comment history for a large workspace can span many hours of throttled calls. Plan the export as a scheduled job with retries and checkpoints, not a one-off script. Check the limits that apply to your Data Center deployment and to any Cloud workspace you export from, because the rules differ by product and may change. Keep an export log with repository, object type and count so that you can reconcile the target against the source before the Hybrid License or Data Center contract ends and read-only access is removed.

How to deploy and operate a self-hosted forge after leaving Data Center

This sequence moves source hosting from Bitbucket Data Center to a self-hosted forge in a controlled order, so repositories, users and metadata arrive intact and the team has a supported upgrade path afterward.

Inventory repositories, users and integrations
The Bitbucket administrator and the platform team list every project and repository, its size and whether it uses Git LFS, the users and groups with access, branch permissions, webhooks, and the CI pipelines and Jira links that depend on them. Work with the Bitbucket administrator to pull this list from the Data Center instance, and note which repositories are large enough to need extra time for transfer. The step is done when the inventory has an owner for each repository and a list of integrations that must be replaced or re-pointed.
Choose the target forge and its support model
Compare self-managed GitLab, Gitea and Forgejo against the inventory, using the license and governance differences, the CI system each one ships and the features your teams need. Confirm the support model in writing: GitLab offers Free, Premium and Ultimate tiers for self-managed installations, Gitea has commercial support from CommitGo, and Forgejo is community-supported with LTS releases. The decision owner signs off on the choice and the support contract, if any, before any installation begins.
Confirm the deployment method and architecture
For GitLab, pick the installation method: the Linux package, the Helm chart, the GitLab Operator, Docker or source. Note that GitLab does not support running PostgreSQL and Redis inside Kubernetes, so the Cloud Native Hybrid architecture keeps stateful services on VMs or managed services. If the environment is air-gapped, check GitLab's offline guidance before ordering hardware. For Gitea or Forgejo, confirm the database and host layout. The step is complete when a written architecture document is approved by the security and operations leads.
Build the environment and harden it
The platform team installs the forge on the agreed infrastructure, configures backups and restore tests, sets up SSO, TLS and network access, and applies the vendor's hardening recommendations. Restore a test backup to a separate host to prove the backup works before any repository moves. The step is done when a restore test passes and the security team has reviewed the configuration.
Mirror repositories and import metadata
Git history moves with a clone or mirror, including LFS objects where they are used. Issues, pull requests, reviews and wikis need a platform importer, and the importer you use depends on the target: GitLab can import from Bitbucket Server and Bitbucket Cloud, while Gitea has no Bitbucket importer and Forgejo's dump-repo does not list Bitbucket as a source. Plan pull request and comment history separately, export it through the Bitbucket API within rate limits, and record which records were migrated and which were archived. The step is complete when repository counts and commit hashes match the inventory.
Run a pilot with a small team
Move a few representative repositories and one team, then test clone, push, merge requests or pull requests, code review, CI runs, permissions and integrations with real workflows. Collect defects in a tracker and fix the configuration before the full cutover. The pilot is done when the pilot team signs off and the open defects have owners and agreed fixes.
Cut over and retire Data Center access
Freeze writes in Bitbucket Data Center for the agreed window, run the final mirror and metadata sync, update remote URLs, webhooks and CI configuration, and redirect developers to the new forge. Keep the Bitbucket instance read-only for a period agreed with the business so teams can check history. The step closes when the new forge is the system of record and the cutover checklist is signed by the repository owners.
Operate upgrades on a fixed cadence
Keep the forge supported by following its published upgrade path. GitLab requires passing through the documented upgrade stops, which fall at versions x.2, x.5, x.8 and x.11, and its maintenance policy sets monthly minor releases and twice-monthly patch releases. Forgejo publishes LTS releases in the first quarter of each year with critical and security support for a defined period, and documents a two-step upgrade from Gitea. Assign an owner, schedule a test upgrade on a staging copy and keep a dated record of each upgrade and restore test.

What auditors and security reviewers ask for when source hosting changes

Whether you renew, move to Bitbucket Cloud or replace Data Center, the same evidence questions come back in every review. Each card below names one body of records that an auditor or security reviewer will want to see, and what to check before you sign anything.

Data location decisions

Record where repositories, pull request data, attachments and backups will be stored, and who in your organization approved that location. Bitbucket Cloud is not among the Atlassian products with data residency, so a Cloud move needs a documented reason if code must stay in-region. For a self-hosted forge, the record should name the data center, the cloud account or the air-gapped network that holds each copy, and confirm that no backup or mirror leaves that boundary.

Access control and authentication settings

Export the configuration that decides who can read, push, approve and administer repositories, including branch protection rules, group membership, SSO settings and two-factor enforcement. Reviewers will compare these against your identity provider records and ask who holds administrator rights on the forge itself. Confirm that the target platform supports the authentication method your policy requires before you commit to it.

Backup and restore tests

A backup is only evidence once a restore has been performed. Keep a dated record of a full restore into a separate environment, covering repositories, pull requests, reviews, wikis and attachments, with a comparison of counts against the source. Reviewers will also ask how long backups are retained and who can delete them, so document that alongside the test.

Upgrade and patch records

Show that the platform version in production is on a release line that still receives security fixes. GitLab documents that security fixes are backported only to the current and previous two monthly releases, and its required upgrade stops must be followed in order. Keep a log of each upgrade, its date, the version moved to and the test evidence. For Forgejo, the upgrade guide and its support windows define how long a release line stays covered.

License and support documentation

Record the license of each component you run and the support arrangement behind it. GitLab is open core, so the proprietary ee/ directory and the tier you buy both matter. Gitea is MIT licensed with commercial support available from CommitGo, and Forgejo is GPL-3.0-or-later from v9.0. Reviewers will want the license files, the subscription or support contract, and a statement of which features depend on a paid tier.

Migration record and change log

Keep a register that maps every repository and project to its source, its destination, the date it moved and the person who verified it. Include what did not migrate, such as Pipelines variables that cannot be read back, and how each gap was handled. Reviewers use this record to confirm that access rights and audit trails were carried over, or that their loss was accepted in writing. Ask your migration partner to deliver this register as part of the fixed scope.

What does moving off Bitbucket Data Center cost and take?

What does a Bitbucket Hybrid License renewal cost compared with a self-hosted forge?

Atlassian's Hybrid License price is set in your renewal quote, and no figure for it is published in the sources used for this page, so ask your Atlassian partner or account team for the number. Compare it by component. The Hybrid License covers Data Center and Cloud use for existing customers, but you still pay for the servers, storage, database, backups and the staff who run them. A self-hosted GitLab, Gitea or Forgejo instance removes the license line but adds its own components: infrastructure, support and the engineering hours to operate it. For GitLab, the public list price for Premium is 29 US dollars per user per month billed annually, according to the GitLab pricing page, and Ultimate is custom priced. Gitea and Forgejo are MIT and GPL licensed, so software cost is zero, and support is a separate decision.

Can our own team migrate Bitbucket Data Center repositories without outside help?

Yes, many teams can, provided they have Git and platform administration skills and time to test. Git history moves with a clone or mirror between any two forges. Pull requests, reviews, issues and wikis need a platform importer. GitLab's import documentation lists Bitbucket Server as a supported source, while Gitea's migration code has no Bitbucket importer, and Forgejo's dump-repo does not list Bitbucket, so check the current tooling for your target before you commit to a plan. Internal teams usually carry the operational load after cutover, which is where ownership questions matter most.

How long does a Bitbucket Data Center to self-hosted forge migration take?

Duration depends mainly on repository count, the volume of pull request and comment history, LFS content, and how many integrations such as Jira links, build pipelines and access rules must be rebuilt. No duration is published in the sources for this page, so treat any figure you hear as a hypothesis until a written scope sets it. As an illustrative example only, a team with a few dozen small repositories and no pull request history to keep will move faster than an organization with thousands of repositories and years of reviews. Bulk exports are also limited by API rate limits, and Bitbucket Cloud allows 1,000 requests per hour for most API resources, according to Atlassian's documentation, which can stretch the timeline for metadata-heavy moves.

What work do our engineers and administrators need to provide during a migration?

Expect to supply several roles for the duration of the project. Engineering leads must confirm which repositories, branches and pull request history are worth keeping. Platform or IT staff must provide hosts, storage, a database layer, identity integration and network access. Security staff must approve access rules, branch protection and authentication settings. Developers must test cloned repositories and update pipelines and local remotes. Each role's hours should be written into the scope, because they are the part of the effort most often underestimated. For GitLab, the reference architecture guidance, which depends on user count, also affects how much platform work is needed.

Can we keep Bitbucket Data Center running beyond 2029?

Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products by March 28, 2029, while its journey-to-cloud page states that Bitbucket Data Center will continue beyond 2029 for existing customers who gain a Hybrid License. Read both statements against your own contract, because the product-level sunset and the Bitbucket-specific continuation are not the same thing. Ask Atlassian, in writing, what happens to your license, support and security patches after each date, and whether your entitlements carry over to a renewal. Plan your exit before that answer changes your options.

What should a fixed-scope quote for leaving Bitbucket Data Center include?

A useful quote lists each deliverable and what is excluded. Ask for the inventory of repositories, LFS objects, pull requests, issues, wikis and pipeline definitions in scope, the chosen target (GitLab, Gitea or Forgejo) and its installation method, the migration approach for each data type, the identity and access model, backup and restore verification, cutover and rollback steps, and the handover to your team. Ask for acceptance criteria, the testing you will run, and the support period after cutover. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

Does DeployOpen prepare evidence for compliance reviews after a migration?

DeployOpen prepares systems, controls and evidence for compliance assessments, including access configuration, backup records and change logs for the forge. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask the scope to name which control areas the evidence will cover, and confirm with your auditor which formats they accept before the work starts.

When renewing Data Center still makes sense

Renewing Bitbucket Data Center makes sense when the organization needs Atlassian's ecosystem to keep working as it does today, the server or data center operations team is already staffed for it, and the Hybrid License path fits the company's plans. Atlassian stopped selling new Data Center subscriptions on March 30, 2026, so the decision for most existing customers is whether to renew what they hold, convert to the Hybrid License, or move. Atlassian has stated that Bitbucket Data Center continues beyond 2029 and that existing customers gain a Hybrid License covering Data Center and Cloud, so the question is less about where the code runs and more about which support and licensing model the organization is buying into.

Before signing, get the terms in writing. Ask Atlassian which Data Center version and support window the renewal covers, how the Hybrid License counts users and whether it lets you move seats or workspaces to Bitbucket Cloud without a second purchase. Confirm the end date of any renewal term, the notice period for changes, and what happens to licenses if the company is acquired or changes its Jira deployment. Also confirm whether Jira and Confluence integrations you rely on are covered by the same license model. The journey-to-cloud guidance from Atlassian is the natural starting point for these questions, and the answers should go into the renewal file alongside your internal cost model.

Renewal also keeps an exit path open. Your own staff still operate the Bitbucket server, backups, upgrades and the database, so the hidden costs of renewal are the people and time needed to run it, not only the subscription. Record which of those tasks depend on Bitbucket specifics, and document how repositories, pull requests and permissions would be exported if you later choose GitLab, Gitea or Forgejo. A renewal that includes a written export test is much easier to revisit than one that leaves the migration plan for later.

How DeployOpen plans and runs a Git forge migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For Bitbucket Data Center, that means treating the move as a fixed-scope engagement that covers repositories, access rules, pipelines and the systems around them.

How we scope

We inventory repositories, LFS objects, pull request history, branch permissions, pipelines and linked Jira projects before any work starts.
The written scope names which forge you are moving to, which data moves, and which data stays in the Bitbucket archive.
We agree deliverables, timelines and acceptance criteria in writing before work starts, so renewal decisions rest on a documented plan.

How we build

We install and configure the chosen forge in your own environment, including authentication, storage, backups and network access controls.
We script repository mirroring and platform imports, then test a sample of pull requests, comments and permissions against the source data.
We rebuild pipeline equivalents and integration points, and document each deviation from the Bitbucket setup for your review.

How we hand over

You receive runbooks for operations, backup and restore, upgrades and user onboarding, written for your own administrators.
Migration evidence, configuration records and access reviews are delivered so your compliance team can review them with auditors.
DeployOpen prepares controls and evidence for compliance assessments, while independent auditors and certification bodies issue any formal conclusions.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover is complete.
Retainers can cover forge version upgrades, which your team should plan against the vendor's published upgrade paths and release schedule.
Ask for a written quote that lists scope, deliverables and support terms, since DeployOpen does not publish a price list.

Bitbucket Data Center after Atlassian's Data Center end of sale