Migrate Make workflows to n8n: plan, test and switch

Concrete reason. Identify the concrete reason first. The process may need approved access to internal systems, a different deployment model or custom API processing. Perhaps consumption or maintainability of the existing scenario is unsatisfactory. “n8n is cheaper” is not yet a sufficient case without comparable operating scope and volume assumptions.

Effort comparison. Measure current effort, including incidents and changes. Compare it with one-off migration, training, parallel testing and future operation. If the existing process works reliably and economically, a limited improvement may be preferable to replacement. Define the expected benefit so that the migration can later be evaluated against it.

First process. Choose a bounded process for the first transfer. A scenario with clear inputs, a manageable destination and reliable outcome references is easier to accept than an intertwined chain of dependent scenarios.

No hidden redesign. Avoid combining a platform migration with an unexplained redesign of the whole business process. Necessary improvements can still be made, but identify and approve them separately so the comparison remains meaningful.

Make blueprint. Make describes blueprints as reusable representations of modules, settings and mappings; connections need to be configured for the account using the imported scenario. See the official blueprint guide, checked on 26 September 2026. Treat the export as an inventory and reconstruction aid.

n8n import and export. n8n has its own workflow import and export methods. Both systems using JSON files does not establish direct compatibility. The n8n import and export documentation describes its own format and transfer options. Any conversion tool should be treated as a starting point requiring business validation.

Outside the scenario. Before changing anything, also record schedules, connections, variables, data stores, incomplete work and settings outside the visible scenario. A screenshot does not reveal the contents of persistent state or identify who can renew a connection.

Record the following for every scenario:

Evidence of success. For each write, record how success is demonstrated. A returned destination ID provides stronger evidence than an assumption that a green step produced the intended effect. Those references are particularly useful during the parallel comparison.

Dependencies. Identify dependencies between scenarios as well. A seemingly independent workflow may rely on a table updated elsewhere or a scheduled cleanup that affects its input. Migration scope should include those relationships even when the dependent scenario remains in Make.

Collect, split, merge. Examine every point at which data is collected, split or merged. One business case can contain several technical items. An enquiry with three attachments should not accidentally create three customer orders. Test this explicitly in both implementations.

Empty values and formats. Compare empty values, absent fields and explicit nulls. A filter identifying “missing” information may need a different expression in the new data structure. Test text identifiers with leading zeros, decimal separators and date formats too.

Plain-language rules. Describe each condition in plain language before implementing it: “Only approved requests with exactly one customer match may create an order.” This preserves the intent even when the technical representation changes.

Ordering assumptions. Record any ordering assumptions. If a process expects records to arrive chronologically, establish whether the source actually guarantees that order. Migration is a useful opportunity to expose an existing assumption, but the resulting correction still needs explicit approval.

Use permitted, anonymised or synthetic inputs with known expected results. Include normal cases and deliberately difficult ones:

• no attachments
• several attachments
• missing customer
• multiple customer matches
• repeated delivery
• unusual characters
• a time-boundary case

Destination failure. Add a temporary destination failure. The comparison should show which cases wait, which are rejected and which complete. Two workflows can report the same number of successful executions while creating different business records.

Coverage. Be honest about coverage. Twenty carefully chosen cases do not prove arbitrary load capacity or every unusual file format. They provide a reproducible basis for targeted additional testing.

Independent expected results. Keep expected results independent of either platform's output. If the old scenario contains an error, copying its results exactly would preserve that error. The business owner should define the correct outcome and approve any intentional departure from existing behaviour.

The following is an invented design, not a live integration tested by modernagents. A Make scenario receives service requests, finds customers, creates CRM cases and stores documents. The replacement n8n workflow must fulfil the same task.

Define six acceptance cases:

Comparison by request ID. Initially, n8n writes only to controlled test destinations or produces an intended-result record. Compare outputs by request ID. Check field values, destination actions and exception states individually. Comparing only totals can conceal one missing request and one duplicate that happen to cancel numerically.

Differences. When a difference appears, decide whether it is a defect or an intended change. Approve desired changes separately. A migration should not silently introduce a new business rule because the replacement platform offers a different default.

One authoritative version. Only one version should perform authoritative production actions during the comparison. The other reads approved input data and calculates its expected result without sending another customer message or creating another order. Clearly identify test destinations.

Side effects of reading. Check whether reading itself has side effects. Some inputs mark messages, move files or advance a retrieval cursor. If both versions affect the source, the comparison can alter the data it is intended to observe. Use a suitable recorded input or controlled copy instead.

Duration. Run the comparison long enough to cover relevant operating conditions, such as a month boundary, a typical peak or a periodic task. Duration follows the process; a fixed number of days does not prove completeness.

Regular reconciliation. Reconcile the shadow output regularly rather than waiting until the end. Early differences often expose mapping or state assumptions that should be corrected before the comparison produces a large backlog of unexplained results.

Open cases. Before cutover, produce a list of open cases with stable IDs and processing states. Separate new inputs, pending retries, business clarifications and partially completed transactions. Decide whether each group will finish in the old system or continue under a controlled procedure in the new one.

Mappings. Transfer necessary mappings between source and destination IDs. Do not copy unnecessary historical data merely because it is available. Preserve the state required for safe continuation and evidence.

Confirmed writes. Already confirmed writes need particular attention. If n8n knows an input but not the existing destination ID, it may try to create the same object again. Complete state reconciliation before granting production write access.

Pending approvals. Where a pending human approval exists, decide whether it remains valid after migration. An approval may refer to an earlier data version. If the proposal changes, obtaining a new decision can be more appropriate than carrying over a stale approval flag.

Decision and window. Name the person responsible for the cutover decision and agree a change window. Record the last input or confirmed processing position handled by Make. Stop the relevant old triggers, then either wait for in-flight work to finish or explicitly account for it.

First production cases. Configure the new input, verify reachability and inspect the first small group of production cases. Reconcile incoming IDs, confirmed outputs and unresolved exceptions. If the reconciliation fails, pause additional writes and investigate.

Webhooks and schedules. For webhooks, changing the destination address belongs in the plan. For scheduled retrieval, establish the correct starting position. Both methods need protection against duplicate and delayed events. Do not assume that switching suppliers produces a perfectly sharp time boundary without overlap.

Cutover log. Keep a short cutover log of actions and observed results. It should identify when old processing stopped, when new processing began and which cases were handled during the transition. This is useful evidence if a customer later asks about an individual transaction.

Not a simple switch. Rollback is not simply turning the old scenario on again. n8n may already have performed valid destination actions that Make does not know about. The rollback plan must capture those results and include them in continued processing.

Rollback criteria. Define rollback criteria in advance, such as unexplained outcome differences or an integration failure that cannot be resolved within the agreed window. Identify changes that make automatic reversal difficult. A message already sent cannot be recalled by restoring an earlier workflow file.

Retention and retirement. Retain old configuration and necessary evidence for an agreed period without leaving obsolete access active indefinitely. After acceptance, retire redundant triggers, accounts and connections deliberately. Migration is complete only when the new operating owner, reconciliation procedure and exit from the old service are all established.

Record the cutover window. Returning after cutover does not simply mean switching the old schedule back on. The new workflow may already have created tasks. During the cutover window, record incoming cases, destination references and the last confirmed state. Reconcile those records before deciding which cases the previous process may still handle.

Synthetic example. A synthetic example makes this clear. Of 40 incoming enquiries, 25 completed in n8n, five have a contact but no task, and ten have not started. Repeating all 40 in Make could create duplicate tasks and conflicting contact changes. Exclude the 25 completed cases, investigate the five partial cases and transfer the ten untouched cases under control. The numbers are invented; the distinction between states is what matters.

The table shows the three states of the synthetic example and how each is handled.

Authorisation and fallback. Decide who authorises the return and which records they need. The business team also needs a fallback for urgent work during reconciliation. Check counts and results again after returning. A technical switch is neither a complete rollback plan nor evidence that no work was lost.

Transition period. Retain the previous configuration with active connections only for the agreed transition period. Afterwards revoke unneeded access and explicitly close or transfer any remaining open cases.

These pages cover the service overview and the related decisions for a migration from Make to n8n:

• n8n implementation and workflow operations
• n8n, Make or Power Automate: one workflow compared
• n8n retries without duplicate business actions
• Hand over an n8n project with tests, ownership and recovery

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.