The Zapier bill is the usual reason, but the migration is also a chance to clean up: most accounts have Zaps nobody remembers, Zaps that fire on events that no longer matter, and three Zaps doing what one workflow should. A good migration ends with fewer, better automations and a bill that no longer scales with success.

Inventory first

Export the list of Zaps with their triggers, actions, run counts and owners. Sort by run count: the top ten are the ones that matter, the bottom half can probably be retired. For each kept Zap write one line: trigger, what it does, why. Half the value of the migration is this document.

Map to n8n patterns

Most Zaps become one workflow each; some merge (three Zaps on the same trigger become one workflow with branches); some split (a Zap with a long chain becomes a workflow calling sub-workflows). Note where Zapier's built-in app connection has no direct n8n node — usually solvable with the generic HTTP node and the vendor's API.

Rebuild and test with real data

Build each workflow in a staging n8n against test records, then replay a sample of recent real events through it and compare the results to what Zapier produced. Fix differences. Add the error handling Zapier hid: retries, an error workflow that alerts, idempotency on writes.

Parallel run, then cut over

Point the trigger at both for a week — Zapier live, n8n logging only — and diff daily. Then switch the trigger to n8n, pause the Zap, and watch for a week before deleting it. Do the top ten first, one at a time, on quiet days. The rest follow quickly once the pattern is proven, and the Zapier account is downgraded at the end, not the start.