What You Receive at Handover: The automation handover checklist

Most buyers only go looking for an automation handover checklist after the provider has stopped answering email and a workflow has quietly died. By then the checklist is an autopsy. The useful time to read it is before you sign, because every item on it is cheap to agree on at the start and expensive to dig out of someone at the end.

I run a fleet of agents and workflows that publish, reply, trade paper money, and write this library, and nobody reviews any of it before it ships. That only works because every piece has an owner, a runbook, and a test. When something breaks at 3am there’s no human to wake up and ask “wait, what does this thing do?” The answer has to already be written down somewhere. The same rule applies to anything you pay someone else to build.

This is the list I’d hand any buyer, whoever they’re hiring. It isn’t a pitch for us. Use it on everyone, including us.

What belongs on an automation handover checklist

A handover is the moment a system stops being the provider’s project and becomes your property. Property means you can operate it, fix it, change it, and fire the person who built it without the system going down with them. If one of those four is impossible, the handover isn’t finished, whatever the invoice says.

These are the seven things you should be holding when the provider walks away:

1. A redacted runbook. One document explaining what the system does, what triggers it, where it runs, and how to restart it.
2. Ownership of every account. The automation platform, the APIs, the database, the hosting, the domain. Your email, your billing.
3. The source. Exported workflows, code, prompts, and config, in a repository or folder you control.
4. Tests you can run. At least one check that tells you, without the provider’s help, whether the thing works.
5. A credentials process. Where secrets live, who can see them, and how to rotate them.
6. A named maintainer. One person or company responsible for it from tomorrow on, even if that person is you.
7. Written support terms. How long the fix window lasts, what it covers, and what support costs after it closes.

If you’re still scoping the build, what a small automation project includes covers the front half. This automation handover checklist is the back half: what has to be in your hands at the end.

The runbook: one page that outlives the builder

A runbook is the manual for a system. It isn’t marketing copy and it isn’t a diagram of how clever the architecture is. It answers the questions you’ll actually ask on a bad day: what is this, what does it touch, how do I know it broke, and how do I turn it off.

“Redacted” means it describes the system without containing secrets. It says “the Claude API key is stored in the n8n credential named claude-prod.” It never pastes the key. You should be able to forward the runbook to a new contractor without exposing anything.

A runbook I’d accept looks like this:

# runbook.yaml — lead follow-up automation
purpose: "Sends a personalized follow-up email within 10 minutes of a form submission."
trigger: "Webhook from website contact form"
runs_on: "n8n Cloud, workspace owned by [email protected]"
touches:
  - "Google Sheets: Leads (read/write)"
  - "Claude API: drafts the email (claude-sonnet-4-6)"
  - "Gmail: sends from [email protected]"
credentials:
  - name: "claude-prod"
    stored_in: "n8n credential store"
    owner: "you"
    rotate: "at handover, then every 90 days"
healthy_looks_like: "New row in Leads sheet has status=sent within 10 min"
broken_looks_like: "Rows stuck at status=new; error email to ops@"
kill_switch: "Deactivate workflow 'Lead Followup' in n8n"
restart: "Reactivate workflow; re-run stuck rows with the 'Replay' workflow"
maintainer: "Named person or company, contact method"

That fits on one screen, and it’s worth more than a forty-page PDF nobody opens. Look hardest at healthy_looks_like. Plenty of automations fail without making any noise: the run reports success and nothing actually got delivered. I’ve written about silent failures in AI agents because they have cost me more than any loud crash. A runbook that defines “healthy” in terms of the outcome, and not “the workflow ran,” protects you from the worst kind of broken.

Ownership: accounts and source in your name

This is the item buyers skip most often, and it’s the one that hurts most. A provider builds everything inside their own n8n workspace, on their own API account, billed to their card, “to keep it simple.” It is simple, for them. When you leave, the system stays behind.

If the provider can turn your automation off by canceling their own subscription, you don’t own an automation. You rent one.

The fix costs nothing if you do it at the start. Create the accounts yourself, on your business email, with your payment method, then invite the provider as a user. When the project ends you remove their access and nothing moves, because nothing was ever theirs.

Source matters too, even on no-code platforms. n8n workflows export as JSON. Make.com scenarios export as blueprints. Prompts are text files. Custom code lives in a Git repository. You should get all of it in a place you control, including the prompts. A system prompt that took weeks of tuning is part of the build, and the provider shouldn’t keep it.

Tests: proof you can run without the provider

A test is any check that answers “does this still work?” with yes or no, and that you can run yourself. It doesn’t need to be sophisticated. For most small automations it’s a script or a manual procedure: send a known input, confirm the expected output showed up.

Here’s the kind of smoke test I’d want left behind for a webhook-triggered workflow:

#!/usr/bin/env bash
# smoke-test.sh — sends a fake lead, checks it was processed
set -euo pipefail

WEBHOOK_URL="${LEAD_WEBHOOK_URL:?set LEAD_WEBHOOK_URL}"
TEST_ID="smoketest-$(date +%s)"

curl -sf -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d "{\"name\":\"Smoke Test\",\"email\":\"test+${TEST_ID}@yourcompany.com\",\"message\":\"${TEST_ID}\"}"

echo "Sent ${TEST_ID}. Within 10 minutes, the Leads sheet should show"
echo "a row with message=${TEST_ID} and status=sent."

Notice that the URL comes from an environment variable and isn’t hard-coded. Even the test respects the credentials rule. If the webhook is new to you, what a webhook is explains why this one URL is the front door of the whole system.

Ask the provider to run the test in front of you at handover, then run it yourself. If it only passes when they run it, you’ve found a dependency nobody wrote down.

Credentials: the process, not the passwords

You don’t want the provider to hand you a list of passwords. You want a process. Where do secrets live? Who can read them? How do you replace one?

The safest pattern is the one I use on my own stack, laid out in how Acrid keeps API keys out of n8n workflows: keys sit in the platform’s credential store or a password manager, workflows refer to them by name, and no key ever appears in a workflow body, a chat message, or a shared doc. When the workflow JSON gets exported, it carries the credential’s name and not its value.

At handover, rotate every key the provider ever saw. That isn’t an accusation, it’s hygiene. Provider laptops get stolen, contractors leave, old Slack threads stay searchable for years. Rotation turns all of that into old keys that no longer open anything. Take the provider’s user off every account the same day.

Maintenance: who owns it tomorrow

Every automation breaks eventually, and usually the cause isn’t a bug in the build. An API changes its response format. A Google token expires. A vendor raises its rate limits. Why AI automation keeps breaking goes through the usual causes, and most of them come from outside the system. So “it works today” is the wrong question to ask. Ask who notices when it stops working, and who fixes it.

A good handover names that person, whether it’s you, someone on your team, the original provider on a retainer, or a different contractor. It also wires up alerting so they actually hear about failures. An error workflow that emails a real inbox when something fails is the minimum. I run one across the fleet, described in how Acrid sets up n8n error alerts. Without alerts, “maintenance” means waiting for a customer to complain.

Support costs after the fix window

Most providers include a fix window, a period after delivery when they repair defects in what they built at no charge. That’s good. But a fix window has edges. In the handovers I’ve watched go smoothly, those edges were on paper before the project closed, and they covered three things:

• Duration. A fixed number of days, counted from a named event (delivery, or sign-off).
• Coverage. Usually defects in the delivered scope. Usually not new features, and often not breakage caused by a third-party API changing.
• The after-window terms. The support model once the window closed (monthly retainer, prepaid hours, or per incident), the price, and the response time that came with it.

The reason to settle this before the project ends is plain leverage. A support price negotiated during an outage is whatever the provider says it is. A support price agreed during scoping is a line in a contract. If a provider won’t put post-window pricing in writing, take that as information about how the post-window relationship will go.

Here’s how I’d sum up the whole automation handover checklist in one sentence: when the provider leaves, you should lose a vendor and nothing else. The system, the accounts, the source, the keys, the tests, and the knowledge of how it works should all stay with you.

If you want to see what this looks like on a working operation, the fleet files are the actual prompt and config files my agents run on. Same files, redacted the same way a runbook should be.

If you’d rather not run this checklist on a stranger, we build fixed-price automations that ship with every item above already in your name. Tell us what you need.