Antes de mexer num único Zap: o inventário que decide a ordem
Quase toda a gente que procura como migrar de Zapier para n8n começa da mesma maneira: abre o n8n e monta o primeiro fluxo. Ordem errada. Construir não é o primeiro passo. O primeiro passo é saber o que tens ligado, o que chama o quê e em que ordem se pode desligar alguma coisa sem que caia outra por trás.
A decisão já está tomada. Se ainda estás no « mudo ou não? », isso resolve-se em alternativas ao Zapier para empresa e em n8n vs Make vs Zapier. Este guia começa onde esses acabam: já sabes para onde vais, agora é chegar lá sem apagar a luz.
O inventário não é uma lista de nomes de Zaps. É uma ficha curta por fluxo, com seis dados e nem mais um:
- O que o dispara. Um webhook, um agendamento ou uma alteração numa aplicação. Os de webhook são os que mais doem, e já vais perceber porquê.
- Que aplicações toca, separando o que lê do que escreve. O que escreve é o que desarruma um sistema real se os dois fluxos correrem ao mesmo tempo.
- Quem o chama de fora. Um formulário, o painel de outro fornecedor, o script de alguém. É a coluna que ninguém preenche e a que dá o susto.
- O que acontece se estiver parado uma hora. Não vale « é importante »: o que se perde e quem dá por isso.
- Com que conta se liga a cada aplicação, e de quem é essa conta.
- Quem o percebe, com nome próprio e apelido. Se a resposta for « ninguém », esse fluxo ainda não se migra: primeiro decifra-se.
O primeiro obstáculo é de plano. O Zapier deixa exportar os Zaps para JSON a partir das definições da conta, na secção de segurança e dados, mas só nos planos Team e Enterprise: no Free e no Professional não há botão. Se estás no Professional —onde vive muita empresa média— o inventário faz-se à mão, Zap a Zap, e essa tarde entra no orçamento.
Com o inventário à frente, a ordem sai sozinha. Não se migra do fácil para o difícil: migra-se do reversível para o irreversível. Um aviso interno pode ser mal migrado e resolvido em dez minutos. Um fluxo que emite uma fatura ou manda um email a um cliente não aceita o « amanhã arranjamos ».
Por ondas, não de uma vez: pedaços que se podem desfazer
A falha mais cara de uma migração não é técnica, é de tamanho. Mexer nos quarenta fluxos no mesmo fim de semana significa que, quando algo falhar na segunda-feira, vais estar a depurar quarenta coisas ao mesmo tempo. Migrar por ondas não é ir devagar: é conseguir apontar a causa.
Uma onda é um grupo de fluxos que se migram, se observam e se dão por bons em conjunto — e que se podem devolver ao Zapier em conjunto. Quatro costumam chegar:
- Onda zero: a canalização. Nenhum fluxo de negócio. Levanta-se o n8n, ligam-se as credenciais das aplicações que aparecem em todo o lado e monta-se o fluxo de erros. Saltá-la é fazer as três seguintes às cegas.
- Onda um: o reversível. Avisos internos, relatórios, sincronizações que se podem relançar. Aprende-se a ferramenta com o custo de errar quase a zero.
- Onda dois: o volume. Os fluxos longos e de muito tráfego, os que justificavam a migração.
- Onda três: o cliente e o dinheiro. Faturação, contratos, emails que saem para fora, escritas no ERP. Os últimos, com execução dupla longa e com alguém a olhar.
E uma onda não acaba quando o fluxo novo funciona. Acaba quando são verdade quatro coisas: passou um período combinado a dar o mesmo resultado que o velho, os seus alertas estão montados e testados, alguém que não o construiu sabe lê-lo, e o Zap original está desligado mas não apagado. Enquanto faltar uma, a onda seguinte não começa.
O que não se copia: o Zap linear de trinta passos redesenha-se
Aqui está a tentação que estraga migrações que iam bem: abrir o Zap, contar os passos e reproduzir um a um os mesmos trinta nós em n8n. Sai um fluxo que funciona no primeiro dia e que ninguém consegue manter ao sexto mês: traduziste literalmente uma estrutura que só existia por causa de um limite da ferramenta que estás a deixar.
O Zapier é uma cadeia: um disparador e uma fila de passos. Quando são precisos dois caminhos, o hábito é partir o processo em vários Zaps encadeados por um campo intermédio. O n8n é uma tela com ramos, ciclos e subfluxos, e essa coleção de Zaps presa com fita-cola costuma colapsar num único fluxo com dois ramos. É a diferença entre poder mudar alguma coisa daqui a um ano ou não te atreveres a lhe tocar.
Atenção, nem tudo se redesenha. O fluxo de dois passos que faz uma coisa e fá-la bem passa-se tal e qual. A regra cabe numa linha: se se explica numa frase, copia-se; se precisas de um parágrafo e de um « exceto quando », redesenha-se.
Os conversores automáticos: ponto de partida, nunca entrega
Nem o Zapier nem o n8n oferecem uma ponte oficial entre as duas plataformas. O que há são conversores de terceiros que leem o JSON exportado e devolvem um fluxo de n8n aproximado. São úteis e tratam da parte mecânica: mapeamento de campos, nomes, forma geral. Usa-os.
E depois trata-os pelo que são: um rascunho. Um conversor traduz a estrutura, e a estrutura é precisamente o que tinhas decidido não copiar. Não traz credenciais, não monta o controlo de erros e não consegue ver que aqueles três Zaps são na verdade um só processo. Entregar a saída de um conversor é entregar o problema traduzido.
Credenciais e OAuth: é aqui que está o trabalho a sério
Pergunta a quem já fez esta migração o que levou as horas e não vai dizer a lógica: vai dizer os acessos. Um export leva a estrutura do fluxo, nunca a chave para entrar nas aplicações. E não é uma falha dos conversores: as credenciais vivem na ligação, não no passo.
A própria documentação do Zapier é clara mesmo no caso mais fácil, importar Zaps dentro do Zapier: depois é preciso ligá-los e testar as ligações às aplicações, voltando a ligar as que já não estejam ativas. Entre duas plataformas diferentes autentica-se tudo outra vez, uma a uma, à mão. Três armadilhas transformam essa tarde numa semana:
- A conta pessoal. Meia dúzia de ligações costumam estar feitas com a conta de alguém em concreto. A migração é a única oportunidade barata de passar tudo para contas de serviço; se repetes o padrão, só mudaste a dívida de sítio.
- As permissões de OAuth. Autorizar uma aplicação nova contra o Google Workspace, o Microsoft 365 ou o Salesforce nem sempre pode ser feito por quem monta o fluxo: em muitas empresas é um administrador que aprova. Não é um clique, é um ticket com um prazo que não controlas. Pede-o na onda zero.
- Os endereços de webhook. Um Zap disparado por webhook tem um URL colado em sítios que não controlas. Ao migrar muda. Se ninguém atualizar a origem, o fluxo novo não falha: simplesmente não lhe chega nada.
Execução dupla: as duas a correr até desligar ser aborrecido
A execução dupla é o período em que o fluxo velho e o novo processam o mesmo ao mesmo tempo e tu comparas as saídas antes de desligar qualquer um. Transforma o corte —o momento que mete medo— numa formalidade: quando desligas o Zap já sabes, com dados à frente, que o fluxo de n8n faz o mesmo.
Tem uma armadilha para resolver antes de começar: se os dois escrevem no mesmo sítio, acabaste de duplicar cada encomenda e cada fatura. Por isso o fluxo novo corre em sombra: lê da fonte real e escreve num destino paralelo. O destino real só lhe é entregue quando a comparação deixa de dar surpresas. E comparar não é « parece que está bem ». São quatro coisas:
- A contagem. Entraram os mesmos casos nos dois? Se o novo processou menos, tens um disparador mal montado ou um filtro a mais.
- O conteúdo campo a campo, sobre uma amostra real. É aqui que saltam os formatos de data, as casas decimais e o campo vazio porque tinha outro nome.
- Os casos estranhos, de propósito. A encomenda sem cliente, o email sem assunto, o valor zero. O caminho feliz coincide sempre; a migração parte-se no punhado que não encaixa.
- O calendário. Deixa passar o fecho do mês ou o ciclo de faturação, aquilo que só acontece no dia um.
Quanto dura a execução dupla não se mede em dias: mede-se em casos vistos. Um fluxo que dispara mil vezes por dia esgota a sua variedade numa semana. Um que dispara quando entra um concurso espera que entre um concurso. Pôr data fixa ao corte é a forma elegante de cortar cedo demais.
Alertas e regresso atrás: montam-se antes do corte, não depois
Um fluxo migrado não está terminado quando funciona. Está terminado quando vais dar por isso que deixou de funcionar e podes voltar atrás sem improvisar. As duas coisas montam-se antes de desligar seja o que for, porque depois já ninguém as monta: assim que o fluxo novo anda, a atenção vai-se embora com a onda seguinte.
No n8n isso tem um nome concreto. Cria-se um fluxo à parte que começa com o nó Error Trigger e escolhe-se como fluxo de erros nas definições de cada fluxo importante. E atenção a um detalhe da própria documentação do n8n que apanha muita gente: esse fluxo de erros não se pode testar com uma execução manual, porque o Error Trigger só dispara quando falha uma execução automática. Testa-o a provocar uma falha real, ou vais descobrir que não funcionava logo no dia em que precisavas dele.
Isto cobre o que falha a fazer barulho. O que morre em silêncio —o fluxo que deixou de receber porque ninguém atualizou o URL do webhook— não é apanhado por nenhum alerta, porque não há erro: não há nada. Vigiar a ausência é a outra metade do trabalho e está desenvolvida em detetar falhas nas automatizações.
O plano de regresso atrás é a parte mais barata de escrever e a que ninguém escreve. Por cada onda, três frases: que Zap se volta a ligar, que fluxo de n8n se desliga e onde é que o URL do webhook tem de ser reposto. Se isso não se pode executar em cinco minutos sem perguntar a ninguém, não tens um plano: tens uma intenção.
Quando fechar a última onda, o que tens não é « o mesmo mas em n8n »: são fluxos novos que a partir de amanhã têm de ser operados. É aí que começa o trabalho de os manter vivos e de governar o que fazem. Montar o n8n para que aguente uma empresa a sério está em n8n para empresas; o mapa completo, no guia de automatizar com IA.