Migrate from sim.ai to Heym
Move sim.ai workflows to Heym. Paste an exported workflow, watch AI Convert rebuild every block on a live canvas, then run it on your own infrastructure.
Sim documents a workspace where workflows are visual programs made of blocks: triggers start a run, Agent, Function, and API blocks do the work, Condition, Router, Loop, and Parallel blocks direct it, and tables plus knowledge bases hold the data it works with.
When it is worth moving a workflow
Both tools model the same thing, so this move is usually about where it runs rather than how it is built. Teams move when the workflow starts handling documents or credentials that cannot leave their network, or when they want the whole runtime, including its execution history and traces, inside infrastructure they operate.
How the move works
- 1
Export from sim.ai
Open the workflow in Sim and export or copy its definition, then paste it. A plain description of what the workflow does works just as well.
- 2
Paste it into AI Convert
A safety check runs, then each construct is mapped to the closest native Heym node and streamed onto a live canvas while you watch.
- 3
Review, download, and import
Read the rebuilt workflow, download or copy it, import it into your own instance, and attach your credentials.
What each sim.ai concept becomes
A reviewer's guide to the rebuilt workflow. Constructs without an exact equivalent are mapped to the closest Heym primitive, which is why the result is worth reading before it handles real traffic.
| In sim.ai | In Heym | What changes |
|---|---|---|
| Start trigger | Input node | Declared inputs become the workflow input schema, reachable from the API, the Portal, or a manual run. |
| Schedule and Webhook triggers | Cron node and the workflow webhook trigger | A timer becomes a cron expression; an inbound HTTP request becomes a property of the workflow, so the URL is new. |
| Agent block | AI Agent node | Model, prompt, and tool use carry over, extended with inline Python tools, MCP servers, skills, and sub-agent delegation. |
| Function block | Code node | Code steps become sandboxed Python running in a Docker sandbox. |
| API block | HTTP node | Methods, headers, and body templating carry over with references rewritten into the Heym DSL. |
| Condition and Router blocks | Condition and Switch nodes | Two-way checks become a Condition; multi-way routing becomes a Switch with labelled branches. |
| Loop and Parallel blocks | Loop node and parallel DAG execution | Iteration becomes a Loop; explicit parallelism is usually unnecessary, since independent nodes already run concurrently. |
| Guardrails block | Guardrails on the LLM and Agent nodes | Safety policy moves onto the node that generates the content, and a block throws a typed workflow error an Error Handler can route. |
| Wait block | Wait node | Delays map across directly. |
| Response block | Output node | The workflow output is explicit here rather than defaulting to the last block, so confirm the final node is the one you meant. |
| Connection tags such as <blockName.field> | Expression DSL, for example $nodeName.field | The same idea in different syntax: name the upstream step, then the value you want. |
| Knowledge bases and tables | RAG / Vector Store node and DataTable node | Knowledge bases become vector stores over Qdrant or Postgres with pgvector; tables become DataTables in your own database. |
| Chat deployment | Portal | A workflow publishes as a chat UI with streaming, file upload, conversation history, and optional authentication. |
Check these before it goes live
- Re-ingest knowledge base documents and reload table rows. Neither is copied by a workflow conversion.
- Set the workflow output explicitly. Heym returns the Output node rather than defaulting to the last block that ran.
- Attach model and integration credentials in the Credentials tab.
- Check any Parallel block. Independent branches already run concurrently here, so an explicit parallel step is usually redundant.
- Run one test execution and compare the result against the same input on the source side.
sim.ai migration FAQ
Can AI Convert read a Sim workflow?
Yes. Paste the exported workflow definition into AI Convert, or describe the workflow in your own words. Both tools model work as connected blocks, so the graph shape usually survives intact.
What happens to the default output behavior?
Sim returns the last block’s output when there is no Response block. Heym always returns its Output node, so a workflow that relied on the implicit default needs one added, wired to whichever node holds the answer.
Do my credentials come across?
No, and that is deliberate. Exported workflow files hold no API keys or secrets, so AI Convert rebuilds the structure only and you attach your own credentials in the Heym Credentials tab afterwards. Nothing copies a secret between two systems on your behalf.
Is the converted workflow ready to run?
Treat it as a reviewed starting point rather than a finished port. Open it on the canvas, attach credentials, run one test execution, and adjust any node that was mapped to the closest Heym primitive rather than an exact equivalent.
Can I run the result on my own infrastructure?
Yes. Heym is source-available under an MIT license with a Commons Clause and runs on your own servers with Docker or Kubernetes, so migrated workflows, their credentials, and their model calls stay inside your environment.
Moving from something else
AI Convert reads exports from 12 tools, and it also accepts a plain description of the automation when there is no file to export.