Short answer
#Irreversible
Three risks that can leave you permanently worse off. Everything else on this page costs time.
| Risk | What it looks like | What prevents it |
|---|---|---|
| Losing the domain | The registration is in a departing person's or supplier's name, and the relationship ends badly. | Transfer the registration to a company account with a company recovery address, before notice. |
| Losing the cloud account | Production runs inside a supplier organisation. You have access; you do not have the account. | Own the account or organisation yourself, with the root credentials and the billing. |
| Losing the data | Backups live in the supplier's storage, or exist and have never been restored. | Take an independent copy you can open yourself. Then restore one into a scratch environment. |
The order that causes this
The common route to all three is the same mistake in sequence: giving notice first and auditing ownership afterwards. Once a relationship is ending, a routine transfer becomes a negotiating position, and the other side knows what it is worth.
#Expensive
These cost weeks to months of reconstruction, usually billed to you twice.
- Nobody outside the outgoing team can deploy. Discovered under pressure, in the first week when something needs fixing. Prevented by one supervised release before the handover starts.
- The understanding was never written down. The new team spends its first months rediscovering what the old one already knew. Prevented by deriving the technical picture early — the same information, in hours instead of months.
- Something runs that is not in the repository. A scheduled task, a console-created cloud resource, a script on somebody's laptop. Discovered when it stops. Prevented by asking, explicitly, in those words.
- An external party depended on you and nobody said. A partner integration, a customer with an API key, a nightly file somebody receives. Discovered when they complain. Prevented by listing inbound interfaces as well as outbound.
- The reasoning left with the people. The new team rebuilds something that existed for a reason, or removes something load-bearing. Prevented only by asking the questions while somebody is still answering.
#Recoverable
- Setup instructions do not work. Annoying, costs a day, and is exactly what the demonstration week is for.
- Monitoring alerts go to a mailbox nobody reads. Fixable in an hour once noticed. The risk is how long "once noticed" takes.
- Credentials were shared over a channel neither party controls. Rotate everything. Uncomfortable, not fatal.
These are the ones most handover plans concentrate on, because they are concrete and easy to list. They are worth fixing and they are not where the damage is.
#When each one becomes unfixable
| Risk | Cheapest moment | Closes when |
|---|---|---|
| Account ownership | Years before, at setup | Notice is given |
| Reasoning and habit | The week notice is given | They stop replying |
| Operability | Any time before the last week | The overlap ends |
| Understanding | Any time, including after | Never — it is derivable |
| Data recovery | Any time | Never, if you hold a copy |
The planning consequence is the whole point of this page. Two rows have windows that close, and two do not. Spend the scarce, closing time on ownership and on reasoning; do the derivable things afterwards, calmly, with whoever is available.
#Early signals
Things that suggest a handover will be harder than planned, none of which implies bad faith:
- Nobody can produce a list of the external services the product uses.
- Nobody can name the last person who restored a backup.
- The answer to "could somebody else deploy?" is about credentials rather than about a person who has.
- The estimate for how long a new team would take varies by a factor of three between two people on your own side.
- Setting up locally is described as "a bit fiddly".
- There is exactly one person who can answer questions about the part that handles money.
#What this does not cover
What this does not do
- Commercial risk — disputes, unpaid invoices, contested intellectual property. Different problem, different adviser.
- People risk on the incoming side. Whether the new team is capable is not a handover property.
- Security exposure created by a departure. Rotating credentials is on the checklist; a security review is a separate exercise.
- Anything specific to a regulated industry.