Introduction

A database migration can bring the new SQL Server secondary online while log shipping still backs up, copies, or restores toward the old one. The new server looks healthy in planning documents, one database ships correctly while another still uses the previous secondary, or failover preparation breaks only after the retired secondary is removed because SQL Agent jobs, monitor metadata, and backup copy paths often survive the cutover.

Treat this as a replication-target problem instead of a generic SQL availability issue. Start by checking which secondary host, backup share, and monitor server an affected database actually uses in the live log shipping chain, because migrations often validate the replacement SQL instance itself while production jobs still reference the older destination.

Symptoms

  • SQL Server log shipping still targets the old secondary after migration
  • Backup, copy, or restore jobs continue referencing the retired secondary or share
  • One database or instance ships correctly while another still uses the old destination
  • Log shipping fails only after the previous secondary or copy share is shut down
  • Monitoring still reports status from the old topology instead of the new one
  • The issue started after moving SQL replicas, backup shares, or DR infrastructure

Common Causes

  • Primary-side backup or copy jobs still reference the old secondary host or UNC path
  • Monitor server metadata still points alerting and status checks at the previous topology
  • Secondary restore jobs were updated on one database set but not another
  • SQL Agent job scripts or automation templates keep recreating the old configuration
  • DNS aliases, backup shares, or credentials still resolve to the old secondary environment
  • Validation confirmed the new secondary could receive logs but did not verify where production jobs actually copied and restored them

Step-by-Step Fix

  1. Capture one affected database and record the primary backup job, copy destination, restore target, and monitor server it actually uses, because the live job chain determines where transaction logs really flow.
  2. Compare that active log shipping path with the intended post-migration SQL design, because one stale SQL Agent job can keep important databases tied to the retired secondary.
  3. Review log shipping configuration on the primary, secondary, and monitor server for references to the old host, share, jobs, and alert targets, because SQL log shipping depends on metadata and scheduled jobs together.
  4. Check each database, instance, and maintenance plan separately if behavior differs, because migrations often fix one log shipping set while another still targets the previous secondary.
  5. Update the authoritative log shipping configuration so backups, copies, and restores run against the intended secondary, because building the new SQL replica alone does not retarget existing job definitions.
  6. Trigger a controlled backup-copy-restore cycle and confirm the intended secondary receives and restores fresh logs, because a healthy SQL service does not prove the right DR chain is active.
  7. Verify the old secondary no longer receives copied logs, restore attempts, or monitor updates from migrated databases, because split replication paths can remain hidden while both environments stay online.
  8. Review job owners, SQL Agent credentials, share permissions, and monitor alerts if shipping still fails, because the destination can be correct while execution context or file access still blocks the new path.
  9. Document which team owns SQL Agent jobs, monitor-server metadata, and DR validation so future database cutovers verify the actual log shipping target before retiring the previous secondary.