Moving off Pipedream Workflows before 31 March 2027: what maps to what in n8n

Tips & Tricks
1

Pipedream is shutting down Workflows on 31 March 2027. By 30 April 2027 it deletes all Workflows data, including the tokens for your connected accounts. Its export gives you a JSON record of each workflow, but I haven’t found anything that imports it, n8n included.

I’ve been going through 103 public Pipedream workflows to see what moving them to n8n involves. Here’s what I found.

**Maps cleanly**

- HTTP trigger → Webhook node. Your URL changes, so update every form, app or third-party webhook that calls the old `*.m.pipedream.net` address.

- Schedule trigger → Schedule Trigger node.

- `$.respond()` → Respond to Webhook node.

- Registry actions (Slack, Google Sheets, Airtable…) → the matching n8n node, in most cases.

- Connected accounts → n8n credentials. Tokens aren’t exported, so reconnect each account.

**Needs work**

- **Code steps.** About 7 in 10 of the code steps I looked at import a package or call an API from inside the code (axios, requests, the Pipedream SDK). On n8n Cloud the Code node can’t import Python libraries, allows only `crypto` and `moment` in JavaScript, and can’t make HTTP requests. Those steps need splitting into HTTP Request nodes, or self-hosted n8n with the modules allowlisted.

- **Step references.** `{{steps.x.$return_value}}` in props and `steps.x.$return_value` in code become n8n expressions like `$(‘x’).item.json`.

- **App-event triggers.** A third of the workflows started from an app event (new row, new email, closed deal). Check n8n has a trigger for the same event, and whether it polls or uses a webhook.

- **Data stores.** Move the data to n8n Data tables (200 MiB per instance by default) or your own database. Data stores aren’t in the export, so download them before 30 April 2027.

- **Private components.** The export names them but leaves out their code. Keep your own copy of the source.

**Getting the export:** Project → Settings → Export Workflows. The zip lands in the project’s File Store. Pipedream’s docs say your plan has to include File Stores, so if the button’s missing, reply with your plan. I’m trying to work out who can export.

**Free migration check**

I’m building a script that reads the export zip and lists, per workflow: the trigger, the steps, which accounts and secrets you’ll re-enter, which code steps won’t run in n8n’s Code node as-is, and a rough effort rating. Until it’s done I’m doing these by hand. Email your export to liftover.migrations@gmail.com and I’ll send the report back within 48 hours, free. Pipedream redacts secrets, but your code and settings (sheet IDs, channel names) are in the zip, so remove anything you’d rather not share. I delete the file once the report’s sent.

2

Useful list. Two things I’d add from the cutover side rather than the mapping side:

Put your own domain in front of the new webhooks. Since every caller has to be updated anyway, point them at something like hooks.yourdomain.com and proxy or redirect that to n8n. Then the next time you move instances (Cloud to self-hosted, new server, whatever) it’s a DNS or proxy change instead of another round of updating forms and third party apps.

Watch the gap and the overlap when you switch triggers. Pipedream sources dedupe emitted events for you, and n8n polling triggers generally start from “now” when you activate them. So anything that happens between turning off the Pipedream workflow and activating the n8n one can just never fire. The safer order is to activate n8n first, let both run for a day, and make the actions idempotent (check the Sheet or CRM for an existing ID before inserting) so the overlap doesn’t create duplicates. Then turn Pipedream off.

Also worth exporting the execution history / event logs for anything audit related before April, since that won’t come along either.

3

Good list. On “haven’t found anything that imports it”: I wrote an open-source converter for this. It takes the project export (or a GitHub Sync folder) and outputs n8n workflow JSON plus a checklist per workflow: GitHub - davobene/migrateflows: Free converters: OpenAI Agent Builder, Flowise and Pipedream workflows → n8n. Runs in your browser. · GitHub

On the code steps: it rewrites axios calls inside code steps (both the @pipedream/platform one and plain axios) to this.helpers.httpRequest, which the Code node allows on n8n Cloud too, so most of those steps don’t need splitting. Steps that import other npm packages get flagged for self-hosted with NODE_FUNCTION_ALLOW_EXTERNAL. steps.x.$return_value references get rewritten the way you describe.

Python steps are the weak spot so far. If anyone has an export it chokes on, I’d like to see it.

4

Nice, a converter that also writes a checklist per workflow is the useful part. One case I’d flag in that checklist if it isn’t already: code steps that use a connected account, i.e. anything reading this.<app>.$auth.oauth_access_token or api_key and passing it into axios.

Rewriting those to this.helpers.httpRequest keeps the call working, but the Code node can’t read n8n credentials, so the token has nowhere safe to come from. People end up pasting it into the code or a Set node, where it sits in plain text in the workflow JSON and in every execution log. For those steps an HTTP Request node with a predefined or generic credential is the safer target, even if it means splitting the step.

Same for steps that call $.flow.exit() or $.flow.delay(): those change control flow rather than data, so they’d map to an IF/Stop and Error node or a Wait node instead of code. Might be worth a dedicated line in the checklist since they’re easy to miss when the rest of the step converts cleanly.

(Disclosure: I’m connected to thirds.ai.)

5

Good point on tokens. The converter doesn’t paste them anywhere: this.<app>.$auth.<field>. becomes a lookup of an n8n Variable or env var (SLACK_OAUTH_ACCESS_TOKEN and so on), and the checklist lists each one to create, so nothing ends up in the workflow JSON. The catch is OAuth tokens that expire, since a variable doesn’t refresh; for those an HTTP Request node with an n8n credential is the better target, agreed. $.flow.delay already gets its own checklist line (use a Wait node), and $.flow.exit is handled inside the step and stops that branch.

6

This is a useful breakdown. I work with n8n, Python APIs, PostgreSQL, and workflow reliability, including idempotency and error handling.

A migration assessment that identifies incompatible code steps, credential changes, and failure risks before rebuilding the workflows could save teams a lot of debugging time.

I’d be interested in helping test migration cases or review a sample workflow if useful.

7

I wanted to play around with this problem, so I found around 90 public Pipedream workflows on GitHub, converted them and imported them to n8n. tbh the import worked fine, but running them was the hardest part.

About 2/3 of the steps are code, and n8n Code node just doesn’t have fetch, URL, process.env etc. What worked for me: swap fetch/axios for this.helpers.httpRequest, move secrets from process.env into n8n credentials, and on self-hosted allow npm packages with NODE_FUNCTION_ALLOW_EXTERNAL. Python steps won’t run on self-hosted without the separate task runner.

I put the results on GitHub, plus a tiny workflow so you can import it and check what your instance allows:

Disclosure: I’m packaging this into a product, would appreciate your support

8

+1 to valerian on the custom domain. I’d just add that you don’t have to wait until the n8n side is ready to do it.

Point everything at hooks.yourdomain.com now and forward to the old *.m.pipedream.net URL for the time being. Then when a workflow is ready in n8n you change where that path forwards, and if it breaks you change it back. You only have to go through Stripe, Shopify etc once.

Also lets you send to both during the overlap and compare, as long as only one side does the writes.

One catch, anything using $.respond() needs the real response to get back to the sender, so that one has to be a plain proxy. If something queues in the middle it’ll answer with its own 200.

A small Cloudflare Worker is enough if all you need is forwarding. (Disclosure: I run AnyHook, a hosted version that also stores and retries events and on Pro and Scale runs Node.js steps mostly as written, but it has that same $.respond() catch. What moves and what doesn’t: Move Pipedream webhooks one workflow at a time, AnyHook)