Cómo migré la captación de clientes de mi bufete de abogados de Zapier a n8n en 6 semanas
Vasquez Law Firm comenzó con Zapier de la misma manera que la mayoría de los pequeños bufetes de abogados comienzan con Zapier — un flujo de trabajo importante, luego cinco, luego treinta, y de repente no podíamos cambiar nada sin estropear algo. Para cuando estábamos ejecutando más de 60 Zaps coordinando CallRail, GoHighLevel, Clio, nuestros formularios y nuestro sistema de pagos, la factura era elevada, la depuración era frustrante, y una condición omitida en un zap había interrumpido la entrega de clientes potenciales durante seis horas durante la noche. Migramos a n8n autoalojado en 6 semanas. Este es el manual.
Por qué Zapier fue el punto de partida correcto — y el punto final equivocado
Zapier es realmente bueno en lo que hace. Para un bufete de un solo abogado que conecta un único formulario de admisión a un único CRM, puede estar en funcionamiento en una tarde, y el precio por tarea es aceptable. Los problemas comienzan cuando sus flujos de trabajo desarrollan lógica de ramificación. Cada rama en un Zap es, aproximadamente, su propio zap. Cada condicional es un módulo de 'rutas' que añade una tarea. Cada reintento cuesta tareas. Teníamos un único flujo de trabajo de 'cliente potencial cualificado' que, al final, pasó por 11 condicionales y llamó a 4 APIs externas. El costo ascendía a varios cientos de dólares al mes solo por ese flujo de trabajo, y era frágil — cambiar una rama a menudo requería recablear otras dos.
La depuración fue el punto de inflexión. Cuando algo fallaba a las 2 de la madrugada, nos enterábamos a la mañana siguiente por un asunto faltante en Clio. La vista de historial de Zapier le dice que un zap falló; no siempre le dice por qué de una manera que se mapee claramente a la lógica condicional. Reconstruir qué entrada llegó y qué rama se ejecutó tomaba entre 20 y 30 minutos por incidente. Estábamos haciendo esto 2-3 veces por semana.
Por qué n8n específicamente
Consideramos tres opciones: permanecer en Zapier, migrar a Make.com o migrar a n8n autoalojado. Make es el punto intermedio más cercano — constructor visual de flujos de trabajo, más depurable que Zapier, modelo de precios SaaS similar. Elegimos n8n autoalojado por dos razones. Primero: visibilidad completa del registro de ejecución del flujo de trabajo, incluyendo las entradas y salidas reales en cada nodo. Segundo: sin precios por tarea — una vez que la instancia de n8n está en funcionamiento, las ejecuciones adicionales de flujos de trabajo son gratuitas en el margen. Nuestro volumen de tareas era lo suficientemente alto como para que los cálculos favorecieran el autoalojamiento en 6 meses.
La contrapartida es la sobrecarga operativa. n8n autoalojado necesita un servidor, monitoreo, copias de seguridad y alguien que sepa qué hacer cuando falla. Utilizamos una implementación gestionada (Docker en un VPS de Hetzner, con PostgreSQL respaldado diariamente en S3), lo que mantiene la carga operativa ligera pero no la elimina. Si no tiene a nadie en el equipo que se sienta cómodo con eso, n8n Cloud o Make.com es probablemente la mejor respuesta.
El plan de migración que funcionó
No hicimos una migración de 'big-bang'. Clasificamos los más de 60 Zaps en tres categorías: (1) flujos de trabajo de alto riesgo y críticos para el negocio, como la entrega de clientes potenciales entrantes — estos se migraron y se ejecutaron en paralelo durante 2 semanas antes de desactivar Zapier; (2) flujos de trabajo de riesgo medio, como las secuencias de seguimiento de contratos — migrados uno a la vez con una ejecución en paralelo de 3 días; (3) zaps de utilidad de bajo riesgo, como 'enviarme un mensaje de Slack cuando X sucede' — migrados al final, sin ejecución en paralelo.
La disciplina de ejecución en paralelo fue lo más importante que hicimos. Durante 2 semanas, cada llamada entrante generó una ejecución de Zapier y una ejecución de n8n, y comparamos manualmente los resultados. Detectamos 4 casos en los que la lógica de n8n produjo resultados sutilmente diferentes a los de Zapier — generalmente porque Zapier había manejado silenciosamente un valor nulo como una cadena vacía y n8n lo estaba tratando como un nulo real. Sin la ejecución en paralelo, habríamos lanzado esos errores a producción y solo los habríamos encontrado cuando los asuntos de Clio posteriores comenzaron a mostrar campos faltantes.
- ✓Clasificar flujos de trabajo por riesgo; migrar los de alto riesgo primero con ejecución en paralelo
- ✓Ejecutar sistemas antiguos + nuevos en paralelo y comparar resultados manualmente durante 1-2 semanas
- ✓No confíe en sus suposiciones sobre cómo el sistema antiguo manejaba los casos extremos
- ✓Mantener un plan de reversión para cada flujo de trabajo durante la ventana de transición
- ✓Migrar los flujos de trabajo de utilidad/bajo riesgo al final, sin necesidad de ejecución en paralelo
Dos incidentes de producción que nos enseñaron lecciones
El primer incidente fue auto-infligido. Habíamos migrado el flujo de trabajo de llamada entrante → creación de contacto en GHL a n8n con lo que pensábamos que era una lógica idéntica. Tres días después de la ejecución solo en producción, notamos una pequeña pero real caída en la tasa de creación de asuntos. La causa raíz: la configuración antigua de Zapier tenía un 'debounce' de 30 segundos para llamadas duplicadas (mismo número en 30 segundos = tratar como una). Nuestra versión de n8n no lo tenía. Así, cuando los llamantes volvían a marcar en segundos, creábamos contactos duplicados y dividíamos los asuntos. No habíamos documentado el 'debounce' porque era una característica específica de Zapier que habíamos ajustado una vez hace 14 meses y habíamos olvidado. Lección: al migrar, audite no solo los flujos de trabajo que escribió, sino también los comportamientos de la plataforma de los que depende implícitamente.
El segundo incidente fue un problema de límite de tasa de Clio. n8n es más rápido que Zapier en el 'happy path' porque no está esperando en una cola SaaS. Pero eso significó que nuestros días de tráfico pico alcanzaron los límites de tasa de la API de Clio que nunca antes habíamos alcanzado. Los asuntos comenzaron a fallar en su creación en tiempo real. Agregamos 'exponential backoff with jitter' en las escrituras de Clio y una cola de respaldo para los asuntos que no pudieron crearse dentro de la ventana de límite de tasa — se crean en 15 minutos cuando la capacidad se recupera. Total de asuntos perdidos: cero desde la corrección. Total de asuntos creados con un retraso de 5-15 minutos: unos pocos por día pico, lo cual es aceptable.
Lo que omitiría si empezara hoy
La mayoría de los flujos de trabajo de riesgo medio y bajo. En retrospectiva, la mitad de ellos existían porque construirlos en Zapier era económico; si estuviéramos empezando en n8n, no los escribiríamos. 'Enviarme un mensaje de Slack cuando una etapa de oportunidad cambia' no era lo suficientemente valioso como para mantenerlo en dos sistemas. Eliminamos alrededor de 25 flujos de trabajo durante la migración simplemente preguntando '¿realmente necesitamos esto?' en cada uno. Eso por sí solo vale la pena hacerlo periódicamente, independientemente de la herramienta de flujo de trabajo que utilice.
