Migrate from CloudBees CI to open-source Jenkins

This pattern moves one controller at a time. Each controller is rebuilt on open-source Jenkins, its jobs and Jenkinsfiles are verified, and only then is it switched over while the other controllers keep running on CloudBees CI. The Jenkins scaling guide describes a primary and backup controller arrangement in which a proxy such as HAProxy or F5 routes traffic to the backup if the primary fails, and the same routing layer can point a single team's hostname at the new controller during a cutover window.

• Parallel running: CloudBees CI and open-source controllers run side by side until every controller has passed verification.
• Rollback: Keep the CloudBees CI controller and its $JENKINS_HOME intact until the new controller has run real builds, then point the proxy back if needed.
• Downtime: Only the controller being moved is unavailable during its window, and you can schedule each window around release calendars.
• Routing: Use HAProxy or F5 to switch traffic per controller, and confirm that webhooks from your forge follow the switch.
• Cost driver: Each controller you run in parallel adds infrastructure and license time until retirement.

Before each switch, confirm with your CloudBees account team the exact end date of the license for that controller and check that its plugins have open-source equivalents.

This pattern moves groups of jobs by owning team, often when each team already has its own folders or controller. Teams migrate on their own schedule, so the platform team runs a shared CloudBees CI footprint for the remaining teams while others move. It suits organizations where teams differ in plugin use, compliance scope or release risk. Authorization is the main hard part, because role-based access that CloudBees CI enforces centrally must be rebuilt with Configuration as Code and open-source authorization plugins for each migrated team.

• Parallel running: Two platforms serve different teams for an extended period, which means two sets of administrators, plugin updates and backups.
• Rollback: A team can return to its CloudBees CI jobs if its open-source controller fails acceptance, as long as the old jobs remain configured.
• Downtime: Each team accepts downtime only for its own jobs, so cutovers can avoid peak delivery periods.
• Access model: Map each team's roles and folder permissions before its move, and test that a user cannot reach another team's credentials.
• Governance gap: Shared pipeline libraries and cross-team deployments need a clear owner during the mixed period.

Confirm which controllers or folders each team owns and whether any job reads credentials from a store that will not move with it.

A big-bang cutover moves every controller, plugin set and job in one planned window and then turns CloudBees CI off. It shortens the period of duplicate cost and administration, but it concentrates risk. Because CI secrets cannot be exported from most hosted or vendor platforms, and because the Jenkins $JENKINS_HOME on each controller holds configuration, plugins and secrets, the team must re-enter or re-source credentials during the window. This pattern is generally suited to small estates with few plugins and strong test coverage of Jenkinsfiles.

• Parallel running: Usually limited to a short rehearsal and validation period before the window, rather than an extended overlap.
• Rollback: Requires that the CloudBees CI installation and its backups stay restorable until the new platform has proven stable, so plan the retention period in advance.
• Downtime: All CI stops during the window, so release freezes and dependent deployment pipelines must be coordinated across teams.
• Credentials: Re-create every secret in the new platform's store, since values in CloudBees CI cannot simply be copied out.
• Risk concentration: One failed plugin or access rule can block all teams at once, so rehearse the full cutover against a copy of production configuration.

Ask your implementation partner for a written rollback runbook and confirm the date your CloudBees CI license ends before you choose this pattern.

A single controller is the simplest starting point. Most of the work is a one-time inventory of what the controller does, followed by a rebuild of its configuration on open-source Jenkins in a test environment. Because only one controller holds jobs, credentials and plugins, cutover can be planned as a single window, and the existing Jenkinsfiles usually move without structural change.

• Plugin inventory: List every installed plugin and flag any that exist only in the CloudBees distribution or depend on CloudBees-licensed features. Confirm each remaining plugin is available from the community update center.
• Configuration export: Everything to recreate lives in $JENKINS_HOME on the controller, so capture jobs, credentials references, system settings and plugin configuration as code where possible, using the Configuration as Code plugin with a jenkins.yaml file.
• Agent rebuild: Recreate build agents on open-source Jenkins, for example with the Kubernetes plugin, and test them against the same toolchain images.
• Secrets re-entry: Stored credential values cannot be read back out of the controller, so plan to re-enter them from your secrets manager or source system during the test build.
• Cutover and rollback: Run a parallel build of representative jobs on the new controller before switching webhooks, and keep the CloudBees controller available until the rollback window closes.

Before cutover, confirm that every Jenkinsfile produces the same artifacts and test results on the new controller.

A small fleet of several controllers that teams configure by hand is harder than a single controller because each one has drifted in its own way. The inventory must be repeated per controller, and the differences between them, such as installed plugin versions, folder structures and credential scopes, decide how many migration targets you need. Consolidation into fewer controllers is possible, but it is a separate decision from the license exit.

• Drift comparison: Compare plugin lists, plugin versions and system settings across controllers to find where configurations differ without a documented reason.
• Target shape decision: Choose whether each existing controller maps to one open-source controller, or whether teams share fewer controllers. Mapping one to one keeps the change smaller.
• Repeatable build: Move controller setup into a single Configuration as Code file or Helm-based deployment so each new controller starts from the same definition.
• Credential ownership: Identify which controllers share credentials, because open-source Jenkins does not provide the operations center's central credential store.
• Staged rollout: Migrate the least critical controller first, record what broke, and fix the shared template before the next move.

Ask your team to document which controller owns which jobs, since that map drives the cutover order.

A large federated estate managed through the CloudBees operations center is the most involved case. Controllers, shared templates, role-based access rules and centrally managed plugin sets are all tied to the operations center, so removing it means rebuilding each of those functions. The work is less about moving jobs and more about replacing the governance layer that sat above them, and the governance gaps need an explicit owner before cutover.

• Governance inventory: Export the role assignments, folder permissions and any policies enforced centrally, then decide which open-source authorization approach will replace each one.
• Shared configuration: Replace centrally pushed configuration with shared Configuration as Code sources and version-controlled templates, and test them across a sample of controllers.
• Dependency mapping: Identify jobs that call other controllers, shared libraries or artifacts that depend on operations-center features, because those links break first.
• Phased waves: Group controllers into migration waves by team or risk, with a go or no-go review before each wave.
• Audit evidence: Keep records of who approved each change and how access was reviewed, since those records were partly produced by the operations center.

For illustrative planning, a team that runs dozens of controllers would usually sequence the work across several waves, but confirm your own count and dependencies before setting any schedule.