What to check when you import an n8n workflow into OCNORA

What the importer does, and what it leaves to you

The importer reads the workflow JSON you export from n8n and builds an OCNORA workflow from it. Node types it knows are mapped onto OCNORA node types with their parameters carried across. Expressions are rewritten. IF nodes become branch rules. What it does not know, it marks. Then it shows you a report of what mapped, what was rewritten and what became a stand-in, before anything runs.

That report is your work queue. Some of the workflow will arrive ready to validate. Some will arrive as a placeholder or an empty code step that a person has to finish. How much of each depends on the workflow, so no import is a promise that the whole graph works on the first attempt. A small workflow built from common nodes may need very little. A large one with custom code will need an afternoon of someone who knows what it was meant to do.

• Prerequisites: the workflow exported from n8n as JSON; access to each account the workflow connects to, ideally with a test or sandbox account alongside it; one repeatable input you have already run through n8n, with its output saved; and someone who can read the JavaScript in any Code node.

Credentials are recreated, never carried across

An n8n export does not contain credentials, and the importer never imports them. Instead it creates a connection request for each credential the workflow needs. No secret, token or OAuth grant comes across in the file. Someone with access to each target account sets the connection up again in OCNORA.

Use the step. Point every connection at a test or sandbox account for the first run, and swap to production only once the outputs match. Check the scopes as you go: a connection created in a hurry is often broader than the workflow needs, and the one you are recreating may have been broader than it needed to be too.

Expressions, branches and notes

Expressions are rewritten from n8n syntax into OCNORA expressions, and the validator checks the result. Read the rewritten ones anyway. The validator catches an expression with a syntax error or one that points at a node that does not exist. It cannot tell you that a field reference still means what it meant, particularly where a node upstream was replaced or rebuilt and now emits a different shape.

IF nodes become control.branch rules with the same conditions. Check each branch has a path out and that the condition still reads the field you expect. Sticky notes are dropped from the canvas; their text is kept in the workflow description, so a note that explained a quirk is still there to read.

import report   (illustrative, synthetic workflow)

  Webhook              mapped       trigger, parameters carried across
  IF: order is paid    rewritten    control.branch, same condition
  Set: customer name   rewritten    expressions converted, validated
  Code (JavaScript)    empty        Python code node, original JS kept
  Custom ledger node   stand-in     placeholder, original config kept
  Slack credential     request      connection request, recreate it
  Sticky note          dropped      text kept in the description

Placeholders and Code nodes need a person

An n8n node type the importer does not map becomes a placeholder step that keeps the original node’s configuration. It does nothing until a person replaces it. It is not converted later on its own. Look in the integration catalogue for a node that does the same job, or rebuild the step with a credential and an HTTP request. You can request the app from inside the builder, which tells the team there is demand for it.

A JavaScript Code node arrives as an empty Python code node, with the original JavaScript kept alongside it. The code node in OCNORA runs Python only, and the JavaScript is not translated for you. Porting it is the work: read what the original did, write the Python, and test that step on its own with a sample input before you connect it back into the graph.

Validate, dry run, then compare one real run

Once the placeholders are replaced, the code is ported and the connections are filled, let Workflow Health check the result. It validates the graph, pre-flights each connection so an expired token or missing scope surfaces there, and dry-runs the workflow with side effects suppressed. A finding it cannot repair goes to a person.

A dry run shows the shape of each step’s output. It does not prove a real write will be accepted, or that a code step has no side effect of its own. So finish with one real run on the same input you gave n8n, against test connections, and compare the outputs step by step. Somebody has to read both. A green check on its own is how a workflow that looks right does something regrettable.

1. Import one workflow and read the report.
2. Replace every placeholder and port every Code node.
3. Fill each connection request, pointing at test accounts.
4. Run Workflow Health and fix what it finds.
5. Run once on a known input and compare with the n8n output.
6. Put an approval step before any write you cannot roll back.
7. Turn the n8n trigger off last, so the two do not both fire.

Limitations and a next step

• The importer maps the node types it knows. Which ones map is not listed node by node here, and no particular workflow is promised to import whole.
• Credentials, placeholder steps and Code nodes always need a person. None of them is finished by the import.
• JavaScript does not run in OCNORA. Ported code is Python, and testing it is your work.
• Workflow Health finds what its checks cover. A workflow that passes can still fail on data or on an external system.

The switching guide lists what imports from n8n and what does not, with the evidence level for each statement, and the n8n comparison sets the two platforms side by side. For irreversible steps, the approval-gate template shows the pattern. If you would rather go through your own exported workflows with someone, book a demo: we read the JSON with you and list what maps, what becomes a placeholder, which Code nodes need porting and which connections to recreate.