Introduction

A registry migration can stand up a new Harbor destination while replication jobs still push images to the old one. Manual pulls and pushes may work against the new platform, but scheduled replication continues sending artifacts to the retired registry, one project rule uses the new endpoint while another still follows the previous target, or failures begin only after the old registry or robot account is removed because replication endpoints, credentials, and project-level policies often change separately.

Treat this as a replication-target problem instead of a generic Harbor outage. Start by checking which destination endpoint an affected replication rule actually uses, because migrations often validate direct registry access first while automated replication jobs continue following older endpoint mappings.

Symptoms

  • Harbor replication still pushes images to the old registry after migration
  • The new registry is healthy, but replicated artifacts still land on the retired destination
  • One project or replication rule uses the new registry while another still uses the previous one
  • Replication failures begin only after the old registry, robot account, or certificate is removed
  • The new Harbor environment exists, but migrated replication jobs never target it consistently
  • The issue started after moving Harbor instances, registry endpoints, replication policies, or credential management

Common Causes

  • The replication endpoint still references the old Harbor or external registry URL
  • A robot account or credential entry was rotated, but the replication destination itself was not updated
  • Project-level replication rules or filters were recreated on one project but not another
  • A configuration export, Terraform run, or bootstrap process restored the earlier endpoint mapping
  • One replication policy was updated while another still points to the retired registry
  • Validation confirmed the new registry accepted manual pushes but did not verify where scheduled replication actually sent artifacts

Step-by-Step Fix

  1. Capture one affected replication job and record the source project, destination endpoint, credential object, and rule or policy it actually uses, because the live replication path determines where images really land.
  2. Compare that active replication path with the intended post-migration registry design, because one stale destination mapping can keep artifact flows tied to the retired registry.
  3. Review Harbor replication endpoints, robot credentials, project rules, filters, and automation templates for references to the old registry, because Harbor replication depends on both endpoint objects and policy-level routing.
  4. Check each project, replication rule, and schedule separately if behavior differs, because migrations often update one image path while another still targets the previous destination.
  5. Update the authoritative destination endpoint and replication policy so affected jobs use the intended registry, because creating the new Harbor environment alone does not retarget existing replication tasks.
  6. Trigger a controlled replication run and confirm the intended destination registry receives the artifact, because successful manual registry access does not prove the right automated target handled replication.
  7. Verify the old registry no longer receives replicated images from migrated Harbor jobs, because split artifact paths can remain hidden while both endpoints stay reachable.
  8. Review robot permissions, TLS trust, project naming, and retention interactions if replication still fails, because the destination can be correct while authorization or artifact policy still blocks the new path.
  9. Document which team owns replication endpoints, credentials, and migration validation so future Harbor cutovers verify the actual runtime destination before retiring the previous registry.