Que un sistema lleve años funcionando no demuestra que deba reemplazarse. La pregunta es si aún permite operar, mantener información confiable y realizar cambios necesarios con riesgos y costos aceptables. A veces la mejor decisión es conservarlo; otras, modernizar una parte o planear una transición completa.

Empieza por lo que depende de él

Documenta usuarios, procesos, datos, proveedores, infraestructura y servicios conectados. Identifica quién conoce las reglas de negocio y si existen código, documentación, licencias y accesos. Una función pequeña puede sostener un cierre mensual o alimentar otro sistema sin que aparezca en la pantalla principal.

Registra problemas concretos: cambios que tardan demasiado, errores repetidos, dificultad para encontrar soporte, dependencia de dispositivos obsoletos o falta de visibilidad de datos. Distingue incidentes medidos de percepciones del equipo para evitar reemplazar por una impresión aislada.

Compara tres caminos

Conservar y estabilizar: si cubre el proceso y puede mantenerse, quizá baste documentar, mejorar respaldos o corregir puntos críticos. Modernizar gradualmente: se reemplaza una capacidad delimitada mientras otras continúan, con una estrategia explícita para compartir datos. Reemplazar: puede evaluarse si la solución impide necesidades importantes y una transición resulta viable.

La guía de Google Cloud sobre modernización describe enfoques diferentes y la necesidad de evaluar el sistema existente. Moverlo a otra infraestructura no corrige automáticamente sus reglas, datos o experiencia.

Define una frontera pequeña y reversible

Selecciona un proceso con responsable, entradas y salida observables. Compara información de origen y destino, decide cómo se manejarán los registros que cambien durante la transición y define una forma de volver atrás. Si ambos sistemas trabajan al mismo tiempo, establece cuál tiene la información oficial para cada dato.

Ejemplo hipotético: una empresa conserva su sistema contable y prueba un nuevo portal de solicitudes. Antes de conectarlos, revisa permisos, frecuencia de actualización y qué ocurre si la conexión falla. No se considera terminado solo porque la nueva pantalla cargue.

Matriz para decidir

  • Continuidad: ¿qué se interrumpe si la transición falla?
  • Datos: ¿se pueden exportar, validar y recuperar?
  • Personas: ¿quién conoce los casos excepcionales?
  • Dependencias: ¿qué proveedores y licencias participan?
  • Costo total: ¿qué implica operar, formar al equipo y mantener cada opción?
  • Salida: ¿qué evidencia permite detener o continuar la siguiente fase?

La edad por sí sola no es un criterio suficiente. La decisión debe comparar necesidades reales, riesgo de cambio y capacidad de sostener la alternativa elegida.

Calcula el costo de cambiar y el de esperar

Una comparación útil incluye no solo el proyecto nuevo, sino el trabajo de limpiar datos, capacitar personas, operar dos sistemas durante la transición y mantener integraciones. En la alternativa de conservar, incorpora el costo conocido de soporte, restricciones para realizar cambios y riesgos que ya se han presentado. Mantén por separado las estimaciones y los hechos observados.

Acuerda una fecha para revisar la decisión aunque se opte por conservar. Si un proveedor anuncia el fin del soporte, una dependencia cambia o el proceso crece, la comparación puede variar. La revisión no obliga a reemplazar: ayuda a decidir con evidencia actualizada y a evitar una transición urgente sin preparación.

Fuentes consultadas

Revisemos tu sistema actual

Cuéntanos qué funciona, qué se ha vuelto difícil y qué no puedes interrumpir.

Hablemos de tu sistema