n8n Cloud to self-hosted migration you can verify

An n8n Cloud to self-hosted migration moves more than a workflow diagram. Your CRM still expects the right lead, your billing system still expects one update, and a support escalation still needs to reach a person. The new editor opening successfully tells you very little about those outcomes. The useful question is whether the same business event produces the same result after the move.

Self-hosting can make sense when workflows need access to private services, when infrastructure ownership matters, or when the total operating cost fits the workload better. It also transfers responsibility for updates, backups, access and incidents to somebody on your team. This guide explains what to check before committing, what belongs in the migration scope, and how we would verify the handover together.

Decide whether self-hosted n8n fits the business

Start with the reason for moving. A private database connection, a required hosting region or a workload that needs its own execution capacity is a concrete reason. A cheaper server price alone is an incomplete comparison. Someone will need to patch the service, test upgrades, monitor failures and restore a backup when the first recovery is needed.

Write down the current monthly operating cost and the expected cost after migration, including human maintenance time. As an illustrative calculation, saving $100 on subscriptions while adding three hours of maintenance valued at $50 an hour costs $50 more each month, before the migration itself. Those are example assumptions, not an n8n price or a Bles quote. Replace them with your actual workload and rates. Staying on Cloud is a reasonable result of that comparison.

Inventory workflows, credentials and hidden dependencies

Build an inventory before exporting anything. For each workflow, record its business owner, trigger, connected accounts, expected volume, external writes and acceptable delay. Include inactive workflows that may still be used monthly, sub-workflows called by other workflows, custom nodes and any files the workflow expects to find. The inventory becomes the acceptance checklist at the end.

n8n supports workflow JSON export and import. Its current documentation also describes preview packages for moving workflows and their related structure between instances. Check the versions and capabilities of both instances before choosing the transfer method. An exported workflow is not proof that its credentials, execution history or every account setting moved with it. Keep the source available until those requirements have been checked separately.

Reconnect credentials without turning exports into a secret store

Plan a credential check for each integration. Confirm who owns the account, which permissions the workflow needs and whether authentication depends on a callback address, an IP allowlist or a service account. Reauthorize the connection in the destination where required. Prove it with a safe read before enabling a workflow that sends messages, changes records or charges a customer.

The n8n export documentation warns that workflow files can contain credential names and that HTTP Request nodes may contain authentication headers. Treat exports as sensitive operational material and inspect them before sharing. Store backups and recovery material with restricted access. A handover should explain who can recover access, without placing passwords in the migration checklist or sending them through a shared chat.

Test webhook cutover and prevent duplicate business actions

Moving hosts changes the destination external services call. Check the public webhook address and reverse-proxy configuration against the n8n documentation for the deployed version. Update the relevant callback or webhook registrations and verify the full request from the sending system. A URL that works from inside the server is not enough to prove a CRM or payment provider can reach it.

Decide which environment is allowed to execute each production trigger during the change. Leaving the Cloud and self-hosted copies active can create duplicate actions. For a lead-routing workflow, use an approved test event, confirm exactly one CRM record, and confirm the expected assignment. Record the event identifier and destination record so the result is inspectable. Repeat for a delayed event and a replayed event before declaring the cutover stable.

Size the deployment for the workflows you actually run

A small workload does not automatically need multiple workers. Measure execution duration, peak overlap, memory use and the size of files moving through the workflows. Separate a slow external API from a capacity problem on the host. Adding infrastructure will not remove a third-party rate limit or fix a workflow that downloads the same large attachment repeatedly.

For workloads that need queue mode, n8n documents a main process, Redis and workers. The workers need access to the shared database and the same encryption key. Its documentation also identifies constraints around binary file storage and the available editions. Check those constraints before promising parallel capacity. Queue mode is a deployment choice to validate against the workload, not a guarantee of availability or a substitute for recovery testing.

Prove recovery, then hand over ownership

A backup only becomes useful evidence after a restore. Define what the backup includes, how long restoration should take and which completed business events must survive. Restore into an isolated environment, confirm the workflows and connections can be recovered, and keep outbound actions disabled until the restored state has been reviewed. Record the result and the steps a different operator can follow.

Agree on a rollback decision before production cutover. It should name the condition that triggers rollback, the person who makes that decision and the treatment of events received during the change. Hand over access ownership, monitoring, update responsibility, the test checklist and a short runbook. The migration is complete when the business can operate the new setup and the recovery route has been demonstrated.

What an n8n migration services scope should include

A useful scope separates discovery, environment setup, workflow transfer, integration reconnection, cutover verification and handover. List the workflows and connected systems included, the data or history that must be preserved, and any edition-dependent feature. The current n8n edition comparison should be checked for requirements such as sharing, projects or external secrets. These details prevent a technically successful move from removing something people rely on.

Bles Software can help map the migration and implement the connections and checks around it. Bring a workflow count, the systems it touches, the reason for moving and the outcome you cannot interrupt. Avoid sending credential exports through the contact form. Those four inputs are enough to begin a useful scoping conversation and decide whether a migration, a workflow repair or staying on Cloud is the right next step.