How to Migrate Pipedream Workflows to n8n Before the Shutdown

Quick answer

Export each Pipedream project as a ZIP before March 31, 2027, save the data the export drops, rebuild each workflow as n8n nodes, reconnect credentials, then move webhook senders to the new n8n URLs and test before switching off Pipedream.

Introduction

Pipedream Workflows has an end date, and it is sooner than a comfortable migration usually takes. If your automations still run there, this tutorial moves them to n8n in an order that avoids the two classic migration failures: discovering too late that the export dropped something you needed, and cutting over webhooks before the replacement has proven itself. You will inventory your workflows, export every project, save the data the export leaves behind, translate Pipedream concepts into n8n nodes, and switch traffic one workflow at a time.

This guide is for people who run production workflows on Pipedream today: a Stripe webhook that posts to Slack, a scheduled sync that pulls rows into a sheet, a code step that calls an internal API. You do not need to be an n8n expert. You do need a running n8n instance, or the willingness to set one up, and access to every app your workflows touch, because every connection must be re-authenticated by hand.

Evidence

Pipedream’s own shutdown notice sets the timeline, in its own words: “Pipedream Workflows and String will shut down on March 31, 2027.” The notice adds that “All Workflows data will be permanently deleted by April 30, 2027, including the credentials and OAuth tokens for your connected accounts.” Workflows is already in maintenance mode, with no new signups or subscriptions and no new features, and Pipedream says it is “focusing on being the integration layer companies rely on to connect AI to the outside world, and Workflows falls outside that focus.” Those three facts drive every deadline in this tutorial: export before March 31, 2027, and treat April 30, 2027 as the date after which nothing can be recovered.

The export itself is well documented but easy to over-trust. According to Pipedream’s export documentation, the export runs one project at a time and produces a ZIP with one JSON file per workflow, describing its triggers, steps, code, configured props, and control flow. Each export is limited to 500 workflows or 256 MB of workflow content, whichever comes first, and the ZIP lands in that project’s File Store, so your plan must include File Stores to use it at all. Secrets are replaced with placeholders, connected accounts keep only an ID, and event history, Data Store contents, and File Store files are not in the ZIP.

An independent analysis of 395 public Pipedream workflows explains why the rebuild is mostly a code translation job, not a drag-and-drop job. Of the 172 complete workflows collected from GitHub Sync repositories, 88% contained at least one code step, and code steps made up 69% of all their steps. Just over half, 53%, started with an HTTP trigger, which means their sender-facing URL changes in the move. And 65% used connected accounts, with 34% reading an account token directly in code, something an n8n Code node cannot do, because n8n credentials are never exposed to code as plain values. Those numbers, published in October 2026, are the reason this tutorial starts with inventory and ends with a parallel run, rather than promising a one-click conversion.

Prerequisites

• A Pipedream account with access to every project you want to move, on a plan that includes File Stores, since the export ZIP is delivered through the File Store.
• A running n8n instance, Cloud or self-hosted, with an admin account. If you do not have one yet, our self-hosted n8n installation guide walks through a Docker install on Ubuntu.
• Admin or owner access to every app your workflows connect to, such as Stripe, Slack, GitHub, or Google Sheets, because each connection must be re-authorized in n8n.
• A list of every external sender that calls your Pipedream webhooks, and access to change each sender’s callback URL.
• Disk space outside Pipedream for the export ZIPs, plus a place to store Data Store dumps and File Store downloads, since Pipedream deletes everything on April 30, 2027.

Step 1: Inventory every workflow before you export anything

Open each Pipedream project and list every workflow with four columns: trigger type, number of code steps, connected accounts used, and whether it reads a token directly in code. Rank the list by simplicity, and migrate the simplest, least critical workflow first. That first win teaches you the mapping and gives you a tested pattern for the harder ones.

Pay special attention to three categories. First, workflows with HTTP triggers, because each one has a sender-facing URL that must change. Second, workflows that read $auth tokens or environment variables inside code steps, because those values are redacted in the export and must be re-entered as n8n credentials. Third, workflows that use Data Stores, File Store files, or scheduled triggers with state, because the export carries none of that state with it. Flag all three now, while you can still open the originals and read them.

Step 2: Export every project, then save what the export drops

In Pipedream, open a project, go to Settings, and click Export Workflows at the bottom of the page. The ZIP is written to that project’s File Store, from which you download it. Repeat this for every project, one at a time, and store the ZIPs outside Pipedream, in version control or object storage, not only on your laptop.

Then save the four things the export drops. First, Data Store contents: open each Data Store and export its records, or write a small Pipedream code step that dumps them to a file before the shutdown. Second, File Store files: download them directly, since they are not in the ZIP. Third, event history you still need for debugging or audits, since it is not exported either. Fourth, the manifest.json warnings list inside each ZIP: read it line by line, because it names every step and prop you must re-enter or reconnect, and it is the most honest migration checklist you will get.

Check the size of each export as you go. If a project holds more than 500 workflows or 256 MB, split it into smaller projects first, or export in parts, because the export stops at whichever limit it hits first, silently leaving the rest behind.

Step 3: Translate Pipedream concepts into n8n nodes

There is no importer, so use this mapping table as your translation guide. A Pipedream HTTP trigger becomes an n8n Webhook node, which gives you a new production URL in your n8n instance. A Pipedream app trigger, such as a new row or a new message, becomes the matching n8n app trigger node, or a Schedule Trigger node plus an app node that polls, depending on whether the app offers webhooks. A Pipedream code step becomes an n8n Code node, which runs JavaScript or Python, and a Pipedream app action becomes the matching n8n app node.

The two translations that trip people up are data shape and credentials. Pipedream code steps work with plain JavaScript objects and the $.step exports of earlier steps. n8n works with items: each node receives a list of JSON items, and a Code node returns items in the form [{ json: { ... } }]. When you port a code step, wrap its output in that shape, and replace $.step references with $json or with explicit references to earlier nodes. For credentials, never paste a token into a Code node. Create an n8n credential for the app, or a Header Auth credential for a raw API, and let an HTTP Request node use it. That is also what fixes the 34% of workflows that read tokens directly in code: the token moves from code into a credential, and the Code node keeps only the logic.

Step 4: Rebuild one workflow end to end, starting with the simplest

Pick the simplest workflow on your inventory, ideally one HTTP trigger, one code step, and one app action. In n8n, create a new workflow and add the trigger node first. If it is a Webhook node, set the HTTP method to match the sender, POST in most cases, and copy the production URL it generates. Then add the Code node, paste the ported code, and fix the item shape as described above. Then add the app node, connect the credential, and map the fields from the Code node output.

Run the workflow with the Execute step button first, then with a real test event from the sender, using the test webhook URL. Compare the n8n output against a recent Pipedream run of the same workflow, field by field. Only when the outputs match do you activate the workflow in n8n, which makes its production webhook URL live. Keep the Pipedream original running until this point: the n8n version is a shadow until it has proven itself on real data.

Step 5: Move webhook senders without a hard cutover

This is the step that decides whether the migration is boring or an incident. For each HTTP-triggered workflow, update the sender’s callback URL from the old *.m.pipedream.net address to the new n8n production URL, one sender at a time, and watch the n8n executions list for the first real events. Do not update all senders at once, and do not deactivate the Pipedream workflow until its n8n replacement has handled real traffic for a few days.

If you expect to move tools again someday, this is the moment to stop hard-coding platform URLs into senders. Point senders at your own domain or a webhook gateway that forwards to n8n, so the next migration changes one forwarding rule instead of every sender configuration. The same advice applies to scheduled workflows: let the n8n version and the Pipedream version run in parallel for one cycle, compare their outputs, and only then deactivate the Pipedream original. Deactivation, not deletion, is the safe intermediate state, since a deactivated workflow can be revived if the n8n version surprises you.

Step 6: Migrate state, schedules, and the long tail

Data Store contents need a new home before you deactivate anything. Small lookup tables fit in an n8n static data pattern or a Google Sheet, and larger state belongs in a database such as Postgres, which n8n reads and writes through its Postgres node. File Store files move to object storage or to the disk of your self-hosted n8n host, and any code that read them must be updated to the new path. Scheduled triggers need their cron expressions copied exactly, and then checked against n8n’s timezone setting, since a schedule that ran at 9 AM in one platform’s timezone can silently shift by hours in another.

Work through the inventory in order of increasing complexity, and keep a running log of each workflow’s status: exported, rebuilt, tested, cut over, Pipedream deactivated. The long tail is where migrations stall, so set a weekly target, for example five workflows per week, and start with the workflows that would hurt most if they stopped on March 31, 2027. Anything you decide to retire instead of migrate still needs its export ZIP saved, because April 30, 2027 deletes the record of what it did.

Troubleshooting

The export ZIP is missing workflows, or stops early. The export is capped at 500 workflows or 256 MB per project. Check the manifest.json inside the ZIP: its warnings list names what was skipped. Split the project or export in smaller batches, and verify the workflow count in the ZIP against the project before moving on.

A rebuilt workflow works in testing but fails on the first real event. The usual cause is data shape. Test events are often simpler than real ones: a real Stripe event carries nested objects and arrays that a sample payload did not. Compare the failing n8n execution input against a real Pipedream run, and fix the Code node to handle arrays and missing fields defensively.

The n8n Code node throws an authentication error the Pipedream code never did. Pipedream code could read a connected account’s token directly, but n8n Code nodes cannot see credential values. Move the token into an n8n credential, call the API through an HTTP Request node that uses that credential, and keep only the data transformation in the Code node.

Webhooks arrive at n8n but the workflow never runs. Check that the workflow is active, not merely saved, and that the sender is calling the production URL, not the test URL. n8n’s test URL only listens while you are actively executing the workflow in the editor, so a sender pointed at it will appear to succeed and nothing will happen.

A scheduled workflow runs at the wrong hour after migration. Pipedream and n8n may interpret the same cron expression in different timezones. Open the Schedule Trigger node, confirm its timezone matches the original, and run one manual execution to confirm the next scheduled run time before deactivating the Pipedream original.

Conclusion

The Pipedream shutdown is a deadline, not an emergency, as long as you start with the export. Save every project ZIP, save the Data Store and File Store contents the export drops, rebuild one workflow at a time starting with the simplest, and move senders only after the n8n version has handled real traffic. If you are moving from another platform too, our Zapier to n8n migration guide uses the same rebuild-one-workflow-at-a-time pattern, and our n8n migration from npm to Docker covers moving an existing n8n instance itself. For the full picture of what n8n can do once you are there, start with the complete n8n guide.

Frequently asked questions