Salir del no-code sin frenar el negocio

El error más común es tratar una migración como una sola mudanza grande. Casi nunca hace falta.

Empieza por la parte que cambias todas las semanas. Suele ser la primera en sentir el techo: es donde esperar al editor visual más te cuesta. En una de nuestras migraciones, el front end pasó a código y el backend se quedó en Xano, porque hacía bien su trabajo.

A veces la respuesta es integrar, no migrar. Trabajamos con un negocio que tenía dos sistemas viejos que nadie quería tocar. El plan obvio era reemplazar los dos. Lo que hicimos fue conectar solo la parte que dolía (la facturación) con su sistema contable, y dejar el resto como estaba.

El no-code es una etapa. Un cliente pasó de un sistema viejo y monolítico a herramientas no-code, y meses después se mudó de nuevo, a código a medida, cuando el no-code se volvió el cuello de botella. Ninguna de las dos mudanzas fue un error. Cada una le dio al negocio el tiempo que necesitaba en ese momento.

Son las señales que vemos una y otra vez. Una sola es motivo para mirar más de cerca. Tres son motivo para decidir.

Cuando reconstruimos desde cero una plataforma de reservas, la regla antes de lanzar fue que, para la gente que la usa, nada se sintiera distinto. Mismos links, mismos pasos, misma forma de trabajar. Le dijimos al cliente que el sistema nuevo no era un sandbox: había que tratarlo con el mismo cuidado que el actual.

Una reescritura sale bien cuando el usuario no la nota. El resultado que buscábamos tampoco era técnico: después de la primera temporada completa de vacaciones con el sistema nuevo, la persona que lleva la operación nos escribió que fueron de las primeras vacaciones en las que ningún grupo llegó al lugar equivocado.

Nunca cambiamos un sistema en producción de una sola vez. El patrón que usamos, conservador a propósito:

1. 01En sombra

   El sistema nuevo calcula todo, pero nada de lo que produce se usa todavía. Funciona al lado del viejo.

2. 02Casos testigo

   Elige dos o tres casos reales que conozcas bien y compara a mano lo que da el nuevo contra el viejo.

3. 03Cambio chico

   Deja que el sistema nuevo escriba de verdad, pero solo para esos pocos casos.

4. 04Todo

   Solo entonces mudas el resto.

En otro proyecto, el piloto de un módulo nuevo funcionó en paralelo con el proceso manual durante semanas antes del cambio. Mientras funcionaban los dos, nada cambió en los procesos que dependían de él.

Parece más lento. Es lo que permite que el negocio siga trabajando mientras se muda.

Asume que el feed va a perder cosas. En un lanzamiento, el webhook de un proveedor de inventario seguía llegando, pero cada movimiento de stock venía con la ubicación vacía. Frenamos el lanzamiento. Desde entonces, los feeds de ese sistema tienen dos caminos: el webhook como el rápido, y un proceso programado que le pregunta directo a la fuente y recupera lo que el webhook perdió. Shopify recomienda lo mismo en su propia documentación: procesos de conciliación funcionando al lado de los webhooks.

Guarda algo desde donde reconstruir. Mientras el proveedor arreglaba su parte, seguimos con una foto de todos los SKUs, para tener siempre un estado confiable.

No confíes en los nombres. Un escaneo de reposición trataba como depósito de reserva cualquier ubicación con una Z en el nombre. El depósito también usaba nombres con Z para lugares de picking reales, y casi mil productos empezaron a generar tareas que no correspondían. Las reglas que dependen de cómo se llama algo se rompen el día que alguien usa el nombre de otra forma. Guarda el significado como dato, no en el nombre.

En una herramienta que un equipo abre todo el día, la velocidad decide si la usan de verdad. La tratamos como un requisito al lado de las funcionalidades, no como algo para arreglar después.

En una herramienta visual, muchas veces son justo las cosas que no puedes controlar. Ese suele ser el momento en que una migración empieza a tener sentido.

Un bug solo pasaba en Australia. La librería de fechas decidía «qué día es» con la zona horaria del navegador, así que con el horario de verano de Sídney una sesión de las 10:15 caía en el día anterior, y la confirmación fallaba sin avisar. Durante semanas no lo pudimos reproducir desde Argentina: los logs estaban limpios.

Escribe dónde termina el setup. En un proyecto, cada pedido chico después del lanzamiento se volvía una negociación, porque en ningún lado decía dónde terminaba el setup y empezaba lo nuevo. Agregamos una línea al acuerdo: el servicio queda funcionando en 72 horas, y los cambios de ahí en adelante se cotizan aparte. Esas conversaciones casi desaparecieron.

Planea quién cambia las cosas después del lanzamiento. Con código y un agente de IA, un founder puede hacer cambios chicos por su cuenta. Lo armamos así para un cliente: cada cambio que pide va a una copia aparte de la app, nunca directo a la que usan sus usuarios, y nada les llega hasta que uno de nosotros lo revisó. Escribir el cambio se abarató. La revisión antes de que algo salga en vivo es lo que sigue necesitándonos.