Migrate from Bamboo to Woodpecker CI: what the move involves
If your Bamboo Data Center team runs on Bitbucket Data Center, the good news is that Woodpecker CI connects to Bitbucket Datacenter as a forge, so your repositories can stay where they are. The harder part is that Bamboo plans and deployment projects do not carry over as they are: each build plan has to be rewritten as Woodpecker workflow YAML, with every step running inside a container image. Plan this as a rewrite of your pipeline logic, not a server swap. In most teams, the work falls to the platform or DevOps engineers who own the Bamboo estate, supported by the developers who own individual build plans. Start with an inventory of plans, shared task configurations, agents and deployment projects, and sort them by how much of each depends on Bamboo-specific tasks. Plans that only compile, test and package usually map cleanly onto container steps. Plans that rely on custom Bamboo tasks, agent-installed tooling or deployment environments tied to specific agents need a decision for each one: find a container image or plugin that does the job, or rebuild the step. Ask your team to confirm which of these cases make up most of the inventory before estimating anything.
Bamboo deployment projects need a different answer. Woodpecker has no direct equivalent of a Bamboo deployment project with environments and release versioning, so the deployment steps usually move into workflow files that run on specific events or branches, or into a separate tool your team already uses. Credentials are the highest-risk item. Bamboo variables and encrypted secrets cannot be read back out for copying, so you will need to recreate each value in your secrets store and confirm that every rewritten step reads the right one. Also check the Woodpecker agents' network access to your deployment targets and your artifact storage before cut-over. Run both systems in parallel for a period, compare build results on the same commits, and keep Bamboo available until your team has signed off on the new pipelines and on how old build history and artifacts will be kept.
Which Bamboo capabilities map to Woodpecker CI and which need rework
This table maps Bamboo plans, agents, tasks, triggers, variables, artifacts and deployment projects to their closest Woodpecker CI equivalents. Read the status column first: clean means a direct mapping, needs rework means the logic must be rewritten or re-entered, and gap means you need to design a replacement before cut-over. The main takeaway is that build logic moves across with moderate effort, while deployment and artifact handling need separate design work.
| Bamboo capability | Woodpecker CI equivalent | Status |
|---|---|---|
| Plans and stages | Workflow files in .woodpecker/ run as parallel workflows, ordered with depends_on | Needs rework |
| Agents and capabilities | Agents connect to the server and run on Docker, Kubernetes or the local machine, selected by labels | Needs rework |
| Tasks (script, build tools, test runners) | Each step runs its commands in a container image you specify | Needs rework |
| Triggers and branch plans | when filters on event, branch and path; push, tag and pull request events on Bitbucket Datacenter | Clean |
| Job variants and matrix | Matrix builds in workflow syntax; confirm each variant maps to one matrix dimension | Needs rework |
| Plugins and marketplace tasks | Plugins are container images configured in a settings block; some Drone plugins may need changes | Needs rework |
| Bamboo variables and encrypted secrets | Woodpecker secrets; Bamboo secret values cannot be exported, so owners must re-enter them | Needs rework |
| Artifacts shared between plans | Steps share a workspace within one workflow; passing files between workflows needs external storage or a registry | Gap |
| Deployment projects, environments and release promotion | No deployment project object; model environments, approvals and promotion with separate pipelines or a CD tool | Gap |
What moves cleanly and what does not
The build logic moves, the Bamboo-specific state does not. Build and test commands, branch and event filters, and parallel jobs can all be rewritten into Woodpecker workflow syntax with the same intent. In Woodpecker, workflows are YAML files, either a single .woodpecker.yaml or several files in a .woodpecker/ directory that run as parallel workflows with depends_on ordering. Every step runs its commands inside a specified container image, so each Bamboo job that relied on a particular agent's installed tools needs an image that provides those tools. Plan the rewrite plan by plan: map each Bamboo stage to a workflow, each task to a step, and each Bamboo branch or trigger condition to a when filter on event, branch and path. Matrix builds in Bamboo variables should be checked against Woodpecker's matrix support rather than assumed to match.
Bamboo's encrypted variables do not carry over. Bamboo does not export secret values in readable form, so every credential used by a plan, deployment or Bitbucket connection must be re-entered in Woodpecker's secret store and scoped to the repositories that need it. Ask your security team to confirm which secrets are still valid before you recreate them, because a migration is a good moment to rotate them. Bamboo deployment projects, environments and their release history are a separate problem. Woodpecker has no direct equivalent of a deployment project with promotion across environments, so each deployment becomes an explicit workflow step or a separate pipeline, and approval gates must be designed on purpose. Build history and artifacts also stay behind. Export the logs and artifacts you must retain for audit before Bamboo is switched off, and confirm your retention requirements with the people who own them.
Plan a parallel run before cut-over. Keep Bamboo building the same branches while Woodpecker runs the converted workflows, and compare outputs such as test reports, image digests and artifact checksums. Woodpecker's Kubernetes backend creates a temporary persistent volume claim per pipeline to share files between steps, so confirm the storage class and access mode in your cluster before depending on that behavior. Check the Woodpecker workflow syntax documentation for each construct you rely on, and confirm the plugins you use against the plugin index, since Drone plugins generally work but may need adjustments.
Which data and integrations to move, and what to rebuild
A Bamboo to Woodpecker move splits into three groups: what the Bitbucket Data Center connection carries over automatically, what can be exported as a starting inventory, and what has to be rebuilt by hand. Secrets, build history and integrations fall into the last two groups, so each needs an owner and a check before cut-over.
Repository access through the forge
Woodpecker connects to Bitbucket Datacenter as a forge, so repositories stay where they are while builds move in-house. Pushes, tags and pull requests trigger pipelines through the forge connection. Confirm which service account Woodpecker uses, that its token can read every project it must build, and that webhooks reach the Woodpecker server. Multi-forge setups are still experimental, so plan for one forge per server.
Plan definitions as a starting inventory
Bamboo plan and deployment definitions can be exported to YAML Specs. Treat that export as an inventory, not a finished pipeline. Each plan's stages, jobs, tasks, triggers and artifact rules need to be mapped by hand to Woodpecker workflow files, because Bamboo tasks have no direct equivalent. Record which plans run on which agent capabilities, since those become container images and labels.
Secrets re-entered in Woodpecker
Bamboo encrypted variables cannot be read back out, so every secret must be re-created in Woodpecker from its original source, such as a vault, the deployment target or the owning team. Build a list of each secret, the plan that uses it and its scope. Rotate credentials during the move where possible, because the old values may already be widely copied. Restrict secrets to the repositories and events that need them.
Build artifacts and logs kept outside Bamboo
Build artifacts, logs and test results held on the Bamboo server do not move with the plan definitions. Export what auditors or release teams need, such as release binaries, test reports and signed build records, to storage you control before decommissioning Bamboo. Confirm retention periods for the new location in writing, and keep a read-only copy of Bamboo for the period your records policy requires.
Jira links, notifications and plugins
Bamboo connects to Jira issue keys, Bitbucket commits and notification channels, and some teams rely on Bamboo plugins for deployments or reports. Woodpecker has no Bamboo plugin equivalent, so each integration needs a container step, a webhook or a script. Inventory every integration, decide whether it is still needed, and verify that Jira and chat notifications still fire on the new pipelines before retiring Bamboo.
Deployment projects and release steps
Bamboo deployment projects handle environments, releases and approvals, which Woodpecker workflows do not model in the same way. Rebuild each deployment as a workflow step that runs a deployment container, with environment-specific secrets and a manual approval where one existed. Woodpecker plugins are container images that may need adjustments when adapted from Drone, so test every plugin used in deployments against a non-production target.
Migration sequence from inventory to decommission
This sequence moves Bamboo builds to Woodpecker CI in controlled stages, so each plan is proven on the new engine before Bamboo stops building it. The output is a decommissioned Bamboo estate with its build history and deployment records archived for audit.
Inventory plans, deployment projects and secrets
The Bamboo administrator and the owning team lists every build plan, deployment project, linked repository, agent capability and shared credential. Each plan is tagged with its owner, branches built, artifacts produced and downstream deployment targets. Secrets are recorded by name and owner only, because Bamboo does not export encrypted values, so each one will need to be re-entered in Woodpecker. The inventory is complete when every active plan has an owner and a disposition: migrate, retire or rebuild as a deployment step.
Stand up a pilot Woodpecker server
The platform team installs a Woodpecker server and at least one agent in a non-production environment, choosing a database appropriate to the expected load and a Docker or Kubernetes backend for the agents. The server is connected to Bitbucket Data Center as its single forge, since connecting multiple forges to one server is still experimental. Done means a test push to a sandbox repository triggers a pipeline, the agent reports status back to Bitbucket, and the team can review the logs in the Woodpecker UI.
Convert a small set of pipelines
Engineers pick three to five representative plans, such as a library build, a service build with tests and a container image build, and rewrite them as
.woodpecker.yamlor files in a.woodpecker/directory. Each step is assigned a container image, and plugins are used where an equivalent exists. Any Bamboo task with no container equivalent is noted as a gap to resolve before cutover. The pilot is complete when the converted pipelines pass on test branches and their outputs match the Bamboo results.Re-create secrets and deployment steps
The security team re-enters each inventoried secret into Woodpecker's secret store, scoped to the repositories that need it, and rotates any credential that Bamboo deployment projects used for production. Deployment projects are rebuilt as workflow steps gated by event, branch or manual approval conditions, and the environment-specific settings are checked against the Bamboo originals. Done means every deployment step has a documented owner, a scoped secret set and a rollback procedure that has been tested in a non-production environment.
Run Bamboo and Woodpecker in parallel
For a defined period agreed by the team, both systems build the same commits. Bamboo remains the system that deploys to production, while Woodpecker builds and tests in parallel and results are compared for each plan. Discrepancies in test results, artifact checksums or environment variables are logged and fixed in the workflow files. The parallel run closes when every migrated plan has matched Bamboo on the agreed set of commits and the team signs off the comparison report.
Cut over branches and webhooks
Plans are switched in batches. For each batch, the team disables the Bamboo trigger, enables the Woodpecker pipeline on the relevant repositories and confirms that Bitbucket webhooks deliver push and pull request events to the Woodpecker server. Branch protection rules and required status checks are updated to point to Woodpecker results. Done means the batch has built several real commits without a Bamboo trigger firing, and the rollback path to Bamboo is documented and tested.
Archive Bamboo history before decommissioning
Before any Bamboo agent is removed, the administrator exports build results, logs, test reports, artifacts and deployment records that auditors or incident responders may need. Bamboo's plan and deployment definitions are saved in a reviewable form, and the archive is stored in a location with the organization's retention controls. Because hosted CI services limit artifact retention, archived records should be verified as readable before the source system is turned off.
Decommission Bamboo agents and confirm closure
Once the archive is verified and no plan has triggered in Bamboo for the agreed period, the Bamboo agents are stopped, their licenses are released at the next renewal decision, and the server is removed or set to read-only. The platform team updates the CMDB, access reviews and runbooks, and the owners sign off that each former Bamboo plan has a Woodpecker replacement. Done means the decommission record lists the archive location, the retained evidence and the names of the approvers.
What drives cost and duration in a Bamboo to Woodpecker move
This table lists the components that set the cost and time of moving Bamboo plans and deployment projects to Woodpecker CI on Bitbucket Data Center. Read each row as a question to answer in your own inventory and a line to ask for in a written quote. The main takeaway is that plan count, secrets and task types usually matter more than the Woodpecker install itself.
| Cost component | What drives it | What to ask for in a quote |
|---|---|---|
| Plans and build configurations | Number of Bamboo plans, branches and stages, and how many use custom scripts rather than standard tasks | A per-plan inventory with a rewrite estimate for each plan, and a list of plans to retire rather than port |
| Deployment projects | Bamboo deployment projects have no direct Woodpecker equivalent, so each release flow must be rebuilt as workflow steps or a separate tool | A written mapping of each deployment project to its replacement and who owns the release approval step |
| Task types without a direct match | Bamboo tasks that rely on Bamboo agents, marketplace add-ons or Atlassian-specific integrations need manual replacement | A list of unsupported task types found in your export, with a proposed container step or script for each |
| Container images for build tools | Each compiler, SDK and test runner used by a plan needs a container image that Woodpecker can pull, or one that the team builds and maintains | Confirmation of which images exist, which must be built internally, and who patches them |
| Plugin fit | Woodpecker plugins are container images configured in workflow steps; Drone plugins generally work but may need adjustment, so each one must be tested | A plugin-by-plugin test plan and the effort allowed for adjustments that the vendor or partner treats as in scope |
| Secrets to re-enter | Bamboo encrypted variables cannot be exported in readable form, so each secret must be re-created in Woodpecker and its use verified | A count of secrets per project, a rotation plan, and who holds the values during the move |
| Kubernetes backend and volume sizing | Each step runs in its own pod, and the pipeline's shared persistent volume claim defaults to 10G with ReadWriteMany access, so storage class and capacity must match your cluster | Confirmation of the storage class, the claim size per pipeline, and the expected concurrency of pipelines |
| Database choice | Woodpecker uses SQLite by default, while PostgreSQL or MariaDB are recommended for larger instances, which adds database operations and backups | Whether the database is managed by your platform team, its backup and restore tests, and its upgrade path |
| Parallel running and staff time | Running Bamboo and Woodpecker side by side during cut-over keeps both teams engaged, and the length depends on how many projects are in each wave | A cut-over schedule by project group, the roles involved, and the hours each role is expected to contribute |
How the move differs by team size and starting point
A small team with a handful of plans and one agent pool usually has the simplest path. The Bamboo estate is small enough to rewrite by hand, and the Woodpecker server, one or two agents and a database can often be stood up and tested in parallel with Bamboo before any cut-over decision. The main risks are forgotten plans and secrets rather than scale.
- Inventory first: List every plan, deployment project and trigger, including the ones nobody has touched in a long time.
- Single pool to single pool: One set of Woodpecker agents can replace the existing Bamboo agents if the workloads share tooling.
- Secrets re-entered: Bamboo encrypted variables cannot be read back, so each value has to be re-created from its owner.
- Small database: The default SQLite database is an option at this size, though PostgreSQL or MariaDB is recommended for larger instances.
- Deployment steps separate: Deployment projects need their own design, since Woodpecker workflows build and test code but do not replace Bamboo's environment-based release tracking on their own.
Before cut-over, confirm that every plan has a Woodpecker equivalent and that a named owner has tested each one.
A large estate with many shared plans, specialist agents and cross-team dependencies needs a migration plan that treats agents, shared tasks and permissions as the main work. Plans often share build configurations, and specialist agents may hold licenses, hardware or network access that a container runner does not provide by default. Consolidation can reduce duplicate plans, but each consolidation changes who depends on what.
- Agent capabilities mapped: Record which agents hold special tools, hardware, licenses or network paths, and decide whether each one becomes a container image, a labeled agent or a retained legacy runner.
- Shared logic reorganized: Bamboo shared tasks and plan templates need an equivalent reuse approach, such as shared steps or templated workflow files in the repository.
- Phased cut-over: Move low-risk projects first and keep high-risk release plans on Bamboo until the parallel run is clean.
- Access model redesigned: Bamboo project and plan permissions do not carry over, so reviewers must define who can edit workflows, view logs and read secrets.
- Forge scope confirmed: Woodpecker multi-forge support is described as experimental, so confirm the forge configuration for Bitbucket Datacenter with the vendor documentation before committing.
Confirm the number of agents with special requirements and the number of plans that depend on them before estimating effort.
A team that already builds and runs Docker images, or operates Kubernetes, starts with most of the infrastructure Woodpecker needs. Woodpecker runs every workflow step inside a container image, so the work shifts to writing images for build tools and to choosing the agent backend. Bamboo's agent-centric model becomes a question of which images and backend each project uses.
- Backend chosen: Agents can run workflows on Docker, Kubernetes or the local machine, so pick the backend that matches existing operations.
- Kubernetes pods per step: On Kubernetes each step runs in its own pod and a temporary persistent volume claim shares files between steps, so confirm the storage class supports the access mode.
- Images reused: Existing build images can often be referenced directly in steps, reducing rewrite work.
- Plugin review: Drone plugins generally work in Woodpecker but may need adjustments, so test each one.
- Autoscaling considered: The optional autoscaler creates cloud VMs for pending builds, which matters if Bamboo agents were always-on.
Check that the existing registry, cluster capacity and storage class meet the requirements in the Woodpecker documentation before the first test pipeline runs.
A team that runs builds on virtual machines without container tooling must add container infrastructure before the workflows can be written. That work is often larger than the pipeline rewrite itself. The team needs a container runtime on agent hosts, an image build and storage process, and network and credential rules that let steps pull images without exposing secrets.
- Runtime on agents: Install and harden a container runtime on each agent host, or choose the Kubernetes backend if the platform team already runs a cluster.
- Base images built: Create and version the images that replace Bamboo's installed build tools, and store them in a registry the agents can reach.
- Pipeline-level secrets: Plan how credentials reach containers, since workflow files should not hold secret values.
- Operations skills: Assign owners for agent patching, image rebuilds and backups of the Woodpecker database.
- Parallel test environment: Stand up a non-production Woodpecker server before deciding whether to add Kubernetes, because the first version can run on a simpler backend.
Ask the implementation partner or internal platform team to confirm the agent operating system, runtime, registry and storage choices in writing before the scope is fixed.
What usually goes wrong and how to prevent it
Most Bamboo to Woodpecker migrations fail in the handoff details rather than in the pipeline code itself. The cards below cover the failure points that repeat across these moves, from secrets and tooling to triggers, history and ownership, with a prevention step for each.
Secrets re-created with wrong values
Bamboo encrypted variables cannot be read back out, so teams re-enter them by hand from memory or from an old runbook. A single wrong character in a deploy key or registry token often fails only at the first production run. Prevention: rotate each credential at its source, store the new value in Woodpecker's secret store, and test every secret with a non-production deploy before cut-over.
Deployment steps assumed to map
Bamboo deployment projects run environment-scoped tasks, approvals and release versioning that have no one-to-one equivalent in a Woodpecker workflow. Teams often assume each deployment task becomes a step and discover missing promotion logic late. Prevention: list every deployment project task on paper, mark which ones are scripts, which are approvals and which depend on Bamboo's release model, and assign each one a named replacement before writing YAML.
Container images missing required tools
Each Woodpecker step runs inside the image you specify, so a build that relied on tools installed on a Bamboo agent may fail with a missing binary, certificate or SDK. Plugins may also need adjustments compared with their Drone versions. Prevention: inventory every command each job calls on the agent, pin an image for each step, and run the pipeline on a clean container before retiring the agent.
Silent differences in triggers
Bamboo branch plans, pull request builds and Bitbucket triggers do not always match Woodpecker's push, tag and pull request events, so a branch can stop building without any error. Path filters and when conditions also behave differently from Bamboo's branch settings. Prevention: write a trigger matrix that lists each Bamboo plan trigger beside its Woodpecker event and filter, then test a push, a tag and a pull request on a throwaway branch.
Lost build history
Bamboo build results, logs and artifacts stay in the old server's database and storage, and the migration does not carry them over automatically. Compliance teams often need that evidence for releases already shipped. Prevention: export logs, test reports and artifacts for the retention period your auditors require, store them in a system you control, and document where each archived record now lives.
Two servers without clear owners
Running Bamboo and Woodpecker in parallel invites duplicate builds, double deployments or a branch that nobody watches. Ownership gets fuzzy when a repository belongs to one team and its deploy job to another. Prevention: assign one named owner per repository and per deployment target, record the cut-over date in the repository, disable the Bamboo plan once its Woodpecker replacement is verified, and review the owner list at each cut-over stage.
Questions buyers ask before moving from Bamboo to Woodpecker CI
What drives the cost of moving from Bamboo to Woodpecker CI?
The cost is driven by how many plans, deployment projects and custom tasks you have, not by the Woodpecker license, which is Apache-2.0 and carries no per-agent fee. Costs fall into one-time work (inventory, rewriting plans as workflow files, rebuilding secrets, testing and cut-over) and recurring work (running the server, database, agents and upgrades). Ask any implementation partner for a written scope that lists each plan, each deployment project and each unsupported task type, because that list sets the effort. Compare the recurring infrastructure and staff time against your current Bamboo Data Center agent subscriptions and the Bitbucket Hybrid License path, which Atlassian says continues beyond its 2029 end of life.
How long does a Bamboo to Woodpecker CI migration take?
The duration depends on the number of plans, the complexity of the build steps, the deployment targets and how many teams must test their pipelines before cut-over. No duration is set by the supplied research, so ask for a timeline in the written scope rather than relying on a generic figure. A useful plan starts with an inventory of plans and deployment projects, moves a pilot set of repositories first, and runs both systems side by side until each pipeline has passed on real branches and tags. Ask the provider which milestones they will report on and what happens if a plan needs a custom container image.
What does the client team need to provide for the migration?
You will need named owners for each Bamboo project, access to the Bamboo configuration and Bitbucket Data Center repositories, and someone who can approve secret handling and production deployment changes. Woodpecker needs a server, a database, agents and a forge connection, so your platform team must be ready to host and secure those components. Engineers must review the converted workflow files because Woodpecker steps run in container images that must be chosen or built. Confirm these responsibilities in the written scope before work starts.
Can our team do the Bamboo to Woodpecker CI migration in-house?
Yes, a capable platform team can do the migration in-house, especially for a small number of plans with standard build steps. The work is mostly rewriting plan logic as YAML workflows, mapping Bamboo tasks to container images and plugins, and rebuilding secrets. Teams without recent Kubernetes or container experience, or with many deployment projects, often find the cut-over and hardening work takes longer than expected. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure on a fixed scope, so you can compare an in-house plan with a written quote.
Do our Bitbucket Data Center repositories have to move?
No. Woodpecker connects to Bitbucket Datacenter as a forge, so it can run builds for repositories that stay in place. Its forge documentation lists push, tag and pull request events for Bitbucket Datacenter. Connecting multiple forges to one Woodpecker server is still experimental, so if you plan to host other forges alongside Bitbucket, confirm that setup with the Woodpecker forge documentation before you commit to it.
How are Bamboo deployment projects handled in Woodpecker CI?
Woodpecker is a CI engine that runs workflows from repository YAML, so Bamboo deployment projects do not map one to one. Each deployment step needs an explicit workflow or step that runs a deployment command, usually with a container image and credentials supplied as secrets. Environment promotion, approvals and rollback must be designed deliberately, and a dedicated deployment tool such as Argo CD or Flux may fit better for Kubernetes targets. Ask for a written list of every deployment project, its targets and its approval rules before estimating the work.
What happens to Bamboo secrets and build history during the move?
Encrypted Bamboo variables and credentials usually cannot be read back out, so they must be re-created in Woodpecker from the original source systems, such as a secrets manager or a vault. Plan to rotate any credential that was shared widely, and keep the secrets store inside your own infrastructure. Build history and artifacts also need a plan. Hosted CI services keep artifacts for limited periods, but Bamboo's retention is set by your own server configuration, so confirm what you keep, where it is archived and who can read it before cut-over.
When is Woodpecker CI not the right fit for Bamboo users?
Woodpecker may not fit if you need a large catalog of mature plugins, a built-in release management suite, or a single platform that also covers repositories, issues and registries. Its plugins are container images, and the documentation notes that Drone plugins generally work but may need adjustments. Teams that want one platform for code and CI may prefer GitLab CI/CD, and teams with many complex pipelines and existing Jenkins expertise may prefer Jenkins. Compare the options against your own build inventory before you decide, and confirm each capability you depend on in its documentation.
How DeployOpen scopes and runs the Bamboo to Woodpecker migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a Bamboo to Woodpecker CI move, that means the Woodpecker server, its agents, the database and the forge connection to Bitbucket Data Center are deployed where your team already operates systems, and the build plans are rebuilt as container-based workflow files under your review. DeployOpen does not issue audit reports or certifications, and it does not claim any partner or reseller status with Atlassian or the Woodpecker project.
Most migrations are fixed-scope. Before work starts, DeployOpen and the client agree in writing on which Bamboo plans and deployment projects move, which Woodpecker version and backend (Docker or Kubernetes) are deployed, how the database and secrets are handled, which plugins replace unsupported Bamboo tasks, and the acceptance tests for each cut-over. The written scope also sets the deliverables and timelines. A quote follows from that scope, so the things that drive cost, such as the number of plans, the count of secrets to re-enter and the number of deployment targets, should be listed explicitly in the request. Ask for each of them to be itemized in the quote.
Retainers are available for ongoing support, Woodpecker and plugin upgrades and continuous testing after cut-over. Ask whether a retainer covers the Woodpecker server, agents and the forge integration, who handles security patches, and how upgrades are tested against your pipelines before they reach production. Before signing, confirm with DeployOpen and with your own change board who owns the Bitbucket webhook configuration, the agent credentials and the rotation of every secret that is re-entered during the move.
