Moving your automations to another tool: what does not come with them
The pricing changed, or the tool cannot do the thing you now need, and moving to another platform starts to look sensible. Somebody counts the workflows — fourteen, most of them simple — and estimates a weekend.
The count is the wrong unit. What makes a move expensive is not the number of steps but everything attached to them that does not travel.
Connections are re-established, not copied
An automation is not self-contained. Every step reaching another service does so through an authorised connection, and those belong to the account they were made in.
Zapier's documentation is clear about the limits here: it does not transfer ownership of accounts, does not update connected app accounts, and does not transfer ownership of connected app accounts. On Pro and Free plans there is no transfer capability at all.
That is about moving between users, but it tells you what a connection is: an authorisation tied to an account, not a setting you can carry. Moving to a different platform means authorising every service again, in the new tool, one at a time — with whoever holds the credentials present, and with whatever two-factor process each service requires.
For fourteen workflows touching six services, that is six authorisations and usually six small surprises: the login nobody has, the account that turns out to be someone's personal one, the service where reconnecting requires an administrator.
Every incoming address changes
The direction people forget is inbound.
Zapier documents that a webhook URL contains the owner's Zapier ID, so transferring a workflow changes the URL, and the sending application has to be updated or requests keep going to the old address.
If a change of owner does that, a change of platform certainly does. Every form, shop, payment provider or partner system that currently posts data into your automations is pointing at an address that will not exist after the move. Each of those has to be updated somewhere you may not control — which is a conversation with a third party rather than a configuration change.
And the failure mode when one is missed is the quiet kind. Nothing errors. The sender posts into the void, your new platform simply never hears about those records, and you find out from the gap.
The settings are not in the steps
The visible logic — trigger, filter, action — is the part people picture transferring, and it is also the part that is genuinely easy to recreate.
What does not come with it is the behaviour around it. Make's documentation notes that incomplete executions are disabled by default and enabled per scenario, with several ways to resolve them. That is one example of a general truth: how a workflow behaves when something goes wrong is configuration, and it sits beside the steps rather than inside them.
Rebuild a scenario faithfully in a new tool and you have reproduced what happens when everything works. What happens when the third step fails at two in the morning is back to whatever the new platform does by default, which is unlikely to match what you had and may be nothing at all.
The same applies to schedules, retry counts, error routing, notification settings and rate limiting. None of it is visible in the diagram, all of it is part of the behaviour you were relying on.
Data moves better than rules
Where your automations read from and write to systems that hold records, the records themselves usually export cleanly — Mailchimp's account export, for instance, gives you audiences, campaigns, reports and templates in files you can keep, though not deleted audiences, billing statements or landing page content, and only one export per 24 hours.
That asymmetry is the thing to hold on to. Contents export. Rules do not. Whatever encodes what your business does — who gets which email, what triggers a follow-up, which orders need review — exists as configuration inside a product and comes out only as somebody writing it down.
How to price the move honestly
Count connections and inbound addresses, not workflows. Those are the units of real work.
Rebuild the two most complicated ones first, not the easiest. The estimate you want comes from the hard cases, and if the platform cannot do one of them you would rather know in hour three than in week three.
Plan to run both for a period. Overlapping costs two subscriptions for a month and saves the far larger cost of discovering a gap after the old system is gone.
Write the behaviour down as you go. For each workflow: what it does, when it runs, what happens if it fails. This is the artefact that makes the next move cheap, and it is only ever produced during a migration.
Do not migrate the ones you would not build today. Every collection of automations contains some nobody would recreate deliberately. A move is the cheapest moment to retire them, and the only moment anybody looks.
The advantage nobody counts
There is one real benefit that makes the arithmetic less painful. Rebuilding forces someone to state what each automation is for, out loud, in the present tense.
Most collections of workflows are archaeology: built at different times, by different people, for reasons that partly no longer apply. A migration is the one occasion when all of it gets read. Businesses that come out of a move well usually end up with fewer automations than they started with, and a written description of the ones they kept.
Whether that is worth doing now depends on why you are moving. If the trigger is price, get the honest number first — connections, inbound addresses, the two hard workflows — because it is routinely several times the first estimate.
Working out what your automations actually do, in a form that would survive being rebuilt anywhere, is one of the things a process audit produces: $299, three business days, and a description of your process that does not live inside a vendor's account.
Related: what you actually take with you when you leave a platform covers the same move for the systems that hold your records, rather than the ones that hold your rules.