Cómo migrar de Zapier a n8n paso a paso, guía completa 2026

Automatización

16 de octubre de 202610 min read

Miguel Ángel Rodríguez (Miguelo DEV)Especialista en automatización de procesos con n8n

La decisión ya está tomada y los números cuadran. Lo que viene ahora es el trabajo de verdad, que es reconstruir en n8n lo que llevas años montando en Zapier.

Y aquí está la primera mala noticia, que conviene saber antes de planificar nada. Zapier no te deja exportar tus Zaps. No hay fichero que llevarte ni conversor que importe. La migración es una reconstrucción manual, flujo a flujo. Si la planteas como una copia, el proyecto se te va de las manos en la primera semana.

La buena noticia es que las piezas se corresponden casi todas, el mapa es corto y los tres sitios donde se tuercen las migraciones son siempre los mismos. Esta guía es ese mapa. Si lo que buscas son precios y plazos, están en cuánto cuesta migrar de Zapier a n8n.

Cómo inventariar tus Zaps antes de empezar la migración a n8n

El inventario no se hace mirando la lista de Zaps, se hace mirando el historial de ejecuciones. La lista te dice lo que montaste alguna vez. El historial te dice lo que está vivo, y la diferencia entre ambas cosas suele ser un tercio de la carpeta.

Para cada Zap encendido, cinco datos y ninguno más.

Qué lo dispara y de qué tipo es. Instantáneo por webhook o por consulta periódica. Esto condiciona todo lo demás y es lo primero que hay que anotar.

Qué aplicaciones toca y con qué cuenta. Importa la cuenta concreta, porque al reconectar en n8n vas a necesitar acceso a esa misma y no siempre lo tiene la persona que te encarga el proyecto.

Cuántas veces se ha ejecutado en los últimos treinta días. Lo que marca cero se queda fuera. Migrar flujos muertos es la forma más común de inflar un proyecto de migración.

Qué pasos tiene y cuáles son de Zapier y no de una aplicación. Los Filter, Paths, Formatter, Delay, Looping, Digest, Storage y Code son las piezas que hay que traducir. Las demás son integraciones y se reconectan.

Quién se entera si deja de funcionar. Si la respuesta es nadie, acabas de encontrar el primer flujo que hay que arreglar en lugar de copiar.

Ese inventario es el presupuesto, el plan de trabajo y la lista de corte, todo a la vez. Hacerlo bien lleva una mañana y ahorra semanas.

Tabla de equivalencias entre las piezas de Zapier y los nodos de n8n

Casi todo tiene su equivalente directo, salvo tres piezas que en n8n se resuelven de otra forma. Esta es la traducción que uso cuando reconstruyo.

Las tres piezas sin traducción directa son Digest, Storage y los avisos automáticos de fallo. Las dos primeras se resuelven con una tabla propia y un flujo programado. La tercera no se resuelve sola y es la que más caro sale ignorar, porque los correos de Zap fallido llevaban años siendo tu sistema de alertas sin que nadie lo decidiera.

El cambio mental de Zapier a n8n, de un registro por ejecución a un listado de items

En Zapier cada registro nuevo lanza una ejecución entera. En n8n entra una sola ejecución con todos los registros dentro y cada nodo posterior corre una vez por item. Es la diferencia que más confusión genera y la que explica casi todos los comportamientos raros de una primera migración.

Tres consecuencias prácticas, las tres cuestan dinero si se descubren tarde.

Las llamadas a una API se multiplican de golpe. Un lote de quinientos registros son quinientas llamadas seguidas, casi sin pausa. En Zapier iban repartidas en quinientas ejecuciones independientes y nunca te rozaron el límite. En n8n te lo comes en diez segundos y el proveedor empieza a devolver 429.

Un item que falla puede tumbar el lote entero. Por defecto, cuando un nodo falla con un item se para la ejecución, y los items que venían detrás no se procesan. En Zapier el registro problemático fallaba solo y los demás seguían su camino. Esto se arregla con la salida de error separada, pero hay que decidirlo nodo a nodo.

Agregar y contar se vuelve fácil y resumir se vuelve raro. Lo que en Zapier exigía Storage o Digest, en n8n a veces es un solo nodo porque ya tienes los quinientos items juntos. A cambio, cualquier paso que esperase un único registro necesita que lo pienses.

Y un detalle que confunde a todo el mundo el primer día. Si un nodo no devuelve ningún item, los nodos siguientes no llegan a ejecutarse. No es un error, es el diseño. En Zapier eso se veía como un Zap filtrado y aquí se ve como media ejecución en blanco.

Cómo se traducen los campos de Zapier a las expresiones de n8n

Donde en Zapier arrastrabas un campo, en n8n escribes una expresión, y esa expresión apunta a un nodo por su nombre. De ahí salen los dos errores más tontos de toda la migración.

El primero, renombrar un nodo después de haberlo referenciado. Las expresiones que apuntaban a su nombre antiguo dejan de resolver y el flujo empieza a escribir campos vacíos sin dar ningún error. Si vas a renombrar, hazlo antes de construir encima.

El segundo, dar por hecho que un campo que no existe va a fallar. No falla. Una expresión que resuelve a nada escribe un vacío en destino y la ejecución sale en verde. Por eso toda migración necesita una comprobación de campos obligatorios antes del nodo que escribe. Ese fallo silencioso y los demás los desgloso en qué hacer cuando un workflow de n8n falla.

Con las fechas hay una trampa más. La instancia de n8n viene con la zona horaria de Nueva York por defecto. Si no se cambia, los formatos de fecha y las programaciones salen desplazadas respecto a lo que hacía Zapier, y nadie lo nota hasta que un informe diario aparece con la fecha del día anterior.

Cómo reconstruir un Zap en n8n y comprobar que hace exactamente lo mismo

El criterio no es que el flujo nuevo funcione, es que produzca la misma salida que el viejo con la misma entrada. Son dos cosas distintas y solo la segunda te deja cortar tranquilo.

El orden que sigo con cada flujo.

Empiezo por el dato, no por el disparador. Cojo una ejecución real reciente del historial de Zapier y me quedo con lo que entró. Ese registro es el caso de prueba de toda la reconstrucción.

Monto el disparador en modo manual y lo dejo quieto. Lo importante al principio es tener el dato dentro de n8n, no que se dispare solo.

Reconstruyo paso a paso comparando salidas. Cada nodo nuevo contra el paso equivalente del historial de Zapier. Si el tercer paso ya diverge, no sigo hasta que cuadre, porque un error arrastrado se vuelve imposible de encontrar diez nodos después.

Dejo lo que escribe para el final y apuntando a un destino de pruebas. Una hoja aparte, un entorno de pruebas, un tablero duplicado. Lo que no vale es probar escribiendo en producción y borrar después, porque el día que ese registro dispara una factura real te acuerdas de esto.

Y solo entonces publico y lanzo con datos de verdad.

El plan de corte de Zapier a n8n sin que nadie se entere

Las dos plataformas encendidas a la vez durante unos días, y Zapier se apaga el último. Encender n8n y apagar Zapier el mismo día es la única parte de la migración que no admite marcha atrás.

El corte, en cinco pasos.

Primero, los flujos que solo leen. Informes, copias, sincronizaciones internas. Pueden correr en paralelo sin consecuencias y te enseñan si las credenciales y los tiempos cuadran.

Después, el periodo en paralelo de los que escriben, pero escribiendo a un destino de pruebas. n8n hace el trabajo completo contra un sitio inofensivo mientras Zapier sigue siendo el que va a producción. Comparas ambos lados cada día.

Tercero, repuntar los webhooks uno a uno y en la misma ventana. Este es el paso delicado. Mientras repuntas, hay un momento en que el evento ya no va a Zapier y todavía no llega bien a n8n. Hazlo en horario de poco movimiento y con la lista del inventario delante.

Cuarto, pausar los Zaps en lugar de borrarlos. Pausados siguen ahí dos o tres semanas, por si hay que volver. Borrarlos el primer día no ahorra nada y te quita la red.

Quinto, montar las alertas antes de dar el proyecto por cerrado. Flujo de errores conectado a todo lo crítico y avisos sobre el resultado del proceso. Sin esto acabas de cambiar una plataforma que te avisaba por una que no.

Qué Zaps no deberías migrar nunca tal y como están

Te lo digo aunque reduzca el tamaño del proyecto, porque copiar errores de un sitio a otro se paga dos veces.

El Zap que lleva treinta días sin ejecutarse. No lo migres, apágalo. Si alguien lo echa de menos en un mes, lo montamos entonces en media hora.

El Zap que tiene un paso puesto para que deje de dar error. Ese paso existe porque algo falla desde hace meses y alguien tapó el aviso. Migrarlo es llevarte el problema de mudanza.

Los cuatro Zaps que hacen casi lo mismo con una variación. En n8n eso es un flujo con un Switch y un subflujo compartido. Reconstruirlos tal cual es multiplicar por cuatro el mantenimiento que vas a pagar durante años.

El Zap que nadie sabe explicar. Si no hay nadie que sepa decir qué tiene que pasar cuando entra un registro, no es un problema de herramienta. Primero se escribe el proceso y luego se automatiza.

Cómo reconstruyo yo un Zap complicado en n8n sin perder una semana

No reconstruyo el Zap, reconstruyo el proceso que el Zap intentaba hacer. Casi todos los flujos largos de Zapier son largos por culpa de la plataforma, no del proceso, y traducirlos nodo a nodo es heredar sus límites.

Separo lo que es el proceso de lo que son parches de Zapier. Un Zap de dieciocho pasos suele tener seis pasos de negocio y doce de dar formato, trocear texto y guardar cosas en Storage. En n8n esos doce se caen solos.

Busco la variación antes de duplicar. Si hay cuatro Zaps parecidos, pregunto qué cambia entre ellos. Casi siempre es un campo. Eso es un flujo con una rama, no cuatro flujos.

Comparo salidas contra el historial de Zapier, no contra lo que yo creo que debería salir. El historial es la especificación real del proceso, con todas sus rarezas, y esas rarezas suelen estar ahí por algo.

Cierro cada flujo con su manejo de errores puesto, no para luego. Qué pasa si un item falla, qué se reintenta, quién se entera. Si lo dejo para el final del proyecto, el final del proyecto llega con prisas y no se hace.

Traducido a tu dinero, esto es lo que hace que la factura de la migración no vuelva a aparecer dentro de seis meses disfrazada de mantenimiento. Migrar mal cuesta poco una vez y mucho todos los meses. Cómo planteo un proyecto entero lo cuento en automatizaciones con n8n.

Si te quedas con una sola idea, que sea esta. Una migración de Zapier a n8n no se mide en Zaps traducidos, se mide en días que tu equipo no se entera de nada.