Antes de mover un solo Zap: el inventario que decide el orden
Casi todo el que busca cómo migrar de Zapier a n8n empieza igual: abre n8n y monta el primer flujo. Es el orden equivocado. Lo primero no es construir: es saber qué tienes encendido, qué llama a qué y en qué orden se puede apagar algo sin que se caiga otra cosa por detrás.
La decisión ya la has tomado. Si sigues en el «¿me cambio o no?», eso se resuelve en alternativas a Zapier para empresa y en n8n vs Make vs Zapier. Esta guía empieza donde aquellas terminan: sabes a dónde vas, ahora hay que llegar sin apagar la luz.
El inventario no es una lista de nombres de Zaps. Es una ficha corta por flujo, con seis datos y ni uno más:
- Qué lo dispara. Webhook, programación o un cambio en una app. Los de webhook son los que más duelen, y en un momento verás por qué.
- Qué apps toca, separando lo que lee de lo que escribe. Lo que escribe es lo que desordena un sistema real si los dos flujos corren a la vez.
- Quién lo llama desde fuera. Un formulario, el panel de otro proveedor, el script de alguien. Es la columna que nadie rellena y la que da el susto.
- Qué pasa si está parado una hora. No vale «es importante»: qué se pierde y quién lo nota.
- Con qué cuenta se conecta a cada app, y de quién es esa cuenta.
- Quién lo entiende, con nombre y apellidos. Si la respuesta es «nadie», ese flujo no se migra: primero se descifra.
El primer obstáculo es de plan. Zapier deja exportar los Zaps a JSON desde los ajustes de cuenta, en la sección de seguridad y datos, pero solo en Team y Enterprise: en Free y en Professional no hay botón. Si estás en Professional —donde vive mucha empresa mediana— el inventario se hace a mano, Zap por Zap, y esa tarde va en el presupuesto.
Con el inventario delante, el orden se cae solo. No se migra de lo fácil a lo difícil: se migra de lo reversible a lo irreversible. Un aviso interno se puede migrar mal y arreglar en diez minutos. Un flujo que emite una factura o manda un correo a un cliente no admite «lo arreglamos mañana».
Por olas, no de golpe: trozos que se pueden deshacer
El fallo más caro de una migración no es técnico, es de tamaño. Mover los cuarenta flujos el mismo fin de semana significa que, cuando algo falle el lunes, estarás depurando cuarenta cosas a la vez. Migrar por olas no es ir despacio: es poder señalar la causa.
Una ola es un grupo de flujos que se migran, se observan y se dan por buenos juntos — y que se pueden devolver a Zapier juntos. Cuatro suelen bastar:
- Ola cero: la infraestructura. Ningún flujo de negocio. Se levanta n8n, se conectan las credenciales de las apps que salen en todas partes y se monta el flujo de errores. Saltársela es hacer las tres siguientes a ciegas.
- Ola uno: lo reversible. Avisos internos, informes, sincronizaciones que se pueden relanzar. Se aprende la herramienta con el coste de equivocarse casi a cero.
- Ola dos: lo que da volumen. Los flujos largos y de mucho tráfico, los que justificaban la migración.
- Ola tres: lo que toca al cliente y al dinero. Facturación, contratos, correos que salen fuera, escrituras en el ERP. Los últimos, con doble ejecución larga y con alguien mirando.
Una ola no termina cuando el flujo nuevo funciona. Termina cuando pasan cuatro cosas: lleva un periodo acordado dando el mismo resultado que el viejo, sus alertas están montadas y probadas, alguien que no lo construyó sabe leerlo, y el Zap original está apagado pero no borrado. Mientras falte una, no se empieza la siguiente.
Lo que no se copia: el Zap lineal de treinta pasos se rediseña
Aquí está la tentación que arruina migraciones que iban bien: abrir el Zap, contar sus pasos y reproducir uno por uno los mismos treinta nodos en n8n. Sale un flujo que funciona el primer día y que nadie puede mantener el mes seis: has traducido literalmente una estructura que existía por una limitación de la herramienta de origen.
Zapier es una cadena: un disparador y una fila de pasos. Cuando hacen falta dos caminos, lo habitual es partir el proceso en varios Zaps encadenados por un campo intermedio. n8n es un lienzo con ramas, bucles y subflujos, y esa colección de Zaps atados con cinta adhesiva suele colapsar en un solo flujo con dos ramas. Es la diferencia entre poder cambiar algo dentro de un año o no atreverte a tocarlo.
Ojo, no todo se rediseña. El flujo de dos pasos que hace una cosa y la hace bien se pasa literal. La regla cabe en una línea: si se explica en una frase, se copia; si necesitas un párrafo y un «salvo cuando», se rediseña.
Los convertidores automáticos: punto de partida, nunca entrega
Ni Zapier ni n8n ofrecen un puente oficial entre las dos plataformas. Lo que hay son convertidores de terceros que leen el JSON exportado y devuelven un flujo de n8n aproximado. Son útiles y se llevan la parte mecánica: el mapeo de campos, los nombres, la forma general. Úsalos.
Y trátalos como lo que son: un borrador. Un convertidor traduce la estructura, y la estructura es justo lo que habías decidido no copiar. No trae credenciales, no monta el control de errores y no puede ver que esos tres Zaps son en realidad un solo proceso. Entregar la salida de un convertidor es entregar el problema traducido.
Credenciales y OAuth: aquí está el trabajo real
Pregúntale a cualquiera que haya hecho esta migración qué se llevó las horas y no dirá la lógica: dirá los accesos. Un export lleva la estructura del flujo, nunca la llave para entrar en las apps. No es una carencia de los convertidores: las credenciales viven en la conexión, no en el paso.
La documentación de Zapier lo deja claro incluso en el caso más fácil, importar Zaps dentro de Zapier: después hay que encenderlos y probar las conexiones, reconectando las que ya no estén activas. Entre dos plataformas distintas se vuelve a autenticar todo, una por una, a mano. Tres trampas convierten esa tarde en una semana:
- La cuenta personal. Media docena de conexiones suelen estar hechas con la cuenta de alguien concreto. La migración es la única oportunidad barata de pasarlo todo a cuentas de servicio; si repites el patrón, solo has movido la deuda de sitio.
- Los permisos de OAuth. Autorizar una aplicación nueva contra Google Workspace, Microsoft 365 o Salesforce no siempre lo puede hacer quien monta el flujo: en muchas empresas lo aprueba un administrador. No es un clic, es un ticket con un plazo que no controlas. Pídelo en la ola cero.
- Las direcciones de webhook. Un Zap disparado por webhook tiene una URL pegada en sitios que no controlas. Al migrar cambia. Si nadie actualiza el origen, el flujo nuevo no falla: simplemente no le llega nada.
Doble ejecución: las dos corriendo a la vez hasta que apagar sea aburrido
La doble ejecución es el periodo en que el flujo viejo y el nuevo procesan lo mismo a la vez y tú comparas sus salidas antes de apagar ninguno. Convierte el corte —el momento que da miedo— en un trámite: cuando apagas el Zap ya sabes, con datos delante, que el flujo de n8n hace lo mismo.
Tiene una trampa que hay que resolver antes de empezar: si los dos escriben en el mismo sitio, acabas de duplicar cada pedido y cada factura. Por eso el flujo nuevo corre en sombra: lee de la fuente real y escribe en un destino paralelo. El destino real solo se le entrega cuando la comparación deja de dar sorpresas. Y comparar no es «parece que va bien». Son cuatro cosas:
- El recuento. ¿Entraron los mismos casos en los dos? Si el nuevo procesó menos, tienes un disparador mal montado o un filtro de más.
- El contenido campo a campo, sobre una muestra real. Aquí salen los formatos de fecha, los decimales y el campo vacío porque se llamaba distinto.
- Los casos raros, a propósito. El pedido sin cliente, el correo sin asunto, el importe cero. El camino feliz coincide siempre; la migración se rompe en el puñado que no encaja.
- El calendario. Deja pasar el cierre de mes o el ciclo de facturación, lo que sea que solo ocurre el día uno.
Cuánto dura no se mide en días: se mide en casos vistos. Un flujo que se dispara mil veces al día agota su variedad en una semana. Uno que se dispara cuando entra una licitación espera a que entre una licitación. Ponerle fecha fija al corte es la forma elegante de cortar antes de tiempo.
Alertas y vuelta atrás: se montan antes del corte, no después
Un flujo migrado no está terminado cuando funciona. Está terminado cuando te vas a enterar de que ha dejado de funcionar y puedes volver atrás sin improvisar. Se montan antes de apagar nada, porque después no las monta nadie: en cuanto el flujo nuevo va, la atención se marcha con la siguiente ola.
En n8n eso tiene un nombre concreto. Se crea un flujo aparte que empieza con el nodo Error Trigger y se selecciona como flujo de errores en los ajustes de cada flujo importante. Y ojo con un detalle de la propia documentación de n8n que pilla a mucha gente: ese flujo de errores no se puede probar ejecutando a mano, porque el Error Trigger solo salta cuando falla una ejecución automática. Pruébalo provocando un fallo real, o te enterarás de que no funcionaba el día que lo necesitabas.
Eso cubre lo que falla haciendo ruido. Lo que se cae en silencio —el flujo que dejó de recibir porque nadie actualizó la URL del webhook— no lo detecta ninguna alerta, porque no hay error: no hay nada. Vigilar la ausencia es la otra mitad y está en detectar fallos en automatizaciones.
El plan de vuelta atrás es la parte más barata de escribir y la que nadie escribe. Por cada ola, tres frases: qué Zap se vuelve a encender, qué flujo de n8n se apaga y dónde hay que devolver la URL del webhook. Si no se puede ejecutar en cinco minutos sin preguntar a nadie, no tienes un plan: tienes una intención.
Cuando cierre la última ola, lo que tienes no es «lo mismo pero en n8n»: son flujos nuevos que a partir de mañana hay que operar. Ahí empieza el trabajo de mantenerlos vivos y de gobernar lo que hacen. Montar n8n para que aguante una empresa está en n8n para empresas; el mapa completo, en la guía de automatizar con IA.