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

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

Un sistema viejo, feo o lento no es motivo para reemplazarlo. De los nueve sistemas heredados que Epicora asumió, dos fueron reemplazados y cinco siguen en mantenimiento. La edad no es un defecto: una interfaz anticuada se resuelve por una fracción del costo de una reescritura, y un sistema que funciona hace años es un argumento a su favor, no en contra.

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.

El engaño más caro: el sistema no es insuficiente, está sin configurar#

Antes de escribir el alcance de un sistema nuevo, audita el actual desde adentro, con acceso. En un caso de agosto de 2026, tres de los cuatro requisitos que pedía el cliente ya existían en el sistema que usaba — desactivados. Un requisito que aparece apagado es configuración y cuesta una fracción del precio; un requisito sin lugar en el modelo de datos es software.

Hay un pedido que llega con la decisión ya tomada: "el sistema que usamos nos sirve bien, solo quería uno nuestro, con estas cuatro mejoras". Es el que parece más fácil de atender, y es el que más engaña.

En agosto de 2026 hicimos, en ese caso, lo que ahora hacemos siempre: antes de escribir una línea de alcance, entramos al sistema actual con sesión abierta, por dentro, con el acceso cedido por el propio cliente. Era un SaaS de gestión vertical, en uso desde hacía cinco meses. De los cuatro requisitos que pidió, tres ya existían allí — apagados:

• La agenda self-service del cliente final estaba activa, con página pública en línea — y 1 de 120 servicios publicado en ella.
• La pre-agenda que pidió existía con otro nombre, configurable servicio por servicio, y estaba en cero en los 120.
• El tercero era un módulo de mensajería que el sistema ofrecía y que nunca se había activado.

El cuarto requisito era real — y más profundo que el pedido. No era un filtro que faltaba en la pantalla: el dato que ese filtro necesitaría no existía en el registro, y los dos frentes de la operación medían capacidad en unidades distintas. Ese es el requisito que justifica software.

Nada de esto aparece en un briefing, porque el cliente describe lo que cree que el sistema no hace — y nadie conoce su propio sistema entero. El descuento que la auditoría le da al proyecto es grande: existía un camino honesto que entregaba tres de los cuatro pedidos con configuración, sin construir nada.

El segundo efecto es menos obvio y vale más: una operación sin configurar es riesgo de proyecto. Si el sistema actual llegó a los cinco meses con 119 de sus 120 servicios fuera de la página pública, el sistema nuevo — más capaz, más lindo, con las cuatro mejoras — llega apagado igual. Lo que faltaba ahí no era software.

El guion cabe en una sesión, y el orden importa: la pantalla del dolor y los filtros que de verdad tiene; el registro detrás de ella, para ver si el dato existe; el menú completo, que es la vara real del "nos sirve bien"; la base de clientes ordenada por gasto, que suele desmentir la persona del briefing; la capacidad física de la operación, que es el cuello de botella antes de cualquier pantalla; y cuántos ítems del catálogo facturan de verdad. Es el mismo principio de diagnosticar antes de decidir que aplicamos en código generado por IA: la pregunta "¿qué se puede rescatar?" siempre es más barata que la respuesta "rehagamos todo".

Una advertencia de conducta, porque vale para quien repita el ejercicio: el contrato de uso de un SaaS suele prohibir ceder el acceso y replicar el software. El acceso lo tiene que dar el cliente — de preferencia con un usuario propio para quien audita —, lo que se documenta es su operación y sus requisitos, nunca la implementación del proveedor, y no se aceptan términos ni se graban datos dentro del sistema de un tercero.

Señal 1 — nadie puede tocar el sistema#

La primera señal de que un sistema necesita ser reemplazado no es técnica: es que nadie puede tocarlo. La prueba lleva un minuto — ¿cuántas personas pueden, hoy, corregir un error en producción y publicar la corrección? Si es una, hay riesgo de continuidad. Si es cero, el sistema dejó de ser un activo y se volvió un pasivo.

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#

La segunda señal es perder el acceso a tu propio producto: la aplicación salió de la tienda, la cuenta de publicación es del proveedor que desapareció, o una dependencia tiene fecha de apagado. La pregunta que resume la señal es directa — ¿existe alguna fecha, definida por otra empresa, en la que tu sistema deja de funcionar?

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.

En los dos casos de aplicación hay una pregunta que precede a la técnica y decide el resto: de quién es la cuenta de la tienda. Si es del proveedor que desapareció, no perdiste solo la app — perdiste el canal, y volver a empezar en una cuenta nueva cuesta la base instalada, el historial de reseñas y el camino de actualización de quien ya la tenía. Lo tratamos en de quién debe ser la cuenta de la App Store.

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#

La tercera señal no genera ningún ticket: el equipo deja de usar la parte que no sirve y resuelve por fuera, en planillas, WhatsApp y documentos armados a mano. Cuando eso pasa, el sistema ya fue parcialmente reemplazado — sin proyecto, sin control y sin nadie responsable por el dato que ahora vive afuera.

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 cuarta señal es que el desempeño cambie lo que la empresa puede hacer — no una pantalla lenta aislada, que suele ser una consulta mal hecha y no justifica cambiar nada. En DNA Genética, 65 animales en tres lotes consumían 1 hora y 35 minutos en el sistema viejo; en el nuevo, con el doble de animales, la misma operación responde en hasta 3 minutos.

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.

Existe además un tercer camino, cuando parte de lo que hace el sistema heredado está bien hecha y la operación no quiere perderla: el viejo queda como fuente de datos y el nuevo se construye alrededor. Aquí vale la advertencia de cualquier integración — lo que la arquitectura puede hacer no es tu elección, es lo que ofrece el otro lado, como describimos al integrar con el ERP que la operación ya usa.

El sistema heredado es la especificación — y ahí es donde el proyecto nuevo se equivoca#

Cuando la decisión de reemplazar ya está tomada, el error siguiente es sutil: tratar el sistema viejo como el problema y no como la fuente de requisitos más completa que existe. Carga años de reglas que nadie escribió en ninguna parte, y la prueba de que lo entendiste no es "el nuevo es mejor" — es el nuevo hace todo lo que hacía el viejo.

En el sistema de gestión que estamos reemplazando ahora, esa prueba reprobó nuestro propio diseño. Antes de escribir código armamos un prototipo navegable del sistema entero — hoy en 44 rutas clicables —, con una regla dura: nada entra en desarrollo antes de la aceptación por escrito. Al reconciliar el prototipo con el sistema en uso, pantalla por pantalla, apareció lo que el alcance no había captado: la pantalla central del trabajo tenía dos secciones donde el sistema actual ya tiene cinco. No era un pedido nuevo del cliente; era una función que el sistema heredado entrega desde hace años y que nosotros habíamos dejado afuera.

Del mismo ejercicio salió lo contrario, que importa igual: reemplazar no es copiar pantalla por pantalla. Un módulo entero del sistema viejo se convirtió en una marca dentro de otra pantalla — porque la pregunta que respondía era una sola, y tener módulo propio obligaba a subir el mismo archivo en dos lugares y a decidir, antes de adjuntarlo, a cuál de los dos pertenecía.

De ahí salen dos conclusiones prácticas, y separan una migración tranquila de una con la operación detenida:

• La reconciliación es contra el sistema en uso, no contra el documento. Comparar el alcance nuevo con el modelo viejo, o con el recuerdo de quien lo operaba, deja pasar comportamiento. Lo que sirve es abrir los dos lado a lado.
• El prototipo es el instrumento más barato para descubrir reglas no documentadas. Mucho más barato que descubrirlas después, con el sistema nuevo en producción y el equipo sin poder cerrar el mes.

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#

¿Cómo sé si el problema es el sistema o su configuración?#

Entrando al sistema actual antes de escribir el alcance, con sesión abierta y con quien lo opera al lado. La verificación es objetiva: para cada cosa que falta, busca el campo que exigiría en el registro y el ítem correspondiente en el menú. Un requisito que aparece apagado es configuración, y cuesta una fracción de un sistema nuevo. Un requisito que no tiene dónde existir en el modelo de datos es software. En un caso reciente, tres de los cuatro pedidos del cliente ya estaban en el sistema — apagados.

¿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.