Introduction

A CI migration can move repositories to a new Git host while Jenkins agents still check out code from the old remote. Builds continue running, but they pull stale content, one pipeline checks out from the new platform while another still clones the previous URL, or failures begin only after the old Git host is restricted because job SCM settings, shared libraries, and cached workspaces often drift separately.

Treat this as an SCM source-selection problem instead of a generic Jenkins outage. Start by checking which repository URL an affected build actually fetches on the agent, because migrations often validate the new Git platform in Jenkins admin settings while live jobs continue following older pipeline or job-level checkout definitions.

Symptoms

  • A Jenkins agent still checks out code from the old Git remote after migration
  • Builds run, but they pull stale branches, tags, or repository content
  • One job or multibranch pipeline uses the new Git host while another still uses the previous one
  • Checkout failures begin only after the old Git host, token, or SSH trust is removed
  • The new repository is healthy, but migrated jobs never fetch from it
  • The issue started after moving Git hosting, Jenkins controllers, or pipeline libraries

Common Causes

  • The job or multibranch pipeline still stores the old SCM URL
  • A Jenkinsfile, shared library, or scripted checkout step still references the previous Git remote
  • Cached workspaces or local .git/config state on the agent preserve the earlier origin URL
  • Credentials were rotated for the new Git host, but the actual repository target was not changed consistently
  • Folder-level defaults, organization scans, or seed jobs keep recreating jobs with the retired remote
  • Validation confirmed the new repository was reachable but did not verify which remote live agent checkouts actually used

Step-by-Step Fix

  1. Capture one affected build and record the job type, checkout step, remote URL, branch source, and agent workspace it actually uses, because the live SCM path determines where build input really comes from.
  2. Compare that active checkout path with the intended post-migration CI design, because one stale checkout definition can keep repeated builds tied to the retired Git host.
  3. Review job SCM settings, multibranch source config, Jenkinsfiles, shared libraries, seed jobs, and agent workspace state for references to the old remote, because Jenkins checkout behavior can come from both controller-managed config and repo-defined pipeline logic.
  4. Check each branch source, shared library, and agent label separately if behavior differs, because migrations often update one pipeline path while another still checks out from the previous host.
  5. Update the authoritative SCM definition and clear stale workspace remote state where needed so affected builds fetch from the intended Git host, because adding the new credentials alone does not retarget existing jobs.
  6. Run a controlled build and confirm the agent fetches from the intended remote URL and branch source, because a successful checkout does not prove the right repository supplied the code.
  7. Verify the old Git host no longer receives clone, fetch, or library traffic from migrated jobs, because split CI paths can stay hidden while both platforms remain reachable.
  8. Review credentials, host key trust, webhook indexing, and branch discovery if checkout still fails, because the destination can be correct while access or source discovery still blocks the new path.
  9. Document which team owns job templates, shared libraries, and migration validation so future Git platform cutovers verify the actual runtime checkout source before retiring the previous remote.