Cuándo hay que reemplazar el sistema heredado — y cuándo no

"Está viejo y es feo" no es motivo para reemplazar#

Cuando alguien nos busca para reemplazar un sistema, las primeras frases son casi siempre las mismas: "esto lo hice hace mucho tiempo", "me gustaría que quedara más lindo, es muy feo", "está viejo".

Ninguna de las tres es un motivo. La edad no es un defecto, una interfaz anticuada se resuelve por mucho menos que una reescritura, y "hace mucho tiempo" describe un sistema que viene funcionando hace mucho tiempo — lo que es un argumento a su favor, no en contra.

La advertencia más conocida sobre esto es del año 2000: en "Things You Should Never Do", Joel Spolsky llama a la reescritura desde cero el peor error estratégico que puede cometer una empresa de software. El argumento es sobre lectura, no sobre código — es más difícil leer código que escribirlo, así que el sistema viejo parece peor de lo que es. Lo que da impresión de desorden suele ser años de correcciones acumuladas: cada línea extraña resolviendo un caso real que ya nadie recuerda.

Nuestra propia práctica lo confirma. En los últimos años asumimos nueve sistemas que ya existían cuando llegamos. Reemplazamos dos.

El caso más ilustrativo es Cirurgicred. El sistema es viejo, no tiene documentación y no funcionaba correctamente — y el cliente llegó queriendo evolucionarlo. Nuestra conclusión fue que evolucionarlo no tenía sentido: entraron ajustes pequeños para acompañar el flujo actual de la operación, y ninguna funcionalidad nueva. Decir eso cuesta facturación en el corto plazo y es la recomendación correcta.

Señal 1 — nadie puede tocar el sistema#

Esta es la señal que aparece disfrazada de comentario casual: "la empresa que lo hizo ya no existe", "el desarrollador no quiere seguir en el proyecto", "nadie sabe bien cómo funciona".

Fijate que ninguno es sobre tecnología. Son sobre personas y conocimiento, y eso es lo que los vuelve serios: un sistema técnicamente sano que nadie sabe modificar está más cerca del final que un sistema feo con equipo activo.

Vimos las tres variaciones:

• En DNA Genética, el sistema tenía más de diez años, lo había construido una software house y no tenía documentación clara. Quedaba un programador que hacía mantenimiento esporádico y no quería seguir desarrollando.
• En Hybri, quien lo construyó era un desarrollador socio del proyecto. Se fue, y la plataforma quedó sin nadie.
• En GT, la aplicación había sido escrita sin tipado y sin documentación — el conocimiento no estaba ni en el código ni en papel.

La prueba es objetiva y lleva un minuto: ¿cuántas personas pueden, hoy, corregir un error en producción y publicar la corrección? Si la respuesta es una, tenés un riesgo de continuidad. Si es cero, el sistema ya dejó de ser un activo y se volvió un pasivo — solo que todavía no pasó la factura.

Señal 2 — perdiste el acceso a tu propio producto#

Esta es la señal más concreta de todas, y sobre la que menos se escribe. No es sobre calidad de código: es el momento en que un tercero decide el destino de tu sistema y no tenés cómo responder.

Aparece en formas bien literales:

• La aplicación salió de la tienda. Es lo que pasó con la app vieja de Reticar: dejó de acompañar las versiones de SDK exigidas y la quitaron. El cliente ya no podía instalar su propia aplicación — no es una metáfora de obsolescencia, es una app que ya no existe para quien la necesita.
• La aplicación nunca llegó a la tienda. En GT, la app heredada se distribuía por archivo, directo al cliente, y el equipo todavía tenía que ayudar a cada persona a instalarla.
• Una dependencia va a ser apagada. La plataforma de Hybri corría scripts en una versión de Node que iba a ser discontinuada. El sistema funcionaba normalmente — lo que iba a romperse era la base debajo de él, en una fecha que no era del cliente.

Lo mismo vale para la plataforma en la que fue escrito el sistema. Vue 2 llegó al fin de vida el 31 de diciembre de 2023: según la página oficial del proyecto, ya no recibe funcionalidades, actualizaciones ni correcciones — pero sigue disponible en los canales de distribución. Ahí está el riesgo: el fin de vida no derriba nada, así que nada avisa. TinyMCE 4, editor común en sistemas de gestión, está sin soporte desde el 31 de diciembre de 2020 — cinco años sin correcciones de seguridad, todavía corriendo en producción por ahí.

La pregunta que resume la sección: ¿existe alguna fecha, definida por otra empresa, en la que tu sistema deja de funcionar? Si existe, el plazo no es tuyo.

Señal 3 — el equipo ya armó un camino por fuera#

Esta es la señal que la dirección descubre última, porque no genera ticket: el equipo simplemente deja de usar la parte que no sirve y lo resuelve por fuera.

En DNA Genética, la recolección de características de los animales en campo se hacía con papel y lápiz, y se cargaba después — el sistema existía, pero no acompañaba a quien estaba en el campo. En otro cliente, el módulo de mensajes internos estaba parado porque el equipo hablaba por WhatsApp, y un informe que el sistema debía emitir se armaba a mano en Word, todos los meses.

Nadie decide esto en una reunión. Va pasando: alguien crea una planilla para verificar un número que el sistema muestra mal, otra persona empieza a mandar el documento por WhatsApp porque el envío desde adentro falla, y en un año la operación real está repartida en cinco herramientas que nadie contrató.

Cuando eso ocurre, el sistema ya fue parcialmente reemplazado — por planilla, WhatsApp y Word. La pregunta deja de ser si tenés que cambiarlo y pasa a ser si te diste cuenta de que el cambio ya empezó: sin proyecto, sin control y sin nadie responsable por el dato que ahora vive afuera.

Señal 4 — el sistema se volvió el límite del negocio#

La lentitud aislada no es una señal: una pantalla pesada suele ser una consulta mal hecha, y cambiar el sistema por eso es demasiado caro. La señal es cuando el rendimiento cambia lo que la empresa puede hacer.

En DNA Genética esto se midió con cronómetro, en el sistema viejo, en un campo real. Un lote de 32 animales llevó 30 minutos solo para correr el apareamiento, y 19 minutos más para imprimir el resultado — con un error en el medio que obligó a empezar de nuevo. El campo entero, 65 animales en tres lotes, consumió 1 hora y 35 minutos. En el sistema que construimos, en una prueba con el doble de animales, la misma operación — correr e imprimir — responde en hasta 3 minutos.

El número importa menos que la consecuencia: con 1h35 por campo, era imposible hacer el apareamiento delante del productor. El trabajo había que llevarlo a la oficina y devolverlo después. No era una pantalla lenta; era el sistema decidiendo cómo se podía prestar el servicio.

La otra forma de esta señal es más silenciosa: cambiar una cosa pasa a costar dos. En un sistema de gestión que diagnosticamos, dos módulos prácticamente iguales fueron implementados en paralelo, ocupando diez tablas donde entrarían cuatro — y cada regla nueva había que escribirla dos veces, o los dos lados divergían. En ese mismo sistema, los datos de los socios estaban guardados como claves fijas de configuración: agregar un socio nuevo no era configurar, era tocar datos. En dos plataformas jurídicas que mantenemos, escritas en JavaScript sin tipado ni documentación, el efecto llegó por otro camino: cada mejora pedida tardaba tanto que el producto del cliente dejó de avanzar.

Resumen de las cuatro señales, con lo que suele estar detrás de cada frase:

¿Se puede cambiar solo una parte?#

Se puede — y esa es la respuesta que más dinero ahorra, cuando encaja. El criterio es si la parte es realmente separable del resto.

GT es el ejemplo. Heredamos de otro equipo un conjunto que venía de una mala experiencia: el proyecto llevó cuatro veces el plazo previsto y no entregó el resultado completo. La aplicación estaba sin tipado, sin documentación y nunca había sido publicada. Aun así, no rehicimos todo. La app es desprendible — se comunica con la plataforma por una interfaz estable —, así que rehicimos solo eso: tipada, documentada, con prototipo aprobado y publicación en las tiendas. La plataforma web y la API quedaron, corriendo en Go.

En las dos plataformas jurídicas que mantenemos, la ganancia vino de un recorte todavía menor: cambiamos la herramienta de firma por otra, reduciendo costo, sin reescribir una línea del sistema.

Existe un nombre consagrado para el reemplazo gradual: el patrón Strangler Fig, descrito por Martin Fowler — construir lo nuevo alrededor de lo viejo e ir transfiriendo función por función hasta que lo viejo pueda apagarse. Funciona, y la condición es siempre la misma: fronteras claras entre las partes. Sin esa frontera, lo gradual sale caro — datos que divergen entre los dos sistemas, dos integraciones en lugar de una, y una arquitectura de transición que suele durar más de lo previsto. Ahí el camino más rápido es el directo: tocar lo mínimo posible el sistema actual y construir el nuevo entero.

Si vas a cambiar todo, cómo ocurre la migración#

Reemplazar un sistema en operación no es convivir con dos sistemas: es construir entero y migrar de una vez.

El camino tiene cuatro tiempos. El sistema nuevo se construye por completo, con entregas parciales que van a homologación a lo largo del desarrollo — el cliente valida en partes, pero no opera en partes. Listo, corre en paralelo con el viejo por un período: el equipo usa los dos, compara y señala lo que faltó. La migración ocurre un día acordado, con los datos migrados en una ventana planificada. Y el sistema viejo queda solo para consulta algunos meses, como contingencia, antes de ser apagado.

El paralelo es la parte mal entendida. No sirve para dividir la operación entre los dos sistemas — sirve para que el equipo gane confianza antes de depender del nuevo. En Reticar fue así: durante las pruebas la app nueva corrió al lado de la vieja, con capacitación presencial y una ronda formal de devolución; recién después se traspasaron los accesos y la vieja salió. La migración llevó 3.819 clientes, preservando identificadores y fechas de alta — el vendedor abrió la aplicación y reconoció su propia cartera, en lugar de un sistema vacío pidiéndole que recargara años de relación.

Un detalle de calendario vale más de lo que parece: la fecha de la migración se elige contra el pico de la operación, no contra el cronograma del proyecto. Si la operación se concentra de enero a mayo, la ventana correcta es entre agosto y octubre — aunque eso signifique esperar.

Preguntas frecuentes#

¿Se puede reemplazar el sistema de a poco, un módulo por vez?#

Sí, cuando la parte es realmente separable — una aplicación que se comunica con la plataforma por una interfaz estable puede rehacerse sola. Cuando no está aislada, dividir la operación entre dos sistemas sale caro: datos que divergen, dos integraciones en lugar de una y una arquitectura temporal que dura más de lo previsto. Ahí resulta más rápido construir todo y migrar de una vez.

¿Cuánto tarda reemplazar un sistema que la empresa usa todos los días?#

Para un sistema de gestión completo, con muchos módulos y años de datos acumulados, el plazo realista entre el inicio del desarrollo y la migración es de diez a doce meses — y buena parte de ese tiempo no es escribir código, es descubrir las reglas que nadie documentó. Para una aplicación o un módulo aislado, es una fracción de eso. En ambos casos el sistema viejo sigue funcionando hasta el día de la migración.

¿Necesito el código fuente del sistema viejo para reemplazarlo?#

No es obligatorio, pero cambia el costo y el riesgo. Sin él, las reglas de negocio hay que redescubrirlas por ingeniería inversa — observando el sistema en uso y entrevistando a quien lo opera —, lo que es lento y deja margen para divergencias. Con el código, lo implícito se vuelve verificable. Si el proveedor anterior todavía existe, negociá el acceso antes de empezar.

¿Qué pasa con los datos y el historial de los años anteriores?#

Se migran, y esa es la parte más subestimada del proyecto. El punto de atención es preservar identificadores y fechas originales, para que quien abre el sistema nuevo reconozca su propia base en lugar de una pantalla vacía. La migración hay que ensayarla más de una vez antes del cambio, y el sistema viejo suele quedar disponible solo para consulta durante algunos meses después.

Mi proveedor desapareció o ya no responde. ¿Eso alcanza como motivo para reemplazar?#

Alcanza como motivo para actuar, y reemplazar es la solución más cara de las disponibles. Un proveedor ausente es un problema de contrato, no de código: en la mayoría de los casos la salida es pasar el mantenimiento a otro equipo, que asume el sistema tal como está. Eso también funciona como diagnóstico barato — después de algunos meses conviviendo con el código, reemplazar o no deja de ser una corazonada.

Fuentes#

• Joel Spolsky — "Things You Should Never Do, Part I" (2000), sobre el riesgo de reescribir desde cero — https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
• Martin Fowler — "Strangler Fig Application" (el patrón de reemplazo gradual) — https://martinfowler.com/bliki/StranglerFigApplication.html
• Vue.js — "Vue 2 has reached End of Life" (página oficial de fin de vida de Vue 2) — https://v2.vuejs.org/eol/
• Tiny — "TinyMCE 4 support window" (anuncio oficial del fin de soporte de TinyMCE 4) — https://www.tiny.cloud/blog/tinymce-4-support-window/

Próximo paso#

Si reconociste dos o más señales acá, el paso siguiente no es pedir una propuesta de reescritura — es diagnosticar. En la mayoría de los casos que atendimos, el desenlace correcto fue asumir el mantenimiento y corregir lo que trababa la operación. Cuando el cambio es la respuesta, suele ser del todo: así fue en Reticar Motores, donde reemplazamos el sistema comercial de campo de una operación viva. Es el tipo de decisión que tratamos en sistemas a medida — y, si tu equipo trabaja donde la señal falla, vale leer también qué cambia en un sistema cuando la app tiene que funcionar sin señal.