The order matters more than the checklist. Most of what goes wrong in a difficult handover happens in the days around giving notice, when access is still in someone else's hands and goodwill has just evaporated. Everything you secure before that conversation is cheap; almost everything you ask for after it is a negotiation.
This is written for the awkward case. If the relationship is ending well, the same list applies with less urgency.
Key takeaways
- Secure access before you give notice: Domains, app store accounts, cloud accounts and the repository.
- Four things are hard to recover afterwards: Undocumented knowledge, third-party accounts, signing keys and the reasoning behind decisions.
- Pay for a proper handover if you can: It is almost always cheaper than reconstructing.
- Do not start the rewrite conversation yet: Understand what you have first.
Before you say anything
Confirm who owns the accounts
Work through every account the product depends on and establish whose name is on it: domain registrar, DNS, hosting or cloud, app store developer accounts, payment provider, email and SMS services, analytics, error monitoring.
It is common for some of these to sit in a supplier's name, sometimes for legitimate practical reasons. Recovering a domain or an app store account from an uncooperative party is slow and occasionally impossible, and until it is resolved you cannot ship an update. This is the single most important item on the list.
Get your own access to the repository
Not a copy sent to you, an account of your own, on an organisation you control, with the full history. The history matters: it is the only record of why things were done, and a zip file of the current state throws it away.
Take a copy of the data
A current export, in a format you can read, stored somewhere that is not the supplier's infrastructure. Do this even if you are confident, because it costs an hour.
Write down what you do not know
Before the conversation, list the questions only they can answer. How deployment works, what the scheduled jobs do, which third-party accounts exist, what breaks regularly and how it is fixed. Once notice is given, you get a limited number of questions answered with real effort, so know what they are.
What to ask for during the handover
Ask for these in writing, with a date:
- A runbook. How to deploy, how to roll back, what to do when the common failures happen.
- Environment setup. The steps to get the system running from nothing, tested by someone following them.
- Credentials and keys. Including signing keys for mobile apps, which cannot be regenerated without consequences for existing users.
- Scheduled and background jobs. What runs automatically, when, and what it touches.
- Known issues. The problems they live with and the workarounds in use.
- Decision notes. Why the significant choices were made. This is the most valuable and the least likely to be offered.
The realistic version of this is a paid handover period of one to four weeks. It feels like paying a team you are unhappy with, and it is still usually the cheapest option available, because reconstructing this from the outside costs several times more.
The four things you cannot get back later
Undocumented knowledge. The reasons, the near-misses, the thing that looks wrong but is deliberate. This leaves with the people.
Third-party accounts in their name. Some of these can take months to recover, and a few cannot be recovered at all.
Mobile signing keys. Lose these and you cannot update the existing app; users have to install a new one.
Goodwill. A team that would have answered one email in three months will not answer it after a hostile exit. Preserving the option to ask a question later is worth more than winning the last exchange.
After the handover
Do not commission a rewrite in the first month. A new team looking at unfamiliar code will usually recommend replacing it, partly because that is genuinely easier for them and partly because unfamiliar code always looks worse than it is.
Get an independent read of the condition first. That gives you a baseline to judge any rewrite proposal against, and it is exactly the moment an audit earns its cost. We cover what that involves in what a technical audit is and when to commission one.
Then take one small, real change through the whole process: modify something minor, deploy it, watch it work. Everything you did not know is revealed by that exercise faster than by any document.
Ali Boran Gazel