Migracija sa Zapier i Make na self-hosted n8n: detaljan playbook korak-po-korak za 2026.

# Što ćete naučiti#

Ovaj playbook je praktičan okvir za migraciju sa Zapier na n8n ili s Make na self-hosted n8n postavu bez lomljenja produkcijskih automatizacija.

Pratit ćete ponovljiv proces: inventarizacija workflowa, mapiranje triggera i akcija, rebuild uz višekratno iskoristive subworkflowe, validacija pariteta s testnim podacima, pa zatim kontrolirani cutover s planom rollbacka.

Ako još procjenjujete alate, krenite s našom usporedbom: n8n vs Zapier vs Make u 2026. Ako ste već odlučili za self-hosting, poslužite se vodičem za hardening: n8n self-hosting s Dockerom i sigurnošću. Za višekratne obrasce, držite ovo pri ruci: vodič za n8n workflow predloške.

# Zašto timovi prelaze sa Zapier i Make na self-hosted n8n#

Većina migracija događa se iz tri razloga: predvidljivost troškova, sigurnost i kontrola podataka te održivost na razini inženjeringa.

Zapier i Make su izvrsni za brzinu, ali im se cijene obično skaliraju po taskovima ili operacijama. Kad dosegnete veći volumen, trošak postaje manje linearan i teže ga je prognozirati. Kod self-hosted n8n, marginalni trošak je uglavnom infrastruktura plus vrijeme održavanja, što nakon inicijalne postave može biti predvidljivije.

Sigurnost je drugi pokretač. Sa self-hosted n8n možete zadržati podatke unutar svog VPC-a, kontrolirati retenciju i nametnuti politike pristupa. To je bitno kada radite s PII podacima, financijskim podacima korisnika ili internim proprietarnim tokovima podataka.

Održivost je treća. n8n je developer-friendly za kompleksno grananje, subworkflowe za ponovnu upotrebu i custom logiku. To postaje važno kada imate desetke automatizacija i više dionika.

ℹ️ Napomena: Kompromis je operativna odgovornost. Self-hosted n8n zahtijeva monitoring, backup, updateove i incident response. Računajte na barem nekoliko sati mjesečno za održavanje, a više tijekom inicijalnog rollouta.

# Checklist za spremnost na migraciju#

Prije nego dotaknete ijedan workflow, uskladite tim i okruženje. Većina neuspjelih migracija nije do spajanja nodeova, nego do izostanka vlasništva, nedostatka testnih podataka i nejasne mehanike cutovera.

# Korak 1: Inventarizirajte svaki workflow i njegovo stvarno ponašanje#

Inventar treba opisivati što workflow stvarno radi, a ne što sugerira ime. U Zapier i Make ponašanje često živi u filterima, pathovima, formatterima i sitnim “glue” koracima koje je lako previdjeti.

Napravite spreadsheet ili laganu bazu s jednim redom po workflowu. Uključite barem ova polja:

Kako brzo izvući inventar#

Iskoristite što platforma nudi, a ručno popunite rupe.

1. 1
   Exportajte ili kopirajte liste workflowa iz Zapier i Make.
2. 2
   Za svaki workflow napravite screenshotove ili export JSON-a gdje je moguće.
3. 3
   Dodajte execution volumen za zadnjih 30 dana i zadnjih 90 dana, jer sezonalnost je bitna.

Ako nemate brojke volumena, procijenite konzervativnim granicama. Primjerice, webhook triggeri često imaju spikeove. Workflow koji u prosjeku ima 200 izvođenja dnevno može ipak skočiti na 2.000 izvođenja na dan lansiranja marketinške kampanje.

💡 Savjet: Dodajte ocjenu “blast radius” od 1 do 5. Workflow koji samo posta u Slack kanal ima nizak blast radius. Workflow koji naplaćuje kartice, izdaje povrate ili briše zapise ima visok blast radius i treba ga migrirati zadnjeg.

# Korak 2: Mapirajte triggere i akcije na n8n ekvivalente#

Ovdje se migracije obično uspore. Nema svaka Zapier app akcija direktan n8n node s identičnim poljima, a Make scenariji se ponekad oslanjaju na proprietarne module.

Krenite izradom tablice mapiranja. To jasno razdvaja što je “native”, što traži HTTP pozive i što traži custom kod.

Kada koristiti HTTP Request umjesto native nodeova#

Preferirajte HTTP Request node kada:

• aplikacija ima stabilan REST API i dobru dokumentaciju
• trebaju vam polja koja native node ne izlaže
• želite konzistentno ponašanje kroz okruženja

Native nodeovi su brži za izradu, ali API pozivi olakšavaju razmišljanje o paritetu jer precizno kontrolirate payload i error handling.

⚠️ Upozorenje: Nemojte pretpostaviti da “success” znači “sigurno”. Neki Zapier koraci su efektivno idempotentni jer Zapier iza kulisa deduplicira za određene triggere. U n8n ćete možda morati implementirati vlastiti idempotency key kako biste izbjegli duplikate.

# Korak 3: Dizajnirajte n8n arhitekturu prije nego išta krenete rebuildati#

Migracija je prilika za standardizaciju obrazaca. Ako rebuildate jedan-na-jedan bez strukture, završit ćete s n8n sprawlom.

Preporučena struktura za održiv n8n u većem opsegu#

Dosljedno primjenjujte ove konvencije:

Ako krećete od nule, uskladite ovo s hosting i sigurnosnim postavkama. Koristite naš vodič za self-hosting kao baseline: n8n self-hosting s Dockerom i sigurnošću.

Minimalna postava okruženja za migraciju#

Minimalno, vodite dva okruženja:

• n8n-dev za rebuild i testna izvođenja
• n8n-prod za produkcijska izvođenja i cutover

Ako ne možete voditi dvije instance, izolirajte kroz credenciale i strogo imenovanje, ali to tretirajte kao privremeni kompromis.

# Korak 4: Rebuildajte workflowe u n8n koristeći subworkflowe za ponovnu upotrebu#

Ovdje dugoročno dobivate najviše. Zapier i Make workflowi često dupliciraju zadatke poput normalizacije imena, validacije emailova ili formatiranja Slack poruka. U n8n to pretvorite u subworkflowe koje možete koristiti posvuda.

Migracijski okvir za ponovnu upotrebu#

Prvo izgradite malu internu biblioteku subworkflowa, pa tek onda poslovne workflowe iznad nje.

Primjer: obrazac poziva subworkflowa#

Neka bude jednostavno: glavni workflow skuplja podatke, poziva subworkflow, pa grana prema rezultatu.

// Primjer Code node-a: generiranje idempotency ključa
const crypto = require('crypto');
 
const payload = $json;
const keySource = `${payload.email || ''}|${payload.eventId || ''}|${payload.timestamp || ''}`;
const idempotencyKey = crypto.createHash('sha256').update(keySource).digest('hex');
 
return [{ ...payload, idempotencyKey }];

Taj se ključ može koristiti za provjeru DB tablice ili Data Store-a prije izvršavanja side effecta poput kreiranja CRM zapisa.

🎯 Ključna poruka: Prvo izgradite subworkflowe za zajedničku logiku, pa tek onda migrirajte workflowe. To smanjuje ukupno vrijeme migracije jer svaki sljedeći workflow postaje uglavnom “wiring”, a ne ponovno izmišljanje.

Koristite predloške kako biste ubrzali rebuild#

n8n templates su dobri kao polazišna točka, ali tretirajte ih kao scaffolding. Cilj je paritet s vašim postojećim poslovnim pravilima, a ne generički flow.

Za praktičan pristup isporuci vođenoj predlošcima, pogledajte: vodič za n8n workflow predloške.

# Korak 5: Validirajte paritet s testnim podacima i shadow runovima#

Paritet znači više od “pokreće se”. Znači da za iste ulaze proizvodi iste izlaze, uključujući edge caseove.

Unaprijed definirajte metrike pariteta#

Koristite mjerljive acceptance kriterije:

Napravite testni dataset koji stvarno “lomi” stvari#

Uključite:

1. 1
   Null i nedostajuća polja
2. 2
   Neočekivane tipove, npr. brojevi kao stringovi
3. 3
   Unicode imena i ne-engleske locale postavke
4. 4
   Duple prijave
5. 5
   Velike payload-e, posebno s arrayima i attachmentima

Ako imate workflow forma->CRM, nemojte testirati samo s jednim savršenim leadom. Testirajte s 30 do 100 leadova koji pokrivaju gore navedeno.

Strategija shadow run-a#

Shadow run znači da oba sustava vide isti event, ali samo jedan sustav radi side effecte.

Uobičajen obrazac:

• Zapier ostaje sistem zapisa (system of record) i piše u produkciju.
• n8n se vrti paralelno i piše u sandbox ili samo logira outpute.
• Svaki dan uspoređujete rezultate dok stopa nepodudarnosti praktično ne postane nula.

Za automatizacije bazirane na webhooks, možete duplicirati evente tako da isti webhook payload šaljete na dva endpointa tijekom migracijskog prozora.

curl -X POST "https://n8n.example.com/webhook/lead" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","eventId":"evt_123","timestamp":"2026-08-04T10:00:00Z"}'

Kad isti payload proizvede iste downstream promjene objekata, spremni ste za cutover.

💡 Savjet: Logirajte kompaktan “parity fingerprint” za svaki run, npr. hash normaliziranih output polja. Usporedba hashova brža je od usporedbe cijelog JSON-a.

# Korak 6: Plan cutovera koji izbjegava duplikate#

Cutover je mjesto gdje migracije uspiju ili padnu. Dva najveća rizika su duplo procesiranje i tiho “data driftanje”.

Odaberite metodu cutovera#

Za većinu timova, faze po domeni + paralelno izvođenje daju najbolji balans.

Praktičan cutover checklist#

1. 1
   Zamrznite promjene u Zapier i Make za workflowe koji se migriraju.
2. 2
   Provjerite da su n8n produkcijski credentiali validni i least-privilege.
3. 3
   Uključite idempotency provjere za svaki workflow koji kreira ili ažurira zapise.
4. 4
   Prebacite triggere:

   • Za webhooks, preusmjerite izvorni sustav na n8n webhook URL.
   • Za polling triggere, ugasite Zapier polling i uključite n8n schedule.
5. 5
   Monitorirajte:

   • stopu grešaka
   • throughput
   • stopu duplikata
6. 6
   Ostavite stari sustav ugašen, ali netaknut radi rollbacka.

Sigurnije rukovanje webhook cutoverom#

Ako izvorni sustav to podržava, dodajte tajni header za webhook pozive i verificirajte ga u n8n prije obrade.

// Primjer Code node-a: osnovna provjera shared secreta
const provided = $headers['x-webhook-secret'];
if (provided !== process.env.WEBHOOK_SECRET) {
  throw new Error('Unauthorized webhook');
}
return [$json];

To sprječava da nasumični pozivi okidaju vaše automatizacije, što postaje važnije kad izložite javne endpointove.

# Korak 7: Strategija rollbacka koju možete izvesti pod pritiskom#

Rollback plan mora biti izvediv u minutama, ne u satima. Pretpostavite da će vam jednom trebati.

Definirajte rollback triggere#

Primjeri pragova za rollback:

• stopa duplikata veća od 1 na 1.000 za CRM zapise
• stopa grešaka veća od 2 posto dulje od 15 minuta
• bilo koji workflow koji uzrokuje customer-facing probleme, npr. šalje krive emailove

Mehanika rollbacka po tipu triggera#

Rollback podataka vs rollback workflowa#

Rollback workflowa vraća procesiranje, ali ne poništava promjene podataka koje su već napravljene. Za visokorizične workflowe planirajte opcije rollbacka podataka:

• “Undo” workflowi koji reverziraju promjene za poznati vremenski prozor
• Point-in-time recovery baze podataka za interne sustave
• CRM bulk revert gdje je podržano

Ako workflow može poslati email ili naplatiti karticu, dodajte “dry-run” flag i approval gate tijekom inicijalnog cutovera.

⚠️ Upozorenje: Nemojte se oslanjati na “disable workflow” kao jedini rollback. Ako je workflow već enqueueao evente, isključivanje možda neće zaustaviti akcije “u letu” osim ako ne zaustavite workere ili ne ispraznite queueve prema vašoj hosting postavi.

# Troškovi: modelirajte prije migracije#

Trošak je čest razlog migracije, ali treba ga izračunati jednako rigorozno kao i svaki inženjerski projekt.

Komponente cost modela#

Jednostavan ROI model:

• Izračunajte mjesečnu uštedu na pretplatama.
• Dodajte mjesečni infra trošak za n8n.
• Dodajte trošak inženjerskog vremena za migraciju plus tekuće održavanje.

Uokvirite račun u formulu: ROI = (annual_savings - annual_cost) / annual_cost * 100.

Tipičan skriveni trošak: workflow sprawl#

Najveća financijska dobit u n8n dolazi iz konsolidacije. Ako 30 Zapier workflowa dijeli iste tri transformacije, pretvaranje toga u subworkflowe smanjuje i održavanje i stopu bugova.

Ako migrirate bez konsolidacije, nastavljate “plaćati” kroz inženjersko vrijeme umjesto kroz pretplate.

# Sigurnost: što se mijenja kada self-hostate#

Self-hosting mijenja vaš threat model. Prelazite s vendor-managed sigurnosti na shared responsibility, a detalji implementacije su važni.

Minimalni sigurnosni baseline#

Za detaljan checklist i Docker hardening obrasce, koristite: n8n self-hosting s Dockerom i sigurnošću.

Sigurno rukovanje PII podacima tijekom paritet testiranja#

Paritet testiranje često uključuje stvarne produkcijske payload-e. Ako morate koristiti stvarne podatke:

• Maskirajte ili hashirajte emailove i brojeve telefona u logovima.
• Isključite pohranu punih execution podataka u produkciji gdje je izvedivo.
• Postavite retention limite usklađene s vašim compliance zahtjevima.

Ako workflow dira osjetljive podatke, dodajte poseban audit log koji sprema samo ono što treba za sljedivost, ne cijeli payload.

# Česte zamke tijekom migracije#

1. 1
   Promaknu poslovna pravila skrivena u filterima — replicirajte točne uvjete, posebno kako se tretiraju prazni stringovi i null vrijednosti.
2. 2
   Timezone drift — scheduling i formatiranje datuma mogu se razlikovati po okruženju; postavite eksplicitno rukovanje timezoneom za svu date logiku.
3. 3
   Rate limiti i backoff — Zapier i Make ponekad “izravnaju” spikeove. U n8n morate eksplicitno implementirati retry, backoff i dead-letter putanje.
4. 4
   Dupli triggeri tijekom cutovera — uvijek provodite idempotenciju prije bilo kakvog side effecta.
5. 5
   Credential sprawl — više OAuth aplikacija i tokena vodi do nepredvidivih kvarova; centralizirajte i dokumentirajte credenciale po okruženju.

# Ključne poruke#

• Inventarizirajte workflowe prema stvarnom ponašanju, uključujući filtere, pathove, transformacije, volumene i downstream side effecte prije nego rebuildate bilo što.
• Rano mapirajte triggere i akcije na n8n nodeove te isplanirajte gdje su HTTP Request i custom kod potrebni za puni paritet.
• Rebuildajte uz subworkflowe za ponovnu upotrebu (normalizacija, logging, idempotencija, error handling) kako biste smanjili dugoročni trošak održavanja.
• Validirajte paritet strukturiranim testnim datasetom i shadow runovima, koristeći mjerljive metrike poput stope grešaka, stope duplikata i SLA vremena.
• Izvedite cutover uz eksplicitan plan po tipu triggera i zadržite rollback putanju koju možete izvršiti u minutama, ne u satima.
• Modelirajte trošak i sigurnost unaprijed: self-hosting povećava kontrolu i predvidljivost, ali donosi stalnu operativnu odgovornost.

# Zaključak#

Migracija sa Zapier ili Make na self-hosted n8n nije zadatak tipa “rekreiraj isti flow”. To je prilika da standardizirate arhitekturu automatizacije, smanjite dupliciranje kroz subworkflowe i dobijete kontrolu nad troškovima, sigurnošću i observabilityjem.

Ako želite migracijski plan prilagođen vašem stacku, možemo auditirati vaš postojeći Zapier ili Make račun, procijeniti effort i ROI, a zatim implementirati faznu migraciju s paritet testiranjem, cutoverom i rollbackom. Javite se Samiodi i pomoći ćemo vam migrirati sa Zapier na n8n sigurno i mjerljivo.