Automation handover checklist: 10 things you hold at the end

Three of the six rescues we have scoped started the same way: the original builder stopped answering, and every account was in his name. The Zapier workspace, the OpenAI key, the phone number, the hosting. The business had paid for automations that worked and owned none of them. Recovering from that starts with claiming the accounts before anyone touches a workflow.

This is rarely malice. It is what happens when nobody defines what a handover means, so below is our definition: the automation handover checklist we run at the end of every build. Use it with us or with anyone else.

Read it either as a document you walk through on a scheduled last day, or as an inventory on the morning you find out the contractor has already gone. The sections are ordered by how much it hurts to be missing them, and the handover failure that actually ends businesses is ownership rather than code.

The ten things you should hold

1. Ownership of every platform and vendor account, billing included, registered to a company address.
2. Credentials and API keys on one page, with the human whose consent each OAuth connection rides on.
3. Environment variables and secrets, including the ones that exist only inside a running container.
4. Workflow exports as JSON or blueprints, committed to a git repository your company controls.
5. An error workflow on every production flow, with its alert pointed at a living person.
6. Execution history, and the retention setting that decides how long it survives.
7. One page of architecture plus a runbook written for a stressed person at 8 a.m.
8. Test data and a way to run each workflow end to end without touching production.
9. Vendor and API dependencies with versions and any published deprecation dates.
10. A recorded handover call in which somebody walks one real failure end to end.

Most of this already exists on the builder's machine; the work is moving it onto yours.

Account ownership and billing

Start here, because everything else is recoverable if you own the accounts and almost nothing is if you do not. Name the billing owner on the OpenAI or Anthropic account, the n8n or Make subscription, the Twilio or Telnyx account, the hosting, and every Google Cloud or Azure project the build touches. Personal accounts and personal cards are the single most common trap, and they get created by accident on a Tuesday afternoon when somebody needs a key in a hurry and promises to sort it out later.

Transfer billing ownership and add a second owner before the contractor's last day, while he still has a reason to click through the confirmation emails. Google Cloud projects need the Owner role granted and the previous one removed. Twilio subaccounts move differently from full accounts. Some platforms cannot transfer a workspace at all and need a fresh one created in your name with the workflows imported, which is a week of work you want to discover early. Billing on your card also means you see the real running costs, which for most systems lands at $40 to $150 a month across four meters.

Credentials, and whose consent they ride on

Every API key on one page: which service, what it can do, where it is used, where it lives. Two years from now, when one of them expires, that page is the difference between a 20-minute fix and a lost day. Rotate everything the vendor's team touched once the handover is complete, and note that a vendor who bristles at rotation is telling you something.

The part people forget is the OAuth connections, because they do not look like credentials in an inventory. A Gmail or Google Sheets node authorised under a departing employee's account keeps working right up to the moment IT disables that account, and then it dies without a sound. The same goes for a Microsoft connection when a conditional access policy changes, and for anything a contractor authorised through his own personal Google account during testing. Write down the human behind each consent and re-authorise the ones tied to somebody who is leaving. The expiry rules per provider are worth reading before you build the list, because a few of them are shorter than anyone expects.

Environment variables and secrets

Ask for the env file, then ask again for the variables that exist only inside a running container or in the platform's own secret store. Self-hosted n8n has an encryption key, webhook URLs and database credentials that never appear in an exported workflow. A Railway or Render service has variables set through a dashboard that nobody has written down anywhere else. If the server had to be rebuilt from scratch tomorrow, this is the list that decides whether it takes an hour or a fortnight.

Exports in a repository you control

n8n workflow JSON, Make blueprints, a written description of each Zap, and any custom code, all committed to a git repository your company owns. Inside the platform is not a backup, because the platform account is exactly the thing that goes missing when a contractor's card declines. Export on a schedule rather than once at handover, since the copy you were handed in March stops matching production the first week somebody edits a node in a hurry.

Error handling that reaches a person

Walk every production workflow and check two things: whether an error workflow is configured at all, and where its output lands. The second one fails more often. We were called into a lead-routing system failing about once a day at roughly 200 runs a day, and the alerts had been going faithfully to a Slack channel archived months earlier, so nobody had seen one. The importable error workflow on the stopped-working page takes about ten minutes to wire in.

Then deal with the failures that never raise an error. A run that completes with zero items looks identical to a real one in every dashboard, so the check on the silent-failure page watches for the work that should have happened. Both belong to the wider set of reasons automations die in production, and a handover that skips them is handing you a system with the smoke alarms unplugged.

Execution history and retention settings

Your execution list is the only forensic record you have, and it expires. n8n prunes execution data on a schedule governed by EXECUTIONS_DATA_MAX_AGE, which defaults to 336 hours, or fourteen days. Cloud platforms have their own windows, usually tied to the plan. Ask what the setting is on your instance, raise it on anything that touches money or customers, and get the answer in writing, because the first question in any diagnosis is when the failures started, and a pruned history cannot answer it.

Architecture and the runbook

One page showing what talks to what, in what order, and where the data sits. Diagram or prose, either is fine, as long as a competent engineer can read it and orient in ten minutes.

Then the runbook, written for a stressed person at 8 a.m. For each workflow: one sentence on what it does, what it costs to run per month, what a normal day looks like in the execution list (roughly how many runs, roughly how long each one takes), and the handful of things most likely to break it, each with a symptom, a first check, a fix and who to call. The duration line matters more than it sounds, because a run that normally takes twelve seconds finishing in 400 milliseconds is the cheapest silent-failure detector anyone will ever hand you.

Test data and a safe way to run

Ask for a sample payload for every trigger, and for a documented way to run each workflow end to end without sending a real customer a real message. A test mode, a staging webhook, a flag that routes email to a sink address, a sandbox key for the payment provider, whatever the stack allows. Without it, the first time your new maintainer touches the system will also be the first time a client receives something strange, and that is a poor way to open a working relationship.

Vendor and API dependencies

List every external service the system depends on, with the API version in use and any deprecation date the vendor has published. Model names belong here too, since a model pinned in January can be retired with three months of notice that only reaches somebody on a mailing list. Note which endpoints sit on a beta or preview track, because those move without ceremony. This list is what turns an eventual breakage into a calendar entry.

The handover call

Record it. Put someone technical on your side in the room, even a contractor hired for the hour, and decline the slide deck. The useful version of this call is the builder taking one real failure end to end in the live system: break something in a test flow, watch the alert arrive, open the execution, find the error, fix it, replay the payload. Forty minutes of that beats four hours of architecture narration, and the recording is what your next engineer watches on their first morning. Store it with the files rather than in a chat thread that expires.

Deployed on the client's own server

An example of what the export item looks like when it is done properly. A hydrogeology client runs a document generator we built, which as of August 2026 has produced 168 documents and holds 349 boreholes in its database. It lives on the client's own server and ships with one-command deploy scripts, so an update is one line in a terminal and a rollback is the same line pointed at the previous version. If we vanished tomorrow, any Python developer could pick it up from the repository and the scripts in a morning. That is the standard the checklist aims at, and it was cheap to reach.

Why vendors resist

Lock-in is a business model. An agency holding your accounts, keys and billing has turned a project into an annuity: leaving means rebuilding, so the retainer renews regardless of quality. A retainer should have to renew on monitoring, a fix window and a monthly report instead. Some vendors engineer this on purpose. More often it accretes, because a proper handover takes hours at the exact moment the vendor has been paid and wants to move on. Either way the incentive points the same direction, and you should assume it applies until a vendor shows you otherwise.

Why we do the opposite

We run this checklist because it is a better business, and I would rather say that plainly than dress it up as principle. A client who can fire us any day and lose nothing renews because the monthly work is visibly worth it. Hostage retention produces resentful clients and ugly endings; usefulness produces referrals. The checklist also disciplines our own builds, since a system has to be documented and transferable to pass it, and that same quality is what makes it maintainable for us.

Where the checklist matters less: a single Zap that copies form submissions into a spreadsheet. Rebuilding that takes an afternoon and ownership is not worth a meeting. The list earns its hours once a rebuild would take weeks or the system touches customers directly.

Ask before you sign

One question tests all of it, and it belongs with the other questions worth asking before you hire an AI agency: "Can you show me your handover checklist?" A vendor who does this has one within reach and will send it, because it is a selling point. A vendor who improvises an answer about "full documentation at project close" has no process, whatever the proposal PDF says.

Two follow-ups take five minutes:

• Whose name will the platform accounts be in on day one? The right answer is yours, from the start. "We will transfer them later" is a no.
• If we part ways in month six, what do I keep, and how long does the transfer take? The right answer is that there is nothing to transfer because you already hold everything.

Get the checklist named in the contract as a deliverable with its own line, alongside the payment terms. Handover work that has no money attached to it is the work that slips, whether the engagement is hourly or fixed price.

If they have already gone

None of the above helps on the morning you discover the contractor is unreachable and the invoices are landing on a card you cannot see. The order changes then. Claim the accounts first, using password resets against the email addresses on file and the billing card as proof of ownership where a support desk asks for it. Export everything you can reach the moment you are in. Only then start fixing, because there is little point repairing a workflow inside an account somebody else can still delete.

The step-by-step version of that recovery is written up separately, and reclaiming accounts, exporting workflows and writing the missing documentation is what our rescue service exists for.