Before migrating off Jenkins or any legacy CI, inventory five things: jobs and who owns them, plugins and what each does, credentials and where each is used, agents and what runs on them, and shared libraries with their trust level. Skipping any of these is how secrets and duties get lost in the move.
The five lists
| List | What to capture | Why it matters |
|---|---|---|
| Jobs | Name, owner, trigger, last run, what it deploys | Dead jobs need not move |
| Plugins | Name, version, which jobs need it | Each one needs an equivalent or a decision to drop |
| Credentials | ID, type, scope, which jobs use it, age | Secrets should be rotated, not copied |
| Agents | Operating system, tools, labels, user, network access | Defines the runner images you need |
| Shared libraries | Repository, trusted or untrusted, pinned version | Trusted code runs outside the sandbox |
Steps
- Export what Jenkins knows. Use the plugin list, the credentials page and the job list.
- Find the owners. A job with no owner is a candidate for deletion, not migration.
- Mark risk. Highlight global credentials, trusted libraries and jobs that run on the built-in node.
- Decide per item. Move, rewrite, replace or retire.
- Rotate instead of copy. Create new secrets in the target system and revoke the old ones afterward. The Jenkins docs advise changing the underlying credentials frequently anyway.
- Run in parallel. Keep the old pipeline running while the new one builds the same commits, and compare outputs.
- Cut over per project. Retire the old job only after the new one has passed for a set period.
- Decommission the controller. Back up what you need, store the key separately, and remove access.
Hidden duties to look for
- Jobs that also publish artifacts, send notices or update tickets.
- Scheduled jobs that someone relies on without knowing.
- Approvals recorded in script approval that allowed unusual methods.
- Plugins that enforce rules, such as authorization or job restrictions.
- Build logs that serve as audit records. Decide how long to keep them and where.
Do not forget the end state
A migration is a chance to improve, not just to copy. Prefer short lived runners, narrowly scoped secrets and a review gate for pipeline changes. For a related look at one target, see migrating from Jenkins to GitHub Actions.
Try it yourself
The demo shows a dependency inventory, a model for the list you need before any move.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard does asset discovery, SBOM and dependency scanning, and policy gates on pull requests, which can help confirm the new pipeline checks what the old one did. Try the free scan.
Quick check
Should I copy credentials to the new system?
Prefer creating new secrets and revoking the old ones. Copying carries any earlier exposure with it.
Do all jobs need to migrate?
No. Jobs with no owner and no recent runs are better retired.
Sources
Last reviewed: 19 October 2026.
