Introduction

A migration handoff can finish successfully while former vendors still retain access to critical systems. The website may already live on the new platform and the project may look complete, but old contractor accounts, shared logins, or delegated permissions remain active across hosting, DNS, registrar, Cloudflare, email, or SSH access paths.

Treat this as a post-handoff access-control problem instead of an administrative cleanup detail. Start by identifying every system touched during the migration, because lingering vendor access usually survives in the accounts and integrations that teams assume were already removed.

Symptoms

  • Former vendor access was not revoked after migration handoff
  • Old contractor accounts still appear in hosting, DNS, registrar, or Cloudflare admin lists
  • Shared passwords, API tokens, or SSH keys remain active after the project ended
  • The new owner cannot confirm who still has administrative access to core systems
  • Unexpected changes, confusion, or control disputes continue after the migration completed
  • The issue became visible during handoff review, access audit, or a later security check

Common Causes

  • Migration teams used shared credentials that were never rotated after handoff
  • Old vendor accounts remained active in one or more admin portals
  • SSH keys, API tokens, or service accounts created during the project were never removed
  • Control of registrar, DNS, or edge services was transferred operationally but not fully cleaned up administratively
  • Teams validated service functionality but did not run a post-project access review
  • Responsibility for revoking external access was unclear between technical and business owners

Step-by-Step Fix

  1. List every system involved in the migration, including hosting, registrar, DNS, Cloudflare, email admin, SSH, deployment platforms, and monitoring tools, because post-handoff exposure usually spans more than one service.
  2. Review user lists, service accounts, tokens, and SSH keys in each system and identify which access paths still belong to former vendors, because hidden project accounts are easy to miss.
  3. Confirm which accounts or credentials are still required for active operations before revoking anything, because you want to remove external access without disrupting legitimate internal ownership.
  4. Revoke or remove former vendor accounts at the actual source of access control, because disabling only one visible login path may leave API, SSH, or delegated admin access active elsewhere.
  5. Rotate shared passwords, API tokens, and any secrets exposed during the migration project, because shared credentials remain a security risk even if the old users promise not to use them.
  6. Review registrar, DNS, CDN, and hosting ownership settings to confirm the business now fully controls the account hierarchy, because operational access and legal ownership are not always the same thing.
  7. Verify that only approved internal users can still access critical systems after cleanup, because account removal should result in a clear and auditable ownership state.
  8. Check logs or audit trails for recent activity from former vendor identities, because unexpected use after handoff may reveal additional cleanup or incident-response needs.
  9. Document the final owner, access model, and vendor-offboarding checklist after recovery, because post-migration security gaps often come from undocumented handoff steps.