How to use it
- 01
Describe what changes hands
Name the system, who is passing it on and the date their involvement ends. That date is the deadline for every missing line, because afterwards answers depend on goodwill.
- 02
Mark strictly
Have means it is in your own account or you have used it yourself. Promised, emailed last year or on someone's laptop all count as missing. Partly should come with a note of what is absent.
- 03
Start with accounts and keys
Send the missing lines under accounts first. Hosting, domains, store listings and signing keys are the items that cannot be recreated if the outgoing team becomes unreachable.
- 04
Prove it with a release
When the lines read have, publish a harmless change through the whole chain yourself. If that works, the handover is real. If it fails, the failure shows which line was not what it seemed.
What a complete takeover consists of
Software is more than its code. A system changes hands properly only when five kinds of thing have moved, and a gap in any one of them can leave you unable to update or even run it.
| Part | What it settles | Why it matters |
|---|---|---|
| Code | The repository and everything needed to build it | Without a clean build, nobody new can change the system safely |
| Accounts | Hosting, domains, stores, keys and services, in your name | Whoever holds the accounts controls the product |
| Data | The database, backups, files and a place to test | User data is the part that cannot be rebuilt |
| Knowledge | How it is structured, released and repaired | It leaves with the people unless it is written or recorded |
| Rights | The agreement, licences and subscriptions | They decide what you may do with what you hold |
A worked example
A hire company inherits its booking system
The example is an invented vehicle hire company whose only developer is leaving. Load it to see the full record. It is an uncomfortable one, which is the point of making it early.
- CodeThe repository exists but nobody knows whether it matches what is live, and no one else has ever built it.
- AccountsHosting is on the developer's own account, and two paid services run on his personal card. These go to the top of the list.
- KnowledgeOne contact and partial setup notes. A recorded walkthrough is requested for the following week.
With a month in hand, every missing line can still be closed. The same record made a month later would be a list of things to reconstruct without help.
What this tool does not do
The checklist shows the state of a handover. It does not assess what you receive.
- It cannot tell you whether the code is good. An independent review does that.
- It does not transfer anything. Each account has its own process, and some need the current holder to act.
- It is not legal advice on rights to the code. Have the agreement read by a legal adviser.
- Nothing is uploaded. The record stays in this browser until you export it.
What to do with the finished document
Send the missing and partly lines to the outgoing team today, with a date for each. If the handover has already gone wrong, send us the record and we will say what can still be recovered. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
When should we start the takeover checklist?
As soon as you know the system will change hands, and ideally while the outgoing team is still under contract. Every missing line is easy to close when the people who hold it are being paid and are available. The same request made after they have left depends on their goodwill and their memory.
What if the previous developer will not cooperate?
Put requests in writing, refer to your agreement and prioritize accounts and keys, which matter most. Many standoffs are about unpaid invoices and can be settled by agreeing what is exchanged for what. If that fails, take legal advice promptly. An independent assessment can tell you what is recoverable from what you already hold.
Is having the source code enough?
No. Code without the accounts cannot be deployed. Code without build instructions may take weeks to get running. Code without the data is an empty system, and code without signing keys cannot update an existing app. The checklist has five parts because each of them can stop you independently.
What does publishing a trivial change prove?
It proves the whole chain at once: that the repository is the right one, that it builds, that you hold the deployment accounts and keys and that the release reaches users. A change as small as a corrected word is enough. It is the only test that distinguishes holding a system from holding files.