Migrate from Bamboo to GitLab CI/CD

Migrating from Bamboo to GitLab CI/CD: what the move involves

Bamboo plans, stages, jobs, agents and deployment projects do not carry over to GitLab as objects. Each Bamboo plan is rebuilt as a `.gitlab-ci.yml` pipeline, and each Bamboo agent is replaced by a GitLab Runner that you install, register and secure in your own infrastructure. Before any code is written, the team should inventory every plan, its triggers, variables, shared artifacts, linked repositories and the environments it deploys to, because that inventory defines the size of the rewrite. The GitLab migration guide is the reference for this mapping, and it is the document to follow alongside your own plan inventory.

Treat the repository move and the pipeline rewrite as two separate workstreams with different owners and different risks. Moving repositories is mostly a question of history, branch and access mapping, and it can be completed and verified before any pipeline changes. The pipeline rewrite depends on the build toolchain, the deployment targets and the secrets each plan uses, so it usually takes longer and needs developers, release engineers and whoever owns the deployment credentials. Plans that are dormant or duplicated should be retired during the inventory rather than rebuilt, which often reduces the rewrite more than any tooling choice.

Effort rises with the number of plans, the amount of custom Bamboo tasks and scripts, the depth of cross-plan dependencies and how many environments need approval gates. Ask any partner for a written scope that lists each plan, its target pipeline and runner type, the secrets it needs and the verification it will pass before cutover. Confirm with your own engineers which Bamboo features your plans rely on, because any feature without a direct GitLab equivalent will need a design decision before the scope can be priced.

Which Bamboo concepts map to GitLab CI/CD and which need redesign

This table compares Bamboo plans, stages, jobs, agents, variables, triggers, artifacts, deployment projects and plan branches with their closest GitLab CI/CD equivalents. Each row is marked as maps cleanly, maps with rework, or needs redesign, so you can estimate where the migration effort sits. Confirm every vendor concept against current GitLab documentation before you commit to a design.

Bamboo concept	GitLab CI/CD equivalent	Migration status
Plan	Pipeline defined in .gitlab-ci.yml, or split across included files	Maps with rework: plan settings become pipeline configuration in the repository
Stage	Stage keyword, which orders jobs within a pipeline	Maps cleanly: stage order and job grouping carry over directly
Job	Job with a script, image and rules	Maps with rework: job scripts move, but task-level logic often needs rewriting as shell or scripts
Task	Commands inside a job script	Maps with rework: Bamboo task types such as built-in plugins need an explicit script or container image
Agent and capability	Runner with tags and an executor (shell, Docker or autoscaling)	Needs redesign: agent pools, capabilities and build hosts must be rebuilt as runner fleets and tags
Variables (plan and global)	CI/CD variables at project, group or instance level, with protected and masked options	Maps with rework: confirm which secrets are masked, protected or moved to an external secrets manager
Triggers and schedules	rules keyword and scheduled pipelines	Maps with rework: repository triggers and cron schedules need equivalent rules and schedule configuration
Artifacts	artifacts keyword with expiry, and cache keyword for dependencies	Maps with rework: artifact retention and cross-job passing must be reviewed against storage limits
Plan branches	Branch-based pipelines and merge request pipelines through rules	Needs redesign: plan branch behavior depends on how your team defines branch lifecycle and cleanup
Deployment project	Jobs deployed to environments, with environment tracking and manual gates	Needs redesign: there is no one-to-one equivalent, so deployment steps are usually rebuilt as jobs with environments

Documented paths for moving repositories and pipeline definitions

Bamboo is not a GitLab importer, so the migration splits into two tracks. Source repositories can move through GitLab's documented import paths, while plan definitions, agents and deployment steps are rebuilt as GitLab CI/CD pipelines and runners. The cards below cover each track and the checks that confirm the rebuilt pipelines behave like the originals.

Importing repositories by URL

GitLab's import documentation covers Git repositories imported by URL or manifest, so source code can move without a Bamboo-specific tool. Confirm which repositories Bamboo plans reference, whether they are reachable from the new instance, and whether each one needs a fresh clone or a mirror. Bamboo plan settings, repository credentials and branch rules do not travel with the code and must be recorded separately before cutover.

No Bamboo importer exists

Bamboo is not among the sources GitLab lists for direct import, so plan definitions, stages, variables and triggers are not moved automatically. Treat the Bamboo plan as a specification and rebuild each plan as a .gitlab-ci.yml pipeline by hand or with scripts your team writes and reviews. Avoid planning around any Bamboo export format, since none is documented as a supported input for GitLab.

Mapping plans to pipelines

Each Bamboo plan typically maps to a pipeline, with Bamboo stages becoming GitLab stages and jobs carrying the build and test steps. Bamboo task-level conditions, artifact sharing and deployment projects need explicit equivalents, such as rules, needs and artifacts. Document each mapping in a table so reviewers can trace every Bamboo task to its replacement.

Linting and the CI/CD API

Validate every rebuilt pipeline with the CI Lint tool or the project CI lint endpoint in the GitLab API before merging it. The API also lets scripts check pipeline status, variables and schedules during the rebuild, so migration progress can be measured rather than assumed. Confirm the exact endpoints and required token scopes against the API docs for your GitLab version, since they can change between releases.

Runner registration and executors

Bamboo agents map to GitLab Runners, which are MIT-licensed and support shell, Docker and autoscaling executors. Choose the executor from the build requirements of each plan, such as Docker images for containerized builds or autoscaling for bursty load. Register runners with the same major and minor version as the GitLab instance, and record which runner tags each job requires so jobs do not fall to the wrong machine.

Verifying parallel pipelines

Run the rebuilt pipeline against the same commits that Bamboo built, then compare artifacts, test counts and deployment outcomes before retiring a plan. Keep Bamboo running in read-only or trigger-disabled mode until each plan has passed this comparison. Agree the acceptance criteria with the teams that own each plan, because they know which failures matter most.

How a Bamboo to GitLab cutover runs in phases

The sequence moves Bamboo plans into GitLab CI/CD in controlled stages, so each plan is proven on runners and deployment access moves only after parallel runs match Bamboo results. It ends with Bamboo retired on a schedule the organization has approved.

Inventory plans, agents and deployment projects
Your team lists every Bamboo plan, its stages, jobs, triggers, variables, shared credentials, linked repositories, artifacts and deployment projects, and records which agents and capabilities each job depends on. DeployOpen can help build the inventory, but the owners of each plan confirm it. The step is done when every plan has an owner, a target environment and a documented list of dependencies that a GitLab pipeline would need.
Choose a pilot project
The team selects one or two plans that are representative but low risk, such as a service with a clear build, test and non-production deployment. The pilot should exercise the features that matter most, including artifacts, environment-specific variables and an approval step if one exists. The output is an agreed pilot scope, named owners on both the Bamboo and GitLab sides, and written success criteria.
Rebuild the pilot as GitLab CI/CD pipelines
Engineers translate Bamboo stages into pipeline stages and jobs, move variables into GitLab CI/CD settings with protection and masking where appropriate, and replace Bamboo tasks with scripts, includes or templates that the team can maintain. Secrets are moved to a designated store rather than copied by hand. The step closes when the pipeline runs from a branch in a non-production project and its output is reviewed against the Bamboo run.
Run pipelines in parallel with Bamboo
For a defined period agreed with the business, both systems build the same commits. Teams compare build outcomes, test results, artifacts and deployment logs, and log every difference with its cause. Bamboo remains the source of deployment truth during this stage. The step is complete when differences are explained and the pilot produces consistent results across the agreed number of runs.
Test runner capacity under load
Platform engineers size the GitLab Runner fleet using the executors and cloud or hypervisor setup the organization chose, then test it with peak concurrency drawn from the Bamboo history. They confirm queue times, job isolation, cache behavior and runner version alignment with GitLab. The output is a documented capacity result and a runbook for scaling, which the team accepts before any production plan moves.
Cut over triggers and deployment access
Teams disable Bamboo triggers and repository hooks for each migrated plan in a planned change window, enable the matching GitLab pipeline triggers, and move deployment credentials and environment permissions to GitLab environments. Rollback steps are rehearsed first. The step is done when a production-bound change is deployed through GitLab, approved by the expected reviewers and recorded in the change system.
Decommission Bamboo after retention
Once every plan has moved and the agreed retention period has passed without a need to fall back, the team disables remaining Bamboo plans, revokes its credentials and agents, and exports the build history and audit logs required by internal policy. Confirm retention and export requirements with your compliance owner before this step. The step closes when Bamboo no longer runs jobs, its access has been removed and the archive is verified.

How Bamboo agents become GitLab Runners

Each Bamboo remote agent becomes a GitLab Runner, and each Bamboo capability or agent requirement becomes a runner tag that a job uses to select a runner. The mapping is not one to one, though. Bamboo agents often carry long-lived installed toolchains, and a shared runner that carries the same tools will behave differently from an agent that was set up for one plan. Inventory every agent, its capabilities and the plans that pin to it before you register any runner, so that each tag in your pipelines points to a runner you have actually built and tested.

The executor decides how isolated each build environment is, and that choice matters more than the tag names. The shell executor runs jobs directly on the host, so builds share its filesystem, installed tools and any state left by earlier jobs, much as a Bamboo agent does today. The Docker executor starts each job in a container from an image you define, which gives cleaner environments but requires that every build tool, SDK and certificate is present in the image. Autoscaling executors create and remove machines or containers on demand across clouds and hypervisors, which suits bursty CI load but adds provisioning design and cost controls. Confirm executor fit for your build toolchain by running a representative set of your heaviest plans, including any that need Docker-in-Docker, privileged access, hardware or licensed compilers, before you decide which executor each tag uses.

GitLab Runner is distributed under the MIT license, so the runner itself carries no edition or licensing gate on your build fleet, although the GitLab instance it connects to does. The Runner documentation advises keeping the Runner major and minor versions aligned with GitLab, so plan runner upgrades alongside each GitLab upgrade stop rather than treating the fleet as separate. Record which Runner version each host runs, and include runner registration, token rotation and version checks in your operating runbook so that the Bamboo agent fleet is not retired until the GitLab runners have handled a full release cycle of your builds. Start with the GitLab Runner documentation to confirm current executor options and version guidance.

What drives the cost and duration of a Bamboo migration

This table lists the factors that change the effort of moving Bamboo plans to GitLab CI/CD and whether each one adds to one-time migration work or to ongoing operation. Use it to see which parts of your Bamboo estate need an inventory before you request a quote. The main takeaway is that custom tasks, secrets and runner capacity usually matter more than the raw plan count.

Driver	Why it changes effort	Type of effort and what to ask for in a quote
Number of plans and branches	Each plan, and each branch or plan variant that builds, must be mapped to a pipeline or pipeline include, then tested.	One-time. Ask how the quote counts active plans versus archived ones and whether branch plans are in scope.
Custom tasks and plugins	Bamboo tasks that run scripts or third-party Marketplace plugins have no direct GitLab equivalent and must be rewritten as scripts, images or components.	One-time, and recurring if custom code must be kept current. Ask which plugins are used and who maintains the replacement.
Deployment environments and approvals	Each environment, its deployment permissions and any manual approval gates must be rebuilt as GitLab environments and protected rules.	One-time setup, with recurring access reviews. Ask how many environments exist and how approvals are recorded today.
Secrets and variables	Plan variables, global variables and credentials must be inventoried, classified and recreated in GitLab CI/CD settings or a secrets manager.	One-time. Ask for the count of variables and credentials, and whether a secrets manager is in scope.
Runner fleet size and agent types	Bamboo remote agents, capabilities and build hosts map to GitLab Runner executors, tags and capacity planning.	One-time for design and build, recurring for patching and scaling. Ask about executor types, OS images and autoscaling needs.
Test suite and external dependencies	Test stages, artifacts, service containers and calls to databases or internal APIs may need network access and rework before pipelines pass.	One-time. Ask which tests depend on external systems and how test reports are consumed today.
Parallel run and cutover	Running Bamboo and GitLab side by side for a period doubles some build and deployment work and needs agreed rules for which system deploys.	One-time, but it extends the schedule. Ask how long both systems will run and who signs off the cutover.

What usually goes wrong in a Bamboo to GitLab move

Most failed Bamboo migrations do not fail on the first pipeline. They fail on behavior nobody wrote down: plugin side effects, credentials that moved in the wrong form, runners that can reach too much, and a cutover with no way back. Each card below names one risk and the step that prevents it before the cutover date.

Unrecorded plugin behavior

Bamboo plugins often perform work that never appears in a plan's task list, such as notifications, artifact cleanup, test result parsing or ticket updates. These side effects are easy to miss because the team only sees the visible tasks. Before cutover, inventory every installed plugin and every task type used in each plan, then decide for each one whether GitLab CI/CD needs a job, an included template, an integration or nothing at all. Confirm the decision with the team that owns the downstream system.

Secrets copied in plain text

Bamboo stores plan variables and shared credentials in its own encrypted store, and teams often paste those values into .gitlab-ci.yml or project variables without masking or protection. Export nothing from Bamboo in plain form. Recreate each secret as a protected, masked CI/CD variable scoped to the right group or environment, rotate any credential that was ever visible in a plan, and confirm that no job echoes a value into logs.

Runners with excess privileges

Bamboo remote agents were often shared across many plans and projects, which means one build machine may hold deploy keys, cloud roles and network access for several teams. If the same pattern is copied into GitLab Runner, any pipeline in a project that can reach the runner can use those privileges. Split runners by trust level, give each one only the access its jobs need, and restrict which projects and branches can use the deployment runners before the first production job runs.

Deployment steps that depended on ordering

Bamboo stages, final tasks and cross-plan triggers can run in an order that was never documented, and some deployments only worked because a dependent plan finished first. In GitLab, jobs in a stage run in parallel unless needs or stage order says otherwise, so the same steps can race. Write the current execution order from the Bamboo plan history, encode every dependency explicitly, and run the deployment against a staging environment to confirm the sequence matches.

Cutover without a rollback path

Teams often switch the build and deploy trigger to GitLab in one step and then discover a broken pipeline with no working Bamboo plan to fall back to. Keep the Bamboo plans, agents and artifact retention in place until the GitLab pipelines have passed a full release cycle, and write down who may reverse the switch and how. Confirm that a restore of the GitLab instance itself has been tested, using the backup procedure your team follows, so that the cutover window does not depend on untested recovery steps.

Questions teams ask before migrating Bamboo to GitLab

What drives the cost of migrating Bamboo plans to GitLab CI/CD?

The cost depends mostly on how many plans, stages, variables and deployment steps you have, and how many of them carry logic that does not map one to one. A migration has one-time work (inventory, rewriting pipelines, building runners, testing deployments and cutover) and some recurring work after the move, such as maintaining runners and pipeline templates. Two parties are usually paid: your own engineers, whose time is an internal cost, and any partner, whose fee follows the written scope. Ask any partner to quote by plan group, separate inventory from rewriting and testing, and state what is excluded, such as repository history conversion or deployment target changes.

How long does a Bamboo to GitLab CI/CD migration usually take?

Duration depends on the number of plans, how much custom logic they contain, how many deployment environments are involved and how much testing your release process requires. Plans that are simple build and test jobs move quickly, while plans with shared tasks, complex deployment approvals or many environment-specific variables take longer. Teams often stage the work by application group so that one group is proven before the next starts. Ask for the phases, the entry and exit criteria for each, and the dependencies on access to your environments and runners before accepting any timeline.

What does our internal team need to provide before the migration starts?

Your team needs to supply a complete inventory of Bamboo plans, branches and deployment projects, an owner for each application or plan group, and access to the source repositories, Bamboo configuration, secrets stores and target environments. Someone must also confirm which plans are still in use, which are scheduled, and which deploy to production. Without named owners, decisions about variables, approvals and cutover dates stall. Agree in writing who approves each pipeline before it replaces a Bamboo plan, and who can reach the deployment targets and the GitLab administrators who will create runners.

Can our own team migrate Bamboo to GitLab using the GitLab migration guide?

Yes, a team with CI/CD experience can work from the GitLab migration guide and rewrite pipelines internally, especially for a small number of plans. The guide covers planning and mapping concepts, but it does not replace knowledge of your deployment targets, secrets handling and release approvals. Most teams find the hard parts are unusual Bamboo tasks, shared plan logic, and runner placement inside a restricted network. Decide early whether you will do the inventory, rewriting, testing and cutover yourselves, or hand part of the work to a partner under a fixed scope.

Can we move repositories to GitLab before we rewrite the pipelines?

Yes, repositories and pipelines can be sequenced separately, and many teams move code first so developers work in GitLab while Bamboo keeps building. Source history, branches and tags move with the repository, while Bamboo plans, variables and agents do not. During the overlap, make sure only one system deploys to each environment so that a commit does not trigger two releases. Define which branch is authoritative, how Bamboo is paused for each application, and when its plans are disabled. The sequencing decision should be recorded in the cutover plan.

How do GitLab pricing tiers relate to a self-managed Bamboo replacement?

GitLab Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually, and Ultimate is custom priced. All three tiers are available for self-managed installations, so the choice depends on the features you need rather than on whether you self-host. The pricing page lists advanced CI/CD and priority support for Premium, and application security testing, software supply chain security, vulnerability management and compliance features for Ultimate. Confirm the tier against the CI/CD features your pipelines use, and check current pricing on the GitLab pricing page before budgeting, since prices can change.

Does moving to self-managed GitLab also require us to run runners and backups?

Yes, pipelines run on GitLab Runner, which is a separate component you install, register and scale in your own infrastructure. Runners need executors chosen for your workloads, such as shell, Docker or autoscaling executors, and their versions should stay aligned with the GitLab version. Backups and upgrade stops also become your responsibility, so plan them alongside the migration rather than after cutover. Ask any partner which runner pattern they will build, how secrets reach jobs, and how the instance will be backed up and upgraded after handover.

What your team provides and what it receives

The migration depends on what your team supplies before any pipeline is rewritten. The most important input is access to the Bamboo plans, their configuration and the variables and shared resources they rely on, including plan-level and global variables, linked repositories, build and deployment projects, and the agent capabilities each job expects. Export or screenshot access alone is rarely enough, so ask your Bamboo administrator to confirm who can read every plan and deployment project in scope, and which of them are still in active use. Your team should also name an owner for each deployment target, such as a Kubernetes cluster, a virtual machine group or a cloud account, because that person decides whether a job may deploy, what approvals it needs and when the old pipeline is switched off.

On the GitLab side, your team needs to decide where the target instance runs and who operates it. That means either an existing self-managed GitLab that is ready to receive pipelines, or an install plan covering the install method, hosting, backups and upgrade ownership. A secrets inventory is equally necessary: list every credential Bamboo plans read, including deployment keys, registry logins and cloud access, and decide which secrets manager or GitLab CI/CD variable store will hold each one. Finally, provide the runner infrastructure or confirm the hosts that will run jobs, along with network paths to the build artifacts, package repositories and deployment targets. Runner design is a separate topic, but the decision about where runners sit affects the rebuilt pipelines directly.

DeployOpen hands over the rebuilt pipeline definitions in the agreed scope, with the .gitlab-ci.yml structure, includes and variable references each plan needs, and a record of which Bamboo plan maps to which pipeline or job. The runner configuration is delivered as documented setup for the runners agreed in the written scope, including tags, executor choices and the settings that control which projects may use them. A cutover runbook sets out the order of changes, the verification steps for each pipeline, the rollback path and the people who approve each stage. The documented decisions record why each plan was rebuilt the way it was, which items were retired or deferred, and which questions remain open for your owners. Confirm in the written scope exactly which of these artifacts are included and in what form they are delivered.

How DeployOpen scopes and delivers Bamboo to GitLab migrations

DeployOpen plans and delivers the move from Bamboo plans to GitLab CI/CD as a fixed-scope engagement inside your own infrastructure. We start from an inventory of your plans, stages, agents and deployment steps, then map each one to pipelines, jobs and runners before anything is rewritten.

How we scope

Inventory of Bamboo plans, stages, jobs, variables, triggers and linked deployment projects
Mapping of each plan to GitLab pipelines, jobs, runners and CI/CD variables, with gaps listed
Written scope that names which plans move, which are retired and which stay on Bamboo during cutover
Decisions on secrets handling, runner placement and environment access agreed before build starts

How we build

Pipeline definitions written in GitLab CI/CD, with shared logic kept in includes or templates
Runner registration and configuration on infrastructure you control, matched to the build workloads
Test runs of each migrated pipeline against non-production targets with results compared to Bamboo output
Deployment jobs wired to protected environments and approval steps that match your change process

How we hand over

Documented pipeline catalog showing each original Bamboo plan and its GitLab equivalent
Runbook for runner operations, scaling, version alignment with GitLab and routine troubleshooting
Cutover record listing what moved, what was verified and what was intentionally left behind
Knowledge transfer sessions with your platform and development teams before the engagement closes

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope agreed in writing, covering runner maintenance and pipeline changes you request
Support for planning GitLab upgrade stops and runner version alignment as your instance evolves
Regular review of pipeline definitions as your Bamboo estate retires and new projects start