A Handover Checklist for Cloud Accounts
Whether a colleague is leaving or an account is changing hands, the same list applies. Work through it in order and nothing is left behind.
Accounts change hands constantly — a developer leaves, an agency finishes a project, an account is bought or sold. Handovers go wrong in the same ways every time, and a checklist fixes most of them.
Before anything else: inventory
You cannot hand over what nobody has listed. Produce a written inventory covering:
- Every region with running resources, not just the obvious one.
- Compute instances, with what each one does.
- Databases, including any running on instances rather than as managed services.
- Storage buckets, and whether any are public.
- DNS zones and where the domain registrar sits — often a different account entirely.
- TLS certificates and their renewal mechanism.
- Scheduled jobs, functions and anything that runs on a timer.
- Third-party integrations authorised against the account.
The registrar is the most commonly missed item. A cloud account handover that leaves the domain behind is not a complete handover.
Credentials, in order
- Change the primary account password.
- Reset multi-factor authentication and enrol a device the new owner controls.
- Change the recovery email and phone to the new owner’s.
- Delete or rotate every API key, access key, service account key and app secret.
- Remove every user, role and service identity that belongs to the previous owner.
- Revoke third-party OAuth authorisations — CI systems, monitoring, deployment tools.
- Check for SSH keys stored in the platform and injected into new instances.
Step six is easily forgotten. A CI system still holding a valid deploy token has write access to production regardless of who owns the console.
Billing
- Replace the payment method with one the new owner controls.
- Remove old billing contacts and add new ones.
- Change the billing address and tax details if the legal entity changed.
- Check for reservations, savings plans or committed use discounts — these are financial obligations that transfer with the account.
- Note the billing cycle date so the first invoice is not a surprise.
- Set a budget alert under the new owner’s email.
Commitments deserve a real look. A three-year reserved instance is a liability attached to the account, and discovering it after transfer is an unpleasant conversation.
Operational continuity
| Item | Question to answer | Why it matters |
|---|---|---|
| Backups | What is backed up, where, and has a restore been tested? | Untested backups are assumptions |
| Monitoring | Where do alerts go now? | Alerts to a departed address are silence |
| Runbooks | Is there written recovery guidance? | Knowledge leaves with people |
| Deployment | How does code reach production? | Often the least documented part |
| Secrets | Where does the application get its credentials? | Rotation breaks things if undocumented |
| Certificates | What renews TLS, and does it still have access? | Expiry causes visible outages |
Documentation to write before you finish
A short document beats a long one that never gets written. At minimum:
- An architecture sketch — what talks to what.
- The inventory from the first section.
- How to deploy, in the fewest steps that actually work.
- How to restore from backup, tested at least once.
- Who to contact at the provider, and which support plan is active.
- Any scheduled work — certificate renewals, licence expiry, commitment end dates.
Verify before you sign off
Do not treat the handover as complete until the new owner has independently: signed in with their own credentials and MFA, made a small change and seen it take effect, received a test alert, and restored something from a backup. Anything less is a handover on paper.
Common questions
Can cloud accounts be transferred between owners officially?
Policies vary by provider and by account type. Enterprise agreements usually have a formal process; self-service accounts often do not. Changing the credentials, billing details and contacts is the practical route, and the checklist above is what makes it complete.
What if the previous owner still has an API key I missed?
That is why the credential sweep is exhaustive rather than selective. Delete every programmatic credential you did not create, then recreate what you need. Breaking an integration you can rebuild is better than leaving one you cannot see.
Should I rotate database passwords too?
Yes, along with any application secrets. Cloud credentials are only part of the surface; application-level credentials in a repository or a secret store deserve the same treatment.
How long should a handover take?
For a small estate, a focused afternoon. The inventory takes longest. Rushing it is how DNS ends up somewhere nobody can reach.
Where to go next
Pair this with securing an account you did not open and API keys and secrets management.
Read next
Choosing a Cloud Region
Region choice affects latency, price, legal exposure and which services you can even use.
Eight Mistakes People Make in Their First Month on Cloud
They are the same eight every time, they are all avoidable, and most of them show up first as a bill nobody expected.
Service Quotas: The Limit You Will Hit First
Nothing stops a deployment faster than a quota you did not know existed.