Before n8n 3.0 arrives: run the Migration Report on your workflows

#n8n #automation #devops #nocode

Plenty of small businesses run their lead intake, renewal reminders and weekly reports on an n8n instance that someone set up once and nobody has opened since. On October 27, 2026, n8n released the 3.0 beta, with breaking changes, a stable release planned for early December, and the end of support for version 1.x on December 31. The next two months decide whether the upgrade is a quiet afternoon or a week of broken workflows.

What changed

According to n8n's announcement, 3.0 adds no headline features: it removes legacy parts and tightens security defaults. The dates: beta on October 27, stable in early December, 2.x keeps security and critical fixes for 12 months after the stable release, and support for 1.x ends December 31, 2026. There is no direct path from 1.x to 3.x, and moving to 3.x is one way: there is no going back to 2.x.

The changes most likely to touch a small business, from the v3.0 breaking changes page:

Removed nodes. Function, Function Item, Item Lists, Cron, Interval, Read PDF, the legacy OpenAI node, version 1 of the AI Agent node and others. A published workflow that uses one does not activate when 3.0 starts, so its trigger simply stops firing.
Gmail Trigger below version 1.4 now skips drafts unless you turn them on, and checks at most 10 emails per poll by default.
Slack Trigger workflows stop receiving events until the Slack credential has a signing secret.
Self-hosted n8n must run on Docker. Installs that run with npm or npx are no longer supported.

The useful part is the Migration Report, under Settings > Migration Report on any instance from version 2.39. The migration tool docs describe it: a progress bar of compatible workflows, an impact level for every issue (from "Upgrade blocked" to "Capability removed"), the number of runs and the last run date per workflow, and a Migrate button that rewrites some nodes for you, such as Cron to Schedule Trigger. The published version keeps running until you publish the migrated one.

What it means for a business that runs on n8n

Picture an insurance agency of 15 whose self-hosted n8n was set up by a freelancer two years ago. About 20 workflows run on it: website leads into the CRM, renewal reminders started by a Gmail Trigger, a Monday report on a Cron node, and alerts to Slack. The freelancer has moved on, and the instance still runs a 1.x version.

That agency has two deadlines. By December 31 it should be on 2.x, because 1.x stops getting fixes. Then, at some point in the next year, it moves to 3.x. The real risk is a quiet failure: the Monday report stops because Cron is gone, renewal reminders skip some emails because the trigger now reads 10 per poll, and nobody notices for two weeks.

The Migration Report shows which of the 20 workflows are affected, sorted by how often they run, without reading the full list of changes. Each flagged workflow either has a Migrate button or needs someone to rebuild a node by hand. The second group is where the original builder, or outside help, is worth the time.

How to set it up

Check your version. On n8n Cloud, the Updates section of Instance settings in the Cloud console shows it. Self-hosted, check the Docker image tag or the About screen in the editor.
On 1.x, move to 2.x first, before December 31. Read the v2.0 breaking changes and take a full backup of the database before you start.
Update to the latest 2.x and open Settings > Migration Report.
Sort by most runs. Fix the busy workflows first. Mark workflows that have not run in 12 months as "Won't fix".
Clear "Upgrade blocked" and "Executions will fail" issues. Use Migrate where it appears, read the list of changed nodes, run the new version with test data, then publish. Add the Slack signing secret and check the Gmail Trigger settings by hand.
Self-hosted on npm or npx: move to Docker while you are still on 2.x, confirm everything runs, and only then plan 3.0.
After the stable release in December, upgrade a test copy first. Run your three busiest workflows on it, then upgrade production. On Cloud, keep the Stable release track and set a maintenance window, as described in Update your version.

Costs, limits and risks

The upgrade costs nothing in licenses: the announcement says 3.0 applies to the free self-hosted Community edition, Cloud and the paid plans. The cost is time. As an estimate, assume 15 to 30 minutes for each workflow the report flags as migratable, including a test run, and an hour or two for each one that needs rebuilding. For the agency above, with an assumed 5 flagged workflows of which 1 needs a rebuild, that is roughly 2 to 4 hours plus the backup and the test copy.

The risks to watch:

One way. A major version update cannot be rolled back, on Cloud or self-hosted. A backup and a test copy are the only safety net.
Automatic migration is partial. The docs say it covers the node changes only. Check that the output still matches what you expect.

Should you do it now?

Do it now if you run any 1.x instance: the move to 2.x has a hard date, and December is a bad month to discover a broken trigger. Do the report now too if you are on 2.x and your business depends on a handful of busy workflows; fixing them on 2.x costs nothing and changes nothing until you publish.

Wait on 3.0 itself if everything already shows as compatible. Version 2.x keeps fixes for a year after the stable release. Skip it only if you no longer use n8n, and then shut the instance down.

What I'd do this week: open Settings > Migration Report on your n8n instance, export the CSV, and fix the single busiest workflow it flags. Success is one workflow migrated, tested and published on 2.x, and a list of the rest with a name next to each.

Sources

Drafted with AI and checked against the linked sources before publishing. Originally published at emergyaiops.com.

DEV Community