Jenkins in 2026: when to keep it and when to migrate

Every platform team we meet has an opinion about Jenkins and almost none of them have the numbers. The opinion is usually "we should move off it". The numbers usually say something more boring: the controller has not been upgraded in three years, half the jobs were configured by hand in the UI by people who left, and nobody knows which of the 400 jobs still matter.

That is not a Jenkins problem. That is what happens to any CI system nobody owns. The decision to keep or migrate should come after you know which one you have.

What Jenkins is still good at

Jenkins is a general-purpose job runner with 1,900 plugins that happens to be used for CI. That generality is the reason it survives in places where the hosted alternatives do not fit:

• Builds that need real machines. Long-running hardware-in-the-loop tests, builds against licensed toolchains pinned to a physical host, anything with a dongle or a lab network. Jenkins puts an agent there and does not care.
• Air-gapped or heavily regulated networks. No egress, no SaaS control plane, the whole system inside your perimeter with audit trails you own.
• Orchestration that is not really CI. Nightly data jobs, release trains, cross-repo choreography. Plenty of "Jenkins jobs" are cron with a UI and an audit log, and replacing them with a CI product is the wrong shape.

If your Jenkins is mostly doing one of those things, migrating buys you very little and costs you a quarter.

What it is bad at, honestly

• Cost per build minute when idle-heavy. A permanently-on controller plus a fleet of static agents that are busy 8 percent of the day is the most common CI waste we find. It is fixable (see below) but it is not the default.
• Configuration drift. Anything configured in the UI exists in exactly one place, on one disk, and is invisible to code review. This is the actual source of most "Jenkins is fragile" complaints.
• Plugin supply chain. The plugin ecosystem is Jenkins's superpower and its main security liability. Each plugin runs with controller privileges, and a controller with a hundred plugins has a hundred update paths that can break the boot.
• Developer experience. Nobody enjoys reading a 600-line Jenkinsfile that calls a shared library that shells into a Groovy script. Contributors avoid touching CI, which means CI stops improving.

The three-number test

Before deciding anything, get these:

Jobs actually run in the last 90 days. From the controller:

// Manage Jenkins > Script Console
Jenkins.instance.getAllItems(Job.class).each { j ->
  def b = j.getLastBuild()
  println "${j.fullName}\t${b ? b.getTime() : 'never'}\t${j.builds.size()}"
}

The typical answer is that 20 to 30 percent of jobs have run this quarter. Everything else is inventory, not workload, and does not count toward migration cost.

Agent utilisation. Busy executor-minutes divided by provisioned executor-minutes. Under 15 percent means you are paying for idle machines and the fastest win is ephemeral agents, not a migration.

Time from commit to deployable artefact, p50 and p95. If p95 is more than three times p50, your problem is queueing or flaky tests, and neither one is solved by changing CI vendor.

The decision

Keep Jenkins, and invest in it, if: the active job count is under a few hundred, most of it is already in Jenkinsfiles in repos, and you have at least one person who will own the controller. The investment is configuration as code, ephemeral agents and shared libraries — roughly two to four weeks of work that makes the next five years cheap.

Migrate if: your builds are ordinary container builds on Linux, your source is already on GitHub or GitLab, and the controller has become a single point of failure nobody wants to touch. The destination is usually GitHub Actions or GitLab CI, and the honest cost is one engineer for six to ten weeks for a mid-size estate, most of it spent on secrets, credentials and the twenty jobs that do something strange.

Do both if the estate is split: migrate the ordinary container builds, and leave a small Jenkins for the hardware and the nightly orchestration. A two-system CI estate is not a failure state if the boundary is explicit and each side is owned.

Do not migrate to escape a problem you are taking with you

The failure mode we see most: a team migrates from Jenkins to Actions to fix a 45-minute build, and ends up with a 45-minute build on different infrastructure, plus a quarter of migration work and a new bill. The build was slow because the test suite has no parallelism and no caching, and that travelled.

Fix pipeline duration where it lives now, on the system you already have. If the result is fast, the migration case gets weaker and the migration itself gets much easier. If it is still slow, at least you know the cause is not the CI engine.