What proves a Jenkins controller migration is complete before retiring the old one?
A replacement controller can load jobs and run a test pipeline while hidden dependencies still point at the old Jenkins home or URL. Agent launch configurations, credentials, shared libraries, webhooks, plugin data, build history, fingerprints, artifact links, scheduled jobs, queue state, script approvals, and external tools may not all move together. A quiet old controller can still be needed by a rare branch, timer, or recovery process.
A migration gate could compare the plugin catalog and versions, configuration-as-code output, credentials IDs, node labels, job and folder counts, global libraries, webhooks, timers, and the effective Jenkins URL. Representative pipelines should exercise checkout, credentials, artifacts, notifications, approvals, and every agent type. A fresh backup and restore on the new controller would test the recovery path before the old home becomes read-only and then offline.
What do you verify before deleting the old controller or its storage? How do you catch hard-coded URLs, jobs that run only monthly, plugins with state outside normal job configuration, and agents that reconnect to the old endpoint after a restart?