n8n 3.0 Migration Report: What It Misses

It's the page n8n built for this upgrade: Settings > Migration Report, on every instance from 2.39 up. n8n shipped the 3.0 beta on October 27 with stable promised for early December, and the announcement calls the report "the part I'd read if I read nothing else."

The report scans every workflow and your instance settings against the v3.0 breaking changes. Each finding gets an impact badge: Upgrade blocked, Executions will fail, Executions might fail, Behavior changes, or Capability removed. A progress bar counts how many workflows are "compatible." You can export a CSV, assign owners, mark things won't-fix, and for a few rules click Migrate.

I went through the breaking changes when the list first leaked in my n8n 3.0 breaking changes post. This time I wanted to know something narrower: if the report says a workflow is fine, is it?

No. I built 12 small workflows, each one aimed at a single breaking change, plus a control. I had to seed them on n8n 2.38.3, because 2.45.7 refuses to import a workflow that contains a Function node at all. That's how a real old instance looks anyway: old workflows, upgraded in place. Then I ran the report on 2.45.7 (the stable tag today) and on a copy with 2.46.3 (the beta tag, released October 30). Last, I booted 3.0.1 on the 2.45.7 database and called every webhook.

The 2.45.7 report marked 6 of my 12 workflows as affected. The progress bar would have told me half my instance was ready. Five of those six "ready" workflows broke on 3.0.1. Only the control survived.

Every miss falls in one of two buckets: rules your 2.x version doesn't have yet, and things a scan of workflow JSON can't know.

The rules ship inside the n8n release, not from a server. 2.45.7 ships the same v3 rule files as 2.44.6. 2.46.3 adds three: langchain-code-removed-v3, edit-image-version-v3 and slack-trigger-signature-secret-v3. Those are exactly the three node breaks the stable report missed.

n8n's blog says to update to the latest 2.x first. Fair, but on October 31 the latest 2.x is a beta, and I wouldn't put a beta on a client's production box to get a better report. You don't have to. Run the newer image against a copy of your data.That's what I did:

# copy the data volume, keep the same encryption key
cp -R ./n8n-data ./n8n-data-v3check

# run the newest 2.x against the copy and open Settings > Migration Report
docker run --rm -p 5679:5678 \
  -v "$PWD/n8n-data-v3check:/home/node/.n8n" \
  -e N8N_ENCRYPTION_KEY="$N8N_ENCRYPTION_KEY" \
  n8nio/n8n:2.46.3

One more difference: 2.46.3 relabels the timeout and SSRF findings from "Executions will fail" to "Executions might fail." More accurate, but less likely to get read.

How long your Code nodes run

3.0 cuts N8N_RUNNERS_TASK_TIMEOUTfrom 300 seconds to 60. The rule only checks whether the variable is set. If it isn't, you get one instance-level note, and no workflow is listed. My 70-second Code node finished in 70.0 s on 2.45.7. On 3.0.1 it died at 60.1 s with Task execution timed out after 60 seconds. Don't confuse that with "Task request timed out," a different 60-second error I covered in this post on the runner broker.

Where your HTTP calls go

With SSRF protection on, 3.0 adds 100.64.0.0/10to the default block list. That's carrier-grade NAT space, and it's also where every Tailscale address lives. My HTTP Request to 100.100.100.100 got back Tailscale's web page on 2.45.7. On 3.0.1 it got SsrfBlockedIpError. None of my own workflows hard-code a 100.x address, but plenty of self-hosters reach a NAS or a GPU box over Tailscale. The rule doesn't look at URLs, so expressions and credentials pointing at those hosts never show up as workflows.

Whether a Slack credential has its secret

On 2.45.7 the report says nothing. Then I found the scarier part. With an empty signing secret, the 2.45.7 Slack Trigger skips verification. Any request with a fresh timestamp header and a garbage signature got through. It echoed the URL challenge and ran the workflow:

curl -X POST "http://localhost:5679/webhook/<webhookId>/webhook" \
  -H "Content-Type: application/json" \
  -H "x-slack-request-timestamp: $(date +%s)" \
  -H "x-slack-signature: v0=deadbeef" \
  -d '{"type":"url_verification","challenge":"abc123"}'

# n8n 2.45.7, no signing secret:  200 {"challenge":"abc123"}
# n8n 3.0.1, first boot:           401 Unauthorized
# n8n 3.0.1, after a restart:      404 webhook is not registered

On 3.0.1, the first boot after the upgrade registered the webhook and rejected everything with 401. After one restart it wasn't registered at all. The startup log was silent, and the editor still showed the workflow as published. The only place the reason showed up was /rest/active-workflows/error/<id>: "The Slack API credential has no signature secret." Add the secret now, even if you're not upgrading.On 2.x it's an open door.

I pulled the 186 workflows from my own n8n through the API, imported them into a throwaway container and ran the real report. No credentials, nothing touching production. 20 of 186 workflows came back flagged, the same on 2.45.7 and 2.46.3 because I don't use any of the three newly detected nodes:

Manageable. The list of what it didn't count was more interesting. 108 of those workflows have Code nodes, 23 of them published, and the report can't tell me which run past a minute. 17 workflows use seven community packages. The report raises unverified packages as one instance warning, without saying which. So I checked each package against n8n's vetted list at api.n8n.io/api/community-nodes, the same endpoint 3.0 uses. Five of seven are on it, including my own Hyros node. A Fireflies preview package and n8n-nodes-puppeteeraren't. Vetting is also per version, so check the version you have installed, not just the name.

Sometimes. I called the same endpoint the button uses on four findings. The Cron node came back rewritten as a Schedule Trigger, saved as a new version with republishable: true. Function, $getPairedItem and the Execute Sub-workflow URL source all answered No automated migration is available. Budget hand edits for those.

One trap while you edit: since 2.43.3, n8n blocks workflows that contain a deprecated node. On 2.45.7, importingone failed with "this node type is deprecated," while saving an existing one still worked in my test. But if your rollback plan is "re-import last month's JSON export," that import will fail on a current 2.x. Keep a database backup, not just workflow files. I use Git-based version control for n8n for history, but it's not a restore plan here.

1. Copy the database and keep the encryption key. Every step below runs on copies.
2. Run the report from the newest 2.x image against the copy and export the CSV.
3. Fix "Executions will fail" first. Use Migrate where it exists and edit the rest by hand.
4. Set the variables the scan can't decide for you, if they apply:

# keep the 2.x Code node timeout (only if you need it)
N8N_RUNNERS_TASK_TIMEOUT=300

# SSRF protection on, but your Tailscale / CGNAT hosts still reachable
N8N_SSRF_ALLOWED_IP_RANGES=100.64.0.0/10

# keep loading community packages that aren't on n8n's vetted list
N8N_UNVERIFIED_PACKAGES_ENABLED=true

5. Add the signing secret to every Slack API credential.
6. Boot 3.0 on a second copy, restart it once, and fire every production trigger. Then check /rest/active-workflows. A workflow can look published and still not be listed there.
7. Only then upgrade production, and remember 3.0 is Docker-only. If you're still weighing hosting, here's my take on n8n Cloud vs self-hosted.

Step 6 is the one people skip, and it's the only step that caught every break in my test.

October 31, 2026, on a Mac mini. Docker images n8nio/n8n:2.38.3 (to seed), 2.45.7 (the stable tag), 2.46.3 (beta) and 3.0.1. SQLite, internal task runner, N8N_SSRF_PROTECTION_ENABLED=true, every other setting at its default. Fixtures were imported and published with the n8n CLI and run through production webhooks. The report was read through the same REST endpoints the Settings page calls, and the rule list came from the shipped source in each image. The 186-workflow scan used a copy with no credentials, and I'm only publishing counts. Read n8n's migration tool docs alongside this. 3.0 is still a beta, so rules will keep landing.