Documenting a Cloud Account Handover

Documentation is the step everyone agrees with and nobody schedules. For a cloud account handover it pays for itself quickly, because the questions it answers all arrive later and all arrive at inconvenient moments.

The questions you are writing for

• Was that server already here, or did we create it?
• When did we take control, and what state was it in?
• Which credentials have been rotated and which have not?
• How much balance was there, and when does it expire?
• Who do we ask about this?

Each is trivial to answer on the day and expensive to reconstruct three months later.

What to record

Identity and access

The date and time control transferred, the account identifier, which credentials were changed, which recovery paths were updated, and who now holds them.

Inventory at handover

A list of what existed before you changed anything: compute instances and their regions, storage volumes and sizes, reserved addresses, snapshots, firewall rules, scheduled tasks. This is the baseline that makes later questions answerable.

Billing state

Any promotional balance and its expiry date, the billing state of the account, and the payment method now attached.

Quotas

Current limits for the resources you care about in the regions you use. These constrain what you can do and are invisible unless recorded. See quotas and service limits.

Open questions

Anything unresolved: a resource whose purpose is unclear, a rule you left alone because you were unsure. Writing these down prevents them from becoming permanent mysteries.

Keep it small

One page in the team wiki, or a markdown file in the infrastructure repository, is enough. A document nobody maintains is worse than a short one that stays accurate.

For agencies

Agencies handing environments to clients benefit from turning this into a standard acceptance document, so both sides agree on what was delivered. That pattern is expanded in managing multiple client cloud accounts.