Atlassian’s wind-down of Server and Data Center for Bamboo turns this from a cost optimization into a forced migration, you’re moving whether you like it or not, which makes it a good moment to leave per-agent licensing behind entirely. Drone CI is a container-native, open-source CI system where every pipeline step runs in a container, defined in a simple YAML file. This guide covers the conversion.
Why Drone, and the alternative worth a look
Drone’s model is clean: pipelines are declared in .drone.yml, each step is a container image, and it scales by running workloads as containers (great if you’re already on Docker/Kubernetes). It removes Bamboo’s per-agent licensing. The trade-off: Drone is leaner than Bamboo’s plan/stage/branch UI, and you own hosting. If you want something closer to Bamboo’s richer UI or a Git-platform-integrated CI, also consider Woodpecker (a Drone fork) or Gitea Actions, the conversion effort is similar.
What changes conceptually
Bamboo is plan/stage/job/task oriented with a server-managed agent pool. Drone is pipeline/step oriented with everything in containers:
- Bamboo plan →
.drone.ymlpipeline in the repo. - Stages/jobs → pipeline steps (each an
image:+commands:), withdepends_onfor ordering. - Tasks (script, build, deploy) → step commands or plugin images.
- Remote agents → Drone runners (docker/kubernetes/exec runners) registered to the server.
- Bamboo variables → Drone secrets and environment, stored in Drone’s secret store.
- Triggers/branch plans → Drone trigger conditions (
when:branch/event).
Pipelines are now versioned in the repo, which is a real improvement over server-stored plans.
Translating a plan step by step
Export each Bamboo plan’s configuration before you start, so you have an authoritative reference for stages, tasks, triggers, and variables. Then work through it in order:
- Stages become ordering, not containers. Bamboo stages that ran sequentially become steps with
depends_onchains. Parallel jobs within a stage become steps without a dependency between them, which Drone can run concurrently. - Tasks become commands or plugin images. A script task is a step with
commands:. A specialized task (artifact download, deploy, notification) usually becomes a plugin image published for that purpose, or an official vendor container running the same tool. - Requirements become runner labels. Bamboo’s agent capability requirements map to runner selection, so a step that needed a particular toolchain now names an image that contains it.
- Branch plans become trigger conditions. Bamboo’s automatic branch plans collapse into
when:blocks keyed on branch and event, kept in the one versioned file.
Migrating repos, agents, and artifacts
Drone connects to a Git host rather than storing code itself, so ensure repos are on a host Drone supports (GitHub, GitLab, Gitea, Bitbucket) before wiring pipelines. If you are also leaving Bitbucket Server as part of the Atlassian wind-down, sequence that repo move first so Drone points at a stable home.
Agents do not migrate; you stand up Drone runners on the compute you already have and register them to the server. Artifacts need a deliberate home too: Drone has no built-in artifact vault, so publish build outputs to an object store or registry with a plugin step, and update anything downstream that used to fetch them from Bamboo. Webhooks are re-pointed per repository as each project cuts over.
The migration flow
- Inventory Bamboo plans, stages/tasks, agents, variables/secrets, artifacts, and integrations (SCM, registries, deploy targets).
- Ensure repos are on a Git host Drone connects to (GitHub/GitLab/Gitea/Bitbucket), if you’re also leaving Bitbucket Server, sequence that first.
- Stand up Drone (server + runners; Docker or Kubernetes runners depending on your infra).
- Convert plans to
.drone.yml, translate each stage/task to containerized steps, re-create secrets in Drone, and wire artifacts/registries. Start with one representative project. - Dry-run the converted pipeline (build → test → deploy) and compare against the Bamboo result.
- Cut over project by project, keeping Bamboo running until each project’s Drone pipeline is green. Re-point webhooks.
Containerization is the real shift
The biggest mental change: every step runs in a container image, so build tools and dependencies are declared as images rather than installed on a persistent agent. This is cleaner and more reproducible, but plans that assumed a stateful agent (pre-installed SDKs, local caches) need rethinking, use step images with the tools baked in, and Drone’s caching/volumes for state.
Validation
Acceptance bar: “a representative project builds, tests, and deploys end-to-end on Drone,” with secrets and artifacts resolving and a deploy + rollback verified. Don’t migrate the whole org until the pilot pipeline is solid, and mind the Bamboo EOL date, which sets your real deadline.
Turning the deadline to your advantage
Bamboo → Drone turns a forced end-of-life into a clean exit from per-agent licensing, moving to versioned, container-native pipelines. The work is converting plans to .drone.yml and adopting the containerized step model; Woodpecker or Gitea Actions are valid alternatives with similar effort. Pilot one project, then cut over project by project before the EOL date. Model your per-seat/agent savings in the calculator above, and treat them as provisional until you scope the pipeline-conversion effort.