Migrar Make o Zapier a n8n

Qué es este recurso y qué problema resuelve

Este workflow es un recordatorio semanal, programado cada lunes a las 09:00 (Europe/Madrid), que ayuda a inventariar flujos, credenciales, webhooks y notas de paridad cuando estás migrando automatizaciones de n8n a Make, o al revés. Cada semana escribe una fila en Google Sheets con el estado de la migración y avisa en Slack de que el checklist se ha actualizado.

Las migraciones entre plataformas de automatización fallan casi siempre por el mismo motivo: alguien olvida una credencial, un webhook o una lógica concreta que funcionaba en la plataforma de origen y que no se replicó en la de destino. Este recurso convierte ese riesgo en un hábito semanal documentado, en lugar de dejarlo a la memoria de una sola persona.

Al tratarse de un recordatorio y no de una migración automática, no mueve ni copia flujos por ti: su valor está en obligar a que alguien se siente cada semana a revisar el estado real del proyecto, en lugar de dar la migración por hecha antes de tiempo. Esa disciplina semanal es precisamente lo que suele faltar en proyectos de migración que se alargan más de lo previsto.

Cuándo usarlo (y en qué fase del proceso)

Actívalo en cuanto empieces a evaluar seriamente una migración entre n8n y Make, no solo cuando ya estés a mitad de camino. Cuanto antes tengas el inventario documentado y actualizado semana a semana, más fácil será detectar huecos antes de que se conviertan en un problema el día del corte definitivo.

Sigue siendo útil incluso después de completar la migración, como registro histórico de qué se movió, cuándo y quién validó la paridad de cada pieza; muchos equipos lo mantienen activo unas semanas más tras el cambio, hasta confirmar que todo funciona igual o mejor que antes. Ese periodo de convivencia entre plataformas suele ser el momento donde aparecen los últimos flecos por resolver.

Qué necesitas antes de importarlo

Necesitas una hoja de Google Sheets accesible con una credencial de Google configurada en n8n (o, mientras no tengas esa conexión OAuth lista, el flujo seguirá enviando el aviso a Slack aunque la escritura en Sheets falle de forma controlada), y un canal de Slack con un Incoming Webhook para recibir la actualización semanal.

Antes de rellenar el nodo de configuración, conviene tener ya un primer listado, aunque sea aproximado, de cuántos flujos existen en la plataforma de origen, qué credenciales usan y qué webhooks públicos hay que redirigir; el flujo organiza esa información, pero no la genera automáticamente por ti.

Cómo funciona el flujo paso a paso

El workflow combina un horario fijado a los lunes a las 09:00, un nodo Config donde guardas todos los datos del inventario, un paso que añade una fila a Google Sheets con ese estado, y un aviso final a Slack confirmando que el checklist de migración se ha actualizado.

Si la conexión OAuth con Google Sheets aún no está lista, el paso de escritura puede fallar de forma controlada (con un manejo de error tipo neverError) sin romper el resto del flujo, de modo que el aviso a Slack sigue llegando aunque el histórico en Sheets todavía no se esté guardando.

Configuración detallada del nodo de inventario

Descarga el JSON e impórtalo en n8n.

Un principio importante: no pegues secretos ni claves reales dentro de este nodo, solo nombres de sistemas y descripciones. La idea es tener un mapa de qué falta por migrar, no una copia de las credenciales reales, que deben seguir viviendo exclusivamente en las credenciales cifradas de cada plataforma.

Buenas prácticas durante la migración, RGPD y alternativa en Zapier

Actualiza los campos del nodo Config a medida que avanza la migración, y marca la paridad de una pieza concreta solo después de haberla probado de verdad en la plataforma de destino con datos de ensayo, nunca por adelantado. Guarda el inventario final firmado o validado por la persona responsable del proyecto, como evidencia de que la migración se hizo de forma controlada.

Documenta siempre quién mantiene el horario y la hoja de Sheets, y revisa que ningún dato personal de clientes quede expuesto en las notas del inventario. Si tu migración implica también Zapier, puedes adaptar el mismo checklist a una lista de control de Zaps, manteniendo la misma estructura semanal de revisión.

Qué revisar con más cuidado y cómo cerrar la migración con confianza

De toda la lista de inventario, los webhooks públicos suelen ser el punto más delicado: si un formulario web o una integración externa sigue apuntando a la URL de la plataforma de origen después del corte, los datos dejan de llegar sin que nadie lo note hasta que un cliente o un comercial pregunta por qué falta algo. Antes de dar por cerrada cualquier pieza del inventario, confirma explícitamente que todas las URLs externas que dependían de ella ya se actualizaron al nuevo destino.

El segundo punto delicado son las credenciales con permisos amplios, como tokens de API de CRM o de correo que varias automatizaciones comparten; al migrar, es buena práctica generar credenciales nuevas y específicas para la plataforma de destino en lugar de reutilizar las mismas claves en ambos sistemas a la vez, reduciendo así el riesgo de que un fallo en una plataforma afecte a la otra.

Una migración se puede dar por completada cuando el inventario final no muestra flujos pendientes de revisión, todas las notas de paridad están marcadas con datos de una prueba real y el equipo ha confirmado que no ha habido incidencias durante al menos dos o tres semanas seguidas de convivencia entre ambas plataformas. Solo entonces tiene sentido desactivar los flujos antiguos en la plataforma de origen, y siempre conservando una copia de seguridad de esos workflows por si hiciera falta consultarlos más adelante.

Guardar este checklist final como parte de la documentación interna del proyecto también ayuda a futuras migraciones: la próxima vez que el equipo tenga que cambiar de plataforma, tendrá una plantilla probada de qué revisar y en qué orden, en lugar de tener que reinventar el proceso desde cero.

Importar, configurar y producción 24/7

En n8n: ⋯ → Import from File → el JSON de este recurso. El flujo llega inactive. Abre el sticky INSTRUCCIONES del lienzo y el nodo Config/Set: URLs, umbrales y placeholders. Enlaza credenciales reales (HTTP Header Auth, OAuth Google Sheets, Slack Incoming Webhook, CRM Private App) — nunca dejes tokens en el archivo versionado.

Prueba una ejecución Manual o un evento de test (formulario, webhook, cron forzado). Revisa CRM, Sheets o Slack. Solo entonces Active. Timezone del workflow: Europe/Madrid.

Para que corra solo hace falta n8n online. Self-hosted UE: VPS Hetzner/OVH/IONOS (o panel con Docker) → Ubuntu → Docker Compose (n8n + Postgres) → HTTPS con Caddy/Nginx → N8N_HOST, WEBHOOK_URL, GENERIC_TIMEZONE=Europe/Madrid, N8N_ENCRYPTION_KEY. Alternativa: n8n Cloud (importas, conectas credenciales y Active; vigila límites). Make/Zapier: mismo mapa mental; este JSON es el esqueleto n8n.

EU AI Act y RGPD: qué es y por qué tu empresa debe aplicarlo

El Reglamento (UE) 2024/1689 (EU AI Act) ya está en vigor. Si tu empresa usa n8n con nodos de IA (Gemini, OpenAI, Claude, etc. ) en ventas o operaciones, actuáis como desplegadores (deployers): no hace falta ser el fabricante del modelo.

En paralelo, el RGPD (AEPD) aplica porque el flujo trata datos de contacto B2B. Base jurídica, minimización y, si hay perfiles automatizados a escala, evaluación de impacto. AI Act y RGPD se acumulan: un fallo puede implicar ambas autoridades.

Este recurso ayuda en la práctica: placeholders sin secretos, Europe/Madrid, opción self-hosted en VPS UE (soberanía de datos), registro de ejecuciones en n8n (logs) y espacio para human-in-the-loop (aprobación antes de acciones sensibles). Detalle: /uso-responsable-de-ia-y-transparencia. Texto informativo, no asesoramiento legal.