Most operators don't migrate because the platform is broken. They migrate because Make's per-operation pricing crosses an invisible line — and once you have 30+ workflows on it, moving feels "basically a full rebuild." This chapter is the version of that move that doesn't break your business.
The tipping point isn't where Make says it is
The Make pricing page makes the math look fine until your workflows compound. The honest operator threshold, drawn from real builders on r/n8n and HN: ~10,000 operations/month is where self-hosted n8n pays for itself in roughly 2 months. Below that, Make is usually cheaper once you factor in your time. Above that, the per-operation tax compounds faster than your revenue.
A real operator quote that captures the shape:
"Every platform has hidden costs — Zapier is money, n8n is time. Pick your poison based on what you have more of."r/SaaS, 2026
What actually breaks during a migration
- Webhook URLs change. Every external system that pings your old Make webhook needs to repoint. If you have 12 integrations that talk to Make, that's 12 places to update at cutover.
- Module-to-node mapping isn't 1:1. Make's HTTP module has subtleties (response parsing, error branches) that map to multiple nodes in n8n.
- Iterators behave differently. Make's array aggregator and n8n's SplitInBatches are both right, but they're not the same. A workflow that processed 100 items "all at once" in Make may now process them sequentially in n8n.
- Auth tokens don't transfer. OAuth connections to every connected service need to be re-authorized in n8n. Plan for the re-auth window.
- Error handling shape changes. Make has built-in error branches per module; n8n uses error workflows. Same outcome, different mental model.
The 5-phase cutover
This is the sequence we use on actual client migrations. It's slower than a "lift and shift" but it's the version where leads don't stop flowing into your CRM at 2am because nobody noticed the cutover broke.
Phase 1 — Inventory (1–2 days)
Before touching n8n, list every Make scenario in a spreadsheet. For each:
- Trigger type (webhook / schedule / app-specific)
- External services it touches (CRM, ads, billing, comms)
- Operations per month (Make's billing screen tells you)
- Business criticality (revenue-touching? fulfillment? internal-only?)
- Last-modified date (older = higher chance of staleness already)
This inventory is the artifact you'll reference for the rest of the project. It also usually reveals that 20–30% of your scenarios are deprecated, half-broken, or running but unused. Those don't migrate. Those get killed.
Phase 2 — Parallel rebuild (1–3 weeks)
Stand up n8n alongside Make, not as a replacement. Self-host on a $5–20/month VPS or use n8n Cloud for the first month while you find your footing. Rebuild scenarios in n8n in priority order: least critical first. This is counterintuitive but deliberate — your most critical workflow is exactly the one you don't want to debug first.
For each scenario, run both versions side-by-side for 48–72 hours with the same trigger. Compare outputs. Don't cut over until they match.
Phase 3 — Webhook redirect (cutover moment)
For webhook-triggered scenarios, the cutover is sharp: update the webhook URL at the source. Two patterns:
- Direct repoint. Update each external service to call the new n8n webhook URL. Cleanest but requires touching 12 places at once.
- Proxy redirect. Stand up a tiny proxy (Cloudflare Worker, Vercel edge function) that receives at the old Make URL and forwards to n8n. Lets you cut over progressively, scenario by scenario, without coordinating 12 simultaneous updates. This is the safer pattern at scale.
Phase 4 — Decommission Make (week 4–6)
Don't cancel Make immediately. Pause scenarios as you migrate them, but keep the account active for 30 days as your rollback. If something breaks in n8n during the first month — and one thing usually does — you can flip a scenario back to Make in seconds while you debug.
After 30 days of clean operation, downgrade Make to the lowest tier or cancel.
Phase 5 — Operate (the part nobody plans for)
This is where self-hosted n8n stops feeling free. From the same operator threads:
"When a workflow breaks at 3am because of a server update or memory leak, that '$0' starts feeling expensive."
Day-2 operations need:
- Backup strategy (n8n's encryption keys, workflow JSON, Postgres if self-hosted)
- Monitoring (uptime + workflow execution alerts — n8n has a basic dashboard but you'll want external)
- Update cadence (n8n ships weekly; you need a "test then promote" pattern)
- Error workflow (one workflow that catches all other workflow errors and pages you)
- Audit log (who changed what — n8n logs this; you need to know where)
What this looks like wrong
The single most common failure: lift-and-shift migration with no inventory phase. Team rebuilds 80 scenarios in two weeks of evenings, cuts over on a Friday, leads stop flowing into the CRM Saturday morning, nobody notices until Tuesday. Three days of revenue-touching workflows broken.
The cause is never one technical thing. It's always two compounding: a webhook that wasn't repointed plus a Make scenario that was deactivated. The proxy-redirect pattern in Phase 3 prevents this exact failure.
When NOT to migrate
- You run fewer than 5,000 operations/month — the savings don't justify the time
- Your team has zero ops/devops capacity — n8n self-hosted will become someone's part-time job
- You're about to refactor the underlying business process — migrate the new shape, don't migrate then refactor
- Your scenarios all run on Make-specific modules with no n8n equivalent (rare but possible)
The decision in one paragraph
If your Make bill is over $300/month and you have ops/dev capacity to maintain a VPS, the migration pays for itself within 2 months and the unit economics improve permanently. If your bill is under $200/month or your team has no DevOps bandwidth, stay on Make and revisit when the bill crosses $300. The migration cost isn't the dollar cost — it's the rebuild plus the day-2 maintenance burden you're now signing up for.
Want this done without becoming the DevOps person? Our Make → n8n migration service handles all 5 phases including the proxy redirect, post-cutover monitoring, and 30-day stabilization. Or take the AI Stack Audit to confirm migration is the right move at all.