Modernización de sistemas existentes

Modernizar un sistema existente no significa reemplazarlo automáticamente: significa identificar qué parte limita la operación y reducir riesgo sin perder continuidad.

Inventario de dependencias

El punto de partida es un inventario que conecte procesos, aplicaciones, bases de datos, archivos, integraciones, usuarios y responsables. No basta con listar nombres: buscamos qué sistema origina cada dato, quién lo modifica, qué tareas dependen de una exportación y qué ocurre cuando una interfaz falla. Se documentan versiones y restricciones conocidas sin asumir que una plataforma ofrece módulos o APIs que aún no se han comprobado. El resultado distingue dependencias críticas, duplicidades y zonas donde falta evidencia. La revisión se hace con personas técnicas y operativas para contrastar el diagrama con el trabajo diario.

Convivencia con el legacy

La convivencia se diseña para que el sistema existente siga cumpliendo su función mientras se prueba una frontera concreta. Puede consistir, por ejemplo, en una consulta operacional que lee datos autorizados sin cambiar el registro principal, o en una captura nueva que devuelve confirmación al flujo anterior. Son ejemplos hipotéticos, no compromisos de arquitectura. Para cada frontera se define quién escribe, quién lee, qué pasa ante un error y cómo se evita que dos equipos crean tener la misma autoridad. Mantener el legacy no significa ocultar sus límites: significa hacerlos visibles y gobernables durante la transición.

Contratos de datos

Antes de conectar componentes acordamos un contrato de datos: campos obligatorios, formatos, identificadores, estados, origen, fecha de actualización y reglas para valores ausentes. También se describen duplicados, cambios de esquema y respuestas parciales. Un contrato útil permite comparar el registro original con la representación transformada y saber qué información no debe modificarse. Si un dato no tiene dueño o significado estable, queda como riesgo y no se disfraza de automatización terminada. Las reglas se prueban con muestras autorizadas y se revisan cuando cambia el proceso, la fuente o el permiso.

Migración reversible

Una migración incremental debe poder detenerse sin perder el camino de vuelta. Se separan lectura, transformación y escritura; se conserva una referencia al origen y se registra cada cambio que pueda conciliarse después. Un ejemplo hipotético sería copiar un conjunto acotado de estados a una vista de trabajo, validar permisos y volver a consultar la fuente original si la prueba no cumple. La reversión concreta depende de los sistemas, respaldos y autorizaciones disponibles; no se presume que sea automática. Antes de ampliar, el equipo confirma qué registro se restaura, quién lo aprueba y cómo se verifica la recuperación.

Conciliación y excepciones

La conciliación compara fuentes con reglas explícitas: identificador, estado, marca temporal y campos que el responsable considere determinantes. Las diferencias se clasifican como actualización válida, duplicado, dato incompleto o conflicto que requiere decisión. Se registra quién resuelve y qué evidencia utilizó. La prueba incluye entradas válidas, campos ausentes, cambios simultáneos y fallos de conexión, porque una coincidencia inicial no demuestra que la convivencia sea sostenible. El tablero o registro de diferencias debe permitir separar un error de transformación de una discrepancia legítima del negocio.

Corte con criterios de aceptación

El corte no se decide por una demostración aislada. Antes se acuerdan casos de prueba, dueño operativo, permisos revisados, evidencia esperada y condición para detenerse. La aceptación puede exigir que los registros comparados mantengan su identidad, que las excepciones queden visibles, que el equipo pueda repetir una comprobación y que exista una ruta de retorno. El alcance puede reducirse, pausarse o descartarse si esos criterios no se cumplen. La decisión queda documentada junto con los casos no cubiertos, para que una aprobación parcial no se interprete como validación total.

Siguiente paso y límites

La salida del diagnóstico es una recomendación condicionada: continuar con una frontera, ampliar el inventario, corregir datos o no intervenir todavía. Se entrega la relación entre dependencias, contratos, riesgos, pruebas y decisiones pendientes. No se promete reescritura total, eliminación inmediata del legacy, compatibilidad universal, ahorro, precio, plazo o nivel de servicio. Agenda un diagnóstico operativo para revisar el caso concreto con la información autorizada y definir una primera validación manejable. Esa conversación debe dejar claro qué se sabe, qué falta comprobar y qué decisión puede tomarse sin comprometer el resto de la operación.