English
Build your map

Free tool

Could another team take this system over?

Nineteen questions with factual answers. At the end you get three named groups — not a number — and a specific list of what to establish before a handover rather than during one.

Build your map

of answered

Where this leaves you

Confirmed

Established, ideally by having done it rather than by having been told.

Not confirmed

Known gaps. Each one has a specific first move in the guidance beside it.

Needs checking

Not yet asked. This pile is usually the largest, and every item in it is checkable this week.

Ownership

The only part of a handover that can leave you permanently worse off. Everything else costs time; this can cost you the ability to operate.

Is the domain registered to an account your company owns?

Not "do you have access" — whose name is on the registration, and does the recovery address go to a company mailbox?

If confirmed Good. Check the recovery email and phone on the registrar account too; a company account with a personal recovery address is not a company account.

If not confirmed Fix this first, before anything else on this page. Losing the domain means losing the product, the email and every integration that resolves to it. Registrar transfers take days, so start now.

If needs checking This is checkable in ten minutes. Open the registrar, look at the account holder and the recovery contacts, and write down what you find.

Is the production cloud account or organisation owned by your company?

A sub-account inside a supplier organisation is not yours, however much access you have been given.

If confirmed Confirm the root account credentials are held by the company and that billing goes to a company payment method.

If not confirmed This is a transfer, not a permissions change, and it has a process. Raise it while the relationship is still comfortable rather than during a notice period.

If needs checking Look at who receives the invoice. That usually settles it faster than asking.

Is the source repository in a company-owned organisation, with its full history?

A squashed snapshot handed over as a zip is not the repository — the history is where a new team finds out why things are the way they are.

If confirmed Also confirm that at least two people in the company have owner rights on the organisation.

If not confirmed Ask for the organisation to be transferred, or for the repository to be moved with history intact. This is normally uncontroversial.

If needs checking Check who the organisation owners are, and whether the commit history goes back to the beginning of the project.

Are the third-party service accounts — payments, email, storage, monitoring — in company names?

These accumulate one at a time, each created by somebody in a hurry, and nobody ever audits the list.

If confirmed Keep a list of them. It is the first thing anybody will ask for during due diligence.

If not confirmed List them and move them one at a time. Payment provider and email first: those carry money and customer contact.

If needs checking Start from what the system actually calls. An integrations map is the fastest way to get a list you have not just remembered.

Operability

The rule here is demonstration, not description. A step nobody outside the current team has personally performed has not been transferred.

Has somebody outside the current team got the system running locally, from the instructions alone?

From the instructions alone. Being walked through it by the person who wrote it proves nothing about the instructions.

If confirmed That is a real result. Note how long it took — it is the best estimate you have for onboarding anybody else.

If not confirmed Try it. It is the cheapest test on this page and it usually finds two or three undocumented steps.

If needs checking If nobody can name the person who last did it, the answer is no.

Has somebody outside the current team deployed to production?

Having the credentials is not the same as having done it. Release processes accumulate steps that live in one person's habit.

If confirmed Good. Make sure it is written down as it was actually performed, not as it is remembered.

If not confirmed Arrange a supervised release now, while the people who know are still available and relaxed about it.

If needs checking Ask directly who has deployed in the last three months. If it is one name, that is your answer.

Is there a rollback procedure that somebody has actually used?

A deployment process without a tested way back is a one-way door under pressure.

If confirmed Check whether it covers database changes as well as code. That is usually where it stops working.

If not confirmed Write it down and rehearse it once. It takes an afternoon and it is the difference between a bad hour and a bad week.

If needs checking Ask what happened the last time a release went wrong. The answer describes your real rollback procedure.

Is there a list of every environment that exists, and what is deployed to each?

Staging environments that nobody remembers tend to hold real customer data.

If confirmed Check the list against the cloud console rather than against memory.

If not confirmed Build it from the cloud accounts, not from a conversation. The forgotten ones are the point.

If needs checking Look for anything running that is not accounted for. That is where this exercise pays.

Recovery

A backup nobody has restored is a belief. This section is short because it only contains things you either did or did not do.

Are backups running, and does somebody check that they are?

Backup jobs fail quietly. A configuration that was correct two years ago is not evidence about last night.

If confirmed Confirm that a failure raises an alert somebody actually receives.

If not confirmed This is the highest-value thing on this page after domain ownership.

If needs checking Find the last successful backup and its timestamp. If nobody can produce it in an hour, treat the answer as no.

Has a backup been restored into a working environment in the last six months?

Restoring is a different operation from backing up, and it is the one that fails.

If confirmed Record how long it took. That number is your real recovery time, and it is usually a surprise.

If not confirmed Do it into a scratch environment. This single exercise finds more real problems than any audit.

If needs checking Nobody forgets restoring a backup. If it is uncertain, it did not happen.

Are production credentials held somewhere the company controls, rather than in one person's tooling?

A shared vault the company owns; not a personal password manager, and not a spreadsheet.

If confirmed Confirm that at least two people can reach it and that a departure procedure exists.

If not confirmed Move them into a company-controlled store, then rotate everything. In that order.

If needs checking Ask where the production database password is. The answer tells you the whole picture.

Understanding

This is the part that decides how long a handover takes. It is also the part that is almost never measured before one starts.

Is there a current, written account of what the system is made of?

Current means it describes the system as it is now, not as it was at some point somebody remembers.

If confirmed Check when it was last verified against the system rather than last edited. Those are different dates.

If not confirmed This is derivable in hours rather than weeks, and it makes every other conversation in a handover shorter.

If needs checking If you cannot name the document and its date, the answer is no.

Is there a list of every external service the system needs in order to work?

Including the ones added years ago by somebody who has left, and the outbound integrations nobody thinks about.

If confirmed Add a column for whose account each one is in. That is the version that matters.

If not confirmed Derive it from the system rather than assembling it from memory — memory reliably omits the interesting ones.

If needs checking Ask two people separately and compare the lists. The difference is the answer.

Do you know everything that runs on a schedule, and what each one does?

Scheduled work is the category with the highest ratio of "nobody knew that existed" to size.

If confirmed Confirm each one has a named owner, and that somebody would notice if it stopped.

If not confirmed Look in the codebase, the cloud console and the server crontabs. All three, because they rarely agree.

If needs checking A monthly or quarterly job is easy to miss. Look at a full year of logs if you have them.

Do you know where customer data lives and what leaves the system?

Outbound flows — a nightly file, an analytics integration, a partner feed — are both a regulatory question and an operational one.

If confirmed Check the destination of each outbound flow is still somebody you have a relationship with.

If not confirmed Start with the outbound side. Inbound is easier to reconstruct later.

If needs checking Where a file is written to a location configured outside the repository, nobody can answer this from the code alone. That is worth knowing explicitly.

Is there any part of the system only one person can explain?

Answer yes here if the answer is "no single points of failure", not if there is one.

If confirmed Good, and unusual. Verify it by asking somebody else to explain the riskiest part.

If not confirmed Count them, name them, and get the reasoning out of those people while they are still reachable. This is the most valuable list you will make.

If needs checking Go part by part and write down who could answer a hard question about each. Twenty minutes, and it is always revealing.

The transfer itself

Whether the mechanics of a handover have been thought about at all, as opposed to assumed.

Does the contract say what happens on termination — accounts, deliverables, notice, a handover period?

Find out now, when it is a question. Later it is a negotiating position.

If confirmed Check that it names acceptance criteria rather than only deliverables.

If not confirmed Add it at the next renewal, for the current supplier and every future one. It protects both sides.

If needs checking Read the termination clause today. It takes ten minutes and it changes how you plan.

Is there a planned overlap in which both teams are available?

A gap between the outgoing and incoming teams is where everything that was assumed turns out not to be true.

If confirmed Use it for demonstration — deploy, restore, ship a change — not for presentations.

If not confirmed Plan and pay for one. It is the cheapest insurance in a transition.

If needs checking If nobody has said how long it is, it is not planned.

Is there a written list of the questions only the outgoing team can answer?

Specific written questions get answered in a leaving week. "Please write documentation" does not.

If confirmed Get the answers in writing, and keep them somewhere other than an inbox.

If not confirmed Build it from the gaps in your technical picture. Those gaps are exactly the list.

If needs checking If it is not written down, it does not exist, and you will remember it three weeks after they have gone.

Your answers stay in this browser. There is no server behind this page: nothing is submitted, no account is needed, and no email address is asked for. Clearing the page or pressing “Start again” removes them.

  • 19 questions
  • about 10 minutes
  • no account, no email
  • nothing is submitted
Free tool Reviewed

Short answer

A handover is ready when another team can deploy the system, restore it, and answer questions about it without contacting the people who built it. This check works through the five things that decide whether that is possible: who owns the accounts, whether anybody outside the current team can operate it, whether recovery has been tested, whether the system is understood, and whether the transfer itself has been planned.

#What this checks, and why these nineteen

The questions are chosen so that every one has a factual answer — something a person could go and establish today. None of them asks how confident you feel, because a handover does not fail on confidence.

They are grouped into the five things that independently decide whether a handover is possible:

  • Ownership — the only category that can leave you permanently worse off rather than merely delayed.
  • Operability — whether anybody outside the current team has actually run, deployed and rolled back the system.
  • Recovery — whether a backup has been restored, as opposed to configured.
  • Understanding — whether the system can be described by anybody, and where the single points of failure are.
  • The transfer — whether the mechanics have been planned or assumed.

#How it decides

There is no model, no weighting and no hidden arithmetic.

Each question goes into one of three groups according to your own answer, and each group carries the guidance written for that answer. That is the whole mechanism. The value is in the questions and in what is written beside them, not in a calculation.

Why not a score

A composite number over nineteen unrelated facts is not meaningful. "Nobody has ever restored a backup" and "the third-party accounts are in mixed names" are not commensurable, and averaging them produces a figure that conceals whichever one was going to hurt you. Three named groups keep the individual items visible, which is the only form in which any of this is actionable.

#What a typical result looks like

An ordinary four-year-old product Invented example — not a customer 
CONFIRMED         5
  Domain in a company account
  Repository in a company organisation, full history
  Backups running
  Contract has termination terms
  Environment list exists

NOT CONFIRMED     4
  No backup restored in the last six months
  Nobody outside the current team has deployed
  Production credentials in one person's password manager
  Two subsystems only one person can explain

NEEDS CHECKING    9
  Third-party account ownership
  Everything that runs on a schedule
  Where customer data goes
  ... and six more

This is a normal, healthy company. Nothing is broken. What the result gives it is a specific week of work — restore a backup, have somebody else deploy, move the credentials — instead of a general unease about a handover that has not started yet.

#What this does not do

What this does not do

  • It does not look at your system. Every answer is yours, from memory or from checking — the tool has no access to anything and does not ask for any.
  • It is not a score, a rating or a benchmark against other companies.
  • It does not cover code quality, security, performance or architecture.
  • It does not cover the commercial side of a handover — contracts, intellectual property, notice periods.
  • A confirmed answer is only as good as what it was based on. “We have backups” answered from memory is not the same fact as “I restored one on Tuesday”.

#What happens to your answers

Nothing leaves the page. There is no endpoint behind this tool, no analytics event carrying your answers, and no email field. Your answers are kept in this browser so that a reload does not lose them, and pressing Start again removes them.

That is a property of the code rather than a promise: the page makes no network request when you answer a question, which you can confirm in your browser's own developer tools.

Questions people actually ask

No. There is no account, no email field and no server behind this page. Answers stay in your browser and are removed when you press Start again.

Because a number hides the one line that mattered. "Confirmed / not confirmed / needs checking" is a result you can take into a meeting; 73/100 is not.

That is the most common result and it is genuinely useful — it means the questions have never been asked, which is different from the answers being bad. Each one is checkable this week.

Yes. The print button produces a clean version with your answers and the guidance that applies to them, and it works as a PDF export in every browser.

You answered from memory. Now check the system.

Several of these questions have answers that are properties of the code rather than of anybody's recollection. One read-only instruction produces the map, the dependencies and an explicit list of what nobody can confirm.

Build your project map — free Read the handover guide