Lo que aprendimos migrando una agencia de Make.com a n8n autoalojado

Una plataforma sin código alojada deja de valer lo que cuesta cuando tu carga se vuelve constante, crece y se cobra por operación. Esa es toda la prueba, y vale la pena aplicarla antes de que la factura obligue la pregunta, porque la migración es mucho más fácil mientras todavía tienes la opción de no hacerla.

Estas son notas de una migración así para una agencia de producto digital. Los números de abajo son los de ese proyecto, y están escritos completos como caso de estudio.

Los dos números eran un solo problema

El punto de partida era alrededor de $500 al mes en costo operativo y unos 3 minutos para que un usuario recibiera una respuesta. Parecen quejas separadas. No lo eran.

Cobrar por operación significa que cada flujo que agregas empeora la factura. El modelo de ejecución de la plataforma significa que cada paso que agregas alarga la espera. Así que el stack había llegado a un lugar incómodo: hacer más de lo que la agencia de verdad quería empeoraba los dos números al mismo tiempo. Esa es la señal para mirar la plataforma y no los flujos.

Tres minutos está bien para un trabajo nocturno. Es inservible para cualquier cosa donde una persona está sentada esperando, y la hoja de ruta de la agencia estaba llena de esa segunda clase.

Después de la migración el costo mensual fue de alrededor de $50 y las respuestas volvían en menos de 20 segundos.

Lo tratamos como construir contra comprar, no como un tiquete de migración

Esto importó más que cualquier decisión técnica posterior. Planteado como migración, la pregunta es cómo mover flujos. Planteado como construir contra comprar, la pregunta es si moverlos siquiera, y la respuesta honesta es que las plataformas alojadas son un buen negocio para muchas cargas.

Valen lo que cuestan cuando la carga es pequeña, irregular y la mantiene gente que no escribe código. Eso describe a muchísimos negocios, y si describe al tuyo, quedarte es la decisión correcta. Dejó de describir a este.

No migres todo al mismo lugar

El instinto es mover el stack entero a la plataforma nueva. Es un error, y evitarlo es buena parte de por qué esto funcionó.

Dividimos por quién mantiene cada cosa:

• Los flujos que alguien sin perfil técnico debería poder leer y ajustar se quedaron como flujos de n8n. Su valor es que una persona de operaciones puede abrir uno y cambiar una condición.
• Todo lo que hiciera procesamiento de lenguaje en varias etapas, normalización de APIs o manejo de estado pasó a Python plano, donde se podía probar.

La segunda categoría era software que había estado viviendo en una herramienta de flujos porque ahí fue donde empezó. Moverlo a n8n habría preservado el problema original con una mejor factura. Ya en Python, ese código recibió pruebas, que es la razón real para moverlo.

Incremental le gana a un cambio de golpe, y no está cerca

Una reescritura queda 90% bien en la primera pasada, y el 10% que falta es invariablemente la parte de la que alguien depende a diario. No vas a adivinar cuál 10%.

Así que los flujos se movieron de a uno, con las dos versiones corriendo hasta que los resultados coincidieran. Terminar así es más lento. Equivocarse así es dramáticamente más barato, y equivocarse en algún punto es una certeza, no un riesgo.

La parte difícil no fue la plataforma

La migración en sí fue mecánica. La ingeniería difícil fue una capa de abstracción de mensajería debajo de un agente conversacional, porque los canales de mensajes no coinciden en nada: identidad, semántica de entrega, adjuntos, y hasta qué cuenta como una conversación son distintos en cada uno.

La capa tenía que esconderle eso al agente sin colapsar en un mínimo común denominador que volviera igual de malos a todos los canales, y a la vez mantener los inquilinos aislados por canal. Ese requisito de aislamiento es lo que impidió que fuera un envoltorio delgado. Una fuga entre dos inquilinos en un canal habría sido peor que cualquier caída.

La lección se generaliza: en una migración, presupuesta tu atención para lo que es genuinamente nuevo, no para lo que es apenas tedioso. La parte tediosa es predecible y la parte nueva es donde se va el cronograma.

Qué corrió encima después

Dos sistemas, y los dos habrían sido incómodos con precios por operación. Un proceso de inteligencia de correo que clasifica y resume más de 300 correos al día para más de 50 usuarios con 80% de precisión, y un agente de agendamiento que más de 20 personas manejan en lenguaje natural desde la aplicación de mensajería que ya tienen abierta.

Ninguno estaba en el alcance inicial. Esa es la parte que vale la pena notar: un tiempo de respuesta de 20 segundos cambió lo que la agencia estuvo dispuesta a automatizar después, y la hoja de ruta creció cuando se quitó la restricción, no antes.

Cuándo hacer esto de verdad

Corre la revisión antes de que la haga la factura por ti. Si tu costo por operación sube con un uso que no puedes reducir, si la latencia de ejecución está bloqueando el trabajo interactivo que quieres construir, y si una porción significativa de tus flujos son en realidad software disfrazado de herramienta de flujos, la aritmética probablemente ya está en tu contra.

Si nada de eso es cierto, quédate. La migración vale la pena cuando la plataforma se volvió la restricción, y no antes. Averiguar en cuál de esos casos estás es para lo que sirve un diagnóstico.