Introduction

A source control migration can move the main Git repository to the new platform while Git LFS clients still upload large objects to the old storage endpoint. Normal git push works, but binary assets fail, uploads succeed in one developer environment and not another, or CI pipelines keep using the retired LFS server because the LFS API endpoint, credential helper, and remote configuration can drift independently from the Git remote itself.

Treat this as an LFS-endpoint problem instead of a generic Git failure. Start by checking which LFS URL an affected client actually uses for batch, upload, and download operations, because migrations often validate the main repository URL while existing clones continue following older LFS metadata or local overrides.

Symptoms

  • Git LFS uploads still go to the old storage endpoint after migration
  • Standard Git operations work, but large file push or pull fails
  • Developers on one machine use the new LFS backend while others still use the old one
  • CI runners continue uploading LFS objects to the retired platform
  • Failures begin only after the old LFS endpoint is disabled
  • The issue started after moving Git hosting, artifact storage, or repository backends

Common Causes

  • Repository-level LFS configuration still advertises the old endpoint
  • Local .lfsconfig, global Git config, or credential helpers override the new URL
  • CI secrets, service connections, or build images still contain the previous LFS target
  • Remote origin was updated, but LFS batch API URLs still resolve to the retired host
  • One fork, mirror, or repository namespace was migrated while another still publishes old LFS metadata
  • Validation confirmed Git pushes to the new platform but did not verify the LFS upload endpoint used by real clients

Step-by-Step Fix

  1. Capture one affected clone or CI runner and record the exact LFS endpoint used during a batch or upload operation, because the live LFS URL determines where large objects actually go.
  2. Compare that active endpoint with the intended post-migration repository design, because one stale .lfsconfig or server-side LFS advertisement can keep developers tied to the retired backend.
  3. Review repository remotes, .lfsconfig, global Git settings, credential helpers, and CI variables for references to the old LFS host, because large-file routing often spans local config and server metadata together.
  4. Check developer workstations, build agents, and long-lived clones separately if behavior differs, because migrations often fix new clones while existing environments keep older LFS settings.
  5. Update the authoritative repository and client configuration so affected users and pipelines discover the intended LFS API endpoint, because changing origin alone does not retarget Git LFS traffic.
  6. Push or fetch a controlled LFS object and confirm the intended storage backend handles the request, because a successful normal Git push does not prove large-file traffic switched too.
  7. Verify the old LFS endpoint no longer receives uploads or downloads from migrated clients, because mixed LFS routing can remain hidden until the retired storage is removed.
  8. Review authentication scopes, pre-signed upload URLs, and proxy rules if uploads still fail after retargeting, because the endpoint can be correct while transport or authorization still points to old infrastructure.
  9. Document which team owns repository migration, LFS configuration, and CI image updates so future source control cutovers verify the real large-file endpoint before retiring the previous backend.