Export and classify every node
Export the workflow JSON and label each part: trigger, transformation, call to your system, call to external SaaS, wait or approval. Separately list every stored credential the workflow touches.
Declare the workflow in stack.json
Triggers become gateway routes or schedules, your-system calls become function and worker steps, and waits become human steps with clear titles. Credentials move into project secrets. Review the plan diff.
Shadow-run against the original
Feed real inputs to both systems and compare outcomes for at least one full business cycle — a week of onboarding, a billing run. Fix translation differences while n8n still owns production.
Take traffic, disable, then retire
Switch the trigger to the KERNSTACK workflow, keep the n8n version disabled but intact for one cycle, export execution history you must retain, and then retire the flow and rotate its old credentials.
Read the flow like the specification it secretly is
Export the workflow JSON and walk it slowly. Each node cluster is one of four things: a trigger (a webhook, a schedule, a form), a transformation, a call to your own system, or a call to somebody else’s SaaS. On KERNSTACK the trigger becomes a gateway route or a scheduled workflow, your-system calls become steps running functions or workers, and transformations become ordinary code inside those steps — tested and reviewed the way product code is, because it now is product code.
Credentials deserve a deliberate pass of their own. Automation tools accumulate them quietly: a CRM key here, a founder’s personal API token there. Every credential the flow used is re-entered as a project secret under the project’s name, and the personal ones are rotated before the old workflow is switched off — the move is the natural audit moment, and teams consistently find at least one key that should not exist.
- Wait and approval nodes become human steps with titles a person can act on; the decision is recorded inside the workflow run.
- Error workflows become explicit failure steps and notifications you declare, instead of a second diagram nobody remembers linking.
- Execution history does not migrate. Export anything compliance needs to keep before the n8n instance is retired.
Run old and new in parallel until the new one has a track record
Product automations fail socially before they fail technically: a flow that silently stops enrolling users is discovered by a customer, not a dashboard. So the translated workflow runs beside the n8n original — shadowing decisions on real inputs, with a human comparing outcomes — until its record is boring. Only then does it take traffic, and the n8n workflow is disabled, not deleted, for one full business cycle.
What stays behind is legitimate. The internal automations — lead routing, report delivery, alert forwarding — remain on n8n where their owners can adjust them visually. The migration is complete when everything a paying user can touch runs as declared, reviewable steps, and everything else kept the tool that fits it.
Resource-by-Resource Mapping from n8n
- Webhook and form triggers →
gateway routes: Public entry points become http routes in stack.json that start the workflow — declared, reviewable, and inside the project’s own domain. - Schedule triggers →
scheduled workflows: Cron-style starts become part of the workflow declaration instead of a setting inside a separate tool. - HTTP Request nodes to your own API →
function and worker steps: Calls into your own system become steps running your code directly — the network hop to yourself disappears, and the code is reviewed with the flow. - SaaS connector nodes (CRM, sheets, chat) →
HTTPS calls from workers: Functions and workers call the same SaaS APIs with ordinary HTTPS. You lose the prebuilt node and gain code your reviewers can read; for product flows that trade favours you. - Wait nodes and approval emails →
human steps: A pause becomes a titled human step in the run: the approver sees the task in context and the decision is recorded in the workflow, not in an inbox. - Code and Function nodes →
functions or workers: JavaScript snippets become nodejs workers; substantial logic becomes a worker with tests. Nothing executable stays hidden inside a diagram. - Stored credentials →
secrets: Every key is re-entered as a project secret, inventoried, and rotated at cutover. Personal tokens found along the way get revoked — plan on finding at least one. - Error workflows →
declared failure handling: Retries, failure branches, and alert steps are written into the workflow and its workers explicitly, visible in the same plan as the happy path.
Frequently asked questions
No. The test is who suffers when it stops: if the answer is a colleague’s morning report, keep it on n8n and let its owner edit it visually. If the answer is a paying user’s onboarding, billing, or fulfilment, that flow is product logic and belongs in the project. Most teams migrate two or three flows, not twenty.
Yes, for those flows — and gain a diff. Changes to a product workflow become code and stack.json changes that a person reviews before production, with agents able to draft them in a sandbox. Teams find the approval step, not the editor, is what they actually missed in incidents.
A typical product flow — a trigger, a handful of system calls, one human approval — translates in days, including the parallel shadow run. Flows with many SaaS connector nodes take longer because each connector becomes hand-written HTTPS calls; that cost is also the honest price of owning the logic.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.