Should We Use iPaaS, Custom Middleware, or Point-to-Point ERP CRM Integration?

The uncomfortable part is that architecture does not repair unclear data responsibility. An elegant platform can still duplicate customers, overwrite an order status, or leave finance working from a different number. IBM's integration guidance gives the useful warning: in changing, complex topologies, proprietary point-to-point connections grow exponentially as applications are added. That is not a product pitch. It is a maintenance bill waiting to be understood.

Should we use iPaaS or build a custom ERP and CRM integration?

Use an integration platform as change, reuse, and operational visibility become recurring needs; build custom middleware when the integration requires behavior the platform cannot sensibly express and your team can own its full lifecycle. Use a direct connection when the two applications are known, rarely change, and the integration scope is genuinely narrow. The technology choice follows the operating model, not the other way around.

IBM Redbooks notes that messaging or managed file transfer can fit applications known in advance and unlikely to change. The same publication identifies reusable connectors, transformations, routing policy, lifecycle management, workload separation, and operational monitoring as benefits of an integration bus. In plain English: a shared layer starts earning its keep when the next connection should reuse work rather than begin from scratch.

Use this as a decision worksheet. List every current system, every planned consumer of ERP or CRM changes, the flows that must be auditable, the compliance controls that must be enforced, and the people who will handle failures at an inconvenient hour. If the answer is “the developer who wrote it,” custom code may be honest but fragile. If the answer includes several business-critical flows and several future consumers, reusable infrastructure is usually the more sober choice.

Security belongs in that worksheet. NIST identifies authentication, access management, secure communication, integrity assurance, monitoring, throttling, and circuit breakers as core needs for API interactions among substantial numbers of components. A circuit breaker stops requests to a failing service after a failure threshold, reducing the chance that one outage turns into several. That requirement does not disappear because the integration has a friendly visual designer.

When does point-to-point integration become too difficult to maintain?

Point-to-point becomes too difficult when a change in one application forces coordinated edits, retesting, and diagnosis across several proprietary connections. IBM describes the underlying pattern directly: the number of point-to-point integrations grows exponentially with the number of applications in complex topologies that change often. The warning is about the shape of the system, not a magic application count.

Look for practical signals rather than pretending there is one universal threshold. A customer update now has to reach more than the ERP. A new reporting, commerce, service, or finance consumer wants the same event. Different links transform the same address or product fields differently. A failure cannot be traced from one correlation ID through to a resolved business record. These are maintenance signals.

There is a useful distinction between a command and an event. Microsoft Learn describes commands as high-value messages with strict at-least-once delivery requirements, while events announce facts that can have multiple independent subscribers. An order-creation command should not become two orders after a retry. A customer-address-change event may legitimately inform several systems. Treating both as a generic API call is how apparently simple integrations acquire expensive edge cases.

A broker can also provide temporal decoupling: the producer can send when the consumer is unavailable, and the consumer can process later. This matters when an ERP maintenance window should not cause the CRM to lose a valid request. It does not make the business process automatic; it gives the process somewhere safe to wait.

A practical maintenance test

For each proposed connection, ask four questions: Can another consumer receive the same change without modifying the producer? Is the transformation defined once or copied into several links? Can an operator see the record, message ID, retry history, and target response in one place? Can a failing endpoint be isolated without blocking unrelated work? If several answers are no, the direct-link design is already asking for a shared integration layer.

Which system should be the source of truth for customer and order data?

Set one source of truth and one field owner for each data domain; do not make both ERP and CRM authoritative for the same field without a written conflict rule. CRM can own sales-facing account details while ERP owns financial and fulfillment facts, but the assignment must be explicit at the field level. “Both systems sync both ways” is a transport description, not a governance policy.

Oracle's documented Siebel CRM and Oracle E-Business Suite design shows a concrete pattern: a new CRM account is synchronized to ERP during order booking, later CRM updates flow only after that account has been synchronized, and initial bulk loading creates cross-references between the systems. That cross-reference is the durable answer to “which record is this?” It is more reliable than matching only on a name, email address, or address line that can change.

Oracle specifically warns that its ERP order API needs a site ID and customer ID to associate an order with an existing record; without them, a new or duplicate customer may be created. It also documents the need to merge or update the related CRM account when customer parties are merged in ERP. Make merge events first-class integration work. A duplicate is not fixed because a matching job eventually notices it.

Then make the receiver tolerant of delivery reality. Microsoft's idempotent consumer guidance explains that at-least-once delivery can produce duplicates after retries, missed acknowledgments, or processing failures. Use a stable producer-assigned message ID or business-level idempotency key, not a transport identifier that changes on redelivery. Record the deduplication marker and the business effect atomically, with a unique constraint or equivalent conditional write so concurrent consumers cannot both accept the same work.

There is no honest promise that every message will arrive exactly once. The practical objective is better: duplicate delivery must not create duplicate business effects.