Cuándo modernizar un sistema y por dónde empezar

Un sistema puede tener muchos años y seguir resolviendo bien su trabajo. También puede ser relativamente nuevo y resultar difícil de cambiar. Para decidir si hace falta modernizarlo, conviene mirar qué ocurre cuando la operación necesita algo distinto.

¿Agregar un campo obliga a tocar varias aplicaciones? ¿Cada actualización requiere que esté disponible una sola persona? ¿Los equipos terminan llevando una planilla paralela para completar lo que el sistema no permite? Esas situaciones dan un punto de partida más útil que la edad de una tecnología.

Mirar el costo de seguir igual

Antes de elegir una solución, registrá algunos cambios recientes. Qué se pidió, qué hubo que modificar, dónde apareció el riesgo y qué trabajo manual quedó después. Separá los problemas que afectan a quienes usan el sistema de los que sólo incomodan al equipo técnico.

Una integración que se interrumpe y obliga a reconstruir pedidos merece una conversación distinta de una pantalla que podría verse más actual. Ambas pueden mejorar, pero su prioridad depende de lo que necesita la operación.

Conservar, aislar o reemplazar

Reescribir todo es una alternativa que merece evaluación, no un requisito previo. Puede haber reglas de negocio que el sistema resuelve bien y que nadie tiene documentadas fuera del código.

Para cada parte, conviene comparar tres caminos:

• Conservar: mantener lo que funciona y hacer explícitas sus condiciones de uso.
• Aislar: definir una frontera para cambiar una parte sin intervenir cada vez en las demás.
• Reemplazar: construir una alternativa cuando sostener lo existente ya no permite resolver la necesidad.

La decisión debe incluir los datos, las integraciones, la forma de volver atrás y quién puede validar que el comportamiento sigue siendo correcto.

Una primera intervención que se pueda evaluar

Imaginemos un sistema de pedidos cuyo catálogo se actualiza mediante una planilla. Es un ejemplo ilustrativo, no un caso de cliente. En lugar de reemplazar toda la aplicación, una primera intervención podría ordenar esa actualización: validar los datos, mostrar errores antes de importar y registrar qué cambió.

Ese alcance permite revisar una mejora concreta con quienes cargan la información. También ayuda a conocer dependencias del sistema antes de abordar cambios mayores. Si el problema central estuviera en otro lugar, habría que elegir otra intervención.

Acordar cómo se reconoce una mejora

“Modernizar” es demasiado amplio para aceptar una entrega. Una condición más útil sería poder importar el catálogo, identificar filas inválidas y recuperar la versión anterior ante un error.

Registrá cómo se hace hoy la tarea y qué debería cambiar. Acordá ejemplos de entrada, excepciones y responsables de validación. Si necesitás medir tiempos o errores, obtené una referencia inicial; no hace falta inventar un porcentaje de mejora para justificar el trabajo.

Qué llevar a la primera conversación

Prepará una descripción del sistema, un cambio reciente que haya costado más de lo esperado y las restricciones que no se pueden perder de vista. Sumá las integraciones conocidas y quién utiliza cada parte. No es necesario llegar con una arquitectura nueva elegida.

El mismo criterio sirve para un prototipo creado con IA: revisar usuarios, datos, permisos, recuperación y mantenimiento ayuda a definir qué falta para ponerlo en uso. La evaluación empieza por lo que debe sostener, no por la herramienta con la que se construyó.