Migrating 23 Make Scenarios to Self-Hosted n8n: a 3-Week Breakdown

The Client and the Starting Point

A DTC ecommerce brand selling skincare across Shopify, Klaviyo, Gorgias, and a 3PL warehouse running on ShipStation. The team was 11 people, with one operations lead owning automation. Over two years they had built up 23 Make scenarios covering order routing, abandoned-cart handoffs, refund-tag automation, ShipStation-to-Shopify sync, Gorgias macro triggers, and a few experimental campaigns. They were on Make Teams at $348/month and were running at roughly 240,000 operations/month, comfortable but trending up.

The driver for migration was not cost. It was a single repeated incident: a Make rate-limit timeout silently dropped order tags during a flash sale, and the team needed deterministic retry semantics they could fully control. They asked us to evaluate self-hosted n8n as the new substrate.

Plan vs Reality

We scoped three weeks. Week 1: stand up n8n on a Hetzner CX21 VPS, port the five highest-volume scenarios, run dual-active for verification. Week 2: port the remaining 18, validate side-by-side, cut over. Week 3: clean up, document, train the operations lead.

Week 1 went mostly to plan. n8n on Docker behind Caddy, Postgres for execution data, daily restic backups to a Hetzner Storage Box. Five scenarios ported, all green by Friday.

Week 2 ran long. The blocker was unexpected: not the logic, the connections.

What Took 40% of the Project Time

Each Make scenario depended on a pile of OAuth credentials, webhook URLs registered with third-party tools, and ShipStation API keys with specific scopes. None of those carry over. Every Shopify webhook has to be re-pointed at the new n8n endpoint. Every Klaviyo and Gorgias OAuth has to be re-authorized. Each ShipStation API key has to be regenerated. We logged the time: 38% of total project hours went into credential and webhook recreation, double-checking scope, and verifying nothing was being delivered to the old Make endpoints. There is no shortcut.

The second time-sink was data-shape drift. Make's built-in iteration and aggregation modules behave slightly differently from n8n's SplitInBatches and Merge nodes around empty arrays and null fields. Three of the 23 scenarios had subtle behavior that depended on Make's specific semantics. We rewrote those flows rather than try to mimic Make's edge cases.

Editor's Note: We deployed self-hosted n8n on a single Hetzner CX21 (~$5.83/mo for the VPS, plus a Storage Box for backups, total around $12/mo) for an 11-person DTC skincare brand. Twenty of the 23 ported scenarios moved over without logic changes; three had to be rewritten because of differences in how Make and n8n handle empty arrays. The honest caveat: the operations lead now spends ~45 minutes/week on VPS upkeep (n8n upgrades, backup verification, log review) that simply did not exist on Make.

What Worked

• Cost. Direct tooling cost fell from $348/month to about $12/month. At 240k operations/month the difference compounds quickly.
• Retry control. n8n's explicit retry-on-fail with exponential backoff replaced the silent Make rate-limit behavior. Verified by replaying a controlled rate-limit storm.
• Versioned workflows. All 23 scenarios live in Git as JSON exports, deploy via a small CI step. Rollbacks are now a git revert away.
• Local development. The operations lead now runs n8n locally to test changes before pushing to production. That was not possible with Make.

What Did Not Work

• Make Datastores have no clean n8n equivalent. We replaced them with Postgres tables, but that added a dependency the operations lead did not previously have to think about.
• Make's built-in error notifications are better. n8n requires you to wire your own Slack/email notifications on failure. We standardized on a single error-handler workflow but it took a half-day to design.
• Cold-start latency on n8n is higher when an executor process spins up. For low-frequency scenarios it does not matter; for the order-tagging scenario triggered on every checkout, we kept a worker warm.
• Documentation drift. During the migration, we discovered three scenarios were already broken on Make and had been failing silently for weeks. Migration did not cause that; it surfaced it.

Would We Do It Again

Editor's Note: For this DTC client, yes — the deterministic retry behavior and Git-versioned workflows mattered more than the cost saving. But we would not recommend this migration for a brand with fewer than ten scenarios. Below that threshold, Make's no-VPS, no-backup-config, no-OAuth-rewiring proposition almost always wins on total time-to-value, even at $9-29/month.

Caveats and Disclaimers

All numbers above are from a single project. Costs and behavior of Make and n8n may differ at other scales. As of May 2026, n8n is fair-code (Sustainable Use License); commercial restrictions apply for some hosted SaaS use cases. Verify the current license before standing up n8n for a multi-tenant offering.