Should you switch to n8n? A test drive and a decision list

n8n is a workflow automation tool, like Zapier or Make. Unlike them, you can run it on your own server. That changes the cost model, where your data lives, and who's responsible when it breaks.

author
Zahara Schaefer
published
updated
read
6 min
tested
n8n 2.x in Docker on Linux and macOS (commands from the n8n Docker install docs)
outline {
  1. What changes when you move to n8n
  2. What you need for the trial
  3. 1. Run n8n locally
  4. 2. Pick the right workflow to rebuild
  5. 3. Rebuild it in n8n
  6. 4. Try the things you'd miss
  7. 5. Compare running costs honestly
  8. 6. Decide
  9. Clean up the trial
  10. Troubleshooting
  11. References

This guide helps you decide before you commit. You'll run n8n on your own machine in a few minutes, rebuild one real workflow in it, and work through the questions that decide whether a move makes sense. If the answer is yes, the Zapier and Make migration guides take it from there.

What changes when you move to n8n

Before you test anything, know what you'd be signing up for:

  • Licence. n8n is source-available under the Sustainable Use License. It isn't open source in the OSI sense. You can self-host it for your own internal business use. Reselling it as a service, or embedding it in a product you sell, needs a different agreement. Some features (such as SSO and multi-main) need a paid licence even when you self-host.
  • Hosting choice. You can self-host, or use n8n Cloud, which n8n runs for you. Self-hosting gives you the most control. Cloud is closest to what you have now.
  • Who runs it. Self-hosted means someone handles updates, backups, monitoring and security. If nobody on your team will, budget for that work or use Cloud.
  • How it counts usage. n8n counts workflow executions, not individual steps or operations. A 20-step workflow that runs once is one execution. On a self-hosted community edition, there's no execution limit at all. Your limit is the server.
  • Building style. n8n works with items (arrays of JSON objects) moving between nodes. Most nodes run once per item automatically. It also has a Code node for JavaScript or Python, which helps when a visual step gets awkward.

What you need for the trial

  • Docker Desktop (Windows or macOS) or Docker Engine (Linux).
  • One real workflow from your current tool, with a note of its trigger, its steps, and the apps it connects.
  • An hour.

Run n8n locally

bash
docker volume create n8n_data

docker run -it --rm --name n8n -p 5678:5678 \
  -e GENERIC_TIMEZONE="America/Chicago" -e TZ="America/Chicago" \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Open http://localhost:5678 and create the owner account. This uses SQLite inside the n8n_data volume, which is fine for a trial. For anything real, use the self-hosting guide with Postgres and HTTPS.

Check it worked: the editor loads, and the terminal shows Editor is now accessible via: http://localhost:5678.

Pick the right workflow to rebuild

Choose one that's:

  • real: something your business runs today;
  • medium-sized: 5 to 15 steps, with at least one condition or branch;
  • low risk: a failure won't send anything to a customer.

A lead form that goes into a CRM and sends a Slack message is a good candidate. Payroll isn't.

Write down the trigger, each step in order, the condition logic, and which fields go where. You'll need that list for the rebuild, and later for the migration.

Rebuild it in n8n

Work through your list:

  1. Trigger. Search the node panel for your app. If the source app supports webhooks, use the Webhook node and point the app at its test URL. For schedules, use Schedule Trigger.
  2. Credentials. Add each connection under Credentials. Many apps use OAuth. Self-hosted instances sometimes need you to create your own OAuth app with the provider. The node's documentation page says which.
  3. Steps. Add the nodes for each app. For apps without a node, use the HTTP Request node with the app's API.
  4. Conditions. Use If for a yes/no split and Switch for several paths.
  5. Field mapping. Drag fields from the input panel into node parameters. n8n writes an expression like {{ $json.email }}.

Use Test step on each node as you go. It shows the exact input and output, which is the fastest way to learn how data moves.

Check it worked: run the whole workflow with real test data and compare the result with what your current tool produces for the same input.

Try the things you'd miss

Spend 20 minutes on the parts that matter in daily use:

  • Execution history. Open Executions, click a run, and step through each node's data. Ask whether your team could debug a failure from this.
  • Errors. Break a credential on purpose and run the workflow. Then read about error workflows, which send you an alert when production runs fail.
  • Sharing. If several people build workflows, check how projects and sharing work on the edition you'd use.
  • Missing integrations. Check every app on your list against the integrations directory. Note which ones need the HTTP Request node.

Compare running costs honestly

I won't quote prices here, because they change and they depend on your plan. Instead, fill in this table with your own numbers from your current bill and from the providers' pricing pages:

ItemCurrent tooln8n self-hostedn8n Cloud
Subscription or plan(none for the community edition)
Server or VM(none)(none)
Backups and storage(none)(none)
Time to maintain each month (hours x rate)
One-off migration time
Paid features you need (SSO, etc.)

Count your current usage in your current tool's units (tasks or operations), and in n8n's units (executions). A workflow with many steps costs a lot of tasks but only one execution, and that difference often decides it.

The maintenance line is the one people skip. Updates, backups and the occasional broken credential take real time each month. If that number is high and the volume is low, staying put or using n8n Cloud can be the better answer.

Decide

Moving to n8n usually makes sense when several of these are true:

  • Your workflows are long or run often, so per-task pricing adds up.
  • You need data to stay on your own infrastructure.
  • You keep hitting limits, such as missing branching, loops or custom code.
  • Someone on the team (or a contractor) will own the server.

Staying put usually makes sense when:

  • Your volume is low and your workflows are simple.
  • Nobody wants to run a server, and Cloud doesn't change the maths.
  • You depend on an integration that n8n doesn't have and that has no usable API.

Check it worked: you can explain the decision in two sentences, with numbers from step 5.

Clean up the trial

bash
docker volume rm n8n_data

Only do this if you don't want to keep what you built. To keep it, export the workflow from the editor (... > Download) first.

Troubleshooting

  • Port 5678 is already in use: change the left side of the port mapping, for example -p 5679:5678, and open http://localhost:5679.
  • OAuth sign-in fails with a redirect error: the provider needs the redirect URL n8n shows in the credential window. Local trials use localhost, which some providers reject. Test those apps with an API key, or on a server with a real domain.
  • Webhooks from cloud apps can't reach localhost: expected. For the trial, trigger the workflow manually with sample data, or use a server with a public URL.

References