n8n 3.0 removes the Function node, and a published workflow will not activate after the upgrade

By the VOXA team · from the n8n 3.0 release notes and breaking changes documentation

31 October 20266 min readBeta 27 October, stable early December

What actually changes

3.0 is an operational release, not a feature release. n8n's own framing is breaking changes, removals and legacy cleanup. The removals that matter for most instances:

Removed in 3.0	Replace it with
Function	Code node, Run Once for All Items
Function Item	Code node, Run Once for Each Item
Item Lists	Split Out, Aggregate, Sort, Limit, Remove Duplicates, Summarize
Cron, Interval	Schedule Trigger
HTML Extract, iCalendar, Convert to/from binary data, Read and Write Binary File	Current node versions of each

Some of it is handled for you. The AI Transform node is migrated automatically to a Code node with the same generated JavaScript. The rest is not: you migrate it, before the upgrade.

Two more things change for self-hosters. The npm installation path goes away, so self-hosted n8n runs on Docker. And the upgrade from 2.x cannot be rolled back, which makes a backup the first step, not the last.

The part that actually bites

n8n's documentation is unusually direct about the failure mode, so read it twice: "Workflows that use a removed node fail when they run. If such a workflow is published, it doesn't activate when n8n 3.0 starts, so its triggers stop firing."

That is the whole problem in two sentences. On a normal day, a broken workflow shouts. It shows a red execution, it retries, it mails you. After this upgrade, the workflow is simply not active. The dashboard shows it in your list, the name is there, and nothing happens at 7am. If that workflow was sending invoices, syncing orders or posting content, you find out from a customer, not from n8n.

That behaviour is not specific to Function. A test upgrade from 2.43.6 to the 3.0.1 pre-release, run by Krafera, the vendor behind the n8n monitoring pack we reviewed in Picks, covered four of the removed node types: Function, Function Item, Cron and Interval. All four workflows stayed published and none of them ran. The Function and Function Item ones still displayed an active trigger, the Cron and Interval ones displayed none, and the n8n log said "Workflow cannot run on this instance". The other 33 nodes on the removal list were not tested one by one, so the safe reading is the one in the docs: any removed node stops the workflow activating.

There is a second, quieter version of the same thing: removed settings and renamed folders. Self-hosters who rely on the old npm install path have to move to Docker, and the binary data folder changes name from binaryData to storage. An instance that starts but reads files from the wrong place is harder to notice than one that refuses to start.

Ten minutes: find out which of your workflows are affected

Do this on your 2.x instance, before you touch the upgrade.

• Step 1. Open Settings, then Migration Report. This screen exists from 2.39 onwards and it lists the affected workflows, nodes and settings on your own instance. Save a copy of it, because it is the closest thing to a work list you will get.
• Step 2. If you are on an older version, upgrade to at least 2.39 first. The Migration Report is worth one small upgrade, and 2.x upgrades are reversible where 3.0 is not.
• Step 3. Count the node types yourself. Export your workflows through the API (/api/v1/workflows) or the CLI, then search the JSON for n8n-nodes-base.function, functionItem, itemLists, n8n-nodes-base.cron and n8n-nodes-base.interval. Every hit is a workflow to fix.
• Step 4. Write the list down with the workflow name, the node, and what it does. That list is your upgrade plan, and it is also your rollback argument if the upgrade goes badly.

Fixing them before the upgrade, not after

Every replacement is mechanical once you know the mapping. The only work is the Function to Code conversion, because the code has to be pasted into a node with a different execution model.

• Function becomes Code, Run Once for All Items. In a Function node you returned an array of items. In the Code node you return the array the same way, but the input arrives as $input.all() and you return an array of objects with a json key.
• Function Item becomes Code, Run Once for Each Item. Here the input is a single item, and what you return is that item's new data. If your Function Item node edited item.json in place, this is the closest equivalent.
• Item Lists becomes a small chain. Split Out, Aggregate, Sort, Limit, Remove Duplicates or Summarize, depending on which operation the old node was doing. One node becomes two or three; keep them named so the next reader understands the step.
• Cron and Interval become Schedule Trigger. A direct swap, and the trigger shows the next run time, which the old nodes did not.

Then test each migrated workflow on 2.x before upgrading. Run it once manually, check the output shape matches what the next node expects, and only then publish. Doing this in one pass on a Friday afternoon is how people end up rolling back an upgrade that cannot be rolled back.

After the upgrade, check the thing nobody checks

Open the workflow list and look at the active toggle on every workflow, not just the ones you migrated. A workflow that lost activation looks identical to a healthy one in a screenshot. The list view is the only place where the difference shows, and only if you look.

If you run more than a handful of workflows, this is exactly the gap that monitoring tools exist to cover. It is also why n8n's own Migration Report is worth the ten minutes: it turns "I think we are fine" into a list.

Questions people are asking

Sources

n8n blog, "Introducing n8n 3.0", 27 October 2026 · n8n docs, v3.0 breaking changes · n8n docs, release notes for 3.0 · n8n docs, deprecated and removed nodes.