See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
The access list comes first, and it is longer than you think
Write it as an inventory with owners, not as a conversation. The repository and its branch protections. The state backend, including who can clear a stuck lock. The cloud accounts or subscriptions, per environment. The CI system and its stored secrets. The secret store itself. The DNS registrar, which is the one everyone forgets until a certificate expires. And any provider account whose credentials are wired into the code.
For each entry, name a person on the receiving side who now holds it, and a date. Handover items with no named owner come back as an incident, usually at renewal time.
ACCESS new owner transferred repository + branch rules .............. .......... state backend + lock owner .............. .......... cloud account per environment .............. .......... CI system + stored secrets .............. .......... secret store .............. .......... DNS registrar .............. .......... third-party provider accounts .............. .......... CONTEXT architecture diagram + doc generated, synced from main unmanaged resource list written once, dated environment map which env is authoritative apply procedure + stack order written known landmines written, one line each
The context pack: five documents, one of them generated
An architecture diagram and an architecture doc, generated from the repository so they describe the code as it stands rather than as it stood when the engagement started. A list of resources the repository does not manage, which is the single highest-value page in any handover and exists nowhere in the code. An environment map saying which environment is authoritative and how they differ. The apply procedure, including the order between stacks if there is one. And a landmines page, one line per trap, written honestly.
The landmines page is the part people skip because it reads like an admission. Write it anyway: the module that cannot be applied twice without a manual step, the resource that must be imported rather than created, the region that has a different SKU available. Each line saves the receiving team a day.
Leave something that is still true in month three
A handover pack made of static documents starts decaying the day it is delivered, and the receiving team has no way to tell which parts have gone stale because they were not there when it was written. That is the specific failure mode worth engineering around.
Connect the repository read-only and hand over a synced project instead. Every .tf and .tfvars file is parsed, the diagram and the architecture doc regenerate on a daily sync of the branch the new owners choose, and nothing needs terraform init, a state file, or cloud credentials, which is what makes this workable on a client repository where you only ever had read access. Azure DevOps, GitHub, and GitLab all connect the same way.
The fetch is bounded, which is the answer to the security question a client will ask before granting the token. It reads up to 400 .tf files and 500 blobs in total including tfvars, skips any file over 400KB, and never descends into a .terraform directory. Nothing is written back to the repository, and no other file type is requested.
For the first weeks, when the receiving team's accounts may not exist yet, a live embed renders the current diagram in their wiki with no account required to view. After that, transfer ownership of the project and the loop keeps running without you. Ownership questions in general are covered in documentation ownership models.
FAQ
What should be included in an infrastructure handover?
How do I document infrastructure that is not managed by Terraform?
Can the receiving team read the architecture diagram without an account?
What access does a repository connection need on a client repository?
How do we stop the handover documentation from going stale?