Migration Report not generated after upgrading from 1.109.2 to 2.32.7

Questions
, ,
1

Why was the migration report not generated when upgrading from 1.109.2 to 2.32.7
How can we check workflow compatibility with the new version without the migration report?
Are there any breaking changes between 1.109.2 to 2.32.7 we should be aware of?

2

Hey @hemchandra, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@mohamed3nan, @A_A4, @Lam_Minh_Phan - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @hemchandra Welcome!

It shipped in 1.121.0, so 1.109.2 never had it. It is also a pre-upgrade tool that scans a 1.x instance, not something the upgrade produces:

You are already on 2.32.7, so the failed executions since the upgrade show what actually broke. To get the formal report, point a scratch 1.121.x instance at a copy of your pre-upgrade database and open Settings > Migration Report.

Yes, the whole v2.0 set. The one that throws no error is sub-workflow return data, a parent now receives the child’s output instead of its own input.

4

what are the ways we can do this compatibility test

5

Two ways, static then dynamic.
Export every workflow to one file and grep it for what v2 changed:

n8n export:workflow --all --output=workflows.json
grep -nE 'nodes-base.start|evaluateExpression|executeCommand|localFileTrigger|readWriteFile|waitForSubWorkflow' workflows.json

Each hit is a workflow to open against the breaking changes list. On Docker, prefix with docker exec -u node -it <container-name>.
Then run the ones that matter without waiting for a trigger:

n8n execute --id <ID>
7

Thank you for the response.

Could you please clarify the execution environment for these commands? We are running n8n on OpenShift (Kubernetes). What would be the equivalent approach for our setup?

8

Same commands, oc exec in place of docker exec. There is no -u node equivalent, oc exec cannot pick a user, and under the restricted SCC the pod already runs as an arbitrary UID in group 0.
That UID cannot write just anywhere in the container either, so drop --output and let the export stream to stdout, redirected on your own machine:

oc exec deploy/n8n -- n8n export:workflow --all > workflows.json

No -it on that one, a TTY corrupts the redirect. Grep that file locally. The run itself stays inside the pod:

oc exec -it deploy/n8n -- n8n execute --id <ID>