What the integration category actually looks like in 2026
MuleSoft and Boomi are the two reference iPaaS platforms in the enterprise category. MuleSoft, acquired by Salesforce in 2018, prices the integration workload against the volume of records processed. Boomi prices against the number of API endpoints and connections. Both platforms are mature and the integrator base across the Middle East market is established. Both platforms carry commercial models that compound with the integration footprint the enterprise builds — more records, more endpoints, more cost.
The category has changed in 2026. The newer iPaaS platforms — Celigo, eZintegrations, the broader open-source-and-permissively-licensed ecosystem — compete on pricing transparency, on scalability without the per-endpoint or per-record meter, and on the agentic-integration direction the category leaders are positioning. The agentic-integration story is real. The architecture combines structured integration workflows with AI-driven document intelligence, LLM classification, and multi-agent orchestration for cross-system workflows.
The conversation worth having at the Middle East enterprise is not which iPaaS platform to choose. The conversation is whether the integration substrate should be the enterprise's institutional asset and whether the agentic direction is achievable on infrastructure the enterprise owns.
What the integration substrate actually contains
The integration substrate at a Middle East enterprise covers four structural layers.
The protocol-and-transport layer. The point-to-point integrations, the API gateways, the event-streaming infrastructure, the file-transfer surfaces, the EDI exchange handling, the broader middleware that moves data between systems. The iPaaS products handle each of these competently. The protocol-and-transport work is the substrate, not the value.
The structured-workflow layer. The integration flows that handle the typical enterprise-system handoffs — order-to-cash, procure-to-pay, hire-to-retire, customer-data-synchronisation — run as configured workflows on the iPaaS platform. The configuration carries the business logic the enterprise has refined against the operating reality. The iPaaS product holds the institutional integration knowledge.
The exception-handling layer. The structured workflow runs against the well-defined cases. The exception cases — the data-quality failures, the timing mismatches, the partner-system unavailability, the regulatory-validation failures — require human intervention. The exception-handling workflow at most enterprises is the largest line on the integration team's calendar.
The agentic-integration layer. The cross-system workflow that the agent absorbs. The natural-language data-mapping, the schema-evolution adaptation, the partner-data-format translation, the cross-system business-process orchestration. The category-leading new entrants are competing here. The hyperscaler AI platforms are competing here. The owned-architecture alternative competes here.
What owning the substrate actually looks like
The owned-integration substrate is not another iPaaS purchase. It is the deliberate building of an integration architecture on infrastructure the enterprise operates.
The protocol-and-transport layer runs on open-source-and-permissively-licensed infrastructure. The API gateway — Kong, Tyk, the broader open-API-gateway ecosystem. The event-streaming infrastructure — Kafka, Pulsar, the open-streaming alternatives. The workflow engine — Temporal, Airflow, the broader workflow-orchestration ecosystem.
The structured-workflow layer lives in the enterprise's source-control system. The integration flows are code — TypeScript, Python, whichever language the platform team operates in. The institutional integration knowledge moves into the enterprise's repository.
The exception-handling layer runs against an owned operational dashboard. The exception cases land in a structured queue the integration team works against. The pattern repeats the architecture we run for every workflow surface.
The agentic-integration layer runs against the enterprise's chosen foundation model. The data-mapping agent reads the schema differences between two systems and proposes the mapping. The format-translation agent handles the partner-data-format variations. The orchestration agent coordinates the cross-system workflow against the enterprise's business intent.
The REFORGE sequence
The replacement runs as workflow-led sprints. The iPaaS platform continues to handle the workloads where the replacement has not landed.
Sprint one — the protocol-and-transport substrate. The API gateway, the event bus, the workflow engine stand up on the enterprise's infrastructure. The new integrations land on the new substrate. The existing iPaaS integrations continue to run.
Sprint two — the new-workflow build. The integration flows for the next-cycle work — a new partner connection, a new system rollout, a new business-process integration — are built against the owned substrate rather than against the iPaaS platform.
Sprint three — the strategic-workflow migration. The integration flows that carry the largest business value, the highest commercial cost on the iPaaS platform, or the deepest agentic-direction roadmap migrate to the owned substrate first.
Sprint four — the residual-workflow migration. The remaining integration flows migrate on a fixed cadence. The iPaaS licence at the next renewal reflects the smaller surface area.
The MuleSoft or Boomi relationship continues at the residual scope where the platform earns its place — typically the workflows where the platform's structured-integration accelerators or the partner-connector library justify the licence. The enterprise's commercial leverage at the next renewal is real.
The Middle East dimension
Three dimensions matter at a Middle East enterprise.
The data-sovereignty posture. The owned substrate runs on the enterprise's chosen infrastructure against the published regulatory expectation.
The partner-integration density. The Middle East enterprise integrates against a complex mix of regional banking partners, government-data-exchange surfaces, supplier-portal connections, and customer-system integrations. The owned substrate respects this through architecture the integration team operates.
The institutional capability. The Middle East platform-engineering talent base operates the open-substrate alternative at the institutional scale that warrants the investment.
The saasinator perspective
The iPaaS platforms are competent at the integration workload. The argument is that the integration substrate is the institutional asset, and the agentic-integration direction is achievable on infrastructure the enterprise owns at materially better economics across the multi-year horizon. The platform-engineering leader who runs the first sprint successfully has changed the institutional default.
What to bring to the diagnostic
Bring the iPaaS deployment scope, the integration-flow inventory, the cost-per-workflow profile, the partner-connection catalogue, and the agentic-integration roadmap the enterprise has been considering. The diagnostic is ten working days. The output is the architecture recommendation, the migration sequence, and the first-quarter scope. Book a diagnostic at /diagnostic.