Introduction

A CI migration can bring a new artifact backend online while build runners still upload job artifacts to the old storage location. Pipelines may finish with warnings, artifact downloads fail later, or retention and release steps behave unpredictably because the runner configuration still targets the previous bucket, object store, or artifact service.

Treat this as a pipeline-storage problem instead of a generic CI outage. Start by checking where the active runner actually uploads artifacts and caches, because migration work often updates the platform UI and credentials first while worker nodes continue using the old backend configuration.

Symptoms

  • CI jobs complete, but artifacts are missing from the new platform after migration
  • The old storage backend still receives fresh uploads from runners
  • Artifact download, retention, or release steps fail after the cutover
  • One runner pool works correctly while another still uploads to the previous backend
  • Cache and artifact behavior differ between local, shared, and autoscaled runners
  • The issue started after moving CI storage, object buckets, or artifact services

Common Causes

  • Runner configuration still points to the old artifact service, bucket, or cache backend
  • Pipeline variables still contain the previous storage URL, bucket name, or credentials
  • One runner group or autoscaling template was updated while another still uses the retired backend
  • Artifact settings and cache settings were migrated separately, leaving one path behind
  • Pre-signed upload URLs, reverse proxies, or DNS aliases still route uploads to the old storage service
  • Validation confirmed the new backend existed but did not check the live runner upload target

Step-by-Step Fix

  1. Capture one job from an affected runner and record the exact storage endpoint, bucket, or artifact service it uses during upload, because the live runner path matters more than the intended migration target.
  2. Compare that active destination with the intended post-migration storage backend, because one stale runner setting can keep every artifact tied to the retired system.
  3. Review runner configuration files, autoscaling templates, pipeline variables, and secret values for references to the old storage location, because CI storage settings often live outside the pipeline definition itself.
  4. Check cache and artifact configuration separately if one works and the other does not, because CI migrations commonly move release artifacts while leaving cache uploads behind on the old backend.
  5. Update the authoritative runner or platform configuration and restart or recycle the affected runners, because build workers keep using the old upload path until their runtime config changes.
  6. Re-run the same pipeline and confirm artifacts appear in the intended backend and remain downloadable, because a successful build alone does not prove storage migrated correctly.
  7. Verify the old storage backend no longer receives new uploads from the runner fleet, because mixed artifact destinations can hide partial migration drift.
  8. Review release jobs, deployment jobs, and retention policies if they rely on the same artifact path, because secondary automation often breaks after artifact storage moves.
  9. Document which team owns runner storage configuration, cache routing, and migration validation, because CI backends often span platform, DevOps, and application ownership boundaries.