Migrate from Bamboo to Jenkins: what the move involves
If your Bamboo Data Center renewal, per-agent cost review or the 2026 to 2029 sunset notices have pushed you to look again, the short answer is that the move is a plan-by-plan rebuild on an MIT-licensed Jenkins controller with build agents, and the Bamboo YAML Specs export gives you a starting inventory rather than a finished migration. Expect the work to be done by platform engineers, who own the Jenkins controller, agents and plugins, with help from the security team (for secrets, access and signing) and the release team (who validate every deployment path before it is switched over). Jenkins is distributed under the MIT License, so the controller itself carries no per-agent subscription, but the time to rebuild each plan is the real cost, and it grows with the number of custom tasks, deployment projects and integrations with Jira or Bitbucket that must be replaced by plugins. Ask your team to count plans, deployment projects, custom scripts and unsupported task types before estimating anything.
Start the inventory with the encrypted secrets, because they are the item most likely to block a cut-over. Bamboo secret variables cannot be read back out of the export, so every credential must be re-entered in Jenkins, preferably through its credentials store or an external secrets manager, and each one should be tied to the owner who can rotate it. Treat this as a security task, not a copy-paste: the security team should confirm which tokens are still valid, which were used by deployments to production, and which can be retired. Plan a fixed-scope review of the controller's $JENKINS_HOME backup and access model before the first production build runs on it, since that directory holds the configuration, plugins and secrets of the whole controller.
Run the old Bamboo server and the new Jenkins controller in parallel until each migrated plan has produced successful builds and deployments for a full release cycle that your release team agrees on. Keep Bamboo read-only for artifacts and build history, because hosted artifact retention limits do not apply to your own servers, but your own retention settings do. Before decommissioning, confirm the Atlassian licensing position for your Data Center contract with your Atlassian account team, since the Atlassian journey-to-cloud page describes Bamboo Data Center continuing under a separate license path. Ask any implementation partner for a written scope listing plans in scope, secrets handling, parallel-run criteria and rollback steps before work starts.
Which Bamboo capabilities map cleanly to Jenkins and which need rework
This table compares the main Bamboo building blocks with their Jenkins equivalents and marks each as clean, needs rework or gap. Read the status as a starting point for planning, since plugin behavior and Bamboo task types must be checked against your own installed versions. The main takeaway is that plan logic and agents translate well, while encrypted variables, deployment projects and Bamboo-specific tasks usually need deliberate rework.
| Bamboo capability | Jenkins equivalent | Status and what to confirm |
|---|---|---|
| Plans, stages and jobs | Declarative Pipeline stages and parallel blocks in a Jenkinsfile | Clean for sequential stages and jobs. Confirm that job dependencies and parallel branches are rebuilt explicitly, since Bamboo stage ordering is not copied automatically. |
| Tasks (script, Maven, Gradle, Docker) | Steps from core and plugins such as Pipeline Maven or Docker Pipeline | Needs rework. Script tasks usually move cleanly, but each Bamboo task type must be matched to a plugin step and tested in your environment. |
| Agents and capabilities | Build agents with labels, selected by the agent expression in each stage | Clean for labels and capabilities. Confirm agent OS, tool installations and Java versions on each agent, which Bamboo capabilities did not always record. |
| Deployment projects and environments | Jenkinsfile deploy stages with input gates, or a separate CD tool | Gap for direct equivalence. Bamboo deployment projects have no one-to-one Jenkins object, so release versioning and environment promotion need a designed replacement. |
| Encrypted variables and secrets | Credentials stored in the Jenkins credentials store, referenced by ID | Needs rework. Bamboo encrypted values cannot be read out for re-entry, so every secret must be re-created from its source system and rotated. |
| Triggers and branch builds | SCM polling, webhooks, multibranch pipeline jobs | Clean for common Git triggers. Confirm webhook delivery from your Git server and how branch discovery is configured for your repositories. |
| Bamboo Specs (YAML or Java) | Jenkinsfile and optionally Configuration as Code for controller settings | Needs rework. Specs are converted by hand or by script into Jenkinsfile logic. Configuration as Code covers controller settings, not pipeline definitions. |
| Jira and Bitbucket integration | Plugins for Jira, Bitbucket Server and Data Center, and Git hosting | Confirm per plugin. Plugin availability and supported versions must be checked against your Jira and Bitbucket releases before assuming parity. |
| Plugin-specific features | Plugins from the catalog of more than 2,300 community contributions | Confirm per plugin. Each Bamboo add-on needs a named Jenkins plugin, its license, its maintenance status and its compatibility with the Jenkins LTS line you run. |
What data and integrations move, and what must be re-created by hand
A Bamboo move splits into three groups: what the documented export carries as an inventory, what you must rebuild by hand, and what sits outside the export altogether. Read each card as a checkpoint for the cut-over plan, since the gaps decide how long the parallel run needs to last.
Plan inventory as YAML Specs
Bamboo plans and deployment projects can be exported to Bamboo YAML Specs. Treat that file set as an inventory of stages, jobs, tasks, triggers and variables to map onto a Jenkinsfile, not as a file that runs unchanged in Jenkins. Check each task type against the plugin you intend to use, because any task without a clear equivalent becomes a manual rewrite. Confirm the export scope with Atlassian for your Bamboo version before you plan from it.
Repository access re-created
Repository connections, deploy keys and service account tokens do not carry over as usable credentials. Create new Jenkins credentials for each Git server and binding the jobs need, then test each connection on a non-production branch. Record which Bamboo user or key each plan used so ownership is clear after the move. Plans that trigger on Bitbucket events also need their webhooks repointed to the new controller.
Encrypted Bamboo secrets must be re-entered
Bamboo encrypts secret variables, and the encrypted values cannot be read back out for import into Jenkins. Each secret must be re-entered from its source system, such as a cloud account, registry or deployment target, and the old value should be rotated where practical. Build an inventory of every secret reference in the plans before cut-over so no job fails on a missing credential during the parallel run.
Jenkins configuration lives in JENKINS_HOME
Jenkins stores its configuration, installed plugins and credentials in $JENKINS_HOME on the controller. That directory becomes part of your backup scope from the first day, and it must be encrypted and restored together with the matching master key material. Jenkins documentation recommends running builds on dedicated agents, so keep the controller's state small and reproducible. Confirm your backup and restore procedure with a test restore before retiring Bamboo.
Build history stays behind
The YAML Specs export carries plan definitions, not past build results, logs, test history or stored artifacts. Archive build logs, test reports and any artifacts you must keep for audit or rollback before Bamboo is shut down, and store them in a location with its own retention rules. Decide now which records your compliance team needs, because they will not be recoverable from Jenkins after the move.
Parallel run and cut-over checks
Run Bamboo and Jenkins side by side for the same branches, and compare artifacts, test results and deployment outcomes for each plan before switching triggers. Keep Bamboo read-only, not deleted, until the archive is verified and every deployment target has been confirmed from the Jenkins side. Document who signs off each plan, since a plan without an owner is the one most likely to be missed.
How Bamboo stages and tasks become a Jenkinsfile
Jenkins Pipeline defines the build as code in a *Jenkinsfile* committed to the project's source control repository, written in either Declarative or Scripted syntax. Map each Bamboo plan to one Jenkinsfile per repository, then map Bamboo stages to Jenkinsfile stage blocks and Bamboo jobs inside a stage to either sequential steps or a parallel block when the jobs do not depend on each other. Bamboo's job-level dependencies and stage ordering are the details most likely to change in translation, so check each plan's execution order against the generated pipeline before retiring the original. Bamboo's remote agents and their capability requirements translate into Jenkins agents selected by label, so a build that needed a specific JDK or Node version becomes a agent { label '...' } expression tied to an agent that actually provides it. The Jenkins scaling guide recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment, which keeps build load off the server that holds your configuration.
Bamboo deployment projects do not have a direct Jenkins equivalent, so each one becomes an explicit deploy stage in the pipeline. Model the environments as stages that run only on the relevant branch, and gate production with the input step, which pauses the pipeline until an authorized user approves it. Decide in advance who may approve each environment and record that rule in the Jenkins authorization configuration, because Bamboo's deployment permissions do not carry over automatically. Confirm with your own team which Bamboo deployment features, such as release versioning or environment-scoped variables, your processes depend on, and design the replacement before cut-over.
Bamboo tasks that Jenkins does not cover natively need a plugin from the Jenkins plugin catalog or a sh or bat step that calls the same script. Treat each unsupported task type as a line item in the migration plan: find the matching plugin, verify it is maintained and compatible with your Jenkins version, or wrap the existing command in a script step with its inputs and exit-code handling written out explicitly. Script steps are quick to port but move the logic out of Bamboo's configuration screens and into code that someone must review and maintain, so record the owner and the expected output of each one.
The migration sequence from inventory to decommission
This sequence moves Bamboo plans to Jenkins in controlled stages, so each team proves its pipelines, secrets and deployments work before Bamboo stops building anything. Every step closes with a written artifact that the migration owner signs off before the next step begins.
Inventory plans, secrets, agents and build history
Export every plan and deployment project to Bamboo YAML Specs as the starting inventory, then list the encrypted variables, shared credentials, agent capabilities and task types that the export does not carry across. Archive the build history and test reports you need to keep, because the export does not include them. Done means a plan-to-owner register, a secrets register that names each credential and its consumers, and an agent and capability inventory are reviewed by the platform owner and each team lead.
Map plans to Jenkinsfile stages
Translate each Bamboo plan into a mapping sheet that shows its stages, jobs and tasks beside the Jenkinsfile stages and the Jenkins plugins or shell steps that replace them. Flag every task type with no direct plugin equivalent, and record the Bamboo deployment projects that must be rebuilt as separate Jenkins deployment stages. Done means the mapping sheet is agreed by each team, and every unsupported task has a named owner and a decision: replace, re-implement or retire.
Provision the Jenkins controller and agents
Stand up the Jenkins controller in your own infrastructure with dedicated build agents, so the controller handles HTTP requests and manages the build environment rather than running builds. Store the Jenkins configuration, plugins and secrets under the controller home directory, and back that up from day one. Confirm the plugin set against the LTS changelog, since some plugins that were bundled earlier must now be installed through the plugin manager. Done means a test build runs on each agent type and a restore from backup has been rehearsed.
Re-create secrets and rebuild deployment access
Re-enter each secret from the secrets register into Jenkins credentials, because Bamboo encrypted values cannot be read out for import. Scope each credential to the one folder or job that uses it, and record the rotation date and the new owner in the register. Where a credential is a shared deploy key or token, rotate it at the source as well, since you are changing where it is held. Done means every pipeline authenticates with the new credentials and the old Bamboo copies are marked for deletion.
Pilot one low-risk plan
Choose a plan with few secrets, a stable test suite and a non-production deployment target, and build it in Jenkins from the same repository and commit as Bamboo. Compare artifacts, test counts, logs and deployment results with the Bamboo run, and log every difference with its cause. Done means the pilot team signs a short pilot report that lists the fixes made and any gaps still open.
Run both servers in parallel
Keep Bamboo and Jenkins building the same commits for each migrated plan, with deployments kept on Bamboo or switched to a dry run in Jenkins until the comparison is clean. Review build outcomes, test results, artifact checksums and deploy logs side by side at a regular cadence agreed with each team. Done means a parallel-run comparison, signed off by the team lead and the platform owner, shows matching results across the agreed observation window.
Cut over by repository or team
Move each repository or team to Jenkins as a block, switching the webhook, the Jenkinsfile as the source of truth and the deployment stages to live targets. Disable the Bamboo plan for that repository only after its cut-over checklist is complete, and keep the Bamboo plan paused rather than deleted so you can roll back. Done means the cut-over checklist, the webhook change record and the deployment confirmation are filed for each migrated team.
Decommission Bamboo after the observation period
Once every plan has run in production on Jenkins through the agreed observation period, export the final build history and logs for retention, revoke Bamboo agent and API access, and remove the stored secrets from Bamboo. Confirm the retention requirements for archived artifacts with your compliance owner before deletion, and check your Bamboo subscription and Bitbucket Hybrid License position with Atlassian. Done means a decommission record lists each removed component, the archive location and a sign-off from the security owner.
How the move differs by estate size and starting point
A small estate has a handful of plans, one agent pool and a small group of owners who know every build. The work is mostly translation: each plan becomes a Jenkinsfile, and the team can review the whole inventory in one sitting. A single Jenkins controller is usually enough at this size, with the build work pushed onto dedicated agents so the controller only handles HTTP requests and manages the build environment, as the Jenkins scaling guide recommends. Because the inventory is short, the team can move plans in small batches and retire each Bamboo plan once its Jenkins replacement has produced a good run.
- Sequencing: Start with the lowest-risk plan that has a single deployment target, then move the rest in batches of two or three.
- Controller layout: One controller with
$JENKINS_HOMEbacked up as a single unit, including plugins and secrets. - Parallel running: Keep Bamboo read-only for a short period after each batch, enough to compare outputs from one full release cycle.
- Secrets: Re-enter each encrypted Bamboo variable by hand and record which owner confirmed it.
- Agents: Map the existing agent pool to Jenkins agents one-for-one before retiring any Bamboo agent.
Check that every plan has a named owner and that the export covers every plan you think exists, since small estates often hide forgotten plans in personal or archived projects.
A large estate has many plans and deployment projects spread across teams, with shared agents, shared variables and inherited settings that few people fully understand. The sequencing question becomes which team moves first and which shared dependencies must be resolved before any team can leave Bamboo. The Jenkins scaling guide describes growing horizontally by adding controllers for new teams or projects, so the usual design is one controller per team or product line rather than one very large shared controller. Teams can then move on their own schedule while a central platform group owns shared libraries and plugin versions.
- Sequencing: Move shared libraries and common deployment steps first, then migrate teams whose plans depend on the fewest shared resources.
- Controller layout: Additional controllers for new teams or projects, with a primary and backup arrangement behind a proxy such as HAProxy or F5 for each controller that is critical.
- Parallel running: Expect Bamboo and Jenkins to run side by side for each team until its last deployment project has been verified, which can mean many overlapping cut-overs.
- Deployment projects: Re-create each deployment project as an explicit Jenkinsfile stage with its own approval step, since the YAML export covers plans and deployment projects differently.
- Build history: Archive Bamboo build results and logs for every team before its Bamboo access is reduced.
Ask the platform team to produce a dependency map of shared agents, variables and plans before the first migration wave is scheduled.
In a regulated environment the technical move is only part of the work. Encrypted Bamboo secrets cannot be exported, so each one must be re-entered, and the people doing that work need to leave evidence that they changed the right value, in the right place, under an approved change. Approvals in Jenkins usually run as pipeline input steps or through a change record system, so the approval path has to be designed and tested before any production deployment moves. Assessors will expect the controls around CI to be documented, so the readiness work covers access, change records and log retention alongside the pipeline code itself.
- Secret re-entry: Record who re-entered each secret, when, and which system confirmed the value, without writing the value into the evidence.
- Approvals: Build the production approval step in Jenkins and test that it blocks a deployment when the approver is missing.
- Parallel running: Keep Bamboo available as the system of record until the first audited production release succeeds in Jenkins, with the period agreed with your auditors.
- Access: Map Bamboo roles to Jenkins roles and remove inherited permissions that no longer match an owner.
- Logs and history: Export Bamboo build logs and retain them under your existing retention policy, since the export does not include build history.
Confirm with your compliance lead and external auditors which evidence they accept for CI changes, and do not assume a control is satisfied until they have reviewed the sample.
What drives the cost and duration of a Bamboo to Jenkins move
This table lists the factors that set the cost and length of a Bamboo to Jenkins migration, with the one-time and recurring costs each one touches. Use it to see where your estimate is likely to grow and what a written quote should spell out. No durations or prices are given here because they depend on your own plan inventory and environment.
| Driver | Why it changes cost or effort | One-time or recurring | How to keep it down or what to ask for |
|---|---|---|---|
| Number of plans and deployment projects | Each plan becomes a Jenkinsfile or pipeline job that needs design, testing and sign-off. Deployment projects often need a separate deployment design. | One-time | Ask for a plan-by-plan inventory with a count of stages, jobs and deployment projects, and retire unused plans before scoping. |
| Custom or unsupported Bamboo task types | Tasks with no Jenkins plugin equivalent need a custom script, a shared library step or a new plugin, each with its own testing. | One-time, plus upkeep if custom code stays | Ask the vendor to list every task type found in the export and the proposed replacement for each. |
| Encrypted variables and secrets | Bamboo encrypted variables cannot be read back for migration, so each value must be re-entered by its owner and stored in Jenkins credentials or an external store. | One-time | Ask who holds the source values and who approves re-entry. Plan a secret inventory and rotation after cut-over. |
| Agents and capabilities | Bamboo agent capabilities and tags map to Jenkins agent labels, node definitions and sometimes container images. Each build environment needs rebuilding and validating. | One-time, then recurring for agent hosting | Reduce distinct build environments by standardizing toolchains. Ask for the agent count and capability list. |
| Jira and Bitbucket integrations | Issue linking, build status reporting and repository triggers are re-created through Jenkins plugins and webhooks, and each integration needs its own test. | One-time, plus plugin upkeep | Ask which integrations are in use and confirm the plugin and version used for each with your Jira and Bitbucket owners. |
| Length of parallel running | Running Bamboo and Jenkins side by side doubles the hosting of two CI servers and the time staff spend checking results from both. | Recurring while both run | Set a fixed parallel period in the written scope and define the exit criteria for ending it. |
| Jenkins LTS and Java version choice | Jenkins 2.580.1 stopped bundling several plugins, so they must be installed through the plugin manager. Java 21 is listed as supported with planned end of support in September 2027, and Java 25 with planned end of support in September 2029, per the Jenkins Java support policy. | Recurring, through upgrades | Pick the Java version and LTS line that match your support window, and ask for the upgrade plan and test effort in the quote. |
| Staff time and skills | Pipeline authors, platform engineers and security reviewers all spend time on translation, testing and secret handling, and this effort is often the largest share. | One-time for the move, recurring for operations | Ask who in your team will own Jenkins after handover, and whether the quote includes knowledge transfer and runbooks. |
| Hosting, backup and support | Controllers, agents and backups of $JENKINS_HOME run on your infrastructure, and the scaling guide notes that all configuration, plugins and secrets live there. | Recurring | Ask for the hosting design, backup schedule, and whether a support retainer covers upgrades and plugin updates after go-live. |
What usually goes wrong and how to prevent it
Most failed Bamboo-to-Jenkins migrations fail on operational details rather than pipeline syntax. The cards below cover the risks that repeatedly break cut-overs, and each one pairs a concrete check with the step that prevents it before production traffic moves.
Build history lost before export
Bamboo build results, logs and artifacts are not carried over by a plan export, and hosted CI services in general keep artifacts for limited periods. If the old server is shut down or its storage is reclaimed first, audit trails for past releases disappear. Archive build logs, test reports and artifacts for every production-facing plan while Bamboo is still running, and confirm the archive opens before the decommission date is set.
Secrets re-entered with wrong values
Bamboo encrypted variables cannot be read back in plain text, so teams usually re-type them into Jenkins credentials from memory or old runbooks. A single wrong deployment key can pass a test run and then fail in production. Rotate each credential at the source, store the new value in the Jenkins credentials store, and record which system owns each secret so a second person can verify it.
Plugins missing after LTS changes
Jenkins LTS 2.580.1 stopped bundling several plugins, including the SSH server and JUnit plugins, so a controller upgraded without a plugin review can lose steps that pipelines depend on. Builds then fail with unknown step errors that look like pipeline bugs. Before the first LTS upgrade, list every plugin your Jenkinsfiles call, install the bundled-removed ones explicitly, and pin versions in code.
Agents with drifting tooling
Bamboo agents often carry hand-installed JDKs, Node versions, certificates and CLI tools that nobody wrote down. Recreating them as Jenkins agents by hand means the same pipeline can pass on one agent and fail on another. Define agent images or build tool setup in code, run the same pipeline on every agent label, and compare tool versions against the Bamboo agent they replace.
No tested restore of JENKINS_HOME
The Jenkins scaling guide places configuration, plugins and secrets to back up in $JENKINS_HOME on the controller, so a backup that was never restored is not a backup. Teams often discover missing credentials or job config only during an outage. Schedule a restore of $JENKINS_HOME into a separate test controller, run a representative pipeline against it, and keep the restore steps in a runbook.
Cut-over without a rollback path
Switching deployments to Jenkins in one step removes the fallback if a pipeline misbehaves under real load. Running both servers in parallel lets teams compare results and keep Bamboo deploy jobs available. Keep Bamboo active for read access and deploy jobs on each migrated plan until several release cycles pass cleanly, write down who can flip traffic back, and set the exact criteria that trigger a rollback before cut-over starts.
Questions buyers ask before moving from Bamboo to Jenkins
What does a Bamboo to Jenkins migration cost?
The cost is mostly people time and parallel running, not a software license, because Jenkins is distributed under the MIT License. The main components are internal engineering time to inventory and rebuild plans, the hours needed to re-create secrets and deployment steps, the cost of the Jenkins controller and build agents you host, and support or staff time after cut-over. Costs rise with the number of plans, the number of custom or unsupported Bamboo tasks, and how many deployment environments must be proven. Ask any vendor or partner for a quote built from a written scope that lists plans, agents, plugins and environments, and separate one-time migration work from recurring hosting and maintenance.
Is Jenkins really free under the MIT License?
Yes, the Jenkins core software is distributed under the MIT License, as stated in the LICENSE.txt file of the jenkinsci/jenkins repository, so you do not pay a license fee to run the controller or to add agents. The MIT License does not cover everything around the server, though. Plugins carry their own licenses, which you should review, and any commercial distribution such as CloudBees CI, support contracts, hosting, and the staff who run Jenkins are separate costs. Confirm the license of each plugin you rely on with your legal or compliance team before you standardize on it.
How long does a migration from Bamboo to Jenkins take?
The pace depends on how many plans you have, how complex each plan is, and how many deployment projects must be re-proven. Work usually runs in phases: inventory, mapping, building the Jenkinsfile and plugin set, secret re-entry, test runs, and a period where both servers run in parallel during cut-over. Teams with a small number of simple plans move faster than teams with many shared plans, custom task types, or strict change windows. No duration is guaranteed, so ask for a written plan with milestones and agree on acceptance criteria before work starts.
Can our own team migrate from Bamboo to Jenkins without outside help?
A capable team can do it in-house if it has Jenkins and Groovy experience, access to both servers, and time to test every plan. Outside help is most useful when the Bamboo estate includes many plans, custom tasks, shared agents, or regulated deployment steps that need evidence. DeployOpen plans, implements and documents self-hosted platforms in your own environment under fixed-scope engagements, so the decision comes down to whether your staff can own the result after handover. Compare the internal effort with a written scope before choosing.
What skills does our staff need to run Jenkins after the move?
Your staff need to operate a Jenkins controller, manage plugins and their updates, maintain build agents, and write or review Jenkinsfile pipelines in Declarative or Scripted syntax. Someone also has to own backups of $JENKINS_HOME, since the Jenkins scaling guide notes that configuration, plugins and secrets live there on the controller. Platform skills for the hosts that run agents, such as Kubernetes if you use the Kubernetes plugin, are also needed. Confirm the skill mix against your own environment and plan a training period before cut-over.
Does the Bamboo Specs export capture everything in our plans?
No, you should not assume it does. Bamboo plan and deployment project export to YAML Specs gives you a useful starting inventory of plans, stages, jobs and tasks, but it does not translate every task type into a Jenkins equivalent, and it does not carry over build history or secret values. Review each exported plan against its live behavior, list every task type that has no matching plugin step, and note any scripts or external calls that the export references. Treat the export as the start of the inventory, not the finished specification.
What happens to our encrypted Bamboo secrets during the move?
Encrypted secrets generally cannot be exported from CI platforms, so you should expect to re-create them in Jenkins rather than copy them. Vendors commonly store secret values in a form that can be replaced or deleted but not read back, and the same limit applies when you move between CI systems. Plan for each credential to be issued or rotated at its source, stored in Jenkins credentials or an external secrets manager, and tested in a parallel run. Keep an audit list of who approved each rotation and retire the old Bamboo values once cut-over is verified.
How DeployOpen scopes and runs a Bamboo to Jenkins migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted Jenkins inside your own infrastructure, whether that is your cloud accounts, data center or air-gapped network. The work starts with a written scope that names the Bamboo plans and deployment projects in use, the agents and build environments, the Jira and Bitbucket integrations, and the decision on how encrypted Bamboo secrets will be re-created in Jenkins. Most engagements are fixed-scope, so the deliverables, the timeline and the acceptance criteria are agreed in writing before any work begins. Ask for the plan inventory and the list of task types that need manual conversion to be part of that scope, because they determine the size of the work more than the number of plans does.
The written scope should also set the cut-over method. A typical plan keeps Bamboo and the new Jenkins controller running side by side while builds are compared, secrets are verified and deployments are rehearsed in a non-production environment. The scope should state who owns the controller configuration, how $JENKINS_HOME and its backups are handled, which agents Jenkins will use, and what the rollback path is if a pipeline fails after cut-over. Confirm with DeployOpen and with your own security team how credentials will be stored and who holds the recovery material, since Bamboo encrypted values cannot be read back for transfer.
Ongoing work is priced separately from the migration. Retainers cover Jenkins upgrades, plugin updates, backup checks and support after go-live, and they are useful if your team does not want to own Jenkins maintenance from the first day. DeployOpen does not publish a price list. A quote follows from the written scope, so bring your plan count, agent count, secret inventory, integration list and the number of environments to the first conversation. DeployOpen prepares systems, controls and evidence for compliance reviews, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
