Sustituir un sistema empresarial: ¿cuándo conviene mantener ambos?

Mantener disponible un sistema empresarial antiguo durante su sustitución puede ayudar a comparar resultados o a trasladar el trabajo por etapas manejables. Antes de aprobar ese periodo, exija cuatro elementos: un propósito concreto, un registro claramente definido como fuente autorizada, una persona responsable de investigar las diferencias y un criterio acordado para ponerle fin.

Para una dirección general, una persona responsable de operaciones o de finanzas, la decisión afecta a cómo la empresa mantiene registros precisos y completa el trabajo diario. «Mantendremos ambos sistemas» deja demasiadas cuestiones sin resolver. La propuesta debe explicar qué hará cada sistema, qué utilizará el personal y cuánto costará la solución temporal.

Tres significados distintos de mantener ambos sistemas

Comparar resultados. Un sistema sigue realizando la operación empresarial real, mientras que el sistema de sustitución calcula un resultado para compararlo. En un hipotético cambio de sistema contable, el equipo podría comparar informes de un mismo periodo definido y con los mismos datos de entrada, mientras el sistema existente sigue siendo responsable de emitir las facturas. La comparación de cálculos no debe generar por error una segunda factura, un pago, un pedido ni un correo electrónico.

Acuerde qué diferencias son relevantes y quién las investiga. Un total coincidente puede ocultar diferencias entre registros individuales, reglas de redondeo o plazos. Copiar los datos correctamente deja una pregunta aparte: ¿puede el personal completar el flujo de trabajo requerido, incluidas las correcciones y las excepciones?

Trasladar la responsabilidad por etapas. Una función definida o un grupo de clientes pasa al sistema de sustitución, mientras el resto del trabajo permanece en el sistema antiguo. Cada etapa necesita instrucciones claras sobre dónde introduce los cambios el personal y de qué sistema proceden los registros de los informes. Tener ambas aplicaciones disponibles no otorga a las dos autoridad sobre todos los registros.

La guía de Microsoft sobre el patrón Strangler Fig describe cómo trasladar funciones gradualmente y retirar finalmente el sistema antiguo. Es necesario prestar atención a las dependencias y a los datos compartidos durante todo el proceso. Para la dirección de la empresa, la pregunta útil es si la responsabilidad puede dividirse con suficiente claridad para operar y comprobar cada etapa.

Escribir deliberadamente en ambos sistemas. En este caso, el software está diseñado expresamente para registrar los cambios en dos lugares. Esto crea otra obligación: explicar qué ocurre cuando una escritura se completa y la otra falla. Alguien debe detectar la diferencia, decidir qué registro prevalece y completar o corregir el trabajo pendiente.

La explicación práctica de AWS sobre la reversión de una migración, publicada por Ed Murray en 2020, ilustra la coordinación que requieren las escrituras dobles y una vuelta escalonada al sistema anterior. Es un ejemplo técnico fechado, no un plan de implementación listo para usar. Introducir los mismos datos a mano o prometer que se sincronizarán no resuelve estas responsabilidades.

Compare la coexistencia con un cambio de una sola vez ensayado

La transición por etapas puede limitar cuánto trabajo cambia de una vez, pero mantener dos entornos operativos añade tareas de soporte, formación, conciliación e integración temporal. Incluya esos costes en la decisión de sustitución, junto con el coste de eliminar las conexiones temporales.

En su artículo de 2022 Arquitectura transitoria, Ian Cartwright, Rob Horn y James Lewis describen puentes temporales y su retirada posterior. Su experiencia explica por qué un puente puede cumplir una función útil y, aun así, necesitar un presupuesto propio y un plan de salida.

Conviene comparar también un cambio de una sola vez ensayado cuando el sistema es pequeño, la responsabilidad no puede dividirse, no hay puntos de integración adecuados o un plazo urgente de retirada impide una coexistencia prolongada. Microsoft señala límites de idoneidad similares para la sustitución gradual. Estas condiciones no hacen que un cambio de una sola vez sea automáticamente seguro. Hacen especialmente importantes la preparación, las comprobaciones operativas y la autoridad para decidir.

Solicite pruebas obtenidas en un ensayo de la transición propuesta y condiciones acordadas para seguir adelante o detenerse. Compare las dos opciones con el trabajo real que debe continuar. Ninguna modalidad tiene una duración ni un umbral de aceptación universal.

Las nuevas transacciones cambian la decisión de reversión

Cuando el personal ya ha introducido trabajo válido en el sistema de sustitución, volver a abrir la aplicación antigua puede dejar atrás esos registros recientes. Además, los pedidos pueden haber activado entregas, pagos o mensajes que no se deshacen al restaurar una base de datos.

La guía de AWS para la fase de cambio distingue entre revertir antes de que haya datos nuevos y hacerlo después de nuevas transacciones, cuando la base de datos original puede estar desactualizada. Antes de aprobar la vuelta al sistema anterior, exija un tratamiento concreto de los nuevos registros y de las acciones posteriores que hayan activado. Una copia de seguridad por sí sola no demuestra que las operaciones puedan reanudarse de forma coherente.

El registro de decisiones que conviene solicitar

Un registro breve debe permitir que las personas responsables de la empresa respondan a estas preguntas:

• Propósito y alcance: ¿Qué trabajo se compara o se traslada y qué aporta mantener ambos sistemas?
• Autoridad: ¿Dónde se introducen los cambios en cada etapa y qué registros rigen los informes y las acciones afectados?
• Conciliación: ¿Quién investiga las diferencias, cómo se registran y quién resuelve los resultados discrepantes?
• Aceptación: ¿Qué pruebas permiten pasar a la etapa siguiente, qué obliga a detenerse y quién decide si se sigue o se para?
• Reversión: ¿Cómo se tratarán las nuevas transacciones y las acciones posteriores ya completadas si el trabajo vuelve al sistema antiguo?
• Salida: ¿Qué pruebas permiten retirar el sistema, quién elimina los puentes temporales y qué registros deben seguir accesibles según los requisitos aplicables?

Apruebe la coexistencia cuando su propósito y las responsabilidades operativas justifiquen el coste y exista una salida viable. Si está evaluando una sustitución, nuestro servicio de sustitución de sistemas heredados es un buen punto de partida para hablar del sistema actual, del trabajo que debe continuar y de las limitaciones del cambio.