Short answer
#What complete actually means
- Software handover
- The transfer of the ability to operate, change and reason about a software system from one team to another. It is complete when the receiving team can deploy, recover and explain the system unaided — not when a set of documents has been delivered.
- In plain terms The point at which somebody else can look after your system without asking the people who built it.
The definition matters because most handovers are managed against the wrong completion criterion. A 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.
#The four things being transferred
They have different costs, different failure modes and different deadlines. Managing them as one thing is the root cause of most bad handovers.
| Part | What it is | If it goes wrong | When it must happen |
|---|---|---|---|
| Ownership | Accounts, domains, cloud, registrar, provider dashboards — in whose name each is | You lose control of something you thought you owned | Before notice is given, ideally years before |
| Operability | Running it locally, deploying it, restoring it, monitoring it | You cannot ship, and discover this under pressure | Verified by demonstration, not by document |
| Understanding | What the system contains, what depends on what, what is not known | Months of rediscovery, billed to you twice | Can be derived from the system at any time |
| Reasoning | Why it is like this, what was rejected, what to be careful with | The new team rebuilds something that existed for a reason | Only while the outgoing people will answer |
The scheduling consequence is the useful part. Understanding can be derived after they have gone. Reasoning cannot. So the outgoing team's limited attention should be spent almost entirely on the fourth row, and almost none of it on producing an architecture document that a machine can derive.
#The order that works
-
Establish ownership before anything is announced
Go through every account the system needs and record whose identity it is in. Anything in a personal name is a transfer with a process and a delay, not a permissions change.
Do this before notice if you possibly can. Once a relationship is ending, “please transfer the domain” is a negotiation rather than an errand.
-
Derive the technical picture — independently
Have the system analysed and produce a map with citations and an explicit list of what could not be established. Crucially, do this early: its gaps are your agenda for everything that follows.
Independently means: not a document written by the outgoing team about their own work. Both are useful; only one can be checked.
-
Convert the gaps into a question list
The unknowns are the shortest list of things only the outgoing team can answer. Send them as written questions with a deadline inside the engagement.
-
Prove operability by doing it
The incoming team runs it locally, deploys a trivial change, and restores a backup into a scratch environment — while the outgoing team is still available to unblock them, and without them doing it.
This is the single highest-value day of any handover. It converts every “should work” into a fact.
-
Take the reasoning while you can
Recorded sessions, specific questions, written answers. What are you nervous about; what did you try that failed; what is here because of a constraint that no longer exists; what breaks regularly and what do you do about it.
-
Analyse again at the end
A second analysis at the close of the engagement, compared against the first, is the most direct account there is of what actually changed during it.
-
Rotate everything, in the right sequence
After ownership is confirmed and company routes exist — not before. Every credential the outgoing team could have seen is treated as exposed. This is hygiene, not an accusation.
#How to test it
Three tests. If all three pass, the handover is real. If any fails, it is not, whatever has been signed.
The three tests
- Ship. The incoming team deploys a small, real change to production without contacting the outgoing team.
- Recover. They restore a backup into a scratch environment and demonstrate the data is usable.
- Explain. They answer ten questions about the system correctly, in writing — chosen by you, not by them.
Write these three into the engagement as the acceptance criteria, in place of "documentation delivered". They are cheap to run, impossible to fake, and change the incentives of everybody involved from the first week.
For the third test, ten reasonable questions: 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.
#Where handovers actually fail
Treating documentation as the deliverable.
Instead Specify the three tests above as the deliverable. Documents are a means; some of them are worth having and none of them is the goal.
Leaving account ownership until the end.
Instead Do it first, and ideally before the relationship is ending. This is the only part of a handover that can leave you permanently worse off.
Spending the outgoing team's time on things a machine can derive.
Instead Derive the structural picture from the system. Spend their hours on reasoning and operational habit, which no analysis can recover.
Accepting a walkthrough instead of a demonstration.
Instead Watching somebody deploy is not the same as deploying. Every step the incoming team has not personally performed is a step that has not been transferred.
Assuming the repository is the whole system.
Instead Ask explicitly what runs that is not in it: scheduled tasks on a server, a script on somebody's machine, a cloud function created in a console, a spreadsheet somebody maintains.
A gap between the two teams.
Instead Overlap them. If the outgoing team leaves on Friday and the incoming one starts on Monday, nobody is responsible for the weekend, and neither will be responsible for anything discovered in month two.
#Where 1ADK helps, and where it does not
Where it helps
- An independent technical picture, without giving anybody repository access.
- Gaps made explicit, as a specific question list rather than a worry.
- A before-and-after comparison across the engagement.
- A record that stays after both teams have moved on.
- Claims a receiving team can check rather than take on trust.
Where it does not
- Transferring accounts and domains. Yours to do, and the sequence matters.
- Proving the system runs. Only running it does that.
- Recovering reasoning, or operational habit.
- Judging code quality, or finding vulnerabilities.
- Negotiating with an uncooperative supplier.
Questions people actually ask
The transfer of accounts and credentials is days. The transfer of understanding is weeks, and it is the part people underestimate by a factor of three or four. A useful planning rule: the incoming team should be able to ship a small change unaided in week two, and that is a milestone worth writing into the contract.
Then everything that is a property of the system is still recoverable and everything that is a property of them is not. Prioritise accordingly: get the picture derived from the code, get every account into company identities, and treat their remaining knowledge as a bonus rather than a dependency.
A limited amount, and not as the main deliverable. Documentation written during a handover describes what the author remembers under time pressure. Use their hours for the things nobody else can supply — reasoning, operational habit, and answers to specific questions — and derive the structural picture from the system itself.
One test: the incoming team, without contacting the outgoing one, deploys a change, restores a backup into a scratch environment, and answers ten questions about the system correctly. If any of the three fails, the handover is not finished, whatever the documents say.