What you can export from Bamboo, and what you cannot
If you are facing a Bamboo Data Center renewal, the Data Center sunset notice, or a move to another CI system, the short answer is this: plan and deployment project configuration can be exported to Bamboo YAML Specs, but secrets, historical data and manually created branches need separate work. Treat the export as a structural inventory of your pipelines, not as a complete backup of your Bamboo instance. From the plan configuration page, use View plan as YAML Specs for each build plan, and View project as YAML Specs for each deployment project, then copy the output into bamboo-specs/bamboo.yaml. The sections that follow cover what that file contains, how to handle encrypted values, and what the export leaves out.
Before you start, confirm the exact export behavior for your Bamboo version against Atlassian's Bamboo 12.1 documentation, since the export steps are documented there. Build a list of every plan, deployment project and branch in scope, and mark which branches were created by hand. Those manually created branches are not included in the YAML Specs export, so each one must be recreated in the new system. The same applies to historical data for plans, so decide early whether you need build results, logs or test history for audit or compliance, and who owns that retention decision.
Plan the work on the secrets side as a separate track. Bamboo writes secrets into the export as encrypted strings beginning with BAMSCRT@0@, which means the values cannot be carried into a new CI system from the file alone. Ask your security team to inventory every credential referenced by those plans, including deployment keys, registry tokens and cloud access, and to plan a rotation or re-entry process in the target platform. Confirm with your Bamboo administrator whether any task types in your plans have no equivalent in the YAML Specs output, because those tasks will need manual rebuilding.
Which Bamboo data exports, by method and format
This table lists each Bamboo data type that can be exported for Bamboo 12.1, the method used, the output format and the limits to plan around. Read it as a starting inventory: the YAML Specs export covers configuration only, so build history, manually created branches and secret values need separate work before cut-over.
| Data type | Export method | Format | Known limits |
|---|---|---|---|
| Build plan configuration | Plan configuration page, Actions menu, View plan as YAML Specs | Bamboo YAML Specs (copied to bamboo-specs/bamboo.yaml) | Historical data for plans is not included; manually created branches must be added by hand |
| Deployment project configuration | View project as YAML Specs on the deployment project | Bamboo YAML Specs (copied to bamboo-specs/bamboo.yaml) | Export is documented for Bamboo 12.1; confirm environment and release coverage in your own instance |
| Stored secrets | Included in the plan YAML Specs output as encrypted values | Strings beginning with BAMSCRT@0@ | Values cannot be used in another CI system; re-enter each secret in the new platform |
| Build history and logs | Not covered by the YAML Specs export | Confirm with Atlassian documentation for your version | Plan a separate retention and archive step before the Bamboo instance is retired |
| Unsupported or custom task types | Review each exported task in the YAML output | YAML Specs text | Tasks without a direct equivalent need a plugin, script or container step rewritten by hand |
| Manually created branches | Not included in the YAML Specs export | Not exported | Recreate each branch and its settings in the target system |
How the YAML Specs export shapes your inventory
The YAML Specs export gives you a starting inventory of every exported plan, its stages, jobs and tasks, which your team can review and map to Jenkinsfile stages or Woodpecker workflow files. Treat it as a list to check against, not as a conversion you can run unattended. For a plan configuration, the export is produced from the plan's Actions menu with View plan as YAML Specs, and for a deployment project from View project as YAML Specs. In both cases the output is copied into bamboo-specs/bamboo.yaml, so that file is the artifact your reviewers work from.
Reviewers should compare each exported plan against the live plan in the Bamboo UI before anything is retired. Walk through the stages, job order, task types, triggers, branch settings and artifact definitions, and mark every item as mapped, replaced or unsupported. Atlassian's documentation states that the export does not include historical data for plans or manually created branches, so confirm which branches are still in use and add them to the inventory by hand. Keep a record of the Bamboo plan keys and their owners, because the mapping decisions and the later cut-over sign-off depend on that list.
Expect the export to carry secrets in a form you cannot use directly. Secrets appear as encrypted strings beginning with BAMSCRT@0@, so the actual values must be supplied again in the new CI system. Flag every plan that references a secret, record who owns that credential, and confirm where the replacement value will be stored before you map the job. Do not retire a Bamboo plan until its replacement pipeline has run successfully with the re-entered values and the team has verified the results against the live plan.
What does not come out of Bamboo, and the workaround for each
The YAML Specs export carries plan structure forward, but it leaves behind secret values, history, some branches, build outputs and anything a plugin or custom task defined. Each gap below needs a named owner and a decision before cut-over, so the new CI system is not left with silent holes.
Encrypted secrets
Secrets appear in the exported file as encrypted strings beginning with BAMSCRT@0@, and the new CI system cannot decrypt them. Treat every exported secret as a placeholder. Ask each owning team to supply the real value from its own vault, then store it in the new system's secret store under the same name. Check that no BAMSCRT string is copied into a pipeline file as if it were a working value.
Historical plan data
The YAML Specs export does not include historical data for plans, so past build results, run numbers and trend data stay in Bamboo. Decide early which history matters for audits, incident reviews or release records. Export or archive that history from Bamboo while the server is still running, and confirm the retention period before the Data Center end of life work starts.
Manually created branches
Branches that were created by hand in Bamboo, rather than by repository branch detection, are not part of the YAML Specs export. Each one has to be recreated in the new system. Compare the branch list in Bamboo with the branches your new pipelines target, and recreate any long-lived branch that still runs builds. Confirm which branch triggers each deployment before retiring the old plan.
Build artifacts and logs
The documented export path covers configuration only, so build artifacts and build logs have no YAML Specs equivalent. Decide what must be kept for traceability, such as signed release packages or test reports, and copy those files to storage you control. Set a written retention rule for logs and results, then confirm with your compliance owner that the archive meets it.
Custom and unsupported tasks
Tasks that the YAML Specs format does not support, including custom task types and scripts wired into a plan, must be rewritten by hand in the target syntax. List every task type in each plan, then mark which ones map to a standard step and which need a new script or container image. Assign a reviewer to test each rewritten step against a sample build.
Plugin-provided configuration
Settings supplied by Bamboo add-ons may not appear in the export, and the replacement may need its own plugin or step. Inventory which Marketplace add-ons your plans use, such as test report or notification integrations, and record the settings each one holds. Then choose a target plugin or script for each, and confirm its behavior with a test run before decommissioning Bamboo.
The sequence for a complete Bamboo export
This sequence turns a live Bamboo Data Center estate into a versioned set of YAML Specs, a secrets inventory and a record of the build history you need to keep. Each step ends with a check so the export can be trusted before any migration work starts.
Freeze new plan changes
Agree a change freeze with the team leads who edit plans, branches and deployment projects, so the export captures one stable state. The Bamboo administrator announces the freeze in writing and records the date and time it starts. The step is done when the team confirms that no one is editing plans, and any change requested during the freeze goes into a queue for after the export.
Inventory every plan and deployment project
Build a list of every build plan, plan branch, deployment project and environment in scope, with its owner, its linked repository and the agents it uses. Include manually created branches, because the YAML Specs export does not carry them over. The output is a spreadsheet or table with one row per item. The step is done when the Bamboo administrator and each owner have signed off on the list, and the count of items matches what the administration screens show.
Export each plan to YAML Specs
For each plan, open the plan configuration page and use Actions, then View plan as YAML Specs. For each deployment project, use View project as YAML Specs. Copy the output to bamboo-specs/bamboo.yaml in a Git repository and commit it with the export date in the message. The step is done when every inventory row has a committed file. Check that the exported files open and parse as valid YAML before going further.
Diff exported stages and tasks against the live plan
Compare each exported file with its live plan, stage by stage and task by task. Confirm that stage order, job names, task types, conditions, artifact definitions and triggers match, and record every task type that the export shows in a form you cannot map directly. These are the items that need manual rewriting later. The step is done when every difference is either fixed in the export notes or listed as a manual item with an owner.
List secret references and collect values from owners
Search the exported files for encrypted secret strings beginning with BAMSCRT@0@ and list each plan or deployment project that uses them. The exported strings cannot be decrypted in a new system, so the values must come from the people or systems that own them, such as cloud credentials, registry tokens and signing keys. Store the collected values in your approved secrets store, not in the Git repository. The step is done when every secret reference has a named owner, a target location and a confirmed rotation plan.
Record build history and artifacts to keep
Decide which build logs, test reports, artifacts and deployment records must leave Bamboo, based on your audit, release and rollback needs. The YAML Specs export does not include historical data for plans, so export or archive that history separately, using the Bamboo reporting and artifact download options available in your version. Confirm the retention rules with your compliance and records owners. The step is done when each record type has a named storage location and an approved retention period.
Create and run a verification checklist
Assemble one checklist that covers the inventory count, the diff results, the secret owner sign-offs, the history archive and the open manual items. Ask a reviewer who did not perform the export to walk through it against the Bamboo instance and the repository. The output is a signed checklist stored with the export files. The step is done when the reviewer confirms every row, and any gap found is either closed or accepted in writing by the owner.
Questions teams ask before exporting Bamboo data
How long does exporting Bamboo data take?
No supplied source gives a duration for a Bamboo export, so treat any timeline as something to confirm for your own instance. The effort scales with the work each item needs: the number of plans and deployment projects, how many plans use custom or unsupported task types, how many secrets must be re-entered, and how many people must supply those values. A small instance with standard tasks is mostly a review exercise. A large one with many custom tasks and secrets spread across teams is mostly coordination. Ask any partner to break the estimate down by these drivers in writing.
Can we export Bamboo plans ourselves without outside help?
Yes, a team with Bamboo administrator access can generate the starting inventory itself. Bamboo can export a build plan from the plan configuration page with View plan as YAML Specs, and a deployment project with View project as YAML Specs, with the output copied to bamboo-specs/bamboo.yaml. The harder part is what the export leaves out: secret values, historical data, manually created branches and any task types the target system does not support. Teams that handle those gaps internally usually need someone who can read Bamboo configuration and the target CI syntax, plus a clear owner for every plan.
What do Bamboo administrators and plan owners need to provide?
Administrators confirm which plans and deployment projects are in scope and who owns each one. Plan owners review the exported YAML Specs, confirm the build steps and triggers still match how the team works, and supply secret values that the export only carries as encrypted strings. Administrators also need to confirm which branches were created by hand, because the export does not include them and they must be added manually. Agree on these owners and approvals before the export starts, since a plan without a named owner tends to be left until the end.
Does the Bamboo export include build history?
No. Atlassian's Bamboo documentation states that YAML Specs export does not include historical data for plans or manually created branches. Plan definitions carry over, but past build results, logs and artifacts do not, so any record you need for audit or troubleshooting must be exported or archived separately from Bamboo before decommissioning. Confirm with your compliance owner which build records must be kept, how long they must be retained, and where they will be stored, because the new CI system will not hold them.
How are Bamboo secrets handled during the export?
Secrets are not moved as usable values. Bamboo YAML Specs exports represent secrets as encrypted strings beginning with BAMSCRT@0@, so the exported file does not let the new system read them. Each secret value must be supplied again in the target CI system, which means the people who hold the original credentials need to be involved. Build an inventory of secrets per plan before the export, record who will re-enter each one, and rotate any credential that is shared widely or that you cannot verify.
What should we ask a partner to include in a written scope?
Ask for a written scope that names the plans and deployment projects in scope, the target platform, and the exact deliverables, such as the exported YAML files, a mapping of unsupported task types, a secret re-entry plan and a list of manual items. Also ask who performs each step, what the client must supply, how history is archived, how parallel running and cut-over are handled, and what acceptance criteria apply. DeployOpen works from fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts, and quotes follow from that scope. DeployOpen does not publish prices.
Which parts of the export create the most manual work?
The most manual work comes from three areas: custom or unsupported task types, which have no direct equivalent in most target systems, secrets that must be re-entered, and build history and manual branches that the export does not carry over. Plans with heavy deployment logic usually need more review than simple build plans. Ask your engineers to list the Bamboo tasks used in each plan and check each one against the target platform's plugins or container steps before estimating effort. The sibling migration guides describe how the target systems handle these mappings.
Verifying the export before Bamboo is switched off
Do not switch Bamboo off until each plan and deployment project has been proven against its exported definition. Start with a plan-by-plan checklist that lists every build plan, its branches, its deployment projects and their environments, and the owning team. For each item, record whether the YAML Specs export was taken from the plan configuration page or the deployment project view, where the file was saved (bamboo-specs/bamboo.yaml), and which items the export cannot cover. Historical data for plans and manually created branches is outside the export, so those branches need their own line items with a decision on whether they are recreated or retired.
Next, run a dry run of the new pipeline against the same commit that Bamboo last built successfully for each plan. Use one commit so that differences come from the CI system, not from code. Compare job outputs, test counts, compiled artifacts and deployment results side by side with the Bamboo run, and treat any difference in environment variables or tool versions as a finding to close. Secrets are the most likely source of failure: the exported file holds only encrypted strings beginning with BAMSCRT@0@, so confirm that every secret was re-entered in the new system and that the dry run used those values, not placeholders.
Keep the exported YAML and the archived build history under your own control, in storage your team administers and not only inside the new CI system or a vendor tool. Confirm with your compliance owner which records must be kept, for how long and in what form, and whether the archived logs contain data that needs protection or redaction. Obtain the owning teams' written sign-off per plan once the checklist and dry run agree, and only then schedule the Bamboo shutdown. Ask the compliance owner and your auditors which evidence they will request, since they, not DeployOpen, decide what is sufficient.
What to plan before the Bamboo contract ends
Bamboo export is the last step of a longer exit. The cards below cover the dates and contract terms that set your timeline, plus the secret, history and ownership questions that decide what the export can and cannot carry across.
Confirm the Data Center end-of-life timing
Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products. Sales to new customers end March 30, 2026, and end of life is March 28, 2029. Atlassian's journey-to-cloud page also says Bamboo Data Center continues beyond 2029 under a Bitbucket Hybrid License. These notices conflict on the surface, so get the current terms in writing from Atlassian before you size the migration window.
Map the renewal notice window
Find the exact date your current subscription must be renewed, changed or cancelled, and the notice period your agreement requires. Ask your Atlassian account team whether the Bitbucket Hybrid License applies to your deployment and what it costs to keep Bamboo running on a renewal. Set the export start date backward from that renewal date, not from the end-of-life date.
Plan a read-only archive period
Once the license lapses or Bamboo is switched off, you may lose the ability to open plans, logs and results. Before cut-over, export plan YAML Specs, deployment project definitions and build history, then keep a read-only copy of the Bamboo database and home directory for the audit window your compliance team requires. Confirm with your auditors which artifacts they expect to see.
Rotate secrets after export
Bamboo YAML Specs keep secrets as encrypted strings beginning with BAMSCRT@0@, so the exported file does not give you usable values. Schedule a rotation of deployment credentials, tokens and keys as part of cut-over, and record which systems each secret protects. Treat any secret that stays in a Bamboo variable after decommissioning as exposed.
Keep a parallel run window
Run Bamboo and the new CI system side by side on the same repositories long enough to compare build results, test counts and deployment outcomes. Agree in advance which system is authoritative for production deploys during that window, and who signs off the switch. The length of the window is a decision for your release managers, based on how often you deploy and how many plans you migrate.
Settle who owns the exported data
Read the termination and data clauses in your Atlassian agreement before you rely on any export. Confirm what Atlassian returns or deletes at the end of the term, how long it keeps backups, and whether any Bitbucket or Bamboo data is held in a hosted service. Record the answers in your data inventory so the archive has a clear owner and retention rule.
Where to start if you want a second opinion on the export
Before you ask anyone to review your export, write down what the review covers. A written scope should list every plan and deployment project in the migration, the number of secrets that must be re-entered, and each task type the plans use, because those three inventories decide how much manual work remains after the YAML Specs files are generated. Start from the plan configuration pages in Bamboo, where you can see which plans have Actions and which deployment projects you need to rebuild. Add a line for any branches created by hand, since the export does not carry them over and they must be recreated. A scope written this way lets two reviewers estimate the same work, and it makes gaps visible early.
DeployOpen plans and implements exit work as fixed-scope engagements. Scope, deliverables and timelines are agreed in writing before work starts, so the list above becomes the basis of the agreement. Ask any provider, including DeployOpen, to state which items are included, which are excluded (for example, build history, which the export does not include, or unsupported task types that need a rewrite), who supplies the secret values, and what evidence of completion you will receive. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask for the cost components to be itemized: discovery and inventory, pipeline conversion, secret re-entry, parallel running and cut-over, and any retained support afterwards. Those items recur or repeat in different ways, so ask which are one-time and which are ongoing.
When the scope is settled, read the Bamboo migration guides in this group before committing to a target. The Migrate from Bamboo to Jenkins guide covers mapping stages and tasks to a Jenkinsfile, and the Woodpecker guide covers container-based workflow files. Use them to check whether your task inventory fits the target you have in mind. If a plan depends on a task type with no clear equivalent, treat that plan as a separate line item in the scope rather than assuming it will convert cleanly.
How DeployOpen scopes and delivers a Bamboo export
DeployOpen treats the export from Bamboo as a fixed-scope piece of work agreed in writing before it starts. We inventory the plans and deployment projects, export what Bamboo can export, and document the gaps that need manual rebuilding, including secrets and build history.
How we scope
- We list every plan and deployment project in scope, with its branches, triggers and owning team.
- We confirm which task types map to YAML Specs export and which need manual rebuilding.
- We agree in writing how encrypted secrets, historical build data and manually created branches will be handled.
How we build
- We run the YAML Specs export for plans and deployment projects and store the output under version control.
- We record each BAMSCRT-encrypted secret as a rotation task, so values are supplied again in the new CI system.
- We test exported configuration against the target CI platform in your own environment before any cut-over.
How we hand over
- We deliver an inventory that maps each Bamboo plan to its exported file, with status and open gaps.
- We document where build artifacts and logs were archived, with retention and access notes for your team.
- We provide a runbook covering secret re-entry, manual rebuilds and the steps your engineers repeat without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Support can cover re-running exports as Bamboo plans change while the migration window stays open.
- Ask us to confirm the support terms, response expectations and included deliverables in the written quote.
