What we learned migrating an agency from Make.com to self-hosted n8n

A hosted no-code platform stops earning its price when your workload becomes steady, growing, and billed by the operation. That is the whole test, and it is worth applying before the bill forces the question, because the migration is much easier while you still have the option of not doing it.

These are notes from one such migration for a digital product agency. The numbers below are that engagement’s, and are written up in full as a case study.

The two numbers were one problem

The starting position was around $500 a month in operational cost and roughly 3 minutes for a user to get a response. Those look like separate complaints. They were not.

Per-operation pricing means every workflow you add makes the bill worse. The platform’s execution model means every step you add makes the wait longer. So the stack had arrived somewhere unpleasant: doing more of what the agency actually wanted made both numbers worse at once. That is the signal to look at the platform rather than at the workflows.

Three minutes is fine for a nightly job. It is unusable for anything a person is sitting there waiting on, and the agency’s roadmap was full of the second kind.

After the migration the monthly cost was roughly $50 and responses came back in under 20 seconds.

We treated it as build versus buy, not as a migration ticket

This mattered more than any technical decision that followed. Framed as a migration, the question is how to move workflows. Framed as build versus buy, the question is whether to move them at all, and the honest answer is that hosted platforms are a good deal for a lot of workloads.

They earn their price when the workload is small, irregular, and maintained by people who do not write code. That describes plenty of businesses, and if it describes yours, staying is the right call. It stopped describing this one.

Do not migrate everything to the same place

The instinct is to move the whole stack onto the new platform. That is a mistake, and avoiding it is most of why this worked.

We split by who maintains a thing:

• Workflows a non-engineer should be able to read and adjust stayed as n8n workflows. Their value is that someone in operations can open one and change a condition.
• Anything doing multi-stage language processing, API normalization or state management became plain Python, where it could be tested.

The second category is software that had been living in a workflow tool because that is where it started. Moving it to n8n would have preserved the original problem with a better bill. Once in Python, that code got tests, which is the actual reason to move it.

Incremental beats a cutover, and it is not close

A rewrite is 90% right on the first pass, and the missing 10% is invariably the part somebody depends on daily. You will not guess which 10%.

So workflows moved across one at a time, with both versions running until the outputs agreed. This is slower to finish. It is dramatically cheaper to be wrong in, and being wrong somewhere is a certainty rather than a risk.

The hard part was not the platform

The migration itself was mechanical. The difficult engineering was a messaging abstraction layer underneath a conversational agent, because message channels do not agree on anything: identity, delivery semantics, attachments, and even what counts as a conversation all differ.

The layer had to hide that from the agent without collapsing into a lowest common denominator that made every channel equally bad, while keeping tenants isolated per channel. That isolation requirement is what stopped it being a thin wrapper. A leak between two tenants on one channel would have been worse than any outage.

The lesson generalizes: in a migration, budget your attention for the thing that is genuinely novel, not for the thing that is merely tedious. The tedious part is predictable and the novel part is where the schedule goes.

What ran on it afterwards

Two systems, both of which would have been uncomfortable on per-operation pricing. An email intelligence pipeline that classifies and summarizes over 300 emails a day for more than 50 users at 80% accuracy, and a scheduling agent that more than 20 people drive in natural language from whichever messaging app they already have open.

Neither was in scope at the start. That is the part worth noticing: a 20-second response time changed what the agency was willing to automate next, and the roadmap grew after the constraint came off rather than before.

When to actually do this

Run the check before the bill does it for you. If your per-operation cost is rising with usage you cannot reduce, if execution latency is blocking the interactive work you want to build, and if a meaningful share of your workflows are really software wearing a workflow tool as a costume, the arithmetic is probably already against you.

If none of those are true, stay. The migration is worth it when the platform has become the constraint, and not before. Working out which of those you are in is what an assessment is for.