Migrate from Bamboo to GitHub Actions

Our migration team moves Bamboo build plans and deployment projects onto reusable GitHub workflows: stages, tasks, artifacts and variables mapped once per family, then delivered in waves of pull requests.

Run by our migration team, on the CodeCargo platform
bamboo-specs/bamboo.ymlBamboo
version: 2
plan:
  project-key: PAY
  key: BUILD
  name: payments build
stages:
  - Build:
      jobs: [Package]
Package:
  tasks:
    - maven:
        goal: clean package
.github/workflows/ci.ymlGitHub Actions
name: ci
on: [push, pull_request]
jobs:
  package:
    uses: acme/platform-workflows/.github/workflows/java-service.yml@v3
    with:
      java-version: "17"
    secrets: inherit
A Bamboo Maven plan becomes a call to your Java building block.

Trusted by teams moving to GitHub at scale

What moves

Everything your Bamboo estate runs on.

  • Build plans

    Stages and jobs become GitHub jobs with needs, in the order they ran.

  • Tasks

    Script, Maven, npm, Docker and test tasks map to steps, actions or your building blocks.

  • Deployment projects

    Deployment projects and environments become GitHub Environments with their approvals.

  • Artifacts

    Shared artifacts between stages map to upload-artifact and download-artifact.

  • Variables

    Plan and global variables become GitHub variables and secrets.

  • Bamboo Specs

    Java and YAML Specs are read directly, alongside plans built in the UI.

scopes, converts and cuts over with you
Our team
build plans and deployment projects together
Plans + deployments
of pull requests to each repository’s owners
Waves

How it maps

Bamboo concepts, in GitHub Actions terms.

Agent capabilities become runner labels, so jobs still land on machines that can run them.

How Bamboo configuration maps to GitHub Actions
BambooGitHub Actions
PlanWorkflow
StageJob with needs:
Script taskrun: step
Maven taskactions/setup-java + mvn (or your Java building block)
Shared artifactupload-artifact / download-artifact
Plan variablesvars and secrets
Repository triggeron: push
Plan branchesbranch filters
Deployment environmentGitHub Environment

No surprises at cutover.

The parts that need a person are named in the plan up front, so they are decided before cutover, not discovered during it.

What needs a person

  • Agent capabilities, matched to GitHub-hosted runners or your own runner groups
  • Marketplace add-on tasks without a GitHub equivalent
  • Secret variable values, entered in GitHub rather than exported

How we run it

  • Inventory every plan, deployment project and agent, then group similar plans into families
  • Convert each family once onto your building blocks, and pilot it with one team
  • Roll out in waves of pull requests, and disable Bamboo triggers as each team cuts over

The same method for every Bamboo estate.

See the full method
  1. 01Inventory everything
  2. 02Convert families, not files
  3. 03Ship in waves of pull requests
  4. 04Cut over with rollback

Your migration, your way

Run it yourself, or run it with us.

Self-serve

Migration Assistant

The whole program in one app: inventory, families, waves of pull requests and cutover. Built for platform teams who want to drive.

  • Inventory, families, waves and cutover in one app
  • Pull requests to repository owners, not tickets
  • Start free on 10 repositories, no card
Start free on 10 repositories →

With our migration team

Migration services

We scope, plan and run the move alongside your team, on the same platform, for the estates and deadlines that can't slip.

  • GitHub Enterprise Cloud to EMU and data-residency moves
  • Scoping, wave plans and cutover support
  • The custom pipelines nobody wants to touch
  • A team that has done this at enterprise scale

After the move

Land clean, then stay clean.

CodeCargo Manage keeps every repository on the standards and building blocks you migrated onto, fixing drift as pull requests, as far on its own as you allow.

See how Manage works

Bamboo migration questions.

Don't see yours? Our migration team will walk through your Bamboo estate with you.

Is Bamboo migration done in the app or by your team?

By our migration team, working on the CodeCargo platform. You get the same families, waves of pull requests and cutover approach as every other source.

Do you migrate Bamboo deployment projects?

Yes. Deployment projects and their environments become GitHub Environments, with approvals carried over as required reviewers.

We use Bamboo Specs. Does that help?

Yes. Java and YAML Specs are read directly, alongside plans built in the Bamboo UI, so nothing has to be exported by hand.

Find out how many weeks
your migration takes.

Or start free on 10 repositories.

Migrate Bamboo to GitHub Actions | CodeCargo