We first wrote this post when Bamboo Server support was ending. That happened on February 15, 2024. Since then Atlassian has announced the end of life for its Data Center products, Bamboo included, and has shipped tooling to move Bamboo plans to Bitbucket Pipelines. This version replaces our earlier advice with the current dates, what stops working, and a migration path you can plan against.
When does Bamboo reach end of life?
Bamboo Data Center is part of Atlassian's Data Center end of life, along with Jira Software, Jira Service Management, Confluence, and Crowd Data Center. Atlassian is winding Data Center down in phases:
- February 15, 2024: support for Bamboo Server ended, along with every other Server product except Fisheye and Crucible.
- March 30, 2026: new customers can no longer buy Data Center subscriptions or Data Center Marketplace apps.
- March 30, 2028: existing customers can no longer buy new Data Center subscriptions, expansions, upgrades, or Marketplace apps. Renewals of what you already have continue.
- March 28, 2029 at 23:59 PST: end of life. Data Center subscriptions and their Marketplace apps expire, and the products become read-only.
Until March 28, 2029, Atlassian continues technical support and security fixes for critical vulnerabilities. Renewals cannot run past that date; a 12-month renewal that would is prorated to it. Atlassian says it will offer extended maintenance after end of life only by exception, at additional cost, so talk to your Atlassian account team early if you think you will need it.
One detail catches teams out. Bitbucket Data Center is not part of the end of life: existing Bitbucket Data Center customers get a Bitbucket Hybrid License that covers both Bitbucket Data Center and Bitbucket Cloud. Bamboo is not excluded. If your code stays on Bitbucket Data Center, your builds still need a new home.
What stops working when the license expires
Atlassian's knowledge base describes what an expired Bamboo Data Center license does. Bamboo switches part of its operations to read-only and asks for a new license key:
- Trigger handling is disabled, so commits and schedules no longer start builds.
- Builds and deployments can no longer be added to the queue.
- Run, Run customized, and Run deployments are disabled.
- Administrators see an expired license warning, other users see a read-only banner, and support is no longer available.
In practice, Bamboo becomes a record of past builds that cannot ship anything new. Atlassian also advises against leaving a read-only Data Center product connected to the internet after end of life, because no new security fixes will be released. Back up what you need for audit, then shut it down.
What Atlassian recommends instead
Atlassian's cloud CI/CD is Bitbucket Pipelines, built into Bitbucket Cloud, and that is where Atlassian is pointing Bamboo customers. Pipelines runs builds on Atlassian-managed cloud runners, or on self-hosted runners on your own Linux, Windows, or macOS machines when builds must stay behind a firewall. Build minutes on self-hosted runners are not charged. Reusable integrations, called pipes, replace many Bamboo tasks.
To move plans, Atlassian released the Bitbucket Pipelines Importer, an open-source command-line tool that runs as a Docker image. Its Bamboo support entered beta on March 31, 2026 and reached general availability on June 29, 2026. It has three commands:
- audit scans your Bamboo instance and writes a readiness report: how many plans migrate cleanly, need review, or are unsupported, plus the exact plugin key of every task it cannot convert.
- forecast reads your historical build and deployment times and agent specs, then recommends Bitbucket runner sizes with estimated billed minutes.
- migrate converts Bamboo YAML specs into bitbucket-pipelines.yml files for one plan, one project, or the whole instance. Since general availability it also converts deployment projects into custom pipelines.
The importer has limits worth knowing before you plan. It works only from Bamboo YAML specs: Java specs, and any setting Bamboo cannot export to YAML, are not migrated. Third-party plugins it does not recognize are left as TODO comments, though you can write Python custom transformers that map a plugin to a pipe or a shell script. And Pipelines needs your repositories in Bitbucket Cloud. Atlassian's migration assistant for Bitbucket moves code, commit history, and pull request metadata from Bitbucket Data Center, and Bitbucket Cloud's repository importer handles other hosts.
Other CI options
Bitbucket Pipelines is Atlassian's answer, not the only one. If your code already lives in GitHub, GitHub Actions Importer can audit and convert Bamboo pipelines; it needs Bamboo 7.1.1 or later. GitLab documents a path from Bamboo Specs to a .gitlab-ci.yml file for GitLab CI/CD. The planning work below is the same whichever target you pick. What changes is the syntax and where your runners live.
Your migration path
We run a Bamboo move in five steps. The importer speeds up the first two. The last three are where the time goes, because Atlassian's own guide says to plan manual follow-up on every migrated plan, even when the importer reports success.
1. Inventory your plans
Run the audit against the whole instance before you estimate anything. Then add what the audit cannot tell you:
- Which plans still run and which nobody owns. Disabled plans migrate as no-ops and disabled tasks are skipped, so decide now whether to retire them.
- Every plugin key the audit flags as unsupported, and the team that depends on it.
- Your agents and their capabilities: remote, elastic (Amazon EC2), and ephemeral (Kubernetes) agents, and the requirements each plan matches against them.
- Integrations: Jira links, webhooks, artifact stores, and notification channels.
- Password variables, and what each one grants access to.
Then run forecast over a representative quarter so runner sizes and Pipelines costs are based on your real build times.
2. Map build and deployment plans
Generate a baseline with migrate, then map what the tool does not. Bamboo stages with parallel jobs become parallel steps. Deployment projects become custom pipelines, but the importer cannot recreate the link between a deployment and the build that produced its artifacts. Wire them back together in one of three ways: build and deploy in the same pipeline, a parent pipeline that runs the build as a child, or artifacts stored outside Bitbucket in S3 or Artifactory.
Some Bamboo logic needs hand mapping:
- Branch-specific tasks driven by task conditions become separate branch pipelines.
- Trigger conditions are dropped and left as comments, and cron schedules move to scheduled builds set in the Bitbucket interface.
- Parent and child plan dependencies become a trigger-pipeline pipe that starts the downstream repository's pipeline.
- Notification settings are not migrated. Recreate them with after-scripts and pipes.
- Pull request checks move into a pull-requests block, enforced with the Require passing pipeline merge check.
3. Replace agents with runners
Bamboo matches jobs to agents by capability. Pipelines replaces most of that with the image field: each step names the Docker image it runs in. Workloads that can run in Atlassian's cloud move to cloud runners, sized from your forecast. Builds that need a private network, licensed tooling, or an operating system you control go to self-hosted runners, which do the job Bamboo agents did. Atlassian documents the IP addresses runners need when they sit behind a corporate firewall.
4. Move secrets and variables
The importer does not migrate secrets. Bamboo password variables become secured variables in Bitbucket, set at the workspace, repository, or deployment level; secured values are encrypted and hidden in logs. Where a build only needs cloud credentials, Pipelines supports OpenID Connect, so a step can reach AWS or Google Cloud without a stored key. Built-in variables change syntax too: ${bamboo.buildNumber} becomes $BITBUCKET_BUILD_NUMBER. The importer maps the common ones, but your scripts may reference others. Treat the move as the moment to rotate every secret and give each one an owner.
5. Test, then cut over
- Commit each generated bitbucket-pipelines.yml to a feature branch and resolve every TODO comment.
- Run it and compare the results with the same build in Bamboo: artifacts, test results, and deployment targets.
- Move mission-critical plans in phases. Atlassian's bamboo-trigger-build pipe lets simple steps move to Pipelines while critical steps keep running in Bamboo.
- Merge to the main branch, turn on the new pipelines, and disable the Bamboo plan.
- Train the teams who own each repository, and record where each old plan went.
- When the last plan has moved, back up what you need for audit and shut Bamboo down.
Plan Bamboo with the rest of your Data Center move
Bamboo rarely moves alone. Jira, Confluence, and Crowd Data Center share its end of life date, and Crowd's end of life changes how people sign in. Atlassian Cloud cannot connect to Crowd or LDAP directly, so you need a cloud identity provider and, in most cases, Atlassian Guard Standard. Sequence the Bamboo work with the rest of the estate so build links to Jira and sign-in both work on the first day. We cover the identity side in identity debt in a migration.
Where we help
We plan and run Data Center moves as an Atlassian Platinum Solution Partner, Bamboo included: the audit, the runner and secrets design, and the cutover. See Atlassian Cloud Migration Services. When the importer leaves a plugin it cannot convert, the fix is code, a custom transformer or a pipe of your own, and that is custom development.
