Transfer team-account control before your only administrator leaves, with successor sign-in checks, recovery rehearsals and a staged access-removal plan.
Direct answer: Appoint an authorised successor, give them their own appropriate access, and verify that they can sign in and perform the necessary administrative work before removing the departing administrator. Rehearse a separate approved recovery route and transfer ownership, billing contacts and connected-service dependencies. Do not treat a forwarded password or an accepted invitation as a completed handover.
The dangerous assumption is that an administrator is simply a person who knows the password. In practice, control may depend on a private phone, a domain registrar, an email account, a billing role or a connection originally authorised by that person. The visible account is only part of what must continue working.
My recommendation is to delay routine removal until a successor has demonstrated control, while setting a firm, authorised departure deadline. If there is suspected compromise or an urgent employment instruction to revoke access, security and HR must coordinate that action immediately with recovery work. This guide covers a planned handover, not a reason to retain risky access.
Applies to: authorised small-team software handovers. Google Workspace examples are documentation-based; other services have different owner roles, permission limits and recovery procedures.
Run the successor access rehearsal
The successor access rehearsal is an editorial handover method with two independent checks: ordinary administration using the successor's own identity, then an approved recovery route that does not depend on the departing person. Complete both before you rely on the handover.
It extends the account-ownership questions in the technology retrospective for small teams into a specific departure process. The evidence is a performed task and a recoverable account, not a document somebody says they have read.
Before changing anything, obtain organisational authorisation, identify the account and paid plan, and confirm who may assign roles. Record current owners and export necessary configuration information into an approved restricted location. Keep recovery codes, secrets and personal information out of a general handover document. Link to their controlled storage location instead.
Do not delete accounts or transfer confidential files simply because they appear in the departing person's workspace. Establish ownership and applicable retention requirements with the responsible team. UK workplace, privacy and contractual requirements depend on the circumstances; use qualified local advice when a specific dispute or retention decision requires it.
Separate the kinds of control
List each capability needed to keep the service operating. Use the service's actual role names, then describe the job behind each one. A billing contact, workspace owner and user administrator may not have interchangeable permissions.
| Control | Evidence to collect | Failure the check prevents |
|---|---|---|
| Membership and roles | Successor can inspect and manage the intended user scope | Invitation accepted but insufficient authority |
| Billing and renewal | Correct authorised contact can access the relevant billing information | Renewal messages still depend on a former employee |
| Workspace or resource ownership | Required files and settings have a continuing organisational owner | Data exists but cannot be managed |
| Authentication and recovery | Independent sign-in and approved fallback both work | Access depends on a departing person's phone |
| Connected services | Essential connections have continuing ownership and a checked renewal path | A later expiry breaks an apparently completed handover |
For Google Workspace, the prebuilt administrator-role documentation distinguishes super administrators from limited roles. A User Management administrator cannot assign administrator privileges or reset an administrator's password. Giving that role to a successor is therefore insufficient if those are the tasks they must inherit.
Record the minimum appropriate roles rather than giving every colleague unrestricted access. If only one person currently has all authority, your handover should resolve that concentration without creating a large group of unnecessary administrators.
Prove ordinary access with the successor's identity
Use the provider's supported invitation or role-assignment process. Google documents role assignment through its Admin console and specifies the required privileges for each method in assigning specific admin roles. Check the actual role and account requirements before following a remembered sequence.
Have the successor sign in through a separate browser profile or session under their own identity. Do not perform the test in the departing administrator's already-authenticated browser. Confirm the displayed account and organisation, because a person can have access to several similar workspaces.
Choose a permitted low-impact administrative task. They might inspect the membership list and role settings, then make and reverse an approved change to a designated test resource. Name the expected result beforehand. Avoid creating paid seats, changing live permissions or deleting data merely to prove that a control exists.
If a task fails, record the exact operation, expected permission and displayed result. Investigate role scope, account identity or provider-documented activation behaviour. Do not repeatedly grant broader rights without understanding the missing capability. The test passes when the successor can perform the job they actually own and explain how to reverse a relevant change.
Rehearse recovery without staging a lockout
The second check asks whether control survives the loss of the ordinary sign-in route. Select a provider-supported fallback, such as an independently held spare security key or another authorised administrator's recovery capability. Confirm that its storage and approval process will remain available after departure.
Google's administrator security guidance recommends multiple super-administrator accounts managed by separate people, individual identities, strong second-factor protection and preparation for recovery. Those recommendations establish useful safeguards; your own organisation must decide who is authorised to hold emergency access.
Rehearse a fallback in a controlled session using a supported method. Do not deliberately lose the only working factor, disable security protections or reset a production administrator merely to see what happens. Where a recovery action would be disruptive, verify the approved prerequisites and have the responsible security or IT specialist supervise the test.
Check for circular dependencies. A recovery address that is accessible only through the same locked service is not an independent route. Similarly, an instruction to contact the departing person is an unresolved dependency, not a recovery plan. Record who can obtain the fallback, who approves its use and how access is logged.
Transfer the connections before removing the person
List automations, integrations and scheduled jobs that were authorised through the departing account. Ask what happens when their access expires, is revoked or is deleted. These are different events, and their effects are product-specific. Read the relevant connection documentation or obtain a written support answer if necessary.
Use supported ownership transfer or reauthorisation with an approved continuing identity. Test a harmless representative run and confirm the result reaches the correct destination. A connection that happens to run today may still depend on a token that needs the former administrator at its next renewal.
Do the same for invoices, renewal notices and domain-management contacts. Establish continuing access before removing obsolete details. Do not forward an entire private mailbox or place payment credentials into shared notes as a shortcut. Transfer the business function through the provider's authorised controls.
Budget the handover as actual work
Consider an explicitly illustrative seven-app handover. Allow 15 minutes per app to identify roles and dependencies, 20 minutes for successor administration and recovery checks, and 10 minutes for documentation. That is 7 × (15 + 20 + 10) = 315 minutes, or 5 hours 15 minutes.
Add an assumed 45 minutes for coordinating owners and 60 minutes for one difficult provider-support issue. Total planned effort becomes 420 minutes, or seven hours. These are planning assumptions, not a measured average or a promise that provider recovery completes within an hour.
If the departing employee has two working days left with three hours available for handover each day, only 2 × 3 = six hours are available. The plan is already one hour short before unexpected delays. Prioritise identity, domain and other services that control access to the rest, assign parallel work to authorised colleagues, and escalate unfinished dependencies immediately.
Calendar time can exceed labour time. A provider approval may take longer than the hands-on work, so begin when the departure is confirmed rather than waiting for the final afternoon.
Finish with a timed access-removal decision
- Today, appoint the successor and list the accounts in dependency order. Identify anything that controls sign-in or recovery for other services first.
- Over the next two working days, complete the ordinary-access and recovery checks, transfer necessary connections and record failed checks with an owner.
- Before the agreed departure deadline, review the evidence with the authorised manager. Resolve or explicitly escalate every remaining dependency; do not call an untested invitation a pass.
- At the approved time, remove obsolete access using each provider's documented process. Then repeat a normal successor task and inspect the next scheduled connection run. Preserve required organisational records and keep account deletion separate from immediate access revocation.
Related guides
Frequently asked questions
Can we just change the old administrator's password?
Do not use a password change as the whole handover. It can leave recovery factors, ownership records, billing contacts and connected services tied to the same departing identity. It also makes it harder to establish who performed later actions if several people use the account. Prefer the provider's supported role and ownership transfer to named authorised successors. There may be services with a single owner identity or constrained transfer process, in which case obtain the provider's documented route. The objective is continuing authorised control, not merely possessing a different secret for an unchanged dependency.
How many administrators should a small team have?
Have enough independently authorised access to recover from one person's absence without giving everyone unrestricted control. For Google Workspace, the vendor recommends more than one super administrator, managed by different people. That product recommendation is not a universal instruction to buy two unrestricted seats in every service. Check the access model, cost and actual recovery needs of each application. Routine tasks may suit limited roles, while emergency authority needs controlled custody and periodic verification. A second administrator who depends on the first person's phone or approval for every sign-in does not provide the independence you need.
What if the administrator has already left?
Start with any continuing authorised owner or administrator and the provider's official recovery process. Collect legitimate evidence of organisational control, account details and billing ownership through approved internal channels. Do not access the former employee's personal email or imitate them to bypass verification. If the account also controls your domain or business sign-in, prioritise specialist help because that dependency can affect several services at once. Preserve evidence of the access problem and keep working through approved alternatives where possible. Recovery timing depends on the provider and available proof, so avoid promising colleagues an unsupported restoration deadline.
Should the successor receive every permission the old administrator had?
No, first establish which permissions are necessary for the continuing role. Historic access often reflects how the account evolved, rather than a deliberate current requirement. Compare the successor's tasks with the provider's role definitions and test that scope. Preserve a separate authorised recovery route for exceptional actions instead of making everyday access unnecessarily broad. If the departing person combined finance, identity and application ownership, those responsibilities may belong with different successors. Do not reduce permissions blindly either; a required but rarely used recovery function can be missed if you assess only the tasks performed last week.
Is receiving billing emails enough to own the subscription?
No. Receiving a message establishes a communication route, not necessarily authority to change the plan, update payment information or transfer the workspace. Confirm the exact billing role and show that the authorised person can inspect the relevant account information. Avoid using a real purchase or cancellation as a test. Check separately whether a reseller or another provider controls the commercial relationship, because the application administrator may not control that agreement. If ownership is disputed or the interface offers no supported transfer, seek a documented resolution from the provider before treating the handover as complete.
When should we delete the departing person's account?
Decide deletion separately from revoking access. First preserve and transfer the organisational material that the responsible team has determined must remain, then check provider-specific effects on ownership, connected services and recovery. Removing sign-in authority at the approved departure time does not require guessing about every later retention decision. A deletion deadline may depend on contract, policy and local requirements, so involve the appropriate owner rather than using an arbitrary waiting period. If the provider documents a recovery window, record the verified limit, but do not rely on it as a substitute for a completed transfer and usable records.
Sources and verification
- Google Workspace: prebuilt administrator roles, checked on 9 September 2026 for the distinction between super-administrator and limited user-management authority.
- Google Workspace: assign specific admin roles, checked for supported role assignment and privilege prerequisites.
- Google Workspace: security best practices for administrator accounts, checked for individual identities, multiple administrators and recovery preparation. No live account changes or recovery tests were performed.
The parent was read in the publication's project; its public category URL could not be retrieved. Internal links follow the supplied article register. The rehearsal and scheduling figures are editorial, not a vendor service-level commitment.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
