Moving your Zaps to n8n: what to ask the freelancer for

The short answer

A move from Zapier to n8n is two jobs. The first is a rebuild: every Zap is recreated as an n8n workflow, with its logins connected again. The second is a switch-over: for each one, the old Zap goes off and the new workflow goes on, without a gap and without an overlap. Freelancers quote the first. Most of the trouble lives in the second.

So brief both. Ask for an inventory before a quote, a side-by-side check for each workflow, a written switch-over order, a way back, and a date when the old Zaps are actually switched off. If you are still deciding whether to move at all, start with n8n, Make, Zapier or code; this guide assumes the decision is made.

Why buyers move, and what that means for the brief

The usual reasons are a usage bill that grows with volume, wanting the workflows on infrastructure you control, or keeping data in-house. Each one changes the brief:

• If the reason is cost, ask the freelancer to estimate what the same volume costs on n8n, including the server or the n8n Cloud plan, and who keeps the server running. A self-hosted setup that nobody maintains is not cheaper.
• If the reason is ownership, the n8n instance, the server and every connected login must be in your accounts from day one. Say so in the brief, not at hand-over.
• If the reason is data, list which workflows touch customer or financial data. Those go last in the switch-over, after the easy ones have proven the setup.

What a migration really involves

A Zap and an n8n workflow can do the same job and still differ in the details that break things:

• Triggers change address. If a form, a store or another app sends data to a Zap through a webhook, the new workflow has a new address, and every sender must be updated. (New to the term? See what is a webhook.)
• Logins are connected again. Every app the Zap used needs a fresh connection in n8n. Expiry dates start over, and some connections may need an admin on your side.
• Schedules are re-entered. “Every day at 9” depends on the time zone setting of the new instance. Check it.
• Filters and formatting steps are rebuilt by hand. These are where small differences hide: a date format, an empty field treated differently, a text field trimmed or not.
• History stays behind. The old tool’s run history does not come with you. Export what you need for your records before the account is closed.

None of this is hard for a capable freelancer. It is just more than “copy the Zaps”, and a quote that assumes copying will run over.

What reworking my own jobs taught me

I have never migrated between automation platforms, from Zapier or anywhere else; everything I run was built with Claude Code. What I have done is rework my own scheduled jobs several times, and the problems were always in the switch, not the build:

• A ported job did what the old one needed, not what the new setup needed. When I set up a daily publisher for a new site of mine, I ported it from a publisher that already ran another site. It worked. When the new site gained a folder of diagrams, the ported publisher needed one more line to commit that folder too, because the old site never had one. A port copies the old job’s assumptions along with its code.
• The old format lingered in three places. When I changed the format of the posts my publishing pipeline produces, the scheduled publisher still expected the old format in three places. It would not have crashed. It would have published each post with one part silently missing.
• Old work was still waiting in the queue. Before switching my publishing slots back on, I found six old-format posts still at the front of the queue, although a note said they had been removed. One covered the same topic as a new post, so the first slots would have published the same topic twice.
• A change was written down but never applied. A note said a permission change had been made to my scheduled jobs. A week later I checked the actual settings, and it had not taken effect on any of them.
• The watchdog had to learn the new list. My watchdog checks that each expected slot ran. When slots are switched on or off, its list has to change too, or it reports the switched-off ones as problems every morning, and an alarm that is often wrong is soon ignored.

Each of these is a line in the brief below.

The brief: eight lines to copy

The fields on the workflow automation brief still apply to each rebuilt workflow; this list adds the switch-over on top.

Questions to ask before you order

• “How do you check that the new workflow does exactly what the Zap did?” Look for a concrete answer: the same inputs, compared outputs, edge cases named.
• “What happens to data that arrives during the switch?” For webhook triggers especially, ask where an event goes if it arrives while the address is being changed.
• “Which of my Zaps would you not move, or would merge?” A migration is a good moment to drop dead Zaps. A freelancer who reads the inventory will usually find some.
• “Who looks after the server afterwards?” If the answer is “you”, you need a run-book written for you. If it is “me”, you need maintenance terms.

Sellers who build on accounts the buyer owns say so in their gig; Get Efficient, for example, builds custom n8n workflows on a platform you own, self-hosted or n8n Cloud.

Accepting the migration

Accept per workflow, not in one go at the end. For each one: the parity test passed, it has run on the real schedule or trigger without anyone pressing Run, a forced failure alerted you, and the old Zap is paused. The acceptance checklist covers the unattended part; the job page acceptance lines fit each rebuilt workflow as they are.

Where it goes wrong

• Both run for a day. The new workflow goes live and the Zap is left on “just in case”. Customers get two emails. Pausing the old one is part of the same step.
• Neither runs for a day. The Zap is paused Friday, the new workflow is turned on Monday. Nothing alerts you, because nothing ran.
• The migration ends at “all rebuilt”. The Zapier account stays open, a forgotten Zap keeps running, and someone later wonders why a sheet has duplicate rows. Put the switch-off date in the brief.

Wrap-up

The rebuild is the part you can see and the part you get quoted for. The switch-over is where runs double, go missing or quietly change. Ask for an inventory, a parity test and a switch-over plan with a way back, accept one workflow at a time, and check the real settings before the old account is closed.