How to migrate from Azure Logic Apps to n8n without a big-bang cutover
Moving from Azure Logic Apps to n8n is a workflow-by-workflow rebuild, not a file import. Exported definitions give you the logic and the inventory, but they do not carry credentials, managed connector bindings or the identities behind them, so each workflow has to be recreated and re-authenticated in n8n before it can run. Platform engineering usually owns the hosting and cutover plan, integration engineers rebuild the flows, and security reviews the credential handling and network paths. Expect the effort to scale with the number of connectors and the complexity of each flow, not with the file size of the export. Confirm with your own team how many production workflows depend on each connector before you set a schedule.
Start by treating the export as an inventory. Export each Logic App's workflow definition and the ARM templates for the resource group, then list every trigger, action, managed connector and API connection in a spreadsheet with an owner and a business criticality for each workflow. Mark any workflow that depends on a private endpoint, a hybrid connection or a Service Bus queue, because those network dependencies decide where the n8n instance must sit. Pick a low-risk workflow first, rebuild it in a non-production n8n instance, and run it in parallel with the Logic App against the same test data. Keep the Logic App enabled but idle for production traffic until the outputs match over several runs. Then disable the Logic App, keep its definition for rollback, and move to the next workflow.
Retries and idempotence need explicit decisions. Logic Apps applies its own retry policies to actions, and n8n has its own retry settings per node, so check each action's retry behavior and the downstream system's ability to accept a duplicate call before you turn anything on. Where a workflow writes to a financial, order or case system, add a deduplication key or a lookup before the write, and test a forced failure midway through the flow. Also confirm that the webhook or trigger URL is changed in the source system during cutover, because a parallel run can double-process events if both platforms listen to the same queue. Ask your n8n partner or internal owner to document which workflows are safe to run in parallel and which must switch in a single window.
Which Logic Apps capabilities map cleanly to n8n and which need rework
This table maps the main Logic Apps building blocks to their n8n counterparts and marks each as clean, needs rework or gap. Treat the exported Logic Apps JSON as a reference for intent, not a file n8n can import directly, because n8n uses its own workflow JSON format. Confirm connector coverage for each service your workflows call before you commit to a rebuild.
| Logic Apps capability | n8n equivalent | Migration status |
|---|---|---|
| Triggers (HTTP request, recurrence, schedule) | Webhook, Schedule and Cron trigger nodes | Clean: HTTP and schedule triggers map directly, but confirm the public webhook URL and authentication you need |
| Actions and control flow (condition, switch, for each, until) | IF, Switch, Split In Batches and Loop nodes | Clean: logic is reproducible, but nested scopes need restructuring into n8n sub-flows |
| Managed connectors (Office 365, SQL, Service Bus, Salesforce) | Built-in n8n nodes or HTTP Request node | Needs rework: confirm each service has a node or plan an HTTP call with your own credentials |
| API connections and OAuth consent | n8n credentials stored in its database | Needs rework: recreate each connection, since Azure-managed connection objects do not carry over |
| Expressions and dynamic content (@ functions) | n8n expression syntax with JavaScript | Needs rework: rewrite each expression, since function names and data references differ |
| Secrets and Key Vault references | Credentials or environment variables, with your own secrets manager | Needs rework: decide where secrets live, and set the n8n encryption key so credentials stay readable across workers |
| Retry policies on actions | Node-level retry settings and error workflows | Needs rework: set retry counts and intervals per node, and design idempotent writes yourself |
| Run history and monitoring | Execution list and log streaming in Business or Enterprise plans | Gap: Azure Monitor history does not migrate, and log streaming requires a Business or Enterprise plan |
| Integration account artifacts (schemas, maps, XML) | Code nodes or external transform services | Gap: no direct equivalent, so plan the transform logic as code and test it separately |
What to export from Logic Apps and what must be recreated in n8n
A Logic Apps migration starts with an inventory of what can be exported and what has to be rebuilt. Each item below changes the work plan differently, so treat the export as a starting point for the migration inventory rather than a finished copy of the integration.
Workflow JSON definitions
The workflow JSON definition holds triggers, actions, expressions, run-after conditions and parameters for each Logic App. It gives your team the logic to read and map to n8n nodes, one workflow at a time. Expect to rewrite it by hand: n8n uses its own workflow JSON format, so the export is a specification, not an import file. Check every expression, loop and error branch against the source definition before you call a workflow migrated.
ARM templates and deployment parameters
ARM templates describe each Logic App resource, its parameters and its app settings as code. They are useful for inventorying environments and spotting differences between development and production. Parameter values for URLs, environment names and feature toggles must be carried into n8n environment variables or credentials, and secrets referenced in templates must be located in your key store, not copied into the new platform.
Connection resources and API connections
API connection resources record which managed connector a workflow uses and which account it authenticates with. The resource names and types show the connector inventory, but the authorization itself does not transfer. Each connector used by a workflow must be replaced by an n8n node or an HTTP Request node, and every account must be authorized again in n8n under a service identity you control.
Integration account schemas and maps
Integration accounts can hold XML schemas, flat-file schemas, certificates and maps used for transformation. Schemas document the message contracts that partners expect, so export and keep them even though n8n has no direct equivalent. Maps usually need to be rewritten as expressions, Code node logic or an external transformation service. Confirm each partner contract with its owner before you change the transform.
Credentials that never leave Azure
Secrets held in Azure Key Vault, connection keys and managed identity bindings do not come out with the workflow definition. Managed identities in particular cannot be used outside Azure, so each affected call needs a new credential, such as a client secret, certificate or token issued by your identity provider. Record the owner, rotation schedule and scope of every credential before cutover, and store the replacements in n8n's credential store with encryption keys managed under your own key policy.
Run history and in-flight messages
Run history in Logic Apps is kept for a limited retention period and does not move with the workflow. In-flight messages and pending triggers stay in Azure until they complete. Plan a drain period for each workflow, keep Logic Apps read access for audit lookups, and confirm with your compliance team which run records must be archived before the Azure resources are removed.
Migration sequence from inventory to decommission
This sequence moves Logic Apps workflows to self-hosted n8n one workflow at a time, with each step producing a record that the next step depends on. It keeps Logic Apps running until every replacement has been proven and has a tested way back.
Classify the Logic Apps inventory
Start from the exported workflow definitions and ARM templates, and list every Logic App with its triggers, actions, managed connectors, API connections, integration account artifacts and callers. Tag each workflow by business owner, data sensitivity, failure impact and whether it depends on Azure-only services. The output is a classified inventory that the migration team and the workflow owners both sign off on, and workflows with no clear owner are flagged before any build begins.
Build and sign off a pilot workflow
Choose one low-risk, well-understood workflow and rebuild it in a non-production n8n instance, mapping each Logic Apps trigger and action to an n8n node or HTTP call. Recreate credentials in n8n's credential store rather than copying secrets, and confirm that retry and idempotence behavior is written down for every external call. The output is a pilot sign-off record listing the design decisions, the open gaps and the named owner who accepted the result.
Run both platforms in parallel and compare outputs
Point a copy of the production trigger at the n8n workflow in a non-production or shadow mode, while Logic Apps continues to handle live traffic. Compare outputs, side effects, error paths and timing for the same inputs, and log every difference with its cause. The output is a comparison log that the workflow owner reviews, and the parallel run continues until the differences are either fixed or accepted in writing.
Plan each cutover with a rollback path
For each workflow, write a cutover runbook that names the trigger switch, the duplicate-message check, the monitoring to watch and the person who can approve a switch back. Confirm before cutover that in-flight Logic Apps runs will finish or be replayed safely, and that the n8n instance has its encryption key, backups and credentials in place. The output is a per-workflow runbook with a documented rollback step, reviewed by the platform and security owners before a change window is booked.
Cut over one workflow at a time
Switch the trigger for one workflow from Logic Apps to n8n, and keep the Logic Apps definition enabled but disabled for new triggers so it can be re-enabled quickly. Watch executions, error queues and downstream records for the agreed period, and check for duplicates or missed events. The output is a signed cutover record for that workflow, and the next workflow does not start until the previous record is complete.
Decommission Logic Apps resources
After every workflow in scope has run on n8n with a signed cutover record, export a final copy of each Logic App definition, connection and integration account artifact, and store it under the retention rules your organization applies. Then disable and remove the Logic Apps, API connections and integration account resources, and confirm that no alerts, schedules or other workflows still call them. The output is a decommission record listing each removed resource, the retained exports and the stored location.
How n8n's runtime and licensing shape the target architecture
Before you map a single Logic Apps workflow, decide which n8n edition and runtime shape your target. n8n runs as the free Community edition unless you add a Business or Enterprise license key, and the hosting documentation says the key enables those editions on a self-hosted install. The licensing decision comes first because it determines which features you can rely on: SSO and LDAP, environments with Git, and log streaming are listed as Business and Enterprise features on n8n's pricing page, and SAML single sign-on requires Business or Enterprise. If your Logic Apps estate relies on Entra ID sign-in for builders, plan for that tier from day one rather than retrofitting it after cutover.
The Sustainable Use License governs the core code and permits use for your own internal business purposes or for non-commercial or personal use. It does not permit distributing or offering n8n as a service to others, so a team that wants to run n8n for customers, not only for its own staff, needs a counsel review. Files with .ee in their name or directory fall outside that license and require a valid Enterprise License, so check which directories your chosen build and any custom nodes touch. Confirm the internal-use reading and the .ee boundary with your legal team and with n8n before you commit, since the license text, not this page, governs your use.
Queue mode applies when one main instance cannot handle your trigger volume or when you need workers close to other systems. In that setup the main instance receives triggers and webhooks and passes executions through Redis to workers that read and write workflow data in PostgreSQL. Two details matter for the design: the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt stored credentials, and multi-main setup for high availability is restricted to Enterprise self-hosted deployments. Ask n8n which of these topologies your license tier supports and size your PostgreSQL and Redis hosting accordingly.
Questions teams ask before moving Logic Apps workflows to n8n
How much effort does moving Logic Apps workflows to n8n take?
The effort depends mainly on how many workflows you run, how many distinct connectors they call, and how much custom logic sits in expressions, transforms and nested control flow. Each workflow needs its trigger, actions and connections mapped to n8n nodes, its error handling rebuilt, and its outputs tested against the current run history. Workflows that call only standard HTTP APIs usually move faster than those that depend on Azure-specific managed connectors. Effort also includes setting up the n8n hosting, credential storage and monitoring, which is a one-time cost. Ask any partner for a written inventory of workflows, connectors and integration account artifacts before accepting a figure.
How long does a Logic Apps to n8n migration take?
The timeline is set by the number of workflows, the number of connectors that need replacement, the testing each workflow requires, and how many systems must be cut over together. No researched figure for duration is available for this migration, so treat any single number as unverified. A practical approach is to inventory first, move low-risk workflows in batches, and run old and new versions side by side until outputs match. Ask for a timeline tied to a written scope, with milestones for each batch and for sign-off on each cutover.
What does our team need to supply for the migration?
The team needs to provide the workflow inventory, the exported workflow definitions, a list of connections and the systems they reach, and named owners who can confirm expected behavior for each workflow. You will also need access to the Azure environment for export, network paths to internal systems from the n8n host, and a place to store secrets. Where Logic Apps used managed connectors, someone must supply new credentials for the target systems, because those connections do not transfer. Test data and a rollback decision for each workflow should be agreed before work starts.
Can our internal staff migrate the workflows without outside help?
Internal staff can migrate workflows alone if they have time, n8n experience, and someone who understands the Azure side well enough to confirm the original behavior. Teams often need help with the parts that carry the most risk: credential handling, idempotent retries, and the cutover plan. Whether you do this in-house or with a partner, the scope should be written down before work starts. DeployOpen plans, implements, integrates and hardens self-hosted platforms in your own infrastructure under fixed-scope engagements, and ongoing support is available as a retainer. Ask any provider to describe what they will do and what your team keeps.
Do Logic Apps connectors and retry settings carry over to n8n?
No, they do not carry over automatically. Logic Apps managed connectors and API connections are Azure objects, so each one must be replaced with an n8n node or an HTTP request node, and credentials must be recreated in n8n. Retry policies are configured per action in Logic Apps, so each retry setting needs to be reviewed and set again in n8n. Idempotence is the harder point: a retried action can create duplicate records if the target system does not handle repeated requests. Check each write action for an idempotency key or a lookup before the write, and confirm the behavior with the owner of the target system.
What does n8n licensing mean for internal use?
n8n's main codebase is under the Sustainable Use License, which allows use or modification for your own internal business purposes or for non-commercial or personal use. Files with .ee in their name or directory are not covered and require a valid n8n Enterprise License. Using n8n internally to run your own workflows fits within the license, but distributing it to customers or offering it as a managed service does not. Confirm the terms against the LICENSE file and with n8n before deciding how to deploy, since your legal team should interpret how the license applies to your organization.
Which n8n edition do we need for high availability and SSO?
Per n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Multi-main setup for high availability is restricted to Enterprise self-hosted deployments and is not available in the Community edition. Queue mode, which splits the main instance from workers, is available for self-hosted installs and requires sharing the encryption key with every worker and webhook processor. Confirm which features you need with n8n before choosing an edition, because the licensing and feature split decides the architecture.
How should we cut over workflows without stopping the business?
Cut over one workflow at a time, starting with those that have low risk and clear success criteria. Run the new n8n workflow in parallel with the Logic Apps version, compare outputs and error logs, and switch triggers only after the results match. Keep the Logic Apps workflow available as a rollback until the new one has run through its normal cycle and any month-end or peak activity. Track each workflow in the inventory with its owner, test evidence and cutover date, so audit questions can be answered from records rather than memory.
What drives migration cost and duration, and how to keep each down
This table lists the factors that change how much effort a Logic Apps to n8n move takes, why each one matters, and how to reduce it. Recurring costs (hosting, n8n licensing, operations) are separate from one-time costs (build, testing, cutover), so read the last column with the cost components in mind.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of workflows | Each workflow needs an inventory entry, a rebuild, a test pass and a cutover step, so effort grows with count even when workflows are small. | Group near-identical Logic Apps into shared sub-workflows in n8n and retire unused or duplicate flows before export. |
| Managed connectors and API connections | Each managed connector is replaced by an n8n node or HTTP Request node with its own credential, scopes and error behavior. Connection objects in the ARM export do not carry secrets, so each one must be recreated. | Count connectors per workflow from the ARM templates, map each to a native n8n node first, and reuse one n8n credential across workflows that share a system. |
| Custom code and Azure Functions calls | Inline JavaScript or C# and calls to Azure Functions must be ported or rewritten in n8n Code nodes or separate services, which is the least predictable part of the work. | Flag every code action during inventory, move stable logic into versioned services, and keep n8n Code nodes small. |
| Integration account artifacts | Schemas, maps, certificates and partner agreements in an integration account have no direct n8n equivalent and need separate transforms and key handling. | Confirm with your integration team which artifacts are still in use, then rebuild only those transforms, storing certificates in your secrets manager. |
| Retry and idempotence design | Logic Apps retry policies are set per action. In n8n, retries and duplicate-safe writes must be designed explicitly, so flows that write to external systems need a key-based check before each write. | Document each action's retry policy from the export, add idempotency keys for create and update calls, and test failure paths on purpose. |
| Parallel-run length | Running Logic Apps and n8n side by side doubles some costs for as long as both are live, and duplicate messages must be prevented during overlap. | Set a per-workflow parallel-run window in advance, disable the Logic Apps trigger at cutover, and compare outputs rather than running both for everything. |
| Identity and secrets integration | Managed identities and Key Vault references do not carry over. n8n needs its own secret source, and SSO for editors may require a paid n8n plan. | Decide the secrets store before the first rebuild. Check whether SAML SSO is needed, since the n8n pricing page places SSO and LDAP only in the Business and Enterprise plans. |
| Hosting and high availability | Queue mode needs a shared encryption key across main and worker processes, a PostgreSQL database and Redis. Multi-main high availability is limited to Enterprise self-hosted deployments, per n8n's queue mode documentation. | Size for the workflows that must stay up, start with a single main instance for low-criticality flows, and confirm HA needs with n8n before choosing an edition. |
| Licensing and edition choice | n8n's Sustainable Use License limits some use, and features such as Git environments and log streaming sit in paid plans. Community use is free, but internal commercial use needs a check against the license terms. | Ask n8n and your legal team to confirm which edition and license fit your use, and budget licensing as a recurring line item. |
What usually goes wrong and how to prevent it
Most failed Logic Apps to n8n migrations fail in the gaps between platforms rather than in the workflow logic itself. The cards below cover the failure modes that recur during parallel runs, credential moves, retries, connector coverage, schedules, audit history and encryption setup, each with a check to run before cutover.
Duplicate execution during parallel runs
While a Logic Apps workflow and its n8n replacement both run, a shared trigger such as a queue poll, mailbox watch or webhook can fire in both systems. The same record is then processed twice, creating duplicate invoices, tickets or messages. Disable the source trigger before enabling the n8n trigger for each workflow, and confirm that only one platform is subscribed to each event source at any time. Keep a written owner for each cutover window.
Lost or re-keyed credentials
Logic Apps managed connections and API connections do not transfer to n8n. Each credential has to be recreated, and during that work teams often paste secrets into the wrong credential type, use a personal account, or leave a service account with broader scope than the original. Inventory every connection from the export and map it to a named n8n credential with an owner, a scope and a rotation date. Check that the sign-in identity matches the one used in production.
Retries that are not idempotent
Logic Apps retry policies and n8n node retry settings both resend failed calls. If an action already reached an external API before the timeout, a retry can create a second payment, order or record. Before copying a retry policy, review each write action and decide whether the target API accepts an idempotency key. Set retries only on idempotent reads, or pass a stable business key on every write and confirm the behavior in a test environment against the vendor's documentation.
Silent connector gaps
A Logic Apps workflow can depend on a managed connector, an integration account map or an action with no direct n8n node. When the gap is not caught, the workflow still runs but skips a step or uses an HTTP call with the wrong authentication. Build a connector matrix from the workflow definitions that lists each action, its n8n equivalent, and the test that proves the output matches. Treat any action without an equivalent as a blocker for that workflow, not as a note.
Timezone and schedule drift
Recurrence triggers in Logic Apps carry an explicit time zone, while cron expressions and scheduler settings in n8n can use the server's time zone unless configured. A move to a host in another region can shift a nightly batch by hours, or run it twice across a daylight saving change. Set the time zone explicitly on every schedule and record the expected next run time for each workflow during the parallel period.
Loss of run history for audit
Logic Apps keeps run history in Azure, and that history often serves as audit evidence for finance, security or clinical teams. n8n stores executions according to its own settings, and a retention or pruning policy can remove records earlier than the organization expects. Decide the retention period with the audit owner before cutover, export the Logic Apps run history you must keep, and confirm that n8n's execution data settings match that decision. Confirm the outcome with your auditors rather than assuming it.
Encryption key mismatch between main and workers
In n8n queue mode, the main instance hands executions to workers through Redis, and workers read credentials from PostgreSQL. Workers and webhook processors need the same encryption key as the main instance, or they cannot decrypt stored credentials, and jobs fail at runtime rather than at deploy time. Store the encryption key in your secrets manager, set the same value on every main, worker and webhook process, and test a credential-backed workflow on each worker type before routing production traffic to it.
How the migration differs by estate size and starting point
A small set of standalone Consumption workflows is usually the simplest starting point. Each workflow is a self-contained JSON definition with its own trigger, actions and managed connectors, so the export can be read end to end by one or two people. The work is mostly rebuilding each flow in n8n, recreating credentials and testing the trigger paths. A single n8n instance on a container host is often enough for this stage, and the Community edition covers it if your use stays within its license terms (confirm this against the n8n LICENSE.md for your organization's use). Start with one low-risk workflow to prove the connector mapping, then move the rest in small batches.
- Inventory from the export: Export each workflow definition and list its trigger, actions, connections and owner in one sheet.
- Pick a pilot: Choose a workflow with a clear success check and no money movement or regulated records.
- Recreate credentials by hand: Managed connector authorizations do not move with the definition, so each n8n credential is set up and tested again.
- Run in parallel briefly: Keep the Logic App enabled while the n8n version runs against a test target, then disable the original.
- Keep the target simple: A single node with backups is usually sufficient at this size.
Before cutting over, check that every trigger fires once, that no workflow sends duplicate notifications and that the owner signs off on the new run history.
A larger Standard estate usually contains more stateful workflows, stored procedures of logic written as inline JavaScript or C# code, and many connections to internal APIs. Scope is larger because each custom code block needs a rewrite as an n8n Code node or a separate service, and each shared connection needs a single owned credential. Sequencing should follow dependencies: workflows that feed others move first, and the ones that call internal APIs wait until those APIs have stable endpoints. Plan for queue mode if throughput or isolation matters, which places the main instance, Redis and PostgreSQL in front of worker processes. Remember that in queue mode the encryption key must be shared with every worker and webhook processor so they can read stored credentials.
- Map custom code early: Identify each inline script and decide whether it becomes a Code node, a small internal service or a retired step.
- Group by dependency: Migrate parent workflows before the children they call, and record the call graph.
- Plan the topology: Queue mode with external PostgreSQL and Redis suits larger volumes, with workers scaled separately from the main instance.
- Protect the encryption key: Store it in a secrets manager and distribute it to every worker and webhook processor.
- Check licensing for high availability: Multi-main setup is limited to Enterprise self-hosted deployments, so confirm whether you need it.
Confirm with your team which features of the Standard runtime your workflows rely on before you choose the n8n edition and topology.
Workflows that depend on integration accounts carry artifacts that the workflow JSON alone does not show. Schemas, maps, partners, agreements and certificates used for EDI, XML or flat-file processing must be identified and exported as separate items. n8n does not provide a direct equivalent of integration account maps, so transformations are usually rebuilt as Code nodes, a transformation library or an external mapping component. Test these flows against sample messages from production, including edge cases such as malformed records and duplicate batches, because a mapping that worked in the designer can behave differently once rewritten. Trading partner connectivity and acknowledgment logic also needs an owner on each side before cutover.
- Export the artifacts separately: List every schema, map, partner, agreement and certificate referenced by each workflow.
- Rebuild transforms with test data: Use recorded production messages as regression fixtures for each rewritten map.
- Decide the message store: Confirm where inbound messages are persisted during processing and how replays are handled.
- Coordinate with trading partners: Agree on cutover windows, endpoints and acknowledgment behavior in writing.
- Consider Apache Camel for message-heavy flows: Heavy B2B routing may fit better on the sibling Camel migration path.
Confirm that no integration account artifact is left unlisted, because a missing map is the most common reason a rebuilt flow fails late.
Estates that must run air-gapped or in a sovereign region face a different set of constraints. Logic Apps managed connectors depend on Azure-hosted connector services, so each connector used must be replaced with a native n8n node, an HTTP request to an internal endpoint or a custom node built in-house. Container images, npm packages and n8n updates must be mirrored into the isolated network, and that mirror becomes part of the change process. Identity should move to an internal provider, and SSO on n8n is part of the Business and Enterprise plans, so confirm that requirement early. Data location, key custody and logging all need to be documented for the auditors who review the system.
- List connector dependencies: Mark every managed connector that calls an external service and identify its internal substitute.
- Mirror dependencies: Plan an internal registry and package mirror for images and packages, with a documented update path.
- Confirm identity needs: Check whether SSO through SAML or LDAP is required and which n8n plan includes it.
- Place the runtime deliberately: Keep the main instance, workers and database inside the restricted zone with no outbound paths you have not approved.
- Document evidence: Record configuration, access and backup decisions so an independent assessor can review them.
Confirm with your security team and your cloud or data center operator which outbound paths are permitted before the design is final.
How DeployOpen scopes and runs a Logic Apps to n8n migration
DeployOpen plans and implements self-hosted n8n inside your own cloud accounts, data centers or air-gapped networks, starting from an inventory of your existing Logic Apps workflows. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every Logic Apps workflow, its triggers, actions, managed connectors and API connections from your exports
- Record which workflows depend on retries, idempotence or Azure-only services that need a replacement plan
- Agree in writing which workflows move, which are retired and which stay on Azure during cutover
How we build
- Deploy self-hosted n8n in your infrastructure, with credentials, encryption keys and database configuration set up for your environment
- Rebuild each in-scope workflow in n8n, replacing managed connectors with community nodes or custom HTTP calls where needed
- Test retry behavior and duplicate handling for each workflow before any production traffic reaches it
How we hand over
- Document the n8n workflow inventory, connector mapping, credential ownership and the rollback step for each workflow
- Run cutover one workflow at a time, with the Logic Apps original kept available until you approve the switch
- Deliver runbooks for backup, upgrades and access control, so your team can operate the platform after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
- Confirm with your team which n8n edition and license fit your use, since some features depend on the plan chosen
- Review your licensing position and internal-use terms with your legal team before wider rollout
