ERP migration: separate connected data flows in stages

Separate individual data flows before switching their destination during an ERP migration. An application that knows the old ERP's internal fields throughout is harder to migrate selectively. A clear handover point can limit that dependency.

Select a bounded path

In a fictional company, a portal creates orders in the old ERP and receives their status later. This exact path is selected for the first migration step. Other connections remain in their agreed state. Include responses and delayed processing in your inventory; an order already sent can still produce a response from the old system after the switch.

Microsoft describes staged replacement through an intermediary in the Strangler Fig pattern. This is an architectural decision with a cost in effort. It is particularly suitable when the old and new paths can coexist for a time.

Keep the business meaning stable at handover

In the example, the portal submits an order creation request with its own operation identifier. An adapter translates it into the format of the intended ERP. The ERP's internal order identifier is mapped to the portal operation.

The table is our own example allocation. Two ERPs must not independently execute the same request as a new order. A technical parallel comparison needs a separately safeguarded path without duplicate production effects.

Check translation and data mapping

An Anti-Corruption Layer translates between different system models. It can sit inside an application. For our example, item and customer identifiers and the meaning of quantities must fit the new ERP. The same field name is insufficient evidence of this.

Before switching, check a new order and a delayed status notification for an old order. Verify that both reach the correct portal operation. Migrating existing data must account for the same mappings.

Plan fallback alongside its data consequences

Specify when new requests may use the old path again. Separately resolve what happens to orders already created in the new ERP. Switching the intermediary back does not automatically transfer or delete them. Also check who monitors and maintains the intermediary; it must not become an unnoticed bottleneck.

The old connection is removed only once outstanding responses and remaining dependencies are resolved. Its retirement therefore depends on the affected operations as well as the date of the first successful new request.

Sources

• Microsoft Learn: Strangler Fig pattern

• Microsoft Learn: Anti-Corruption Layer pattern