Migrar un sistema viejo sin frenar la operación.

El punto de partida

El sistema funcionaba, y ese era parte del problema. Llevaba décadas registrando contratos, movimientos, saldos, liquidaciones y recibos. Pero corría sobre DOS, no había soporte técnico disponible y estaba instalado en una sola computadora: si esa máquina fallaba, se detenía la operación. Dos personas cargaban todo a mano y respondían, todos los días, las mismas consultas de inquilinos y propietarios.

Ningún sistema heredado se cambia porque sí. Se cambia cuando el riesgo de seguir es mayor que el riesgo de migrar. Ese momento había llegado.

Paso 1: entender el sistema antes de tocarlo

Casi nunca hay documentación de un sistema de esa edad, y quien lo programó ya no está. Por eso el primer trabajo fue de ingeniería inversa: reconstruir, a partir de los archivos y del uso diario, el modelo de datos completo de contratos, movimientos, saldos, liquidaciones y recibos, y las reglas que los relacionan.

Esta etapa define todo lo que viene después. Un error acá se traslada al sistema nuevo y aparece meses más tarde, en un saldo que no cierra.

Paso 2: una demo con los datos reales

Con el modelo de datos reconstruido se construyó una demo funcional usando los datos reales del cliente, anonimizados. No una maqueta: un sistema navegable con su información. La demo se iteró en cinco versiones junto al equipo, que era quien mejor sabía qué casos raros tenía la operación.

Cada versión hizo aparecer algo que no estaba en ningún documento: una excepción en un tipo de contrato, una forma particular de registrar un pago. Esos hallazgos cuestan poco en una demo y mucho en producción.

Paso 3: migrar por etapas

La migración no se hace de una sola vez. Se ordena en etapas, de modo que la operación siga funcionando en todo momento. Las prácticas que aplicamos:

• Migrar por bloques funcionales, empezando por la plataforma base y los datos, y sumando después la carga automática de documentos y la atención por WhatsApp.
• Mantener el sistema viejo disponible mientras se valida el nuevo, para poder comparar resultados.
• Preservar el historial completo: cuatro décadas de registros no se descartan.

Lo que no se puede romper

Toda operación tiene reglas que no se ven hasta que se rompen. En este caso, la numeración correlativa de los recibos tiene valor contable y legal, y el sistema nuevo tenía que respetarla sin saltos ni duplicados. Identificar esas reglas temprano, con el equipo, es parte del relevamiento.

Que el equipo no pierda velocidad

Después de años con el mismo sistema, el equipo cargaba datos muy rápido. Un sistema nuevo lleno de formularios habría sido un retroceso. Por eso la interfaz es conversacional: se carga por texto o por voz, y el sistema estructura el dato. La herramienta cambió; el ritmo de trabajo, no.

Agentes con permisos distintos

Las consultas repetitivas de inquilinos y propietarios se resuelven con un agente de atención externa, separado del agente principal y con permisos restringidos: solo puede ver y compartir la información que la empresa autoriza. Lo que excede ese límite se deriva a una persona.

Señales de que un sistema ya es un riesgo

• Funciona en una sola computadora o en un servidor que nadie se anima a tocar.
• No hay soporte técnico ni quien pueda modificarlo.
• Solo una o dos personas saben usarlo bien.
• Para sacar un informe hay que exportar a planillas y rearmar a mano.
• No se puede conectar con nada: cada dato nuevo se vuelve a cargar.