How Do You Move an Automation From One Platform to Another?

How Do You Move an Automation From One Platform to Another?

You rebuild it, deliberately, while the old one keeps running. There is no format that carries a workflow from one vendor to another, so a migration is a reimplementation with a known specification. The good news is that the specification already exists, in the automation you are replacing.

We end up doing this more than we expected. A team outgrows a per-task pricing model, or a compliance requirement means the automation has to run somewhere they control, or the automation has quietly become load-bearing and nobody can read it any more.

Whatever the reason, the failure modes are the same every time. Here is the order we work in.

Why Would You Move at All?

Usually cost, control or complexity. Cost bites when volume grows and per-task pricing outruns the value of each task. Control bites when data cannot leave your infrastructure. Complexity bites when an automation grows past what a visual builder can express clearly.

The reason matters, because it decides whether a migration is even the answer. If the problem is complexity, moving the same tangle to a different tool gives you the same tangle with unfamiliar buttons. That is a rewrite pretending to be a migration.

Be honest about which one you have. Our guide to building versus buying an AI automation covers the decision one level up from this one.

Is There a Format That Moves Between Platforms?

No. Every platform has its own export, and every export is written for its own importer. n8n documents that it saves workflows in JSON format and offers a Download option in the editor's three-dot menu. That file is for n8n, not for anyone else.

n8n also has a richer format for moving work between its own instances. Its packages are described as holding a slice of your n8n instance, some workflows plus the structure and references those workflows need to run, distributed as a gzipped tar archive with the .n8np extension containing multiple JSON files organised by a manifest.

That is exactly what a same-vendor migration should look like, and exactly what does not exist across vendors. So plan for a rebuild and use the export only as documentation of what the old thing did.

Reading the export as a specification is genuinely useful, though. It is the most accurate description of your automation that exists, and it is usually more accurate than the document someone wrote about it.

What Does a Real Export Actually Contain?

Structure, not secrets. n8n's documentation is clear that exported workflow files include credential names and IDs, and warns that while IDs are not sensitive, the names could be depending on how you name your credentials.

There is a sharper warning worth repeating. n8n notes that HTTP Request nodes may contain authentication headers when imported from cURL, and advises removing or anonymising that information from the JSON file before sharing it.

That single sentence describes the most common way automation secrets leak. Someone pastes a working cURL command into a node to save time, the header comes with it, and six months later the workflow JSON is in a shared drive or a support ticket.

Before you move anything, grep your exports for authorization headers and API keys. Do it even if you are certain there are none, because the cost of being wrong is high and the check takes a minute.

What Happens to Your Credentials?

They do not travel, and that is correct behaviour rather than an inconvenience. n8n states plainly that credential secrets never travel with a package, which preserves only the ID, name and type of each credential. It also notes that configuration data such as hosts or base URLs does not travel either, because it is stored with the secrets.

On import, n8n either matches credentials to existing ones on the target instance or creates empty placeholders. That behaviour is worth internalising, because an imported workflow that looks complete can be full of hollow credentials that fail on first run.

Across platforms you have no matching at all. Every connection is a fresh authorisation, which means a list of every third-party account the automation touches, who owns it, and who can approve the OAuth prompt. Building that list is usually the slowest part of the whole migration, and it is the part teams never schedule.

Take the opportunity to fix ownership while you are there. Automations authorised against a departed employee's personal account are extremely common and they break without warning.

What Breaks When the Webhook URL Changes?

Everything upstream that you do not control. A new platform means a new inbound URL, and every system sending events to the old one has to be updated by whoever administers it. That includes systems owned by other teams, and sometimes by other companies.

The details matter here. Zapier documents that a webhook URL changes only if the Zap is transferred to another user, because the URL contains the owner's Zapier ID. So the URL is stable in normal operation, which is exactly why nobody has an inventory of who is sending to it.

There is a genuinely dangerous behaviour to plan around. Zapier documents that when a Zap is turned off or deleted it will return a 404 for incoming webhook requests, but that there is a system update delay of up to several hours before the 404 takes effect, during which the URL will continue to return a 200 response.

Read that carefully. For a window after you switch off the old automation, senders will be told their event was accepted while nothing processes it. If your cutover plan is to turn the old one off and turn the new one on, that window is where your lost records will come from.

How Do You Cut Over Without Losing Events?

Run both for a while and make the new one harmless. Point the new platform at the same sources, let it process everything, and have it write to a staging location instead of your production systems. Nothing downstream changes until you are satisfied.

Where the source supports more than one destination, send events to both. Where it does not, fan out from the old automation to the new one as an extra step, so the old platform becomes the source of truth during the overlap.

Then switch destinations before you switch sources. Let the new automation write for real while the old one still runs but writes nowhere. That order means a failure during cutover leaves you with a working old system rather than two half-connected ones.

Watch the size limits during the overlap, because they differ by platform. Zapier documents a maximum webhook payload size of 10MB for triggers and 2MB for Catch Raw Hook. A payload that was fine on one platform can be rejected on another, and that rejection will be silent in most builds. We covered the delivery mechanics in our piece on webhooks versus polling.

How Do You Prove the New Version Does the Same Thing?

Compare outputs on identical inputs, not diagrams. Take a week of real events from the old platform's run history, replay them through the new automation in staging, and diff the results field by field. Anything that differs is either a bug or a decision, and both need to be named.

Expect differences you did not intend. Date formats, number rounding, how empty strings and nulls are treated, how arrays are flattened, and what happens to a field that is missing rather than blank. These are the classic sources of silent corruption after a migration.

Also test the failure paths, not just the happy path. Feed it a malformed record, a rate-limited response and a timeout, and check that the new automation surfaces each one somewhere a human will look. Our piece on handling failure in AI automations covers what that looks like in practice.

What Should You Deliberately Not Rebuild?

The steps nobody can justify. Every automation older than a year contains things added for a reason that has expired: a notification to a channel nobody reads, a sync to a tool you no longer use, a branch handling a case that stopped occurring.

A migration is the only moment you get to audit those cheaply, because you are reading every step anyway. Make a list as you go and ask the owner about each one. In our experience a meaningful fraction of steps in a mature automation have no current owner at all.

Resist the opposite temptation just as firmly. Do not add new capability during the migration. You want a version you can compare against the old one, and every improvement you slip in makes that comparison weaker.

How Long Does This Actually Take?

Longer than the rebuild suggests, because the rebuild is not the work. The workflow logic is usually the fastest part. The slow parts are collecting credentials and approvals, finding every upstream sender, running a parallel period long enough to be meaningful, and diffing the outputs.

A reasonable planning shape is to allow as much time for the overlap period as for the build. If your automation runs on a weekly cycle, a one-week parallel run tells you about one cycle, which is not enough to see the monthly edge cases.

Document the new version as you build it rather than afterwards. The reason this migration is hard is that the last one was not documented, and you are currently deciding whether the next one will be too. Our guide to documenting an AI automation covers the minimum that actually helps.

What Would We Do First?

Export the current automation and read it end to end before deciding anything. Half the time that reading changes the plan, because the automation turns out to be doing less, or more, than anyone believed.

Then build the inventory of credentials and upstream senders, because that is the long pole and it involves other people's calendars. Everything else you can do alone at a keyboard.

If you want help planning a cutover that does not lose records, or a second opinion on whether to migrate at all, we are happy to walk through it. You can find us at phoenix.studio.