Short answer
A direct integration (custom code connecting the ecommerce platform to the ERP) gives full control and low running cost but makes you responsible for reliability features. Middleware or iPaaS provides connectors, queues, monitoring, and mapping tools out of the box, at a subscription cost and with platform constraints. Direct tends to fit one or two systems with custom logic and an engineering team; middleware tends to fit many systems, standard ERPs, and teams with limited development capacity.
- Store
- Direct code or middleware hub Mapping
- ERP
With two systems the difference is small. With five, a hub avoids a mesh of individual connections.
Every ecommerce–ERP project reaches this decision: write the integration yourself, or adopt an integration platform. Both approaches work in production for many businesses. The right choice depends on how many systems you connect, how standard your processes are, and who will operate the result.
Definitions
Direct integration means custom code that connects your ecommerce platform to your ERP. It may be a small service with a queue and workers, but it is built for this specific pair of systems.
Middleware means a general-purpose integration layer between systems. This includes iPaaS products (hosted integration platforms with connectors and visual mapping), self-hosted integration frameworks, and enterprise service buses. See what middleware does for more detail.
Side-by-side comparison
| Dimension | Direct integration | Middleware / iPaaS |
|---|---|---|
| Upfront effort | Higher for the first workflow: you build plumbing (queues, retries, logging) | Lower if connectors exist for both systems |
| Running cost | Hosting only, typically low | Subscription fees, often based on volume, connectors, or environments |
| Control over logic | Complete | Within what the platform supports; custom code options vary |
| Custom ERP support | Natural fit | Requires a custom connector or generic HTTP/database adapter |
| Reliability features | You build them (idempotency, dead letters, replay) | Usually included; quality varies by product |
| Monitoring | You build or integrate it | Usually included dashboards and alerting |
| Adding a third or fourth system | New code per connection | Add connectors to the hub |
| Skills needed | Software engineering | Platform-specific skills plus engineering for custom parts |
| Vendor dependency | None beyond the platforms themselves | Dependency on the middleware vendor and its pricing |
| Testing | Standard software testing tools | Depends on platform; some have limited automated testing |
| Performance at high volume | Tunable to your needs | Bounded by platform limits and pricing tiers |
When a direct integration is a good fit
- One ecommerce platform and one ERP, with no near-term plans for more.
- A custom ERP, where no connector exists and you would build an adapter anyway.
- Unusual business logic that would fight a platform’s mapping model.
- An in-house or partner engineering team that will maintain the code.
- Cost sensitivity over the long term, where subscription fees outweigh engineering time.
The main risk is underbuilding: a “simple script” without idempotency, retries, and monitoring. If you build direct, build it properly — see the architecture guide.
When middleware is a good fit
- Many systems: ecommerce, ERP, WMS, CRM, marketplaces, accounting. A hub avoids a mesh of point-to-point links.
- Standard ERPs and platforms with mature connectors for both sides.
- Limited engineering capacity, where an operations or IT team will own the integration.
- Need for built-in monitoring and replay without building them.
- Organizational standards that already mandate an integration platform.
The main risks are cost growth with volume, limits on complex logic, and lock-in to the platform’s mapping language and runtime.
Hidden costs on both sides
Direct integration:
- Building and maintaining reliability features.
- Keeping up with platform API version changes.
- Knowledge concentrated in a few developers.
Middleware:
- Volume-based pricing at peak periods.
- Custom connector development for a custom ERP.
- Workarounds when a requirement does not fit the platform.
- Migration cost if you later change vendors.
A middle path
Many teams combine both: a lightweight custom service for the core order and inventory flows (where control and cost matter most), and middleware or simple automation tools for peripheral, low-risk flows such as marketing list updates. The deciding factor should be the risk and complexity of each flow, not a one-size-fits-all policy.
Decision checklist
Answer these, and the direction usually becomes clear:
- How many systems will be connected in the next two to three years?
- Does a mature connector exist for both your platform and your ERP?
- Who will operate and change the integration after launch?
- How much custom logic do your workflows need?
- What is the expected volume at peak, and how does middleware pricing scale with it?
- What is your tolerance for vendor dependency?
If most answers point to “few systems, custom ERP, engineering team,” build direct. If most point to “many systems, standard ERP, limited engineering,” evaluate middleware.
Summary
Direct integrations give control and low running costs, at the price of building reliability yourself. Middleware gives connectors and operational tooling, at the price of subscriptions and constraints. Neither is universally better. Use the checklist above, or try the architecture planner for a structured starting recommendation.
Frequently asked questions
Is a direct integration the same as a point-to-point integration?
Usually yes. A direct integration connects two systems with code written specifically for that pair. It may still include a queue and worker service — "direct" refers to the absence of a general-purpose integration platform, not to the absence of architecture.
Does middleware remove the need for developers?
No. Low-code tools reduce boilerplate, but mapping rules, edge cases, error handling, and custom ERP adapters still need technical people. Middleware changes the type of work more than it eliminates it.
Can I start direct and move to middleware later?
Yes, especially if the direct integration is built with clear boundaries — a mapping layer, an ERP client, and a queue. Those pieces map naturally onto middleware concepts. Tightly coupled code is harder to migrate.
What is an ESB, and is it the same as iPaaS?
An enterprise service bus is a middleware architecture, traditionally run on your own infrastructure. iPaaS (integration platform as a service) delivers similar capabilities as a hosted cloud service. Both are forms of middleware.
Sources and further reading
Platform-specific statements on this page were checked against these sources on . Vendor APIs change; confirm details in the current documentation before you build.
- [1] Enterprise Integration Patterns — Gregor Hohpe and Bobby Woolf
- [2] Transactional outbox pattern — microservices.io (Chris Richardson)
Related reading
- Concepts What Does Integration Middleware Do? What integration middleware is, what it does between ecommerce platforms and ERPs, the common types — iPaaS, ESB, message brokers — and the trade-offs involved.
- Comparisons Custom ERP Integration vs. Off-the-Shelf Connectors Compare building a custom ecommerce-ERP integration with buying a prebuilt connector — fit, cost over time, flexibility, support, and the questions to ask vendors.
- Guides Shopify ERP Integration Architecture: A Practical Guide The components of a dependable Shopify-to-ERP integration — receivers, queues, workers, outbox, reconciliation, and monitoring — and when to use each pattern.
- Guides How to Estimate the Cost of an Ecommerce ERP Integration A structured method for estimating ecommerce-ERP integration effort and cost — workflow scoping, complexity drivers, ERP readiness, testing, and ongoing operating costs.
- Tools Integration Architecture Planner Get a general architecture recommendation based on your systems and workflows.