Automation supplier handover: can your team run it without the builder?

Define the takeover before collecting files

Write down what the receiving team will operate and what remains with a supplier. Include the workflow version, connected systems, scheduled runs, business owner and maintenance contact. Decide who handles failures during the changeover. An exported workflow is useful only if somebody can explain where it runs and what authorizes its actions.

NIST’s Cybersecurity Framework 2.0 includes planning for activities after a supplier relationship ends in GV.SC-10. It also addresses supplier responsibilities in GV.SC-02. ^[1] Our recommendation is to turn those broad outcomes into observable acceptance checks for one workflow; this exercise is not a NIST certification.

For a reporting workflow, distinguish collecting source records, preparing a draft and sending it to a client. The receiving operator may need control of the first two while the account lead keeps distribution approval. Keep that boundary explicit during handover. The [weekly reporting guide](/blog/ai-weekly-reports/) describes the underlying reporting process.

Build an inventory someone can verify

Ask for a short inventory with one entry per dependency. Record the account or workspace name, business owner, billing responsibility, access administrator and recovery contact. List the workflow files, prompts, field mappings and installed dependencies that the operator needs. Mark which items are business-owned, licensed or supplied under continuing terms; agree unresolved ownership questions before acceptance.

Keep credentials in the approved secret store. The inventory should contain references and owners, not token values. Ask the receiving administrator to verify access using their own identity. A screenshot of the builder’s settings does not demonstrate that your team can manage the account.

Check platform-specific transfer rules. GitHub says a repository transfer retains associated webhooks, secrets and deploy keys; existing collaborators also remain, including the original owner as a collaborator. ^[2] If your implementation uses GitHub, treat transfer and access review as separate checks. Do not assume other platforms transfer the same assets or permissions.

Record an exception for anything that cannot move, including proprietary supplier components. Agree whether the replacement is continued licensing, a rebuild or a manual step. Put the expected cost and responsible person beside the exception. Avoid promising portability before the receiving operator has tried the exported material.

Worked example: take over an agency report draft

Imagine a five-person agency taking over a workflow that reads an approved task export and prepares an internal report. All names and records in this exercise are fictional. The outgoing builder provides version R7, its configuration instructions and a record of pending runs. The agency operations lead becomes the receiving operator; the account lead remains responsible for approving client distribution.

Create fixture HANDOVER-01 with three deliverables: T1 complete, T2 awaiting feedback and T3 blocked. The expected draft contains one item in each state, with those three identifiers. The receiving operator loads R7 into an isolated test environment and connects only the synthetic source. External sending stays disabled. They prepare the report using the written instructions while the builder observes without operating the controls.

Next, remove the synthetic source and run fixture HANDOVER-02. The expected output is an explicit unavailable-source status routed to the operator. The draft must not recycle the earlier counts as current information. Then use the documented pause control and verify that a scheduled test event does not start new processing. Record what happens to an already-running test separately, because stopping future triggers may leave current work active.

The acceptance record should contain the workflow version, fixture ID, expected result, actual result and evidence location. For this example, a successful exercise means the operator can produce and inspect the draft, recognize the collection failure and demonstrate the documented pause behavior. These are proposed pass conditions, not results of a real deployment. A failed check becomes an open item with an owner before live takeover.

Account for unfinished work at changeover

Before the agreed changeover, identify queued jobs, active runs and drafts awaiting approval. For each item, record its identifier, last verified step and the operator who will resolve it. Reconcile any external action with the destination system before deciding to replay it. An uncertain send needs investigation; a fresh installation does not make it safe to send again.

Assign one operator authority over the live schedule. Document when the old schedule stops and when the receiving schedule may start. If you need comparison runs, send their outputs to an isolated review destination. Check that the outgoing copy cannot continue writing after takeover. Our [duplicate-action guide](/blog/prevent-duplicate-ai-actions/) explains why retries need their own controls.

Plan credential replacement and supplier access removal with the authorized administrator. Test replacement access before the agreed removal, then verify the retired identity no longer has the intended access. Check retained exports and stored outputs separately. Removing an account does not establish that every previously copied file has been deleted. Keep the agreed data-return and retention responsibilities in the handover record.

Accept the evidence and name tomorrow’s owner

Close the handover with a named operator, backup contact and a list of unresolved exceptions. Agree the first live run’s reviewer and the manual fallback if it fails. Record which support work is included, what needs a new agreement and who pays for ongoing platform usage. Specific response commitments belong in the agreed scope, rather than being assumed from a support label.

A takeover test covers only the version, fixtures and environment you exercised. It does not prove every future report will be accurate or that every connector can be transferred. Some managed platforms require provider assistance; contractual rights and technical administrator access are separate questions. If the receiving operator cannot safely maintain the workflow, keeping a scoped maintenance service may be the sensible choice.

Use the [reporting demo](/demos/) to discuss the kind of workflow you want to operate, then bring the ownership question into scoping. For help planning a handover, use the [Croissant contact form](/#contact) with the source tools, intended operator and action that must remain approved. Keep private client records and credentials out of the enquiry. A tidy recipe is helpful; the receiving cook still needs to try it.

Implementation checklist

• Name the receiving operator, business owner and maintenance contact.
• Inventory workflow versions, dependencies, account control and licensing exceptions.
• Verify receiving access without placing credentials in handover documents.
• Run synthetic normal, unavailable-source and pause tests without the builder operating.
• Record expected and actual results with evidence for each acceptance check.
• Reconcile pending jobs and external actions before replay or schedule changeover.
• Verify the outgoing schedule and retired access can no longer perform the agreed actions.
• Agree the first live review, manual fallback and remaining support responsibilities.