En muchas entidades públicas existen sistemas construidos hace diez, quince o veinte años que todavía permiten consultar información, registrar actuaciones y completar las funciones para las que fueron creados. Por eso puede parecer innecesario modernizarlos mientras continúen encendiendo y no presenten una falla grave. El verdadero problema de la obsolescencia no comienza cuando el software deja de funcionar, sino cuando la entidad necesita cambiar y descubre que cada nueva norma, integración, servicio o aumento de usuarios exige meses de trabajo, soluciones provisionales y riesgos que nadie quiere asumir.
Una plataforma fue creada cuando la entidad recibía documentos por pocos canales y atendía una carga mucho menor. Con el tiempo aparecen nuevas dependencias, trámites digitales, firmas electrónicas, servicios en línea, intercambio de información con otras instituciones y ciudadanos que esperan consultar el estado de sus solicitudes sin desplazarse. El sistema original continúa operando gracias a ajustes pequeños, hojas de cálculo, correos paralelos y el conocimiento de dos o tres personas que saben dónde tocar sin romperlo. La tecnología parece seguir funcionando, pero la operación real ya ocurre alrededor de ella.
Un sistema antiguo no es necesariamente un sistema obsoleto. Un software con años puede continuar siendo seguro, mantenible y capaz de integrarse. Uno más reciente puede volverse una carga si depende de tecnologías difíciles de encontrar, no permite extraer información, concentra demasiadas funciones en una sola pieza o exige especialistas que la entidad ya no puede contratar. Elegir tecnología también significa elegir una comunidad, una oferta futura de talento y la posibilidad de que otras personas puedan mantenerla cuando quienes la construyeron ya no estén.
Modernizar tampoco significa reemplazar de una vez todo aquello que funciona. Una migración completa puede detener servicios esenciales, perder conocimiento acumulado y convertir una mejora necesaria en un proyecto imposible de terminar. Suele ser más razonable identificar primero las partes que producen mayor dependencia, separar los datos de las aplicaciones, crear integraciones controladas, renovar componentes por etapas y construir una arquitectura donde cada nueva capacidad pueda incorporarse sin intervenir todo el sistema. Incluso una plataforma exitosa necesita reconstruir infraestructura, monitoreo, procesos y núcleo tecnológico cuando el crecimiento supera aquello para lo que fue diseñada.
La obsolescencia casi nunca llega como un apagón repentino. Normalmente se presenta como pequeños retrasos, tareas manuales, cambios que siempre se aplazan, dificultades para integrar una nueva herramienta y decisiones que dependen de la única persona que todavía entiende el sistema. Esperar hasta que la plataforma falle no es ahorrar recursos; es acumular una deuda que la siguiente administración tendrá que pagar con menos tiempo y mayor riesgo. La pregunta no debería ser únicamente si el sistema todavía funciona, sino si puede acompañar con seguridad a la entidad que necesitaremos dentro de los próximos años.
Pregunta para conversar: ¿Tu sistema sigue siendo útil porque funciona o porque todavía puede cambiar sin poner en riesgo la operación?
