Moving Off Self-Hosted Jenkins: CloudBees CI or GitLab CI/CD?
This page is for teams weighing whether to keep running Jenkins themselves, buy support for it, or replace it. It covers what self-hosted Jenkins genuinely costs in maintenance terms, what each destination involves, and what typically breaks.
The short answer: there are two realistic destinations and they are very different projects. CloudBees CI is an upgrade in place — your Jenkinsfiles and shared libraries come with you, and the work is plugin reconciliation. GitLab CI/CD is a rewrite — and the single largest item is Groovy shared libraries, which have no equivalent and which GitLab’s own migration documentation does not address at all.
What does running Jenkins yourself actually cost?
Not the licence — that is genuinely $0. The cost is the maintenance treadmill, and it is measurable.
The patch cadence
| Measure | Reality |
|---|---|
| Security advisories in 2025 | 11 |
| Security advisories in 2026 (to mid-September) | 9 |
| Typical advisory size | 10–20 plugins; one September 2026 advisory covered Jenkins core plus 18 plugins, 31 distinct CVEs |
| LTS baseline change | Every 12 weeks |
| LTS patch releases | Three per cycle, at four-week intervals |
| Plugins in the ecosystem | 2,000+ |
| Plugins currently suspended with unresolved vulnerabilities | ~45, plus ~13 dependent plugins |
So a multi-controller Jenkins estate faces a multi-plugin patch event roughly monthly. Each one requires triaging which of your installed plugins are affected, assessing regression risk, and coordinating an upgrade window across every controller.
The structural problem in one line: the Jenkins project’s own policy is that when a plugin maintainer declines to fix an issue or does not respond, the project publishes an advisory noting that there is no fix, and may suspend distribution. That is not hypothetical — a September 2026 advisory shipped with one plugin having no fix available at publication. On community Jenkins, you can be told you are vulnerable and given nothing to install.
We will not quote you a Jenkins TCO figure. Every “Jenkins really costs $X” headline we could find traces back to vendor content marketing with undisclosed methodology. The honest approach is to model it from your own inputs: headcount on CI platform work multiplied by loaded cost, plus the patch cadence above, plus your own incident exposure. We would rather build that with you than borrow someone else’s number.
Option 1: CloudBees CI — keep Jenkins, get it supported
This is an upgrade in place rather than a rewrite. Jenkinsfiles, shared libraries and job definitions carry over. What you are buying:
- Contracted CVE backports. CloudBees commits to including fixes for critical security issues in each monthly release even if they are not yet in the community Jenkins release. Against the “no fix available” problem above, this is the strongest single differentiator.
- Active/active high availability — multiple controller replicas behind a load balancer with shared storage, rolling restarts with zero downtime. Genuinely hard to self-build.
- Operations Center for central management of many controllers, which open-source Jenkins has no equivalent of.
- Configuration-as-Code bundles distributed fleet-wide, rather than per-controller JCasC.
- Air-gapped support via proxy artifact repositories and plugin catalogs — for regulated and defence buyers, often the whole reason for the contract.
- A support SLA — up to 30-minute P1 response with 24/7 coverage on the top tier.
What breaks
Plugin envelope reconciliation is where this bites. CloudBees classifies plugins as verified, trusted or untrusted and enforces an envelope; only Tier I and Tier II plugins are supported. Every plugin in your estate that falls outside must be replaced, justified, or accepted as unsupported. A long tail of niche plugins is the main source of unplanned work, and it is the thing to inventory before you commit to a date.
Also: pipelines relying on controller-local filesystem state become a problem under active/active, and plugin version pinning can conflict with the envelope. Note too that the CloudBees CI trial is seven days — not a realistic window for evaluating a controller migration, so do the preparation before starting the clock.
Option 2: GitLab CI/CD — replace Jenkins entirely
GitLab documents a six-phase approach: pipeline assessment and inventory, parallel migration of individual pipelines, running both systems side by side for verification, continuous validation, making GitLab CI the standard, then phasing Jenkins out. Three strategies are offered — new projects only, strategic projects first, or comprehensive migration, still recommended iteratively.
What maps cleanly
| Jenkins | GitLab CI |
|---|---|
| Jenkinsfile (Groovy) | .gitlab-ci.yml (YAML) |
| stages | stages |
| steps | script |
| agents | runners |
environment block | variables |
archiveArtifacts | artifacts |
Several common plugin dependencies disappear entirely because the capability is native: SCM, container registry, and security scanning templates. Native replacements exist for JUnit, Cobertura and Build Timeout among others.
What does not map
Groovy shared libraries are the single largest rewrite item, and GitLab’s migration documentation does not address them at all. There is no equivalent construct. The closest patterns — include:, CI/CD components, reusable templates — are all declarative and cannot express arbitrary Groovy logic. If your answer to “how many lines of shared library do you have?” is “thousands, across dozens of libraries,” that fact alone may decide this for you.
Also without a direct equivalent: the parameters directive (reconstructed with CI/CD variables), the tools directive (GitLab’s guidance is prebuilt container images instead, which changes your build-environment management model entirely), and any plugin-dependent step whose behaviour lives in the plugin rather than in your script. Imperative, stateful, conditional Groovy does not translate to declarative YAML without redesign.
The tooling has genuinely improved
GitLab Duo’s “Convert to GitLab CI/CD” flow is official, current and Jenkins-specific. It analyses the existing pipeline, converts the syntax, opens a merge request with the converted config, and offers guidance on migrating Jenkins plugins to GitLab features. It covers stages, steps, variables, triggers, artifacts, parallel execution, conditionals and post-build actions.
It is available on Free, Premium and Ultimate, across GitLab.com, Self-Managed and Dedicated. Limitations: UI only with no API, and it requires Developer role or higher.
This materially changes the migration economics compared with even eighteen months ago. Pilot it on five to ten representative Jenkinsfiles before estimating the project — it is the cheapest way to de-risk the estimate, and it costs nothing to try.
The JenkinsFile Wrapper is also worth knowing about: it runs a Jenkins instance inside a GitLab CI job, enabling a gradual strangler transition rather than a cutover.
What does each option cost?
| Option | Licence cost | Counting unit |
|---|---|---|
| Self-hosted Jenkins | $0 | — |
| CloudBees CI, self-managed | Quote only — anchor around $100/user/month | Named users, including anyone who commits to an SCM that triggers a job |
| CloudBees Unify Team | $30/user/month | Monthly active users, 25-user cap |
| GitLab Premium | $29/user/month annual | Billable seats |
| GitLab Ultimate | Custom — contact sales | Billable seats; Guest users free |
Model both against the same licensable population, not the same nominal rate. CloudBees CI at roughly $100 per user per month is about 3.4× GitLab Premium on paper. But CloudBees counts committers — anyone whose commits trigger a job, whether or not they ever open Jenkins — while GitLab counts seats. On an organisation with 400 committers and 30 Jenkins users, the effective gap is far wider than 3.4×. Contact us and we will establish the real numbers on both sides before you take a quote.
The questions that actually decide it
What happens to our Groovy shared libraries?
On a GitLab move, they get rewritten — there is no equivalent construct and GitLab’s docs are silent on them. If you have a large shared library estate, CloudBees CI becomes much more attractive on effort alone. Run this inventory first; it is the highest-information question on the list.
How many of our plugins have no equivalent, and how many are already unsupported?
Both destinations force this audit — GitLab because plugins must be replaced with native features, CloudBees because the assurance programme will reject untrusted plugins. Cross-check your installed list against the ~45 currently suspended plugins while you are at it; you may find you have a live problem regardless of which way you go.
Who exactly counts as a licensed user on CloudBees?
Every SCM committer whose commits trigger jobs, whether or not they log in. This question alone routinely changes a CloudBees quote by an order of magnitude, and it is better established before the quote than after.
Do we actually need high availability?
Active/active Jenkins is genuinely hard to self-build, so if HA is a hard requirement CloudBees CI has a strong case. If it is a nice-to-have, it is the most over-bought capability in this category.
Is the support SLA response or resolution?
CloudBees publishes response targets — 30 minutes for P1 on the top tier. We found no published resolution-time or uptime SLA for self-managed CloudBees CI. Ask for both explicitly.
Are we air-gapped, or heading that way?
If yes, this collapses the shortlist quickly. CloudBees has documented, supported air-gap mechanisms.
Can we migrate incrementally?
Both support it — GitLab’s six-phase parallel-run model and the JenkinsFile Wrapper, or CloudBees’ in-place upgrade. Big-bang migrations of mature Jenkins estates have no published success benchmark, which should tell you something.
What is our exit cost from the destination?
Leaving CloudBees means reverting to Jenkins LTS and losing Operations Center, CasC and HA. Leaving GitLab means your pipelines are GitLab-YAML-shaped. Worth asking before signing rather than at renewal.
Advisory counts, LTS cadence and plugin figures verified 19 September 2026 against the Jenkins project’s published security advisories, plugin policy and LTS documentation; these change continuously and should be re-checked at point of use. CloudBees CI pricing is quote-only. Neither CloudBees nor GitLab publishes migration effort estimates or timeline benchmarks.
Start with the inventory, not the quote
Plugin estate, shared library footprint, real committer count, and whether HA is a genuine requirement — those four answers decide this, and all of them can be established before you talk to a vendor. We run that assessment, then deliver whichever migration the answers point to.
Speak With An Expert