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

Automatización

19 de octubre de 202611 min read

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

Migrar de Make a n8n se parece bastante a migrar de Zapier, salvo en dos cosas, y las dos juegan a tu favor.

La primera es que Make sí te deja exportar cada escenario como un blueprint en JSON. n8n no lo puede importar, pero te ahorra la parte más aburrida de cualquier migración, que es documentar lo que hay. La segunda es que quien viene de Make ya piensa en rutas, iteradores y agregadores, y eso se traduce a n8n con bastante menos fricción que las cajas lineales de Zapier.

Lo que sí hay que mirar de cerca son tres piezas de Make que en n8n no existen igual. Los data stores, la cola de ejecuciones incompletas y los manejadores de error por módulo. Esta guía va de traducir lo fácil deprisa y de resolver esas tres sin sorpresas.

Cómo usar el blueprint de Make como inventario antes de migrar a n8n

Exporta el blueprint de todos los escenarios activos antes de tocar nada. Es un fichero por escenario y dentro está todo, módulos, orden, filtros de cada ruta y los mapeos campo a campo.

Con esos ficheros delante, el inventario sale casi solo. Cuatro datos por escenario.

Cuántos módulos tiene y cuántos son de la propia Make. Los routers, iteradores, agregadores, herramientas y data stores son lo que hay que traducir. Los demás son conectores y se reconectan.

Qué lo dispara. Webhook instantáneo, programación o ejecución bajo demanda. Esto decide cómo se corta después.

Cuántas operaciones consume al mes. El panel de Make te lo da por escenario. Esta columna ordena el proyecto, porque el escenario que más operaciones gasta es el que más ahorro trae y el primero que conviene mover.

Si usa data stores o cola de incompletas. Si la respuesta es sí, ese escenario no es una traducción, es un pequeño proyecto aparte. Hay que marcarlo desde el principio.

Un aviso sobre el fichero. El blueprint lleva la estructura y los mapeos pero no lleva los valores de tus credenciales. Reconectar las cuentas una por una es trabajo manual que hay que contar aparte, igual que en cualquier migración.

Tabla de equivalencias entre los módulos de Make y los nodos de n8n

La mayoría son equivalencias limpias y tres no lo son. Esta es la traducción que uso al reconstruir.

Por qué Make procesa bundle a bundle y n8n procesa el lote entero nodo a nodo

Make termina todo el recorrido con el primer bundle y después empieza con el segundo. n8n pasa todos los items por el primer nodo, luego todos por el segundo y así hasta el final. El resultado suele ser el mismo y el camino no se parece en nada.

Tres consecuencias que conviene tener claras antes de reconstruir.

Las llamadas a una API dejan de estar repartidas. Donde Make hacía una llamada por bundle intercalada con el resto del trabajo, n8n hace todas las llamadas de ese nodo seguidas. Con lotes grandes eso llega al límite de peticiones del proveedor mucho antes. Se arregla troceando con Loop Over Items y poniendo una pausa, pero hay que decidirlo.

Un fallo a mitad de lote se ve distinto. En Make el bundle problemático fallaba por su cuenta y los que venían detrás seguían su camino. En n8n, por defecto, el primer item que falla para la ejecución y los siguientes no se procesan. La salida de error separada lo resuelve, nodo por nodo.

El orden deja de estar garantizado de principio a fin. Si tu escenario de Make dependía de que el bundle uno terminara entero antes de empezar el dos, en n8n eso no se cumple sin más. Cuando hace falta ese orden, se fuerza con un bucle explícito.

Lo bueno es que el cambio también regala cosas. Agrupar, contar, comparar dos conjuntos o cruzar dos orígenes es mucho más sencillo cuando tienes los doscientos items juntos en la mano que cuando te llegan de uno en uno.

Qué hacer con los data stores de Make al pasar a n8n

Un data store es una tabla, así que en n8n se sustituye por una tabla de verdad. Puede ser una base de datos tuya, la tabla de datos que traiga tu versión de n8n o incluso una hoja de cálculo si el volumen es pequeño y no te importa la velocidad.

Lo que importa es para qué lo estabas usando, porque de eso depende el trabajo.

Si lo usabas como memoria de qué registros ya procesaste, eso en n8n es una comprobación de duplicados antes del primer efecto. Es el uso más común y el más fácil de replicar.

Si lo usabas para acumular y enviar junto, el patrón es guardar en la tabla y que un flujo programado lea, envíe y marque. Dos flujos pequeños en lugar de uno grande.

Si lo usabas como tabla de consulta con equivalencias, muchas veces se resuelve con una hoja de cálculo o con un fichero en el propio flujo, sin montar nada.

Y si lo usabas para pasar datos entre escenarios, en n8n casi siempre desaparece, porque un subflujo devuelve datos al flujo que lo llamó y ya no hace falta un almacén intermedio.

Cómo se traducen los filtros, las funciones y las fechas de Make a n8n

Donde en Make abrías el panel de funciones, en n8n escribes una expresión dentro de dobles llaves. Es el mismo trabajo con otra sintaxis, y hay tres diferencias que conviene conocer antes de empezar.

Las funciones de fecha cambian de familia. n8n usa Luxon dentro de las expresiones, así que las fórmulas de formato y de suma de días se reescriben. Antes de traducir ninguna, hay que mirar la zona horaria de la instancia, que viene configurada en la de Nueva York por defecto y desplaza todo lo que tenga que ver con días y con horas programadas.

Los campos que no existen no dan error. Una expresión que no resuelve escribe un vacío en destino y la ejecución sale en verde. En Make el mapeo vacío solía ser más visible. 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.

Las referencias apuntan al nombre del nodo. Renombrar un nodo después de haberlo referenciado rompe las expresiones que apuntaban a él. Si vas a renombrar, hazlo antes de construir encima.

El plan de corte de Make a n8n sin perder ejecuciones

Los dos sistemas encendidos unos días y Make se apaga el último. El procedimiento se parece al de cualquier migración y tiene un paso propio por culpa de las colas.

Primero mueve los escenarios programados. Son los más fáciles de correr en paralelo, porque basta con desplazar la hora del flujo nuevo respecto al viejo y comparar resultados.

Después los escenarios que solo leen o escriben en destinos internos. Informes, sincronizaciones, copias. Ningún riesgo y mucha información sobre si las credenciales y los tiempos cuadran.

Tercero, vacía la cola de incompletas antes de cortar. Este es el paso propio de Make. Si quedan ejecuciones incompletas sin reprocesar y apagas el escenario, esos datos no van a ninguna parte. Hay que dejar la lista a cero antes de tocar el interruptor.

Cuarto, repunta los webhooks uno a uno. La URL de n8n es distinta y nadie te avisa si queda uno apuntando a Make. Hazlo en horario de poco movimiento y con el inventario delante. Es exactamente el mismo paso que detallo en migrar de Zapier a n8n paso a paso, y falla por los mismos motivos.

Quinto, deja los escenarios en pausa dos o tres semanas en lugar de borrarlos. Pausados no consumen operaciones y siguen siendo tu red de seguridad.

Cuándo no merece la pena migrar de Make a n8n

Te lo digo aunque me quite proyectos, porque una migración que no debía hacerse se nota a los dos meses.

Si tu consumo de operaciones es bajo y estable. El ahorro no cubre el proyecto en un plazo razonable. Revisa dentro de un año o cuando el volumen crezca.

Si tu operación vive encima de los data stores y nadie va a mantener una base de datos. Puede hacerse, pero estás cambiando una pieza que funcionaba sola por una que alguien tiene que cuidar. Si no hay nadie para cuidarla, no migres.

Si el valor que aporta Make en tu caso es el catálogo de conectores raros. Si dependes de dos o tres integraciones que n8n no trae, construirlas contra la API puede costar más que varios años de diferencia de factura.

Si estás en temporada alta. Un corte de automatizaciones en el mes de más volumen no se arregla con un plan mejor, se arregla no haciéndolo en ese mes.

Dicho eso, hay tres motivos para migrar que no salen en la hoja de cálculo. Que tus datos dejen de pasar por un tercero si alojas tú la instancia. Que crecer deje de significar pagar más por operación. Y que puedas escribir código el día que la plataforma no llegue, en lugar de quedarte con lo que el catálogo permita.

Cómo migro yo un escenario de Make con iteradores y agregadores sin perder datos a n8n

Lo primero que hago es borrar la mitad del escenario, no traducirlo. Un escenario de Make largo suele tener tantos módulos de iterar, agregar y dar formato como de negocio, y en n8n la mayoría de esos no tienen que existir.

Separo lo que es el proceso de lo que es andamiaje de Make. Si un bloque de cuatro módulos solo está ahí para desmontar un array y volverlo a montar, en n8n se cae entero. De ahí sale la primera reducción, y suele ser grande.

Reconstruyo contra una ejecución real, no contra el diagrama. Cojo el historial de una ejecución buena de Make, me quedo con lo que entró y comparo la salida de cada nodo nuevo contra lo que hizo el módulo equivalente. Si el tercer paso ya diverge, paro ahí.

Resuelvo el data store antes de tocar los flujos que lo usan. Montar la tabla, el acceso y la deduplicación primero, porque si lo dejo para después todos los flujos que dependen de ella quedan a medias a la vez.

Diseño el reintento como una pieza, no como una opción de cada nodo. Qué item falló, dónde se guarda y quién lo vuelve a lanzar. Es lo que sustituye a la cola de incompletas y es la parte que más se agradece seis meses después.

Y cierro cada flujo con sus alertas puestas, no para luego. Avisos sobre el resultado del proceso, trazabilidad de la ejecución e inventario de credenciales con su fecha. Si lo dejo para el final del proyecto, el final del proyecto llega con prisas.

Traducido a tu dinero, la diferencia está en que un escenario traducido módulo a módulo te deja pagando en mantenimiento lo que creías haber ahorrado en operaciones. Cómo planteo un proyecto completo lo cuento en automatizaciones con n8n.

Si te quedas con una sola idea, que sea esta. Venir de Make es una ventaja, porque ya piensas en rutas y en lotes. El trabajo de verdad no está en traducir módulos, está en las tres piezas que n8n no tiene y que hay que diseñar.