iPaaS vs point-to-point vs middleware: how to choose

Most mid-market integration estates were never designed. They accumulated. Someone connected the CRM to the ERP because an order had to reach finance. Someone else connected the ecommerce platform because the warehouse needed to pick. A third person connected the warehouse system to a carrier. Each decision was sensible in isolation and made by someone competent, and the aggregate is an estate nobody can draw on a whiteboard.

The cost of that arrives later and indirectly. It shows up as a project estimate that seems disproportionate to the change requested, because the change touches four undocumented connections. It shows up as an ERP upgrade that stalls because nobody knows what depends on a particular interface. It shows up as a report that disagrees with another report for reasons that take two days to trace.

This article is about the strategic decision rather than the individual connection: which integration approach to standardise on, what each one actually costs over its life, and — the question almost nobody asks at selection time — what it costs to leave.

Article 16 in this series applies the same architectural choices specifically to ecommerce order flow. This piece addresses the estate-wide decision.

Why this matters

Integration architecture determines the cost of change, and the cost of change determines how quickly a company can do anything.

A mid-market company will, over five years, typically add or replace several systems — a new ecommerce platform, a warehouse system, a CRM migration, an acquisition bringing its own stack. The integration approach chosen today sets the marginal cost of each of those events. A well-governed platform makes each one a matter of weeks. An undocumented point-to-point estate makes each one a project with an unpredictable estimate.

There is a resilience dimension too. Point-to-point estates concentrate knowledge in individuals, and mid-market companies do not retain those individuals for the life of the integration. When the person who wrote the connection leaves, the connection becomes a black box that everyone routes around rather than through — which is how estates acquire duplicate, contradictory data flows.

And there is an audit dimension that surfaces at inconvenient moments. When a financial figure is questioned, the answer often requires tracing how data reached the ledger. An estate without documented lineage cannot answer that quickly, and "we are not sure how this number got here" is an unpleasant sentence in front of an auditor.

At a glance: the three approaches over their life

The row clients examine least and regret most is cost to exit. Logic implemented inside a platform is expressed in that platform's constructs, and moving it means re-implementing rather than migrating. This is not an argument against platforms — it is an argument for keeping a plain-language record of what each flow does, independent of the tool implementing it.

What works, and what to be honest about

What works:

Standardising on one approach, with documented exceptions. The problem in most estates is not the approach chosen — it is that three approaches coexist without anyone deciding. Pick one as default and require justification for departures.

Naming an owner before the first flow is built. Integration estates degrade through accumulation of undocumented flows. An owner with authority over naming, documentation and review prevents that. This is the single highest-value governance decision and it costs nothing.

Documenting each flow independently of the tool. For every flow: source, target, objects, direction, trigger, transformation rules in plain language, error behaviour, owner. This is what makes the estate comprehensible to the next person, survivable when the platform changes, and answerable to an auditor.

Centralised error handling with agent-based triage. Consistent, visible failure handling across all flows is one of the strongest arguments for a platform. An agent classifying failures, resolving mechanical ones and routing the rest with context is what makes it operationally sustainable rather than a queue nobody reads.

Periodic review to retire dead flows. Estates accumulate flows serving processes that no longer exist. An annual review, retiring what is unused, keeps the estate proportionate to the business.

What to be honest about:

A platform will not save a company that will not govern it. Ungoverned platforms become point-to-point estates with a licence fee — the same undocumented logic, in a nicer interface. The discipline is the product; the platform only makes the discipline cheaper.

Volume-based pricing can surprise you. Platform costs scale with transaction volume, and ecommerce and marketplace traffic scales unpredictably. Model your costs at three times current volume before committing, and understand what counts as a billable transaction.

Traditional middleware is usually the wrong answer at mid-market scale. It is capable, and it demands specialist skills that mid-market companies struggle to hire, retain or replace. The exception is a company with an existing platform, existing skills and a substantial estate already built on it.

Point-to-point is not always wrong. For a company with two systems and no plan to add more, a well-documented direct connection is proportionate. The failure is not choosing it — it is choosing it repeatedly.

Migration is real work, and delay makes it worse. Moving an existing estate onto a platform means running in parallel, reconciling, and cutting over per flow. It is a genuine project. It is also cheaper this year than next, because the estate is still growing.

Decision framework: choosing and governing

Run in order. Stop at the first match.

1. Can you draw your current integration estate — every flow, source to target?
If not, produce that inventory first. It usually takes one to two weeks and routinely finds flows nobody knew existed, plus at least one duplicate. Every subsequent decision depends on knowing what you have.

2. Do you have exactly two systems needing integration, with no plans to add more?
A documented point-to-point connection is proportionate. Document it externally and set a review trigger for when a third system appears.

3. Do you have three or more systems, or a plan to add one within two years?
Standardise on an integration platform. Assign an owner and define documentation standards before the first flow. Most mid-market companies reading this are here.

4. Do you already have substantial middleware and the skills to run it?
Keep it, and govern it. Migrating a functioning, well-staffed middleware estate is rarely worth the disruption. Reassess when the specialist skills become hard to sustain.

5. Are you currently on point-to-point with three or more systems?
Plan a migration, sequenced flow by flow outside peak periods, with parallel running and reconciliation. Start with the flow that breaks most often — the operational relief funds the political capital for the rest.

6. Do you have a platform with no named owner and no documentation standard?
Fix governance before adding flows. You are accumulating the problem you bought the platform to avoid, and the cost of retrofitting documentation rises monthly.

7. Estate governed, documented and still expensive to change?
The constraint is likely in the systems rather than the integration — an ERP customisation that makes a standard object non-standard, or a system without a usable API. That is an application problem, not an integration one.

Indicative cost and effort

Assumes mid-market transaction volumes and a single ERP instance. Multi-instance or multi-entity estates extend these. Get a quote for a scoped estimate.

Frequently asked questions

How do we compare platform costs when pricing models differ?
Model total cost over three years at your projected volume, not current volume, and establish precisely what counts as a billable unit — a message, a record, a flow execution. Two platforms with similar headline pricing can differ substantially at real volume because of how they count.

Is vendor lock-in a reason to avoid platforms?
It is a reason to mitigate, not to avoid. Keep tool-independent documentation of every flow's business logic and you convert an exit from a reverse-engineering exercise into a re-implementation. The alternative — point-to-point — has its own lock-in, to individual people, which is harder to manage.

Where do agents fit?
On top of any of these approaches, handling exceptions rather than the transport. The integration moves data; the agent handles what happens when the data is wrong, incomplete or unmatched. Selecting a platform on its agent capability is reasonable; expecting an agent to compensate for a poor architectural fit is not.

Should we build our own integration layer?
Almost never at mid-market scale. It is a product-development commitment — monitoring, retry, logging, credential management, versioning — competing for the engineering capacity that should go to your actual business. The exception is a genuinely unusual requirement no platform supports, which is rarer than teams believe.

How do we justify this when nothing is currently broken?
Frame it as cost of change rather than cost of failure. Take the last three projects that touched integration and estimate how much of each went on understanding existing connections. That number is the recurring tax, and it is the honest business case.

How long does it take to actually stand up an iPaaS or sync layer once we've chosen one?
Shorter than most teams budget for, if the choice above is made first. A certified implementation partner — Stacksync, for real-time bidirectional sync specifically — can typically have a first integration live in a matter of weeks. What takes longer is everything this article is actually about: agreeing the pattern, mapping the data model, and deciding who owns exceptions. Pick the platform after that work, not before it, and the deployment itself stops being the bottleneck.

Closing — Next steps

Integration strategy is a decision about the marginal cost of every future system change, made before you know what those changes will be. That is why the criteria that matter are not features but governance: who owns it, how it is documented, how failures are handled, and what it costs to leave.

The starting point is the same regardless of which row of the framework you land in: inventory the estate. One to two weeks, and it will find flows nobody remembers, at least one duplicate, and usually the reason a recent project cost more than expected.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, SuiteTalk and integration documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, integration platform research and Magic Quadrant for iPaaS (largely client-access) — https://www.gartner.com
• The Open Group, TOGAF — application and integration architecture guidance — https://www.opengroup.org
• European Commission, VAT in the Digital Age (ViDA) — structured data and e-invoicing implications for integration design — https://taxation-customs.ec.europa.eu
• Atypical Tech engagement experience, mid-market integration estates across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog