You already have 100 n8n workflows. You don’t want to rewrite them.

m9m reads n8n workflow JSON. 32 built-in node types cover the most-used surface area of n8n. The majority of typical automation workflows run unchanged. Here’s what to expect.

What runs unchanged

• The workflow JSON format and node connections.
• Expression syntax — {{ $json.field }}, {{ $node["name"].data }}, and the full built-in function set.
• HTTP Request, Set, Switch, Merge, Filter, Item Lists, and ~25 other core nodes.
• Cron schedules and webhook triggers.
• Postgres / MySQL / SQLite reads and writes.
• AWS S3, Google Sheets, Slack, Discord, GitHub, GitLab nodes.

What needs a look

• Community nodes — anything from n8n’s community node registry isn’t in m9m out of the box. Most are a small wrap over the HTTP node; a few we’ll port on request.
• Credentials — supported, but you re-enter them. Credentials are encrypted at rest; OAuth2 flows work the same way.
• UI editing workflows — m9m’s editor is simpler than n8n’s. If your team is doing heavy visual editing, plan on keeping n8n for authoring and using m9m for execution, or migrate team-by-team.

A pragmatic cut-over plan

1. Audit your n8n export. Bucket workflows into "runs on m9m today," "needs small patch," "needs a custom node."
2. Shadow-run the "runs today" bucket on m9m for a week. Compare outputs to n8n. Fix the handful of differences.
3. Cut over one trigger at a time. Keep the n8n equivalent paused, not deleted, for a month.
4. Port or port-around community nodes: either write a thin Go node, or re-express as HTTP calls.

Related

• m9m vs n8n — detailed comparison
• Case study: migrating ~80 production n8n workflows
• Guide: building a custom node in Go