Cambio de ERP: separar por etapas los flujos conectados

Separe los distintos flujos de datos antes de cambiar su destino durante una migración de ERP. Una aplicación que conoce los campos internos del ERP antiguo en todas sus partes es más difícil de migrar de forma selectiva. Un punto de entrega claro puede limitar esa dependencia.

Elegir una ruta delimitada

En una empresa ficticia, un portal crea pedidos en el ERP antiguo y recibe su estado más tarde. Se elige precisamente esa ruta para el primer paso de la migración. Las demás conexiones permanecen en el estado acordado. Registre también las respuestas y el procesamiento diferido; un pedido ya enviado puede producir una respuesta del sistema antiguo después del cambio.

Microsoft describe la sustitución gradual mediante un intermediario en el patrón Strangler Fig. Es una decisión arquitectónica que requiere esfuerzo. Resulta especialmente adecuada cuando las rutas antigua y nueva pueden coexistir durante un tiempo.

Mantener estable el significado de negocio en la entrega

En el ejemplo, el portal entrega una solicitud de creación de pedido con su propio identificador de operación. Un adaptador la traduce al formato del ERP previsto. El identificador interno del pedido en el ERP se relaciona con la operación del portal.

La tabla es nuestra propia distribución de ejemplo. Dos ERP no deben ejecutar independientemente la misma solicitud como un pedido nuevo. Una comparación técnica en paralelo necesita una ruta protegida por separado, sin efectos duplicados en producción.

Comprobar la traducción y la correspondencia de datos

Una Anti-Corruption Layer traduce entre modelos de sistemas diferentes. Puede estar dentro de una aplicación. En nuestro ejemplo, los identificadores de artículos y clientes y el significado de las cantidades deben ajustarse al ERP nuevo. El mismo nombre de campo no basta para demostrarlo.

Antes del cambio, compruebe un pedido nuevo y una notificación de estado tardía de un pedido antiguo. Verifique que ambos lleguen a la operación correcta del portal. La migración de datos existentes debe tener en cuenta las mismas correspondencias.

Planificar el retorno con sus consecuencias para los datos

Defina cuándo las solicitudes nuevas pueden volver a la ruta antigua. Resuelva por separado qué ocurre con los pedidos ya creados en el ERP nuevo. Cambiar el intermediario a la ruta anterior no los transfiere ni elimina automáticamente. Compruebe también quién supervisa y mantiene el intermediario; no debe convertirse en un cuello de botella inadvertido.

La conexión antigua se retira solo cuando las respuestas pendientes y las dependencias restantes están aclaradas. Su final depende así de las operaciones afectadas, además de la fecha de la primera solicitud nueva completada con éxito.

Fuentes

• Microsoft Learn: Strangler Fig pattern

• Microsoft Learn: Anti-Corruption Layer pattern