Migrating from n8n: What Transfers Automatically and What Doesn't
Workflows can import n8n JSON directly, but today it converts 10 node types automatically and flags everything else for manual rebuild.
We're publishing the honest version of this feature, because a migration tool is only useful if you know exactly where it stops.
What the importer does today
Workflows accepts an exported n8n workflow JSON file and converts it directly. Ten node types map automatically: if, filter, switch, splitInBatches, itemLists, splitOut, httpRequest, emailSend, wait, and set (sticky notes are skipped, not converted). Anything outside that list becomes a placeholder step — it keeps the original node's name so you can find it, but it doesn't run, and it's listed separately as unsupported so nothing gets silently dropped.
Where the gap actually is
We measured this against a real corpus of 11,827 n8n workflow files, and the pattern is clear: the most common node types in real-world n8n workflows are exactly the ones without a mapping yet. code nodes (custom JavaScript) are the single biggest blocker, followed by googleSheets, then langchain.agent — which has partial coverage today through our own agent step type (goal, tool list, step budget), just not a direct 1:1 conversion — then gmail, partially addressed by mailbox capabilities elsewhere on the platform, and merge, which exists in both tools but means something different in each, so it's treated as unsupported rather than guessed at.
What this means for a migration
If your n8n workflows lean on if/switch/httpRequest-style logic, expect a clean, working import. If they lean on custom code nodes or Google Sheets integrations, expect a working skeleton with clearly marked gaps to fill in by hand — not a workflow that silently does the wrong thing.
We'd rather tell you 10-of-many node types convert automatically today than let you find that out the hard way after import. The importer will keep growing; this is where it stands right now.