Safely transfer website or app admin access to a new agency

TL;DR — The safe way to hand admin access to a new agency is: add named user accounts for each agency person, give the minimum role they need, turn on two-factor authentication (2FA, a second login check), and verify they can sign in before removing the old agency. Do not send your own password by email or chat; the single most common fix is to create separate accounts in each dashboard instead of sharing one owner login. Reading time: ~5 min

Goal

When you finish, the new agency will be able to sign in to the systems that run your website or app using their own accounts, with the right level of access to do their work, and you will still keep the top-level owner access needed to remove or change them later.

Prerequisites

• Your own working login for each system the agency needs to touch
• Owner or administrator access in those systems
• The new agency's list of named people and email addresses
• A password manager (a secure app that stores passwords), or a secure note you control
• Your phone for 2FA prompts or backup codes
• A current list of services used by your site or app, such as:
  • Domain registrar (where the domain is registered)
  • DNS provider (where DNS records are managed)
  • Hosting or cloud provider
  • CMS (content management system, such as WordPress)
  • Source code repository (such as GitHub, GitLab, or Bitbucket)
  • Analytics, email sending, payment, and app store accounts if relevant
• If your site uses WordPress, a current admin login to /wp-admin
• If your app uses GitHub and you prefer CLI (command line), GitHub CLI version 2.x or later — check with:

gh --version

Steps

Step 1: List every system the agency actually needs

Create a handover list in a note or spreadsheet with these exact columns:

System | URL | What it controls | New agency person | Role to grant | Owner account kept by you

Fill it with literal entries like these:

Domain registrar | https://registrar.example | Domain renewals and nameservers | alex@agency.com | Billing or admin | yes
DNS provider | https://dash.example | DNS records | alex@agency.com | DNS admin | yes
Hosting | https://hosting.example | Server/app deploys | sam@agency.com | Admin | yes
WordPress | https://example.com/wp-admin | Content and plugins | editor@agency.com | Administrator | yes
GitHub | https://github.com/your-org | Source code | dev@agency.com | Admin on repo, not owner of org | yes

What you should see when this step succeeds: a complete list of every login the agency needs, with a named person and a specific role for each one.

Step 2: Turn on 2FA and save backup codes on owner accounts

In each provider's dashboard, open the security area and enable 2FA on your own owner account. Common menu paths are:

Profile or Avatar → Security → Two-Factor Authentication → Enable
Account Settings → Login & Security → 2FA → Turn on

Save the backup codes exactly where your password manager tells you to save secure notes.

What you should see when this step succeeds: the security page shows "Two-factor authentication enabled" or a green/active badge, and you have backup codes saved.

Step 3: Add the new agency as separate users, not as your shared login

For each system, invite each agency person by email from the dashboard. Use your provider's user-management area. Common menu paths are:

Settings → Users → Invite user
Account → Team → Add member
Organization → People or Members → Invite member

Use these literal role choices where available:

What you should see when this step succeeds: each agency person appears in the users/team list with a status like "Invited" or "Pending acceptance."

Step 4: Give access only to the systems they need

If your provider supports project-level or site-level access, grant access to the exact project, site, or repository instead of the whole account. Common menu paths are:

Project → Settings → Access → Add member
Repository → Settings → Collaborators and teams → Add people
Site → Users → Add existing user

Use these literal scoping choices where available:

Project: your production website only
Repository: website repo only
Environment: production and staging only if they deploy
Site: example.com only

What you should see when this step succeeds: the agency account is attached to the correct project/site/repo, not to unrelated properties.

⚠️ Removing the old agency too early can cause downtime if they still control DNS, hosting, deployment, or SSL renewal. Do not delete old access until the new agency has signed in and confirmed they can see the same systems.

Step 5: Transfer shared secrets safely if the agency truly needs them

Prefer replacing old secrets over sharing existing ones. If the new agency needs API keys, SMTP credentials, or app passwords, rotate them in the provider dashboard and send the new values through your password manager's sharing feature.

Common menu paths are:

Settings → API Keys → Create new key
Security → App passwords → Generate
Email service → SMTP credentials → Create credentials

Use labels like these when creating them:

Agency-2026-production
Agency-2026-staging

What you should see when this step succeeds: a newly created key or password exists with a clear label, and the old one is still active until the new agency confirms they can use the replacement.

Step 6: Ask the new agency to accept invites and confirm access live

Send this exact checklist to the agency in email or chat:

Please accept all invites, sign in with your own account, enable 2FA, and reply with:
1) the systems you can access,
2) any system still showing pending or denied,
3) whether you can view production and staging.
Do not use my login.

What you should see when this step succeeds: all invites change from "Pending" to "Active," and the agency confirms access using their own named accounts.

Step 7: Remove the old agency and shared logins

After the new agency confirms access, remove the old agency users and disable any shared admin account.

Common menu paths are:

Settings → Users → Remove user
Team → Members → Revoke access
Security → Sessions → Sign out of all sessions
Security → API Keys → Revoke old key

If you have a WordPress shared admin user, create a replacement named admin for yourself first, then remove the shared one:

Users → Add New → Role: Administrator
Users → All Users → shared-admin → Delete

What you should see when this step succeeds: the old agency no longer appears in the team/user list, old keys are revoked, and only named active users remain.

Verify it works

Check each system from your handover list and confirm these exact states:

Users or Team page: new agency users show Active
Users or Team page: old agency users are absent or Disabled
Security page: your owner account shows 2FA enabled
API Keys page: only current labeled keys remain active

For WordPress, verify in the dashboard:

Users → All Users

Expected result: your own named admin account is present, the new agency users are present with the intended roles, and any old shared admin is gone.

For GitHub, verify in the web UI:

Organization or Repository → Settings → Collaborators and teams

Expected result: the new agency user or team has the intended repository access, and they are not listed as organization owner unless you explicitly chose that.

Use this simple access flow as your mental check:

[You: owner] ---- 1. invite ----> [New agency users]
[New agency users] ---- 2. accept ----> [Provider dashboards]
[You: owner] ---- 3. remove ----> [Old agency users]
[You: owner] ---- 4. keep ----> [Top-level owner access]

Common pitfalls

Shared one login instead of separate named users

Mistake: sending your own admin email and password to the new agency.

Symptom: you cannot tell who changed what, and removing access later means changing your own password everywhere.

Fix: go to Settings → Users → Invite user and create one account per agency person.

Giving organization-owner or account-owner access by default

Mistake: choosing the highest role because it is faster.

Symptom: the agency can remove you, change billing, or access unrelated sites.

Fix: re-open the member entry and change the role to project admin, repo admin, DNS admin, Editor, or Administrator only for the specific site.

Removing the old agency before the new one has accepted invites

Mistake: deleting old access immediately after sending invitations.

Symptom: nobody can deploy, edit DNS, renew SSL, or update content if the invite is still pending.

Fix: wait until the new agency status shows Active in each dashboard before removing the old users.

Forgetting API keys, SMTP passwords, or deploy tokens

Mistake: handing over dashboard access but not the machine-to-machine credentials.

Symptom: the agency can log in but deployments fail, forms stop sending, or integrations break.

Fix: open Settings → API Keys or the provider's credentials page, create a new labeled key, share it securely, then revoke the old key after testing.

Leaving old sessions active after access removal

Mistake: removing a user but not revoking active sessions or app passwords.

Symptom: the old agency may stay signed in on a browser or CI tool for hours or days.

Fix: use Security → Sessions → Sign out of all sessions and Security → API Keys → Revoke for old tokens.

No owner account retained by you

Mistake: letting the agency become the only top-level admin.

Symptom: you need the agency to approve your own access changes later.

Fix: keep one owner account in your name on every critical system: registrar, DNS, hosting, code, CMS, and payments.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.