Introduction

A privileged access migration can put the new bastion or jump host into service while administrators still launch sessions through the old one. SSH or RDP works for some engineers but not others, session logging still lands on the retired jump server, or access breaks only after the previous bastion is disabled because saved shortcuts, local config files, and access portal bookmarks often outlive the infrastructure change.

Treat this as an admin-entry-point problem instead of a generic remote access outage. Start by checking which hostname, alias, or profile an affected administrator actually launches when opening a privileged session, because migrations often validate the new bastion itself while real operators continue using old bookmarks or workstation config.

Symptoms

  • Admins still launch SSH or RDP sessions through the old bastion after migration
  • Session recording or audit logs still appear on the retired jump host
  • One admin group uses the new bastion while another still uses the previous entry point
  • Access fails only after the old bastion is shut down
  • The new bastion is healthy, but operators never reach it from their normal workflow
  • The issue started after moving jump hosts, bastion infrastructure, or privileged access workflows

Common Causes

  • Saved SSH config aliases, RDP files, or desktop shortcuts still reference the old bastion
  • Access portals, bookmarks, or PAM launch workflows still publish the previous hostname
  • DNS aliases or certificates still resolve the jump host name to the retired server
  • One admin team or workstation image was updated while another still uses the old entry point
  • Automation scripts or onboarding docs keep distributing the retired bastion address
  • Validation confirmed the new bastion worked but did not verify what endpoint administrators actually launched from daily workflow

Step-by-Step Fix

  1. Capture one affected admin workflow and record the exact hostname, profile, or shortcut it launches, because the real session entry point determines what bastion handles privileged access.
  2. Compare that active launch path with the intended post-migration design, because one stale shortcut or alias can keep a whole operations team tied to the retired jump host.
  3. Review SSH config, RDP profiles, access portal entries, DNS aliases, and onboarding artifacts for references to the old bastion, because admin access often depends on both central publishing and local workstation state.
  4. Check different admin teams, workstation images, and access methods separately if behavior differs, because migrations often fix one launch path while another still distributes the previous server.
  5. Update the authoritative admin-access publication path so new and existing operators use the intended bastion, because deploying the replacement host alone does not retarget saved workflows.
  6. Launch a controlled privileged session and confirm it traverses the intended bastion and records activity there, because a successful login does not prove the right entry point handled the session.
  7. Verify the old bastion no longer receives admin sessions from migrated operators, because split privileged-access paths can remain hidden while both servers stay reachable.
  8. Review MFA, certificates, and client trust settings if admins still fail to switch, because the destination can be correct while local trust or policy still blocks the new host.
  9. Document which team owns admin portals, workstation config, and cutover validation so future bastion migrations verify the actual launch path used by administrators before retiring the previous server.