How We Moved 200 Services off Jenkins in About 3 Months

I owned the least glamorous part of platform engineering: keeping an aging Jenkins estate alive while the rest of the company added more services every quarter. By the time we started this migration, we had around 200 repositories, a Jenkins controller, and a few dozen EC2-backed workers glued together with plugins, shared libraries, and a lot of institutional memory. Average build time hovered around 18 minutes, but the real complaint was queue time whenever a few teams tried to release at once.

The migration got approved after a plugin update broke the controller and we lost most of a workday coaxing Jenkins back to life. We did not build a magical Jenkins-to-Actions compiler. We wrote a converter for the three Jenkinsfile patterns most teams had copied from shared libraries, and that got about 70% of repositories most of the way there. Everything else was manual: secrets cleanup, Docker layer caching, self-hosted runners for jobs that needed VPC access, and a long tail of weird assumptions buried in old Groovy helpers.

We finished the risky part in about 11 weeks and spent the last week cleaning up stragglers and shutting the old fleet down. Median build time ended up just under 10 minutes, queueing was dramatically lower, and CI spend fell because the new runner fleet scaled down at night instead of idling all day. The best outcome was not the dashboard metric. It was getting two platform engineers back from "Jenkins janitor" duty so they could work on deployment safety and developer tooling instead.