Handing over an automation: a checklist for your business

After an automation project, the business must own more than the running workflows. That includes the workflows as a copy outside the system, the access to the connected programs, the key without which stored passwords are unreadable, and a description that a third party can read. An export of the workflows alone is not enough for a handover, and a missing key is particularly costly.

What this is about

A workflow is a defined sequence of steps that a program carries out by itself, for example from an enquiry arriving through a form to a message to the office administrator. What that means in a small business is explained in Process automation in a small business. The example tool is n8n, which a business can run itself on its own or a rented server (self-hosting). The technical statements come from the manufacturer’s documentation (as of November 2026). With other tools the same question arises, and the answers are in their documentation. The author has not checked the cloud service.

What the BSI says about the end of an outsourcing

The Federal Office for Information Security (BSI) describes in the IT-Grundschutz Compendium, Edition 2023, how institutions secure the outsourcing of IT. Module OPS.2.3 states: “However, responsibility from the point of view of information security always remains with the outsourcing institution” (author’s translation). As a threat it names missing rules for the end, which can lead to “hardware, data and access” not being handed over to the customer, or not properly (author’s translation).

Requirement A7 demands rules for planned and unplanned termination and a definition of how all information, data and hardware are returned, observing statutory retention obligations. It should be checked whether the provider’s access rights were revoked with the end. A14 adds that contracts should contain termination options and regulate how the customer’s property is returned.

The module addresses institutions. Whether it is binding for your business, for example through a customer contract, is an individual question. It still works as a yardstick. For the case that the provider fails, A20 calls for joint emergency plans.

What technically belongs to it

Item	What belongs to it according to the n8n documentation
Workflows	Export on the command line, one file per workflow (export:workflow --backup)
Credentials	Export of the stored credentials (export:credentials --backup), encrypted
Key	File config in the folder .n8n or the environment variable N8N_ENCRYPTION_KEY
Users and roles	not in the export; roles according to user management: Owner, Member, more depending on the plan
Full backup	Folder .n8n, with PostgreSQL also the database, external storage, directories of custom extensions, the business’s configuration

With the default database SQLite, n8n should be stopped before copying, otherwise the backup may be unusable.

The export is not the handover

According to the documentation, the export with --backup contains only workflows and credentials. It does not contain users and their roles, the execution history, variables and the instance settings including the key. After importing into a fresh installation the set-up of the owner account appears again, and whoever completes it first becomes the owner.

1. KeyWithout it, stored credentials are unreadable
2. Full backupFolder, database, configuration, restore test
3. ExportWorkflows and credentials, nothing more
4. Accounts and usersAccounts owned by the business, provider access ended
5. DocumentationPurpose, owners, failure case, change log

Text version of the graphic

• Layer 1 from the bottom: Key, Without it, stored credentials are unreadable
• Layer 2 from the bottom: Full backup, Folder, database, configuration, restore test
• Layer 3 from the bottom: Export, Workflows and credentials, nothing more
• Layer 4 from the bottom: Accounts and users, Accounts owned by the business, provider access ended
• Layer 5 from the bottom: Documentation, Purpose, owners, failure case, change log

The key is created at random on first start and sits in the folder .n8n. n8n uses it to encrypt the credentials before storing them in the database. Without it, according to the documentation, a restored database and an encrypted export cannot be decrypted. The option --decrypted writes all credentials in plain text. Such files are to be deleted after importing.

On import, workflows with the same ID in the target instance are overwritten. Imported workflows are deactivated at first. Anyone who moves workflows between user accounts by export and import loses the change history, according to the documentation.

The author’s practical recommendation: keep the key separate from the backup. If it sat next to it, the encryption of the credentials would be useless as soon as someone got hold of the backup. In ORP.4.A8 the BSI permits a written-down password only for deposit in an emergency and then requires secure storage; the use of a password manager is to be examined.

An example with invented data: an electrical firm with twelve employees has a workflow for enquiries built, and the export sits on a USB stick in the office. The server fails and is set up again. The workflows can be imported, the stored connection to the mailbox cannot, because the key was only in the folder of the failed server.

Who owns the access

There are two kinds of access. The first leads into the tool itself: n8n recommends that the owner creates a second account with the Member role, because owners see everything but cannot tell who created a workflow. When deleting an active user, n8n asks whether their workflows and credentials are copied to a new user or permanently deleted. When the provider leaves, you should choose that deliberately.

In ORP.4 the BSI requires that every user ID can be assigned unambiguously to one person (A1), that IDs and permissions no longer needed are removed when staff change (A2), and that it is documented which IDs were created. This documentation is to be compared regularly with the actual state and included in the data backup (A3).

The second access leads to the connected programs: mailbox, calendar, accounting, AI service. The author’s practical recommendation: these accounts are in the business’s name, not the provider’s, and a list gives each account’s purpose and the workflows that use it. Whether credentials are replaced after the handover is for you to decide, depending on whether the provider knew them.

It also matters who operates the server. According to the licence FAQ, a service provider may run workflows for customers on its own instance as long as they have no access to the interface and receive only results. It may also set up and maintain n8n on the customer’s server, as long as it does not also host. In the first case the business has nothing it could start itself without an explicit return (the author’s conclusion). On the licence see The n8n licence: what a business and a service provider may do with it.

Documentation and monitoring

According to OPS.1.1.2.A11, the documentation of administration work should be traceable. It should show at least what changes were made, when, by whom, for what reason and why, where applicable, standards were departed from. As a threat the BSI names documentation that no longer matches the actual state.

Module CON.3 points out that recovery information that exists only digitally can be lost along with everything else in a major incident such as ransomware. A printed short version in another place therefore has its point. CON.3.A15 also requires regular tests of whether backups work properly and can be restored in reasonable time.

From this follows the author’s practical recommendation for acceptance: the handover is complete only when someone from the business has restored the backup on a second system.

Checklist (the author’s practical recommendation)

The list summarises the sources named for small businesses and is not a standard.

• The contract regulates, before the project starts, what is returned on termination, including sudden failure of the provider, and observes retention obligations.
• It is stated in writing who operates the instance and who owns the server and the accounts.
• An export of all workflows, one file per workflow, is held by the business.
• A dated full backup is held by the business: folder, database, configuration.
• The key is held by the business, separate from the backup, and at least two people know where it is.
• A restore test on a second system has been carried out by staff of the business.
• A person in the business is the owner, and the provider’s account is deleted or time-limited.
• The accounts of the connected programs are in the business’s name, and a list gives purpose and associated workflows.
• Every workflow has a description with purpose, trigger, connected programs, owners and behaviour on failure, plus a change log.
• It is named who notices a failure and who fixes it.
• A printed short version with the location of the key is kept outside the system.
• A date for review is set, for example after six months.

What remains open

The technical statements hold according to the n8n documentation (as of November 2026), and the BSI lists the compendium as Edition 2023. If the provider processes personal data for you, Article 28(3)(g) of the GDPR requires that it deletes or returns the data as you choose once the service ends, unless a storage obligation applies. Retention periods, contracts and data processing are individual questions for your legal adviser, your tax adviser or your data protection officer. This article is not legal advice.

What you can do now

1. Ask your service provider who operates the instance, where the key is kept and when a restore test was last done.
2. Have the export and a full backup placed on a medium you control, and test-restore the backup on a second system.
3. Check in whose name the accounts of the connected programs are held, and start the list.
4. Have the contract extended by a rule on returning workflows, data and keys at the end and in case of failure.