Cloud accounts outlast projects, contracts and staff. The difference between a clean handover and an expensive one is almost entirely whether somebody wrote things down while they still knew them.
Settle ownership before anything else
Three questions, answered explicitly and in writing at the start of an engagement rather than the end:
- Whose account is it? An account in the client’s name with the agency granted access is a fundamentally different arrangement from an agency account hosting a client’s workload — for billing, for data, and for what happens if the relationship ends.
- Who pays, and on whose payment method? This determines who can reach billing support during an incident.
- Who is the account recovery contact? If that is an individual’s personal email, it will eventually be a problem.
The general recommendation is that the client owns the account and grants access, because it makes every later question simpler. Whatever is decided, decide it deliberately.
Use named identities, never shared logins
A shared root login cannot be handed over — it can only be given away, and afterwards nobody knows who did what. Every person gets their own identity with their own multi-factor authentication, and access is granted by role. Handover is then a matter of adding and removing people rather than rotating a secret everybody knows.
What to document
- What each resource is for. One line per server, database, bucket and load balancer. This is the single most valuable document in the account.
- How to deploy. The actual commands, not a description of them.
- How to restore. Where backups are, and the steps to bring the service back. See snapshots vs backups.
- DNS. Where the zone is hosted and who can change it — frequently a different vendor from the cloud account, and frequently forgotten.
- Certificates. What renews them, and what happens if the renewal fails.
- Third-party credentials the workload depends on, and which vault holds them.
- Scheduled jobs and what breaks if they stop.
- Monitoring and alerting, and who receives the alerts today.
The transfer itself
- Add the incoming team’s identities with the access they need.
- Walk through a deploy and a restore together, on the real account.
- Move billing ownership and confirm the first invoice arrives where it should.
- Repoint alerts and monitoring to the new on-call address.
- Update DNS registrar and certificate contacts.
- Only then revoke the outgoing team’s access — and check for automation keys, not just human logins.
Step six catches the item that outlives most handovers: a deployment key or API token created by somebody who has left, which no longer maps to any person and which nobody dares delete.
Ongoing hygiene that makes handover cheap
- Tag every resource with the project and the owner at creation.
- Separate environments by account or project rather than by naming convention.
- Review access quarterly and remove what is unused.
- Keep a single runbook per client, updated when something changes rather than at the end.
Where to go next
- Cloud accounts for agencies managing client infrastructure
- Reading a cloud provider’s terms before you build
- Browse cloud accounts
Questions
Frequently asked
Should the agency or the client own the cloud account?
Client-owned with agency access granted is usually cleaner. It keeps billing, data and continuity with the party that will still be there after the engagement ends.
What is most often forgotten in a handover?
Automation credentials — deployment keys and API tokens created by an individual. They survive the removal of that person's login and belong on the revocation list.
How much documentation is enough?
One line per resource explaining what it is for, plus a deploy procedure and a restore procedure that have both been executed. That covers the majority of handover pain.