Short answer
#The sequence
Read this before the list. The order is the part that is hard to recover from getting wrong.
-
Ownership — before notice is given, if you possibly can
Go through every account the system needs and record whose identity it is in. Anything in a personal or supplier name is a transfer with a process and a delay, not a permissions change.
Once a relationship is ending, “please transfer the domain” stops being an errand and becomes a negotiating position.
-
The technical picture — early, because its gaps are the agenda
Have the system analysed independently, so you have a map with citations and an explicit list of what could not be established. Everything after this step gets shorter once it exists.
-
Demonstration — while the people who know are still available
The incoming team runs it locally, deploys a real change, and restores a backup. Themselves, not watched. This converts every “should work” into a fact.
-
Reasoning — the only thing that cannot be recovered later
Specific written questions, answered in writing. What are you nervous about; what did you try that failed; what breaks regularly; what is here because of a constraint that no longer exists.
-
Rotation — last, after your own routes in are verified
Every credential the outgoing team could have seen, treated as exposed. This is hygiene rather than an accusation, and it must come after ownership is settled.
Revoking before transferring can remove the only route into an account that was never yours.
#The nine areas
1. Code and history
- Repository in a company-owned organisation
- Full commit history — not a squashed snapshot The history is where a new team finds out why things are the way they are.
- All branches, tags and release history present
- Two company people hold owner rights on the organisation
- A list of any code that lives outside this repository
2. Environments
- Every environment listed, with what is deployed to each
- Somebody outside the outgoing team has run it locally, from the instructions alone
- The instructions corrected to match what they actually had to do
- Environment variables documented by name and purpose
- Any staging environment holding real customer data identified
3. Infrastructure and accounts
The only area that can leave you permanently worse off.
- Domain registration in a company-owned account
- DNS control in a company-owned account
- Cloud account or organisation owned by the company
- Recovery email and phone on every critical account point at company mailboxes The most commonly missed item on any handover list.
- Billing for every service goes to a company payment method
- Certificates and anything that auto-renews accounted for
- App store publisher accounts transferred, if relevant
4. Deployment and release
- The incoming team has deployed to production themselves
- CI/CD configuration transferred, including its stored secrets
- A rollback procedure somebody has actually performed
- Release process written down as performed, not as remembered
- Any manual step in a release identified
5. Data and recovery
- Database access transferred and verified by signing in
- Backups running, with a failure alert somebody receives
- A backup restored into a scratch environment during the handover The test that most often fails. Record how long it took.
- Retention and deletion behaviour documented
- Where customer data lives, and what leaves the system
6. Integrations and dependencies
- Every external service the system needs, listed
- Whose account each one is in, recorded beside it
- Inbound interfaces listed — who outside depends on this system
- Outbound flows listed, including scheduled files and webhooks
- Any contract or commercial term attached to a dependency
7. Operations
- Everything that runs on a schedule, with what it does Check the codebase, the cloud console and the crontabs. They rarely agree.
- Monitoring and alerting inventory: what alerts, to whom, meaning what
- On-call or escalation arrangement, if there is one
- A list of what breaks regularly and what is done about it
- Any task that has to be done by hand, and how often
- Error tracking and log access transferred
8. Understanding
- A current technical picture, derived rather than remembered
- The open questions written down and prioritised
- Written answers to the questions only the outgoing team can give
- Which parts they would be nervous about somebody changing, and why
- What was tried and abandoned, and what is here for a constraint that has gone
- Single points of failure named
9. Closing the transfer
- Ownership confirmed and your own routes verified BEFORE any revocation
- All credentials rotated after the transfer
- Personal accounts and keys removed
- A paid consultation window agreed for the weeks afterwards
- The three acceptance tests passed
#What replaces documentation as the definition of done
Most handovers are managed against the wrong completion criterion. The contract says "documentation and knowledge transfer sessions", both sides deliver those, everybody signs, and four months later the new team is still discovering things. Nothing was breached — the wrong thing was specified.
- Ship. The incoming team deploys a real change to production without contacting the outgoing one.
- Recover. They restore a backup into a scratch environment and show the data is usable.
- Explain. They answer ten questions about the system — chosen by you, not by them — correctly, in writing.
Ten reasonable questions for the third test: what are the components; what does it depend on outside itself; where is customer data; what happens when a payment fails; what runs on a schedule and what does it do; who can deploy; what happens if the queue stops; which parts have no tests; what is the recovery procedure; what did the last analysis say nobody could confirm.
#What to put in the contract
Four clauses, none of them adversarial, all of them cheaper to agree at renewal than during a termination.
- Accounts remain company-owned. The supplier gets access, not ownership, and any new account is created in a company identity.
- A defined handover period on termination, with both teams available and paid.
- The three tests as acceptance criteria, in place of "documentation delivered".
- A consultation window afterwards — a small number of paid hours over the following month or two, because the questions that matter surface once the new team starts changing things.
#What goes wrong
Leaving account ownership until the end of the process.
Instead Do it first. It is the only category that can leave you unable to operate rather than merely delayed, and the only one that gets harder once notice is given.
Spending the outgoing team's remaining hours on an architecture document.
Instead Derive the structural picture. Spend their time on reasoning and operational habit, which nothing can derive.
Accepting a walkthrough instead of a demonstration.
Instead Every step the incoming team has not personally performed is a step that has not been transferred.
Rotating credentials before ownership is confirmed.
Instead Confirm ownership, create your own routes in, verify them, then rotate.
A zero-day gap between the outgoing and incoming teams.
Instead Overlap them and pay for it. The gap is where everything that was assumed turns out not to be true.
Assuming the repository is the whole system.
Instead Ask explicitly what runs that is not in it: scheduled tasks on a server, a cloud function created in a console, a script on somebody's machine, a spreadsheet somebody maintains.
#What this does not cover
What this does not do
- Commercial and legal terms — intellectual property, notice, liability, warranties. Those need somebody qualified to read your contract.
- Regulated industries. Payment, health and public-sector handovers carry obligations this list does not know about.
- Code quality, security and architecture review. A handover establishes that a system can be operated, not that it is good.
- Whether the incoming team is capable. No checklist establishes that.