Introduction

A backup migration can add the new Veeam proxy to the environment while jobs still process through the old one. Backups technically keep running, but data movers stay on the retired host, one job uses the new proxy while another still uses the previous path, or performance and failures change only after the old proxy is removed because proxy assignment, transport mode selection, and job targeting policy often remain pinned to the earlier infrastructure.

Treat this as a backup-path problem instead of a generic Veeam failure. Start by checking which proxy, transport mode, and repository path an affected job actually uses during a live run, because migrations often validate that the new proxy is available while production jobs still prefer the older processing path.

Symptoms

  • Veeam jobs still use the old backup proxy after migration
  • Backup sessions continue on the retired proxy host even though the new one is available
  • One job or job chain uses the new proxy while another still uses the old one
  • Backup failures begin only after the previous proxy is disabled
  • Repositories look healthy, but processing still depends on the old data mover path
  • The issue started after moving Veeam proxies, repositories, or backup infrastructure

Common Causes

  • Jobs still have explicit proxy assignment to the old backup proxy
  • Automatic proxy selection still prefers the previous host because of transport mode or resource settings
  • Backup copy jobs, SOBR components, or repositories were updated separately from primary jobs
  • Veeam components were migrated, but managed servers or mount hosts still reference the old proxy
  • Automation or configuration replication keeps restoring the retired proxy assignment
  • Validation confirmed the new proxy was online but did not verify which proxy live jobs actually selected

Step-by-Step Fix

  1. Capture one affected Veeam job run and record the proxy, transport mode, repository, and data mover path it actually uses, because the runtime processing path determines where backup workload really runs.
  2. Compare that active Veeam path with the intended post-migration backup design, because one stale proxy assignment can keep many jobs tied to the retired host.
  3. Review job settings, proxy selection rules, transport modes, repositories, managed servers, and backup copy chains for references to the old proxy, because Veeam job execution depends on proxy, storage, and transport choices together.
  4. Check primary backup jobs, backup copy jobs, and different workload types separately if behavior differs, because migrations often fix one processing path while another still uses the previous proxy.
  5. Update the authoritative Veeam configuration so affected jobs process through the intended proxy set, because adding the new proxy to inventory alone does not retarget existing jobs.
  6. Run a controlled backup job and confirm the intended proxy handles processing, throughput, and repository traffic, because a successful backup result does not prove the right proxy executed it.
  7. Verify the old proxy no longer receives job sessions, mount activity, or transport selection from migrated workloads, because split backup paths can remain hidden while both proxies stay registered.
  8. Review credentials, transport mode support, and repository connectivity if jobs still fail, because the destination can be correct while data mover access or mode selection still blocks the new path.
  9. Document which team owns proxy assignment, repository design, and migration validation so future Veeam cutovers verify the actual runtime proxy before retiring the previous host.