n8n 3 Migration: Prove Workflow Readiness

Early access changes the upgrade decision

n8n's release notes date the n8n 3.0 entry to October 27, 2026, and warn that this major release contains breaking changes. The migration documentation identifies n8n 3.0.0 as early access. Treat those statements separately: a release entry is not a declaration that the version is stable. See the official release notes and breaking-change guidance.

For a business owner, the most important warning concerns existing automations. n8n says workflows containing removed nodes fail when run. Published workflows containing those nodes do not activate when n8n 3.0 starts, so their triggers stop firing. This makes workflow readiness—not simply starting the application—the useful approval question.

Our recommendation is to prepare an acceptance record before considering an upgrade. Use the vendor's Migration Report to identify technical work, then require evidence that the intended triggers and outputs still work. The review process below is an editorial recommendation grounded in n8n's documented migration behavior, not a claim that we have tested your instance.

Establish whose report you are reviewing

Open Settings > Migration Report with an instance owner or administrator. According to the migration-tool documentation, those roles can see every workflow's issues, inspect the Instance issues tab and refresh the report. Other users see only workflows they can edit and cannot see instance issues.

Before assigning fixes, record the current version, target version and full-scan time. Ask the administrator to inspect both tabs and select Refresh. A report from an individual workflow editor should not serve as evidence that the whole deployment is ready.

Use Export CSV to preserve an overview. The documented export contains one row per issue, with version information, scan time, impact and unresolved-workflow counts. It is not a separate acceptance record for each business workflow. Build that record alongside it rather than assuming the export contains every test result you need.

Keep the review material sanitized. Record roles, workflow labels and test conclusions; exclude credentials and sensitive business data from shared notes or screenshots.

Turn findings into business decisions

The report distinguishes upgrade blockers, execution failures, possible failures, behavior changes and removed capabilities. Its detail pages show affected nodes, owners, publication status and execution usage. n8n recommends resolving the highest-impact findings first and testing changed workflows in a development environment. Use those documented report features to organize the work.

For each required workflow, write down:

• The business purpose and the role responsible for accepting it.
• The relevant migration finding and planned change.
• The trigger behavior that must be preserved.
• The expected output and how it will be checked.
• The test result, remaining exception and approval decision.

Prioritize technical blockers first, then use business importance to order the remaining tests. Do not equate a rarely used workflow with an unnecessary one; ask its owner whether it is still required.

Pay particular attention to Won't fix. n8n counts that state as resolved and removes it from the open count. Notified, by contrast, remains unresolved. Require a documented retirement decision before using Won't fix for an affected business workflow. A lower open count should not substitute for an explicit decision about what the business will stop running.

Separate hosting readiness from workflow readiness

For self-hosted deployments, n8n 3.0 requires Docker-based deployment. The official migration guidance says installations using npm or npx are no longer supported and that version 3.0 does not publish a runnable n8n package to npm. It directs those users to move to Docker before upgrading. Existing users of their own Docker Compose file do not need to switch setup methods.

Make hosting readiness a separate approval item. Ask the operator to confirm the deployment method and resolve relevant instance findings before anyone signs off on workflow behavior. Do not interpret a newly started instance as proof that existing automations have been migrated.

Keep this distinction visible in the acceptance record: deployment preparation, workflow changes and business-output tests are separate tasks. Avoid promising a migration duration before the actual findings have been reviewed.

Require evidence from the migrated version

Some findings support automatic migration. n8n documents Cron-to-Schedule-Trigger replacement as one example. The migration saves a new workflow version, but a published workflow continues running its current version until the new one is published. n8n explicitly says automatic migration covers node changes only and instructs users to test outputs before publishing. See automatic migration behavior.

That distinction matters when reviewing evidence. Require the tester to identify which version was tested and which version is published. Do not accept an execution from the unchanged version as evidence for the migrated one.

AI Transform needs particular care. The breaking-change page says to migrate existing nodes to Code through the report; generated JavaScript is retained. It also explicitly says this does not happen automatically on upgrade. If the node never generated code, it must be replaced manually.

For acceptance, compare the migrated workflow's output with the agreed expectation. Record a mismatch as unresolved even if the node conversion itself completed successfully.

Test triggers and changed branches, not just completion

Use documented behavior changes to choose tests rather than repeating the same happy-path run. These are acceptance checks derived from official guidance, not reported customer results.

Scheduled workflows: n8n replaces Cron and Interval with Schedule Trigger. Its Schedule Trigger documentation requires saving and publishing the workflow. The node uses the workflow timezone when configured, otherwise the instance timezone. In a controlled test environment, verify the intended schedule and timezone, publish the test version, and observe a scheduled execution. Record both the trigger result and the downstream output.

Gmail-triggered workflows: the breaking-change guidance says older Gmail Trigger versions run with version 1.4 behavior. Drafts are skipped unless Include Drafts is enabled; sent messages outside the inbox and scheduled messages no longer trigger the workflow. Ask the owner which message categories are required, then test those categories. If sent or scheduled messages are essential, review the documented replacement pattern: Schedule Trigger followed by Gmail's Get Many messages operation.

Branching workflows: the same guidance changes Always Output Data for nodes with several outputs, including If and Switch. An empty item is now added only when every output is empty, rather than to each empty output. Test both a case that selects a branch and a case where all outputs are empty. Verify which downstream actions should occur and which should not.

These checks make acceptance specific: the required event starts the intended version, the correct path runs, and the resulting output matches the owner's expectation.

Approve only the scope you have verified

After fixes, ask the administrator to refresh the report and review both tabs again. The migration-tool documentation says even an empty report requires reviewing breaking changes for items the tool cannot detect.

For an early-access evaluation, keep the decision narrow: permission to test is not permission to replace production. Require resolved blockers, explicit retirement decisions, evidence from migrated versions and owner acceptance of required outputs before considering a production change.

If you need help organizing the review, scope business automation support around those deliverables. Where the required outputs enter a CRM, include CRM integration review in the acceptance work. Approve the behavior you have verified, not merely the version number you have installed.