Vora
Agree what ends and what transfers
Some clients stop the service entirely. Others move it in-house or to another agency. Those situations require different decisions about credentials, scheduled work and historical records.
Record the effective cutover time, including the time zone. Name the client's receiving owner and the agency operator who will carry out the changes. Identify any service that must continue during a transfer, along with who responds if it fails.
Start with a shared inventory:
| Asset or obligation | Decision to record | Evidence for the handover |
|---|---|---|
| Workflows and configuration | Transfer, archive or remove | Versioned export and receiving owner's review |
| Pending jobs and reminders | Finish, transfer or cancel | Item list with an owner and final disposition |
| Numbers, domains and endpoints | Transfer or release | Provider-side status and effective time |
| Provider accounts | Client-owned, agency-owned or shared | Billing owner and administrative contact |
| Credentials and user access | Reissue, revoke or remove | Scoped access check after the change |
| Client data and execution history | Export, retain or delete by category | Location, action, evidence and exceptions |
| Continuing charges | Cancel or move payment responsibility | Cancellation or transfer confirmation |
Shared infrastructure needs particular care. Removing a client from a shared account should not delete another client's records or cancel their subscription. Identify the boundary before changing the resource.
This inventory also belongs in planning a first-client deliverable. Decide ownership while the accounts are being created.
Stop new work and account for the queue
Choose what happens to requests arriving after the cutoff. A form can show the client's replacement contact route. A caller may need a staffed number. Test whichever route the client has approved.
Then inspect work that entered earlier. Include scheduled runs, delayed messages, retry queues and jobs waiting for approval. Check provider-side schedules as well as your own automation dashboard.
Imagine a hypothetical client ending an appointment-reminder service on Friday. The agency disables the agent and sends the exported workflow. A reminder is still scheduled for the following week, and a phone number remains on the agency's bill.
For each pending item, record the last completed step and any external result. A request marked failed may already have created a CRM record. A sent message cannot be unsent by deleting its local job.
Transfer ownership explicitly when another operator will continue a job. Preserve the request identifier, destination account and evidence of completed actions. The receiving system needs to distinguish work still required from work already performed.
If the client cancels the remaining jobs, verify that no worker can resume them. Keep an appropriate record of the cancellation without retaining unnecessary customer payloads. If a provider action remains uncertain, give it a named owner and a deadline for investigation.
For a service that continues elsewhere, use the migration checklist to plan the routing change and rollback. Avoid treating a transfer as a simple account shutdown.
Hand over something the client can use
Ask the receiving owner to open the export and inspect a controlled run before your access ends. They need the configuration, field mappings, knowledge sources and operating instructions relevant to their service.
Keep customer records and secrets out of a general handover folder. Use the agreed secure transfer method for sensitive material. n8n documents that exported workflow JSON can include credential names and IDs, and that some HTTP Request nodes can contain authentication headers. Review exports before passing them on.
An inventory entry saying “credentials transferred” is often too vague. Record who owns each connection and how the receiving operator establishes authorized access. Where possible, have the client create or authorize the connection in the account they will control.
Leave the client a short operating note: what triggers the workflow, where results appear, how failures surface and who now handles them. Include a known test request with synthetic data. The post-call testing guide shows how to compare a promised outcome with the saved record when the transferred service includes voice.
If the client requests new behavior during the transfer, record it through the scope-change guide with its effect on effort and timing.
Remove access at the provider as well as locally
Review human accounts, API keys, OAuth grants, service identities, webhook secrets and recovery contacts. Removing a credential from an agency interface is one action; revoking the permission held at the provider is another.
Plan the order around continuity. Establish and test the client's replacement connection before retiring the agency's connection when the service must remain available. A suspected compromise may require immediate revocation and a temporary pause instead.
For a connection that fails during this work, follow the OAuth recovery guide before releasing held jobs under the replacement account.
Check the scope of revocation. Review Google's OAuth revocation guidance for the grant you are retiring and its propagation behavior. Check the other workflows that use the same authorization before removing it.
Record the provider's response and check access again after the documented propagation behavior. Use an appropriately scoped test that does not expose client data. Remove local token copies and retire obsolete secrets from the systems that stored them.
Do not leave an agency employee as the client's only administrator or recovery contact. Have the client's owner confirm access from their own account.
Describe deletion by location and evidence
A useful deletion record names the data category, storage location and action performed. It should distinguish active records, derived indexes, execution logs, exported files and backups.
Use the client's agreed instructions and the applicable retention requirements when deciding what to remove. If a category must remain, record why, who can access it and when it is due for review. Escalate a conflict between those instructions and a retention obligation to the responsible owner before deleting the records.
Read the provider's actual deletion behavior. For example, n8n's execution pruning documentation excludes new, running and waiting executions, as well as annotated executions. Its binary-data pruning applies to the active storage mode. An enabled pruning setting therefore needs checks against the records and storage locations involved.
For backups, record the documented retention and restore process. If the provider does not document whether a deleted record remains in backups, write “not confirmed” and assign follow-up. Do not turn an unknown into a claim that every copy has disappeared.
Keep the completion statement narrow: which systems were checked, which actions succeeded and which exceptions remain. The technical record supports a review; it does not establish that every legal obligation has been satisfied.
Check the bill after changing the service
Review subscriptions, minimum commitments, reserved capacity, rented numbers, storage and separately billed integrations. Identify which charges stop automatically and which require their own cancellation or transfer.
Confirm the effective date and billing owner for each item in the provider account. Record any expected final usage charge and who will review it. An empty workflow dashboard does not show whether a separate resource still incurs charges.
Finish the handover with a short evidence list:
- The client can access the assets and accounts they are keeping.
- New requests follow the agreed route after the cutoff.
- Every pending job has a recorded disposition and owner.
- Agency access has been removed or has a specific documented exception.
- Data actions list completed checks, retained categories and unresolved locations.
- Continuing resources have a named payer or confirmed cancellation.
Keep an owner assigned to the next invoice review. In the reminder example, that person should be able to find the scheduled message's final status and the phone number's billing status without asking the former project team to reconstruct either one.