Arn8n 2.0: a migration checklist for self-hosted workflows
The archive date follows the period covered. This retrospective was added on November 3, 2026.
For a business that relies on self-hosted n8n workflows, an upgrade is a change to an operational system. A successful container restart is only the beginning of the acceptance check.
The 2025 milestone
n8n announced the 2.0 beta on December 8, 2025. The transition highlighted execution isolation and more deliberate workflow publishing. This article reviews that milestone using documentation checked in November 2026. It is not a recommendation to install 2.0 as the current target version.
The v2 breaking-change documentation covers task runners enabled by default, default restrictions on environment-variable access from Code nodes, changes to waiting sub-workflow results and a distinction between saving and publishing a workflow. Each can affect assumptions embedded in existing automations.
Inventory workflows by consequence
Start with the workflows that move money, update customer records, publish content or trigger fulfilment. For each, record the trigger, credentials, external systems, expected output and the person responsible for failures. Include inactive workflows that might be brought back later.
A useful audit also identifies custom Code nodes, community nodes and sub-workflows. These deserve targeted review because a successful run of one ordinary webhook workflow tells you little about the rest of the instance.
Build a rehearsal that cannot act on customers
Our recommended staging setup uses isolated credentials or sandbox destinations, controlled webhook routing and disabled production schedules. Simply copying a database can leave a test instance capable of sending real emails or changing live CRM records.
Before upgrading that copy, verify the restore procedure for the database, persistent configuration and the encryption key needed to use stored credentials. Keep secrets out of workflow exports shared for review. A backup is useful when the team knows what it restores and has checked that it can be read.
Test inputs and outputs, not only green execution icons
For a lead-routing workflow, prepare an accepted lead, a missing field, a duplicate request, an unavailable CRM and an approval that resumes after waiting. Write the expected business result for each fixture before running it.
A repeated request should follow the integration’s agreed duplicate-handling rule. A timeout should leave enough information for a controlled retry. An approval sub-workflow should return the data the parent expects. These are project acceptance criteria, rather than behaviour every workflow gets automatically.
The n8n migration tool can help identify version-specific issues. Use its findings alongside a manual review of custom logic and the release notes for the actual source and target versions; it cannot prove that an external business action happened correctly.
Separate the upgrade from the release decision
Agree which workflow version is published, how incoming events will be handled during the cutover and who can pause execution. The rollback plan must also address external actions already completed: restoring a database does not retract an invoice or undo an API call.
ArAgile combines n8n workflow development with server and infrastructure work. For an upgrade project, the first useful deliverable is an instance-specific dependency list and rehearsal plan, followed by evidence that the critical workflows still produce the intended results.
Plan an n8n workflow audit or migration
Tell us about your existing setup, the process you want to improve and the constraints that matter.