Saltar al contenido
Zapier / Make a n8n

Migrar de Zapier a n8n sin romper lo que ya funciona

Migrar de Zapier a n8n significa mover las automatizaciones que tu empresa corre en Zapier (o en Make) a n8n, una plataforma de flujos de código abierto que puede correr en infraestructura que controlas, sin interrumpir los procesos que dependen de ellas. Es para empresas cuya cuenta de Zapier creció con el volumen de tareas, que chocaron con límites como no poder meter código, no tener ciclos o necesitar que los datos queden en su propia nube, o que acumularon cien zaps que nadie documentó. Soy ingeniero de sistemas de IA independiente y DevOps senior con diez años de infraestructura en producción, y uso n8n a diario en mi propia operación. El método es siempre el mismo: inventariar cada zap, clasificarlo por criticidad, mapearlo a su equivalente en n8n, reconstruir por lotes, correr ambas plataformas en paralelo y cortar con un plan de retroceso. Un precio fijo acordado tras una llamada de diagnóstico, garantía operativa de 60 días y flujos 100% tuyos.

¿Cuándo conviene migrar de Zapier a n8n y cuándo no?

Migrar vale la pena cuando se cumple alguna de cuatro cosas. La cuenta escala con el volumen de tareas y cada automatización nueva ya cuesta más de lo que ahorra. Necesitas algo que Zapier no hace bien: código real, un ciclo sobre cientos de registros, una decisión con varias ramas y rutas de error, o un flujo que debe correr en tu propia nube por residencia de datos. Tienes más zaps de los que alguien puede explicar, armados por tres personas en cuatro años, y nadie sabe cuáles sostienen la operación. O quieres pasos de IA y agentes sobre tus propios documentos, en infraestructura tuya y no a través de un conector que cobra por tarea.

Migrar no vale la pena cuando corres un puñado de zaps simples: un formulario a una planilla, un negocio nuevo a Slack, un evento del calendario a un correo. Zapier es excelente en eso, el costo es despreciable y una migración sería un proyecto sin retorno. Lo digo en la primera llamada. Lo mismo vale si nadie puede responder por actualizaciones y respaldos de la instancia: ahí n8n Cloud o quedarse donde estás es la recomendación honesta.

  • Migra: la cuenta crece con el volumen, necesitas código, ciclos, ramas o residencia de datos, o tienes más de 100 zaps sin documentar
  • Quédate: menos de una docena de zaps simples y una cuenta que ni notas
  • Parcial: deja los zaps triviales en Zapier y mueve los pesados y los sensibles

¿Cuál es el método para migrar de Zapier a n8n?

Cada migración sigue los mismos seis pasos, porque el riesgo nunca está en construir el flujo en n8n. Está en olvidar un zap que movía plata en silencio, o en cortar un viernes sin camino de vuelta. Primero, inventario: exportar cada zap y escenario de Make, incluidos los pausados, con disparador, aplicaciones, dueño, última ejecución y tareas mensuales. Segundo, clasificar: cada automatización queda como crítica (toca ingresos, clientes o facturación), importante (operación interna) o desechable (nadie la ha necesitado en seis meses). Cerca de un tercio suele caer en la última categoría, y se elimina, no se migra.

Tercero, mapear: cada zap que sobrevive recibe su equivalente en n8n por escrito, nodo por nodo, con lo que no se traduce 1:1 marcado. Cuarto, reconstruir por lotes, primero lo de bajo riesgo, para que el equipo aprenda la plataforma antes de mover los flujos críticos. Quinto, corrida en paralelo: las automatizaciones críticas corren en ambas plataformas una o dos semanas, con n8n en modo sombra escribiendo a un registro en vez del sistema real, y las salidas se comparan registro por registro. Sexto, cortar un lote a la vez, con el zap de Zapier pausado pero no eliminado, para que volver atrás sea un clic durante 30 días.

¿Qué piezas de Zapier y Make no se traducen 1:1 a n8n?

La mayoría de los zaps se traduce directo: un nodo disparador, un par de nodos de aplicación, listo. El trabajo está en las piezas que no. Los Paths de Zapier pasan a nodos IF y Switch, más flexibles pero con la lógica de las ramas escrita en vez de clickeada. Los pasos Formatter (fechas, división de texto, tablas de búsqueda) pasan a expresiones de n8n, o a un nodo Code pequeño en JavaScript o Python cuando la cadena tenía cinco pasos. Las Tables y el Storage de Zapier pasan a una base de datos real, normalmente Postgres, con más capacidad y un cambio en cómo el equipo mira los datos.

Los sub-zaps pasan a subflujos con el nodo Execute Workflow, un modelo mejor que necesita una convención de nombres. Los retrasos merecen cuidado: Zapier guarda el estado de un Delay por ti, mientras que el nodo Wait de n8n lo guarda en la base de datos, así que muchas esperas largas exigen una base dimensionada para eso. Los iteradores y agregadores de Make pasan a Split Out y Aggregate; los routers, a Switch; los manejadores de error, a flujos de error de n8n más reintentos por nodo. Las URL de webhook cambian, así que cada sistema externo que publica en un catch hook de Zapier tiene que apuntarse de nuevo, y esa lista es parte del inventario.

n8n propio o n8n Cloud: ¿cómo se hacen los números?

No voy a citar precios acá porque Zapier, Make y n8n cambian sus planes, y cualquier cifra estaría mal dentro de un año. Revisa el precio vigente en el sitio de cada uno. Lo que no cambia es la estructura, y la estructura decide los números. Zapier cobra por tarea: cada acción de cada zap cuenta, así que un zap de seis pasos que corre mil veces al mes son seis mil tareas. Make cobra por operación, con una forma parecida. n8n Cloud cobra por ejecución de flujo: una corrida cuenta una vez sin importar cuántos nodos tenga, así que los flujos largos salen mucho más baratos con volumen. n8n propio no cobra por ejecución; pagas el cómputo, normalmente un servidor chico más un Postgres administrado, y el costo marginal de un flujo más es cero.

La forma honesta de decidir: toma el inventario, multiplica las corridas mensuales de cada zap por su cantidad de pasos y tienes tu volumen de tareas en Zapier. Compáralo contra las mismas corridas contadas una vez para n8n Cloud, y contra una cuenta fija mensual de cómputo para la instancia propia, más el costo de operarla. Con pocos zaps simples la respuesta es quedarse. Pasando de unos miles de ejecuciones de varios pasos al mes suele ser instancia propia, con n8n Cloud como punto medio cuando nadie puede operar la infraestructura. Digo cuál calza después de ver el inventario, no antes.

¿Cómo se ve una migración real de Zapier a n8n?

Una migración representativa, en palabras simples. La empresa corre unos 120 zaps armados en cuatro años por ventas, operaciones y finanzas. La cuenta se triplicó, tres zaps fallan cada semana sin que nadie sepa por qué, y la gerencia quiere que la IA redacte cotizaciones, algo que Zapier no permite.

Semana uno: el inventario queda en una planilla de 120 filas. 41 están pausados o muertos y se eliminan con el visto bueno de sus dueños; 58 son importantes y 21 críticos (tocan el CRM, la facturación y el correo a clientes). Se despliega n8n en la cuenta de nube de la empresa con red privada, Postgres administrado, gestor de secretos, respaldos nocturnos, alertas de disponibilidad y flujos exportados a git en cada cambio. Semana dos: los 58 zaps importantes se reconstruyen en lotes de diez, las cadenas de Formatter pasan a expresiones, los catch hooks del sitio web se apuntan de nuevo y el equipo recibe un video Loom por lote. Semana tres: los 21 zaps críticos corren en modo sombra diez días, escribiendo a una tabla de comparación en vez del CRM. Se corrigen las diferencias; dos resultan ser errores que la versión de Zapier tenía desde siempre. El corte se hace por lote un martes en la mañana con los zaps de Zapier pausados, y el plan de Zapier se baja tras la ventana de retroceso de 30 días.

  • Disparador: webhooks de formularios y eventos del CRM, más agendas para reportes
  • Datos: Postgres administrado en la nube del cliente, respaldo nocturno
  • Modelo: un nodo LLM solo donde un zap necesita criterio, con la API key del cliente
  • Guardarraíles: flujo de error con alertas, reintentos en cada llamada externa, flujos en git
  • Aprobación humana: cotizaciones y correos a clientes esperan hasta que alguien aprieta enviar
  • Dónde corre y de quién es: nube del cliente, red privada, su gestor de secretos, su repositorio

¿Cuánto cuesta contratarme para la migración?

No cobro por hora para migrar. Después de una llamada de diagnóstico gratuita donde miramos el inventario de zaps (o lo armamos juntos), recibes una propuesta escrita con alcance cerrado, plazo y un solo precio fijo. La mayoría de las migraciones se hace en un sprint de tres semanas; inventarios con muchos flujos críticos toman de tres a cinco. Como referencia, los sistemas productizados publicados en este sitio van de USD 4.000 a 6.800 fijos, con una operación mensual opcional; una migración se cotiza a medida, pero esos son los puntos de referencia. Hosting, base de datos y n8n Cloud, si lo eliges, se facturan a tu nombre, con un tope declarado en la propuesta. Trabajo desde Chile y facturo en USD o en pesos con factura electrónica del SII.

Aplica la garantía operativa de 60 días: si un flujo migrado se rompe en esa ventana después de la entrega, lo arreglo sin costo. El soporte mensual opcional cubre actualizaciones, flujos nuevos y la capa de IA. Para inventarios grandes sumo a un segundo ingeniero; en cualquier caso trabajas directo con quien construye.

¿Qué queda en tus manos después de la migración?

Todo. La instancia de n8n corre en tu nube o en tu espacio de n8n Cloud, facturada a tu nombre. Cada flujo se exporta como JSON a un repositorio git tuyo, con un commit por cambio, así que la instancia es desechable y la automatización no. Las credenciales viven en tu gestor de secretos, la base de datos es tuya y los prompts se versionan en el mismo repositorio. La entrega incluye documentación por flujo, una vista de la arquitectura y videos Loom, para que el sistema sobreviva al "¿y si te atropella un bus?", incluso si el atropellado soy yo.

No hay amarre de mi lado. No soy partner certificado de n8n ni revendo herramientas, así que nada pasa por mis cuentas. Si más adelante contratas a otra persona o lo llevas dentro de la empresa, parten de un sistema documentado y versionado.

¿Qué IA se vuelve posible una vez que estás en n8n?

Para muchas empresas la razón de migrar no es la cuenta; es que n8n hace cosas que Zapier no. Con los flujos ya en n8n, agregar un paso con LLM es un nodo: clasificar un correo, extraer campos de una factura en PDF, redactar una respuesta con tu tono, resumir una llamada. Un agente es un flujo que llama herramientas (buscar al cliente, revisar inventario, crear un borrador de cotización) y decide el siguiente paso, con aprobación humana antes de enviar o facturar. Búsqueda es un Postgres con pgvector con tus documentos, para que el modelo responda con tu material y no con internet.

En mi operación esto es un pipeline de llamada a propuesta: la reunión se transcribe, un LLM redacta la propuesta y n8n la deja en cola para mi aprobación; nunca envía sola. El mismo patrón sirve para cotizaciones, triage de soporte, calificación de leads y documentos, con Claude, OpenAI o Gemini detrás y las API keys en tu cuenta, y con los mismos guardarraíles que la migración: reintentos, registro, prompts versionados y una persona delante de lo irreversible.

Preguntas frecuentes

¿También puedes pasar de Make a n8n?

Sí. El método es idéntico: inventario, clasificación, mapeo, reconstrucción, corrida en paralelo y corte. Los escenarios de Make se traducen a n8n más de cerca que Zapier, porque iteradores, agregadores y routers tienen equivalentes directos, así que pasar de Make a n8n suele ser más rápido por escenario. Los manejadores de error y los data stores son las piezas que más atención piden.

¿Cuánto demora una migración de Zapier a n8n?

La mayoría se hace en un sprint de tres semanas. Inventarios con muchos flujos críticos, o con muchos webhooks externos que apuntar de nuevo, toman de tres a cinco semanas, sobre todo porque la corrida en paralelo de las automatizaciones críticas necesita una ventana de tráfico real antes del corte. El plazo va en la propuesta y no se mueve una vez acordado.

¿Tenemos que apagar Zapier el primer día?

No, y no deberías. Los zaps se pausan, no se eliminan, a medida que cada lote hace el corte, y el plan de Zapier sigue activo durante la ventana de retroceso. Lo bajas o cancelas cuando el último lote lleva 30 días corriendo limpio en n8n.

¿Hay que migrar todos los zaps?

No. Cerca de un tercio de la mayoría de los inventarios está muerto y se elimina. Del resto, los zaps triviales con costo despreciable pueden quedarse en Zapier si prefieres; no tengo interés en migrar porque sí. Si todo tu inventario es una docena de zaps simples, te lo digo en la llamada de diagnóstico: no necesitas una migración, ni a mí.

¿Eres partner certificado de n8n?

No. Soy un ingeniero senior independiente que usa n8n todos los días en su propia operación y lo despliega para clientes, propio y en la nube. No ser partner significa que no tengo incentivo para empujarte hacia n8n Cloud, ni hacia n8n en general, cuando otra cosa calza mejor.

¿Nuestro equipo puede mantener n8n después de la migración?

Sí, ese es el objetivo de la entrega. Cada flujo queda documentado, exportado a tu repositorio y explicado en video. Para instancias propias dejo un procedimiento escrito de actualización y respaldo. Si nadie en la empresa quiere hacerse cargo de la instancia, n8n Cloud o el soporte mensual opcional son las dos formas de cubrirlo.

¿Atiendes empresas fuera de Chile?

Sí. Trabajo remoto desde la Región de Valparaíso con empresas de Chile, Latinoamérica, Estados Unidos, Canadá y Europa, en español o inglés. La migración se hace completamente a distancia, dentro de tus cuentas, y la corrida en paralelo y el corte se agendan según tu horario de trabajo.

Mándame cuántos zaps tienes y en 15 minutos te digo si migrar vale la pena.

Llamada gratis. Te digo derecho qué se puede automatizar hoy con IA y qué necesita tu infraestructura para que funcione de verdad. Si calza, avanzamos. Si no, te oriento gratis.