Bamboo Data Center end of life: renew or replace

Bamboo Data Center end of life: what to decide before renewal

If you hold a Bamboo Data Center renewal or sunset notice, the first decision is whether you are buying time or buying a platform. Renewing Bamboo keeps your current plans running under a Bitbucket Hybrid License path, while Jenkins, Woodpecker CI or GitLab CI/CD give you a self-hosted option that does not depend on an Atlassian subscription. Atlassian's notices conflict, so read both before you sign anything.

The sunset announcement, dated September 8, 2025, says sales of Data Center products to new customers end March 30, 2026 and end of life falls on March 28, 2029. Atlassian's journey-to-cloud options page says Bitbucket and Bamboo Data Center continue beyond that end of life under the Bitbucket Hybrid License. Ask your Atlassian account team in writing which terms apply to your contract, whether the Hybrid License carries support and security fixes, and what the renewal price and term will be. Confirm the answers in writing rather than relying on the public pages alone.

Whichever path you choose, inventory what the renewal does not cover. Confirm which agents, plans, deployment projects and secrets depend on Bamboo, and note that CI secret values generally cannot be exported from one platform to another, so every credential will need to be re-entered in the new system. Set a decision date that leaves room for a parallel run if you move. Before the renewal date, ask your team to record the current Bamboo version, the number of agents you pay for, and the plugins or task types your builds rely on, because those facts drive both the renewal quote and any migration estimate.

What a Bamboo replacement must preserve

Replacing Bamboo Data Center is less about copying plans than about keeping what the pipelines depend on: deployments that still ship, secrets that still resolve, history that still exists and access that still gets audited. Each card below is a point where a move can silently lose something, and each names what to confirm before cut-over.

Build and deploy continuity

Every Bamboo plan and deployment project is a link in a release path that someone depends on. Inventory which plans trigger production deployments, which run on schedules, and which feed other teams. Confirm that each one has a Jenkins, Woodpecker CI or GitLab CI/CD equivalent and that both systems can run in parallel until the first real release has passed through the new pipeline.

Secrets do not move automatically

Deployment credentials, registry tokens and signing keys are the most sensitive items in a Bamboo instance. Vendors generally do not export secret values: GitHub returns secret names without values, and Bitbucket secured variables can only be replaced or deleted. Plan to re-create every secret in the new system from its source, rotate credentials that were stored in Bamboo, and record who holds each value.

Build history and artifacts must be exported

Hosted CI services keep build artifacts for limited periods, such as 30 days for CircleCI and 14 days for Bitbucket Pipelines, so long-running retention is a design choice you make on your own servers. Before cut-over, decide which build logs, test reports, release artifacts and audit trails your compliance or incident response needs. Export them to storage you control, because a Bamboo export does not preserve the full history.

Repository connectivity through a forge

Bamboo reads repositories from Bitbucket Data Center, and the new engine must do the same without a forced repository move. Woodpecker CI connects to Bitbucket Datacenter, GitHub, GitLab, Gitea and Forgejo, while Jenkins and GitLab CI/CD use their own integrations. Confirm webhook delivery, branch and pull request triggers, and credentials for read access in the chosen forge before retiring Bamboo triggers.

Access control and pipeline audit

Bamboo permissions decide who can edit plans, view variables and approve deployments, and those rules must map onto the new platform. Define roles for pipeline authors, release approvers and administrators in the identity system you already run. Confirm that pipeline changes, secret access and deployment approvals are logged somewhere your auditors can read, and that runner or agent labels cannot be used to run jobs in a privileged context.

Runner and agent capacity

Bamboo bills per agent, so teams often size their agent pool around licensing rather than workload. Self-managed alternatives change that calculation: Jenkins recommends dedicated build agents so the controller handles only requests and configuration, and Woodpecker agents can run workflows on Docker, Kubernetes or the local machine. Measure your peak concurrent builds, decide which agents run on hosts you already own, and confirm how each build environment is isolated.

Renew Bamboo, Jenkins, Woodpecker CI or GitLab CI/CD

Renewing keeps your plans, agents and deployment projects in place while you decide. Atlassian's journey-to-cloud page says Bitbucket and Bamboo Data Center continue beyond the 2029 end of life under a Bitbucket Hybrid License, but the sunset announcement stops new sales from March 30, 2026 and sets end of life for March 28, 2029. Read the journey-to-cloud page and the contract terms together before relying on either.

Written confirmation: Ask Atlassian to confirm in writing what happens to Bamboo Data Center after March 28, 2029, and under which license.
Renewal cost: Recurring cost is per agent per year, so agent count and tier drive the quote. Compare the figures on the Bamboo pricing page with your current invoice.
Hybrid license terms: Confirm support scope, upgrade obligations and whether the license covers your deployment model.
Lock-in: Plans and secrets stay tied to Bamboo, so a later move still needs an export and manual rework of encrypted values.
Exit cost: Renewing defers migration work but does not remove it, so budget for the move that will eventually happen.

Before renewing, confirm the term in writing, the agent count you will pay for and the date by which a migration plan must start.

Jenkins is the closest like-for-like self-hosted CI server. It is distributed under the MIT License, has more than 2,300 community plugins and defines pipelines as a Jenkinsfile committed to the repository. You run the controller and your own build agents, so there is no per-agent subscription, but you own every upgrade, plugin and backup decision.

Architecture: The scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment.
Backup scope: All configuration, plugins and secrets live in $JENKINS_HOME on the controller, so back it up and test restores as a core task.
Availability: A primary and backup controller behind a proxy such as HAProxy or F5 is the documented pattern, and it is more work to operate than a single node.
Java and LTS: Java 21 has a planned end of support in September 2027, and Java 25 is supported to September 2029. LTS 2.580.1 stopped bundling several plugins, so check the plugin list on upgrade.
Configuration as code: The Configuration as Code plugin reads YAML from CASC_JENKINS_CONFIG, but it does not install plugins, so pin plugin versions through images or the Helm chart.

Confirm which Bamboo tasks map to plugins you can support, and who will own plugin security updates after cut-over.

GitLab CI/CD is the option when you want to leave Bamboo and Bitbucket Data Center for one platform. GitLab is open core: content under the ee/ directory is covered by the Enterprise Edition license, and the rest is MIT Expat licensed. Pipelines are defined in .gitlab-ci.yml, and self-managed editions can be installed offline, which matters for regulated networks.

Tiers: Free costs 0 US dollars. Premium costs 29 US dollars per user per month billed annually and includes advanced CI/CD and priority support. Ultimate is custom priced and adds security and compliance features. Confirm which tier your controls require.
Offline installs: GitLab documents air-gapped operation, but security scanners and GitLab Duo Self-Hosted have separate offline guidance.
Scale: Reference architectures run from 1,000 to 50,000 users. For 3,000 or more users, the docs recommend a high availability design.
Stateful services: Running PostgreSQL or Redis inside Kubernetes is not supported, so the Cloud Native Hybrid pattern puts them on VMs or managed services.
Upgrades: Upgrades must pass through required upgrade stops, such as 18.2, 18.5 and 18.8, and the maintenance policy schedules a major release each year.

Confirm your user count, required tier and whether your Git hosting moves with the CI platform, since that changes the migration scope.

How each option compares on key trade-offs

This table compares Jenkins, Woodpecker CI and GitLab CI/CD on the factors that shape a Bamboo renewal decision: licensing, hosting, workflow format, forge support, offline operation and upgrade cadence. Read each row against the per-agent Bamboo Data Center subscription and the Bitbucket Hybrid License path. Where a cell says confirm, check that capability in your own network and with the vendor before you commit.

Trade-off	Jenkins	Woodpecker CI	GitLab CI/CD
Licensing	MIT License with no per-agent subscription. Confirm any distribution or add-on fees before you commit.	Apache-2.0 code with CC BY-SA 4.0 documentation. Its origin as a Drone fork followed Drone's license change.	Open core: MIT for code outside the ee/ directory, Enterprise Edition license under ee/. Free, Premium and Ultimate tiers.
Hosting model	Controller in your infrastructure with separate build agents. Configuration, plugins and secrets live in JENKINS_HOME on the controller.	Server, gRPC-connected agents and an optional autoscaler. SQLite by default, with PostgreSQL or MariaDB recommended for larger instances.	Self-managed through the Linux package, Helm chart, Operator, Docker or source. Stateful services should run on VMs or managed services.
Workflow format	Jenkinsfile in source control, using Declarative or Scripted syntax with stages and steps. Bamboo Specs must be rewritten.	YAML in a single .woodpecker.yaml or a .woodpecker/ directory. Each step runs inside a specified container image.	.gitlab-ci.yml pipelines with environments. Plan a manual mapping of Bamboo plans and deployment projects and confirm feature parity.
Forge support	Forge integration comes through plugins. Confirm the Bitbucket Data Center plugin version against your Atlassian release.	GitHub, Gitea, Forgejo, GitLab, Bitbucket and Bitbucket Datacenter. Connecting several forges to one server is experimental.	Built around GitLab repositories and merge requests. Keeping Bitbucket Data Center means planning a repository move.
Air-gapped suitability	Confirm that plugins, update sources and agent images can come from an internal mirror in your network.	Confirm container image pulls, plugin downloads and forge access from isolated networks, since plugins are container images.	Documented for offline, air-gapped environments, with separate guidance for security scanners. Confirm against your own network rules.
Upgrade cadence	A new LTS baseline every 12 weeks with three LTS releases each. LTS 2.580.1 stopped bundling several plugins, so install them explicitly.	Recent releases include 3.18.0 on August 24, 2026 and 3.19.0 on October 7, 2026. Plan regular upgrades and test them.	Yearly major releases, monthly minor releases and required upgrade stops at x.2, x.5, x.8 and x.11, such as 18.5 and 19.5.
Secrets and history export	Recreate credentials in the controller and include JENKINS_HOME in backups, since it holds secrets.	Recreate secrets on the server. Bamboo encrypted values usually need re-entry, so confirm the export path with Atlassian.	Recreate CI/CD variables in the instance. Use the backup and restore documentation to plan recovery before cut-over.

What renewal and migration cost, component by component

The renewal path and the migration path both carry costs that are easy to undercount, so compare them on the same list of components. On the renewal side, the main recurring line is the Bamboo Data Center agent-tier subscription, renewed annually and sized to the number of agents you run. Ask Atlassian or your partner for the current Bamboo Data Center renewal quote, the agent tier that matches your build capacity, and whether the Bitbucket Hybrid License applies to your Bamboo estate after the 2029 end of life, since the journey-to-cloud page makes that statement but the terms of that license are what decide your renewal cost beyond 2029. The Bamboo pricing page at Atlassian Bamboo pricing is the place to start, but confirm figures in writing rather than from the public page. On the open-source side, Jenkins and Woodpecker CI carry no license fee, so the recurring costs are the servers, the database, the storage for build history and the people who run them.

Migration costs are mostly one-time, but they are not small. Budget for translating plans into Jenkinsfiles or Woodpecker workflow files, re-creating secrets in the new platform (CI secret values generally cannot be exported, so each one must be re-entered by someone who holds the source value), exporting build history before the Bamboo instance is retired, and running Bamboo and the new platform in parallel during cut-over. Parallel running is a recurring cost for as long as it lasts, and it doubles agent and server spend for that window. Staff time covers platform engineering, security review of the new secrets model and the operations work that Atlassian otherwise handles for you. For GitLab, the public GitLab pricing page lists Free at 0 US dollars and Premium at 29 US dollars per user per month billed annually, with all tiers available for self-managed installations, so a GitLab quote scales with the number of users, not with agents. Confirm the user count and the tier you need before comparing.

Use the same checklist for every quote. Ask each vendor or partner to state what is one-time and what recurs, how the price scales with agents, users, cores and storage, and what the quote excludes, such as upgrades, backups, support hours and hardening. Ask for the build history retention and export effort, the number of Bamboo plans and deployment projects in scope, and the number of secrets to re-create. The cost drivers that move the total most are the agent count, the size of the plan inventory, the number of secrets and integrations with Jira or Bitbucket, and how long the parallel run lasts. Treat any figure in a proposal, including ours, as valid only with the written scope behind it, and request a fixed-scope quote so the migration hours are tied to named deliverables.

How to deploy the chosen option and run it in parallel

This sequence moves Bamboo plans, secrets and build history to a self-hosted CI platform in your own infrastructure, with both systems running side by side until each pipeline has been proven and Bamboo can be retired safely.

Inventory plans, projects and secrets
Your platform or build engineering lead lists every Bamboo plan, deployment project, agent, shared task and secret variable, and marks which ones feed production releases. Record which plans depend on Bamboo-specific task types, which agents have custom tooling and which Bitbucket or Jira links each plan uses. Done means every plan has an owner, a criticality rating and a target destination in the inventory, reviewed by the team that owns releases.
Export what Bamboo allows
Export plan and deployment definitions to the format your Bamboo edition supports, and keep those files in version control as a starting inventory rather than a finished pipeline. Save build logs, test reports and artifacts you must retain for audit, because a new CI platform will not carry Bamboo history forward. Encrypted secret values generally cannot be read back from the server, so plan to re-enter them from their original sources. Done means a dated archive exists and a named person has confirmed it opens and is complete.
Decide the target platform
Choose Jenkins, Woodpecker CI or GitLab CI/CD using the inventory, the Git forge you will keep, and the skills and approval paths your teams already have. Confirm the licensing terms and support model in writing for the platform you pick, including any paid edition or support contract. Record the decision with the reasons and the owner who signs off. Done means a written decision record is approved by engineering, security and the business owner of the releases.
Build the server and agents in your infrastructure
Your infrastructure team deploys the controller or server, the build agents and the database in your own cloud account, data center or air-gapped network, following the vendor's installation guidance and your hardening standard. Set up scheduled backups from day one: for Jenkins, back up $JENKINS_HOME on the controller, which holds configuration, plugins and secrets, and for GitLab, use the backup and restore procedure and test a restore in a separate environment. Done means a test restore has succeeded and a sample build runs on a dedicated agent.
Re-create secrets manually
Engineers who own each deployment credential re-enter values in the new platform's secret store, using fresh credentials where the old ones are weak or shared. Restrict each secret to the pipelines and environments that need it, and remove any value that is no longer used. Keep a record of which secret was moved, by whom and when, without storing the values in the record. Done means every production secret has been tested in a non-production pipeline and the old Bamboo variables are scheduled for removal.
Migrate one pipeline at a time
Rebuild each plan as a Jenkinsfile, Woodpecker workflow or GitLab CI configuration, starting with a low-risk pipeline that has few deployment steps. Run the new pipeline against the same branch and compare its test results, artifacts and deployment outputs with the Bamboo run. Repeat for each plan in priority order, and do not move the production release pipeline until earlier ones have passed review. Done means each migrated pipeline has a documented comparison and an owner's approval.
Run both servers in parallel
Keep Bamboo and the new platform running together, with migrated pipelines triggered on the new platform and any unmigrated pipelines left on Bamboo. Monitor failure rates, queue times and agent capacity on both sides, and make sure only one system deploys to each environment at a time to avoid conflicting releases. Done means every pipeline has run successfully on the new platform through its normal release cadence and the parallel period has been reviewed by the release owners.
Cut over and retire Bamboo
Switch all triggers to the new platform, disable Bamboo plans and deployment projects, and revoke Bamboo agent access and credentials. Confirm your renewal or termination notice with Atlassian in writing, and keep a read-only archive of Bamboo data for the retention period your compliance team sets. Document the final state and update runbooks, access reviews and the backup schedule. Done means Bamboo has no active triggers, its credentials are revoked, and the archive and runbook updates are filed with the change record.

Evidence to keep for auditors during the move

Auditors and assessors will ask how the CI server was chosen, how secrets and build history moved, and how the new system is operated. The records below are internal evidence that your own teams produce, and none of them is a certification or attestation. Keep them together in one controlled location so each decision can be traced from renewal choice to cut-over.

Renewal or replacement decision record

Write down the options considered: renewing Bamboo Data Center under the Bitbucket Hybrid License path, moving to Jenkins, Woodpecker CI or GitLab CI/CD, and the reasons for the choice. Atlassian's announcement of September 8, 2025 sets sales to new customers ending March 30, 2026 and end of life on March 28, 2029, while its journey-to-cloud page says Bamboo Data Center continues. Record which notice you relied on, the date you checked it, and who approved the decision.

Secrets re-creation log

CI secrets generally cannot be exported from one platform to another, so each secret needs a record of where it was re-created, who did it and when, with the value itself kept only in the new secrets store. Log the secret name, owner, consuming pipelines and the rotation performed. Rotating credentials at cut-over also gives you a clear before and after record for each secret.

Exported build history and artifact records

Hosted CI services keep artifacts for limited periods, and Bamboo's own export does not include build history, so exported results must be archived before decommissioning. Keep a manifest listing each exported plan, build log, test report and artifact, with checksums and the storage location. Confirm with your auditors which retention period applies to each record class.

Backup and restore test results

Jenkins keeps its configuration, plugins and secrets in $JENKINS_HOME on the controller, and Woodpecker and GitLab each have their own state and database to protect. Record each restore test: the backup taken, the target environment, the steps run, the time taken and the result. A backup that has never been restored is not evidence that recovery works.

Cut-over change records

Each step of the parallel run and cut-over needs a change ticket that names the pipelines moved, the approver, the rollback plan and the verification evidence. Keep the old Bamboo server available until the records are complete. These entries show how production deployments were controlled during the transition.

Access reviews for the new CI server

Review who holds administrator, approver and deployment roles on the new CI server, and which service accounts can reach forge repositories and deployment targets. Record each review with the reviewer, the date and the changes made. Confirm with your assessor which review cadence and scope they expect for this system.

Common questions about Bamboo end of life

Will Bamboo Data Center keep working after 2029?

Atlassian's journey-to-cloud page states that Bitbucket and Bamboo Data Center will continue beyond the 2029 end of life under a Bitbucket Hybrid License, while the September 8, 2025 sunset announcement sets end of life on March 28, 2029 and ends sales to new customers on March 30, 2026. These notices conflict, so get the current terms in writing from Atlassian before you plan. Ask specifically whether the Hybrid License covers Bamboo, what support is included, and whether security patches continue. Your renewal decision depends on those answers, not on the marketing language.

What does renewing Bamboo cost compared with migrating?

Renewing costs recur through Bamboo Data Center agent-tier subscriptions and any Hybrid License terms Atlassian sets, plus the servers, database and staff time you already spend running it. Migrating costs are mostly one-time: pipeline conversion, secret re-entry, testing, cut-over and training, plus recurring infrastructure and support for the new platform. Jenkins and Woodpecker CI are open source with no per-agent license, so their recurring cost is infrastructure and people. GitLab self-managed Premium is priced per user per month on the GitLab pricing page, which makes user count the main driver. Ask vendors for a quote built from your agent count, user count and pipeline inventory.

How long does a move off Bamboo take?

The duration depends on how many plans you have, how many use custom or unsupported tasks, how many deployment projects and secrets need manual handling, and how much the new platform must match your current release gates. Plan size and task complexity matter more than the number of servers. Ask for a timeline based on a plan inventory and a written scope, and check whether it includes running both servers in parallel during cut-over. No duration is given here because none has been researched for your environment.

What does the migration need from our own engineers?

Your team needs to own the decisions and the knowledge of what each plan does. That means someone who can list every Bamboo plan and deployment project, identify the ones that depend on Bitbucket, Jira or custom scripts, approve the target pipeline design, and sign off on test results. Engineers also need to review each converted pipeline, rotate and re-enter secrets, and learn the new syntax. Budget their time explicitly, since it is often the largest unplanned cost in a migration.

Can our own team migrate Bamboo without a partner?

Yes, if you have engineers who know Jenkins, Woodpecker CI or GitLab CI/CD well, time to run parallel builds, and a clear rollback plan. Smaller inventories with simple build steps are the easiest to move in house. A partner adds value when plans are heavily customized, when secrets and compliance evidence must be handled carefully, or when you lack capacity to run both systems during cut-over. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, usually under a fixed-scope written agreement.

How are Bamboo secrets handled during a platform change?

Bamboo encrypted variables generally cannot be exported in readable form, so you should assume they must be re-created on the new platform. Inventory every credential, token and deployment key first, then decide which ones to rotate instead of copying them. Store the new values in your chosen secrets store or the target CI credential store with restricted access, and remove the old values after cut-over. Hosted CI incidents, such as the CircleCI January 4, 2023 incident, are a reason to rotate credentials as part of the move, not just relocate them.

What happens to Bamboo build history during the move?

Build history and artifacts stay in Bamboo unless you export them, and the export does not preserve everything, so plan for it before the move. Decide which logs, test reports and artifacts you must keep for audit or traceability, export them to long-term storage, and record where each release was built. Keep the old Bamboo instance readable for an agreed retention period. Confirm the retention and evidence requirements with your compliance lead or auditor, since DeployOpen prepares evidence but does not issue audit opinions.

When should we hire a partner for a fixed-scope Bamboo replacement?

Hire a partner when the plan inventory is large, the pipelines are customized, deployments are regulated, or your team cannot absorb the work alongside normal releases. A fixed-scope engagement defines scope, deliverables and timelines in writing before work starts, so you know what is included and what is not. Ask the partner to show how they will inventory plans, test parallel builds, handle secrets and document the result. Ongoing support, upgrades and continuous testing can follow as a retainer if you want them.

How DeployOpen plans a Bamboo replacement

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source CI/CD platforms inside your own infrastructure, so the replacement path for Bamboo Data Center fits your environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Bamboo plan, deployment project, agent pool and linked Bitbucket or Jira integration before choosing a target platform.
Record which secrets, shared credentials and build artifacts must be re-created or exported, since they generally cannot be copied out of Bamboo.
Agree the written scope, deliverables and timeline for the renew or replace decision, including what the Bitbucket Hybrid License path would cost to keep in place.

How we build

Translate representative Bamboo plans into Jenkinsfile, Woodpecker CI or GitLab CI/CD pipelines, and test them against your real repositories in a staging environment.
Deploy the controller, agents and database into your cloud accounts, data center or air-gapped network, with backup and restore configured from the start.
Harden the platform, configure access and secrets handling, and run the old and new servers in parallel during cut-over.

How we hand over

Deliver runbooks for upgrades, plugin management, agent scaling and backup and restore so your team can operate the platform independently.
Document pipeline conventions, secret ownership and the decommissioning steps for Bamboo, including the export of build history you need to keep.
Provide evidence of configuration, testing and access controls that your internal or external auditors can review for compliance readiness.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, covering the platform release cycle you choose to follow.
Review plugin, runtime and version changes against your pipelines before each upgrade, so builds do not break unexpectedly.
Confirm the support boundaries, response expectations and retainer terms in writing with your scope before any work begins.