Pre-launch audit on a 23-workflow booking system. `n8n_validate_workflow` flagged 30+ nodes on outdated typeVersions — all running fine at runtime, just behind the current defaults.
Root cause: I was building with Claude Code + n8n MCP tools. The AI hardcoded typeVersions from training data instead of calling `get_node` first. The MCP tool injects a `⚠️ Use typeVersion: X` notice when you call `get_node` — but only if you call it. I’ve since added a mandatory rule to always call `get_node` before configuring any node.
**The hard case:** one IF node on typeVersion 1 controls an anti-bot Turnstile gate. The v1→v2.3 schema is a complete rewrite (`conditions.string[0]` with `value1/value2` → `conditions.conditions` with `leftValue/rightValue` and typed operators). Migrate it wrong and it silently passes all submissions through — no error, just wrong routing.
**My question:** Is there tooling to bulk-upgrade typeVersions, or is every node a manual rewrite? And is there any real risk to leaving old typeVersions indefinitely beyond validator warnings — or is “it runs, leave it” the right call here?
Self-hosted, single VPS instance, going live in the next week or two.
welcome to the n8n community @Giacomo_Benedetti
Honestly, if I were in your shoes, I wouldn’t dream of bulk-migrating 30+ node versions right before go-live just to make a validator happy.
My rule of thumb is that if it’s working, leave it alone until after the launch—especially with something like the IF node, where the schema changes can be a nightmare to debug. n8n is built to keep running the version you saved your workflow with, so you aren’t in any immediate danger of things breaking just because a newer typeVersion exists.
Once the launch is behind you, I’d suggest a controlled pass: upgrade one workflow at a time, test every branch, and maybe even duplicate the workflow to test the new nodes in a sandbox first. The risk of a silent logic failure during a rushed migration is way higher than the risk of running an ‘outdated’ node.
Hi Tamy, thanks for the suggestion. In the end, I opted to update the IF node for the anti-bot Turnstile and the Crypto node (everything seems to be working for the moment). I left out all the remaining HTTP and AirTable nodes, as they were just a minor version bump. It’s my first project, and I would be a bit worried to touch anything else once live! I’ll keep in mind the workflow duplication and in case run them in parallel for a while before migrating, whenever a new workflow upgrade is needed.
Thanks, that confirms the approach. Migrated the IF node and Crypto node, tested the gate routing, leaving the rest for a post-launch cleanup pass.