ERP Integration Patterns: Point-to-Point vs. iPaaS
A furniture retailer built eleven separate point-to-point integrations between its ERP and various systems — an e-commerce platform, a freight carrier API, a payment processor, three regional 3PLs — over four years, each one built by a different contractor with no shared documentation. When the ERP vendor pushed a required security update that changed an authentication method, six of the eleven integrations broke simultaneously, and it took the IT team three weeks to even map out which integration touched what, because nothing was centrally documented. That's the point-to-point integration trap, and it's the single most common integration mistake mid-market companies make.
Three integration patterns, and what they actually cost over time
| Pattern | How it works | Upfront cost | Long-term cost |
|---|---|---|---|
| Point-to-point | Direct connection between each pair of systems | Lowest per integration ($5,000-$15,000 each) | Compounds badly past 5-6 integrations; each new system multiplies connection count |
| Middleware / ESB | Central hub routes and transforms data between all systems | Higher upfront ($40,000-$100,000+ for platform and initial build) | Scales much better; new integrations connect once to the hub |
| iPaaS (cloud integration platform) | Managed, cloud-hosted middleware with pre-built connectors | Moderate ($15,000-$40,000 setup, plus $500-$3,000/month subscription) | Lower maintenance burden than self-hosted middleware; connector library often covers common systems out of the box |
The math that matters: point-to-point genuinely is cheaper for one or two connections. The furniture retailer's mistake wasn't building the first integration point-to-point — it was building the sixth, seventh, and eighth one the same way instead of recognizing the pattern had stopped making sense around integration number four.
Where integrations actually fail
Not at the connection level — establishing that System A can talk to System B is usually the easy part, well-documented in both systems' API references. Integrations fail at three specific points that get underestimated during planning:
- Data mapping edge cases. Two systems rarely define the same concept identically. A "customer" in a CRM might be a company; a "customer" in an ERP might be a specific billing entity within that company, with several CRM customers mapping to one ERP customer record. These mismatches surface as data corruption weeks after go-live, not as an obvious error at build time, because they only trigger on specific real-world scenarios (a company with multiple subsidiaries, a customer who changes their billing address mid-order) that clean test data doesn't include.
- Error handling and retry logic. What happens when the receiving system is down for maintenance during a scheduled sync? A well-built integration queues and retries with alerting; a poorly built one silently drops the transaction, and nobody notices until a customer calls asking where their order went. Ask explicitly, for every integration, what the failure behavior is — not whether it can fail, but specifically what happens when it does.
- Volume and timing assumptions that don't hold at scale. An integration tested with 50 sample orders during build often behaves completely differently at 5,000 orders during a seasonal spike — rate limits get hit, batch windows overlap, and a sync that took two minutes in testing takes four hours in production, backing up behind the next scheduled sync.
EDI: still the backbone for B2B integration
For integrations with large trading partners — big-box retailers, major distributors, healthcare payers — Electronic Data Interchange (EDI) remains the standard rather than a modern REST API, because the trading partner mandates it, not because it's the newest technology. Building EDI capability into an ERP integration strategy is its own specialized undertaking with its own document standards and typically requires either a dedicated EDI translator/VAN service or an ERP module built specifically for it. Budget this as a distinct integration category from general API work; the skill set and tooling barely overlap.
What a real integration budget should include
- Monitoring and alerting. Someone needs to know within minutes, not days, when an integration silently stops syncing. This is either a feature of the iPaaS/middleware platform or a separate monitoring tool, but it needs to exist explicitly, not be assumed.
- Version management. Every connected system's API evolves independently. Budget a recurring maintenance allocation — commonly 10-15% of the original build cost annually — for adapting to upstream API changes, not just for fixing outright breakage.
- Documentation upkeep. The furniture retailer's three-week diagnosis time was a direct consequence of undocumented integrations. A living integration map — what connects to what, what data flows which direction, who owns each connection — should be a deliverable of every integration project, not an optional extra.
Choosing a pattern for a specific situation
A rough decision guide: fewer than three integrations and no plans to add more, point-to-point is genuinely fine and probably cheaper. Growing past four or five, or already dealing with a tangle of undocumented connections, an iPaaS platform is usually the better long-term economics even with the subscription cost, because it centralizes monitoring, error handling, and documentation as platform features rather than things each point-to-point build has to reinvent. Full middleware/ESB deployment tends to make sense only at genuine enterprise scale — dozens of systems, high transaction volumes, dedicated integration engineering staff — where the platform cost is justified by scale most mid-market companies haven't reached.
A migration path for an existing point-to-point tangle
Rebuilding all integrations at once is rarely necessary or affordable. A more realistic approach: document the existing tangle first (even retroactively, as the furniture retailer eventually had to), then migrate integrations to a hub pattern opportunistically — whenever an existing point-to-point connection breaks or a new system gets added, that's the trigger to rebuild it through the new integration layer instead of patching the old direct connection. Within 12-18 months, most of the integration traffic typically migrates without a dedicated "rip and replace" project, at a fraction of the cost of doing it all at once.
Who should own an integration after it ships
Ownership tends to be the piece organizations skip even when they get the technical pattern right. An integration built by a contractor during an ERP implementation needs a named internal owner before that contractor's engagement ends — someone who knows where the mapping logic lives, has credentials to the monitoring dashboard, and is the first call when something breaks at 6am on a Monday. Without that handoff explicitly documented and assigned, the knowledge walks out the door with the contractor, and the next failure becomes a much longer and more expensive diagnosis than it needed to be, regardless of how well the integration itself was architected.
Questions worth asking before approving any new integration
- What's the documented failure behavior, specifically, not just "it's reliable"?
- Who owns this integration after go-live, by name, not by department?
- Does this get added to the integration map, and is that map actually kept current?
- At current growth, will this be integration number three or number nine in eighteen months — and does that change which pattern makes sense?
Testing integrations before go-live, not after
Integration testing gets folded into general UAT far too often, and it shouldn't be, because integration failures have a different signature than ordinary functional bugs — they often only appear under real production data volume and timing, which staged test data doesn't replicate. A dedicated integration test pass using a full copy of production-scale data (anonymized where needed for compliance), run against a staging environment that mirrors production infrastructure as closely as possible, catches the rate-limit and batch-window problems that a handful of sample records never will. Budget this as its own testing phase with its own sign-off criteria, distinct from functional UAT, even though the two often run in parallel on the same calendar.
Integration debt at M&A time
Undocumented, tangled integrations become a specific and expensive problem during a merger or acquisition, when a buyer's due diligence team needs to understand exactly what systems talk to what before committing to a valuation or an integration timeline. A target company that can produce a clean, current integration map moves through technical due diligence measurably faster than one where the buyer's team has to reverse-engineer the connections from scratch — the same three-week diagnostic problem the furniture retailer hit, except now it's happening under deal-timeline pressure with real money riding on the answer. Companies anticipating a future sale or acquisition have a concrete business reason, beyond day-to-day operations, to keep the integration map current.
A note on vendor lock-in through integration
Heavy point-to-point integration into a specific ERP's proprietary data structures creates switching costs that go beyond the license itself — every direct integration built against vendor-specific internals is effectively additional lock-in, on top of whatever the contract says. Building integrations against a stable, documented API layer rather than internal tables reduces this lock-in incidentally, as a side effect of the same architectural discipline that makes upgrades cheaper, which is one more reason the iPaaS or middleware pattern tends to pay for itself at scale beyond the direct maintenance-cost argument.