Enterprise application integration is the work of making your ERP, CRM, custom systems and SaaS tools share data and trigger each other reliably. There are five patterns: point-to-point, an API layer, middleware, iPaaS and event streaming. A single well-documented API integration costs $8,000 to $25,000 (€7,000 to €22,000, £6,000 to £18,000). An integration layer in front of a core system costs $60,000 to $200,000 (€50,000 to €175,000, £44,000 to £150,000), and iPaaS licenses run $10,000 to $50,000 per year (€8,500 to €44,000 per year, £7,500 to £37,000 per year). The design decision that matters most is which system is the system of record for each kind of data.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Most enterprise software problems are integration problems wearing a disguise. The sales team cannot see stock because the CRM and the ERP do not talk. Finance re-keys invoices because the custom ordering system exports a CSV. The new customer portal is late because it needs data from four places, each with its own idea of what a customer is. This post is for the person who has to fix that. It compares the five ways systems get connected, explains the one decision that shapes every design, lists the ways integrations fail, and shows how to scope one so the quote you get means something.
What are the integration patterns and what do they cost?
| Pattern | How it works | Typical cost | Fits when | Breaks when |
|---|---|---|---|---|
| Point-to-point | System A calls system B directly, one connection per pair. | $8,000 to $25,000 (€7,000 to €22,000, £6,000 to £18,000) per integration | Two or three systems, stable, well-documented APIs. | You pass five systems. Ten connections become forty, and nobody knows what calls what. |
| API layer | A service in front of a core system exposes clean, versioned endpoints. Everything else talks to the layer. | $60,000 to $200,000 (€50,000 to €175,000, £44,000 to £150,000) | A legacy or complex core that many things need, especially during modernization. | The layer is treated as a pass-through and copies the core's quirks instead of hiding them. |
| Middleware or ESB | A central hub routes, transforms and queues messages between systems. | $60,000 to $200,000 (€50,000 to €175,000, £44,000 to £150,000) plus licensing | Many systems, heavy transformation, a team to own the hub. | The hub becomes the bottleneck and the only person who understands it leaves. |
| iPaaS | A hosted integration platform with prebuilt connectors to common SaaS products. | $10,000 to $50,000 per year (€8,500 to €44,000 per year, £7,500 to £37,000 per year) licenses plus configuration | Mostly SaaS systems, standard flows, limited custom logic. | A custom or legacy system has no connector, or volumes exceed the pricing tier. |
| Event streaming | Systems publish events to a log. Consumers subscribe. Nothing calls anything directly. | $100,000 to $300,000 (€85,000 to €260,000, £75,000 to £220,000) to establish, then per consumer | High volume, many consumers, real-time needs, engineering capacity to run it. | The business flows are simple request-and-reply and the platform is overkill. |
Most companies run a mix: iPaaS for the SaaS edges, an API layer in front of the ERP or the custom core, and point-to-point for the two or three connections that predate everything. That is fine. What is not fine is a mix nobody has drawn.
Which system is the system of record?
This is the question that decides most integration designs and the one most projects skip. For every kind of data, customer, product, price, order, employee, exactly one system should be the source of truth, and every other system should hold a copy it does not edit. When two systems can both change a customer's address, you do not have an integration problem. You have a reconciliation problem that will never end.
Write the table before anyone designs a flow: data type, system of record, which systems hold copies, how fresh the copy must be. Prices might be owned by the ERP and copied to the e-commerce platform within a minute. Customer contacts might be owned by the CRM and copied to the ERP nightly. The moment this table exists, half of the proposed integrations turn out to be one-directional, which makes them simpler and cheaper.
Where the business genuinely needs two systems to edit the same data, the answer is usually a small custom service that owns it, with both systems reading from it. That is a custom internal tool with a clear purpose, not an admission of defeat.
What are the common failure modes?
- The undocumented interface. A nightly job on a server nobody owns moves a file that three downstream systems depend on. It is discovered when the server is decommissioned.
- Silent failure. The integration stops, nothing alerts, and three weeks of orders are missing from the warehouse system. Every integration needs monitoring that someone reads, and a reconciliation report that counts what went in and what came out.
- No idempotency. A retry after a timeout creates the order twice. Every write across a system boundary must be safe to repeat.
- Vendor API limits. The SaaS tool allows 1,000 calls an hour and the month-end run needs 20,000. Rate limits and batch endpoints belong in the design, not in the incident review.
- Transformation sprawl. Field mappings live in six places and disagree. One mapping, versioned, in one place.
- Tight coupling to a system you plan to replace. If the ERP is being modernized, nothing new should call it directly. See the modernization options for why the interface comes first.
How do you scope an integration?
A quote for "integrate the CRM with the ERP" is a guess. A quote for a scoped integration is an estimate. The scope needs:
- The flows. Each one named: what data, from where, to where, triggered by what, how often, how fresh.
- The system of record for each data type in the flow.
- The field mapping, including the fields that do not map and what happens to them.
- Volumes, typical and peak, with the month-end or seasonal spike named.
- Error handling. What happens when the target is down, when a record is invalid, when a retry is needed. Who gets told.
- Access. API credentials, sandbox environments, vendor documentation, and the name of the person at the vendor who answers questions. A missing sandbox is the most common cause of a late integration.
- Reconciliation. How you will prove the integration is correct, every day, not just at go-live.
With those seven things on paper, a well-documented API integration is $8,000 to $25,000 (€7,000 to €22,000, £6,000 to £18,000) and two to four weeks. Without them, the same integration is an open-ended project. The RFP guide shows where this scope sits in a tender.
Build, buy or configure?
| Situation | Recommendation |
|---|---|
| Two SaaS tools with standard objects | iPaaS. Configure it in days, pay the license, move on. |
| Anything touching a legacy or custom core | Build an API layer. Hide the core's quirks behind clean endpoints that outlive it. |
| Ten or more systems with heavy transformation and an internal platform team | Middleware or event streaming, owned by that team. |
| A one-off connection between two stable systems | Point-to-point, documented, monitored. |
Before anyone quotes an integration
- Draw every existing connection, including the file transfers.
- Decide the system of record for each data type.
- Name each flow, its trigger, its frequency and its peak volume.
- Get sandbox access and vendor documentation in hand.
- Define what "correct" means and how you will check it daily.
How 7L approaches integration
7L International builds and modernizes software end-to-end from hubs in New York, London and Athens, and integration is in almost every engagement we take on, from connecting hotel systems to building a unified picture of a smart building's devices. Our default is an API layer in front of any core system that is complex or due to change, iPaaS at the SaaS edges, and a reconciliation report from day one so the integration proves itself every morning. We start by drawing the map and writing the system-of-record table, which is often the first time a client has seen their own estate on one page. The enterprise software development guide covers where that fits in a program. If you have systems that do not talk, describe the flows you need and we will tell you which pattern fits.
Frequently asked questions
What does an API integration cost?
A single integration between two systems with documented APIs costs $8,000 to $25,000 (€7,000 to €22,000, £6,000 to £18,000) and takes two to four weeks once scope, credentials and a sandbox are in hand. An integration layer in front of a core system, exposing clean endpoints to many consumers, costs $60,000 to $200,000 (€50,000 to €175,000, £44,000 to £150,000). iPaaS platforms add $10,000 to $50,000 per year (€8,500 to €44,000 per year, £7,500 to £37,000 per year) in licenses on top of configuration.
What is the difference between middleware and iPaaS?
Middleware is a hub you run, usually on your own infrastructure, that routes and transforms messages between any systems, including custom and legacy ones. iPaaS is a hosted platform with prebuilt connectors to common SaaS products. iPaaS is faster and cheaper when both ends are mainstream SaaS. Middleware or a custom API layer is needed when one end is a legacy or custom system with no connector.
What is a system of record?
The one system that owns a particular kind of data and is the source of truth for it. Other systems hold copies they do not edit. Deciding the system of record for each data type, customer, product, order, employee, is the single most important integration decision, because it turns most two-way syncs into simpler one-way copies and removes the reconciliation problems that come from two systems editing the same record.
Should integrations be real time or batch?
Decide per flow from how fresh the data needs to be, not from what is fashionable. Stock levels shown to customers need minutes. Contacts copied to finance can be nightly. Real-time integrations cost more to build and operate and fail in more interesting ways, so use them where the business needs them and batch everything else.
How do we know an integration is working?
Monitoring that alerts someone when a flow stops or errors rise, and a daily reconciliation report that counts records sent, received and rejected on each side. An integration without both is one that fails silently, and silent failure is the most common and most expensive integration incident.