- Map data ownership and decision rights before drawing APIs.
- Use an anti-corruption layer so legacy semantics do not leak into the new domain.
- Every migration slice needs reconciliation and a tested rollback path.
Find the real seams
Enterprise integration fails when the architecture diagram ignores how work actually happens. We map business capabilities, system owners, batch windows and manual workarounds with the people who operate them. The source of truth for customer, item, price and invoice is documented per field where necessary, because one system is rarely authoritative for an entire entity.
The target state defines bounded contexts, API and event contracts, identity propagation and explicit non-goals. This is where we decide what will remain batch, what becomes near-real-time and what should not be integrated at all.
- Capability and dependency mapping
- Field-level source-of-truth rules
- API and event contracts with ownership
- Explicit non-goals and migration order
Strangle, do not rewrite blind
A strangler migration routes one capability at a time through an anti-corruption layer. New services translate legacy semantics into a clean domain model, while the old system continues to run. A feature gate decides which path is active, and reconciliation compares both outputs during the transition.
Idempotent consumers, schema evolution and dead-letter queues are mandatory. If a CRM update fails, the business needs an exception queue and an owner, not a silent retry loop. We design compensating actions for workflows that cross systems and cannot be one transaction.
- Anti-corruption layer for legacy semantics
- Feature-gated traffic migration
- Parallel-run reconciliation reports
- Dead-letter queues and compensating actions
Operate the new seam
Distributed tracing follows a business event across ERP, CRM, messaging and custom services. Dashboards report business lag, not just CPU. SLOs are tied to an owner who can act. Runbooks cover replay, reconciliation and rollback.
Knowledge transfer happens during delivery. The goal is not a permanent dependency on the implementation team; it is an operating model your engineers can support, with architecture decisions recorded and failure modes understood.
- Business-level tracing and lag metrics
- Owned SLOs and alert routing
- Replay, reconciliation and rollback runbooks
- Architecture decision records and handover
Questions we hear in the room
Do we have to replace our ERP?
Usually not. Most programmes extend and strangle legacy capabilities in slices. Replacement is considered when security, vendor or cost constraints make modernisation uneconomic.
How do you prevent duplicate records?
Deterministic matching rules, idempotent writes, field-level ownership and reconciliation queues with human review for ambiguous cases.
