When a Zapier workflow stops being enough.

Most automation should be built in a no-code tool, and most of it should stay there. Zapier and Make solve a genuine problem well: a small number of steps between two well-supported systems, running at modest volume, maintained by somebody who is not a developer. If that describes what your client needs, building it any other way is an act of self-harm.

This post is about the other case. Something you built two years ago now handles work the business depends on, and it has started to creak. The useful skill is recognising which specific ceiling you have hit, because each one has a different answer and only some of them require moving anything.

The symptoms, and what is actually causing them.

What you notice	The underlying limit	What addresses it
The monthly bill climbs faster than the volume	Pricing per task, where a task is any step, including filtered-out ones	Filtering earlier, batching, or a runtime billed by time rather than steps
Records occasionally duplicate	No native idempotency. A retried trigger runs the whole path again	Deduplication on a stable key, held in a store the workflow controls
Nobody notices when it breaks	Failures surface in an activity log nobody opens	Explicit error paths that alert a human, with a heartbeat check
The editor has become unreadable	Deep branching in a linear canvas	Splitting into workflows with a defined interface between them
A vendor step lacks the field you need	Prebuilt connectors expose a subset of the API	Direct HTTP calls against the vendor API
Signed webhooks cannot be verified	No access to the raw request body before parsing	A runtime where you control request handling
Long jobs time out	Execution time caps per run	Chunking into batches, or a queue with its own worker
Legal asks where the data is processed	Processing happens in the vendor’s region	Self-hosted or region-pinned execution

The first three appear far more often than the rest, and none of the three is really a reason to change platform. They are reasons to change how the workflow is built.

Cost is usually a design problem before it is a platform problem.

A workflow triggered on every record change, which then filters out ninety percent of them, is paying for the ninety percent. Moving that filter into the trigger, or into a query, removes most of the cost without touching anything else.

The same applies to loops. A step that runs once per row in a two hundred row list consumes two hundred tasks. Batching the rows into a single call to an API that accepts arrays consumes one.

Check this before concluding that the tool is expensive. The tool is expensive when it is doing work it was never asked to avoid.

The ceilings that genuinely are ceilings.

Four limits cannot be designed around, and these are the ones worth taking seriously.

Idempotency

A webhook delivered twice should produce one record, not two. Doing that reliably means storing a key derived from the payload and checking it before acting. Some platforms offer partial support, but if your workflow writes to a system where duplicates cause real damage, such as an invoice or an order, you need control over that check rather than a setting.

Raw payloads

Signed webhooks from payment providers and similar systems require computing a signature over the exact bytes received. A platform that parses the body before you see it cannot verify the signature, and an unverified webhook endpoint is an open door.

Custom auth

Prebuilt connectors handle common OAuth flows. They do not handle a client’s internal API behind mutual TLS, or a legacy system that expects a token fetched from a separate endpoint and refreshed on a schedule you control.

Data residency

If the client is subject to constraints on where personal data is processed, a hosted runtime in another region is a compliance question, not a technical preference. Self-hosting is often the only answer that survives a review.

Stay where you are if any of this is true.

Migrations are rewrites, and rewrites of working systems are how agencies lose money. Do not move if:

• It works, and the only complaint is aesthetic
• The volume is low enough that cost is not material
• The person who maintains it is not technical and will still be maintaining it afterwards
• The client has no environment to host anything, and no appetite for one
• You are moving because of one missing connector that an HTTP request would solve
• Nobody has yet written down what the current workflow actually does

That last point stops more migrations than it should be allowed to, and correctly. If the existing behaviour is undocumented, the first deliverable is documentation, not a new platform.

What a migration actually involves.

When it is justified, the work is more than recreating the same boxes elsewhere. Assume five things.

Documenting current behaviour comes first, including the undocumented parts. Somebody added a filter for a specific client eighteen months ago and nobody remembers why. That filter is now business logic.

Credentials get reissued. Every connection is authorised again, in a new place, often by someone who has left the account.

The two run in parallel for a period. The new workflow runs alongside the old one without writing anything, and the outputs are compared. Cutting over on the strength of a single successful test is how duplicates reach production.

Error handling gets built explicitly, because it was previously implicit and inadequate. This is usually the largest single piece of new work and the main reason the result is more reliable.

And something now needs hosting, updating and monitoring. Self-hosted n8n is not free. It costs less than per-task pricing at volume, and it costs more than nothing.

The honest summary.

The question is not which platform is better. It is whether what you have hit is a design problem, a missing connector or a genuine ceiling. Two of those three are cheaper to fix where you are.

If a client workflow is failing in ways you cannot explain, or you are weighing a migration and would rather have a second opinion before quoting it, send us the requirement and a description of what breaks. We will tell you which of the three it looks like, and whether moving is worth it. Send us the details and you will get a reply from a person.