Why ERP integrations stall—and how to move forward

Revisited from the Foresaw archive. The argument and structure have been updated for this edition.

ERP projects often look like software projects until the first migration rehearsal. Then the team discovers inconsistent records, undocumented workarounds, and a business process nobody owns end to end.

Those are not peripheral issues. They are part of the system being integrated. The path forward is to make them visible early enough to address deliberately.

Treat migration as a repeatable process

Profile the existing data before choosing the cutover date. Identify duplicate identities, missing references, and fields whose meaning has changed. Agree on the rules for correcting them with the people who use the records.

Build a repeatable migration and validation process. Rehearse it on representative data, compare the important business totals, and record the exceptions. A migration that works only once is difficult to trust when the final cutover arrives.

Bring operators into the design

A technically correct workflow can still add friction. The people who approve invoices, correct stock, or resolve customer issues know where the difficult cases live.

Use their real tasks in walkthroughs and testing. Document what changes, what remains manual, and who handles an exception. Training should explain the work, rather than just the location of a new button.

Plan the transition explicitly

Decide when the old system stops accepting changes, how in-flight work is handled, and what conditions justify a rollback. Give those decisions clear owners.

A phased rollout can reduce the amount of change at once, but it creates a period where old and new processes coexist. That period needs its own reconciliation and support plan.

Measure business completion

Track whether transactions finish, whether records agree, and whether teams can recover from failures. Those measures reveal more than a checklist of delivered endpoints.