ERP integration middleware in NZ: what it actually is and when you need it

The word "middleware" appears in almost every conversation about ERP integration — and it almost never means the same thing twice. Sometimes it refers to a dedicated integration platform (iPaaS). Sometimes it means a custom sync layer built for a specific project. Sometimes it just means "the thing that connects our ERP to everything else." The ambiguity matters because choosing the wrong integration architecture is a reliable source of unexpected cost, maintenance overhead, and integrations that quietly break.

This guide is for NZ businesses planning to connect an ERP system — Accredo, MYOB Exo, MYOB Acumatica, CSB-System, Pronto Xi, SAP, NetSuite, or similar — to one or more other systems: a B2B ordering portal, a 3PL, a warehouse management system, a reporting platform, or a customer-facing application. It covers what the three main integration architecture options actually are, when each one is appropriate, and the NZ-specific context that generic middleware guides leave out.

Three integration architectures — and what each one actually means

Most integration discussions collapse into "do we need middleware?" without first agreeing on what the options are. There are three distinct architectures, and they are not interchangeable.

Native ERP connectors. Many ERP vendors, and many target systems, provide pre-built connectors for common integration pairs. If your ERP vendor supports a native connector to the system you want to connect — and that connector handles the data flows you actually need — this is the cheapest and lowest-maintenance option. The catch is that native connectors are built for common cases. If your pricing model, workflow, or data structure is non-standard, the native connector will not cover it, and the workarounds become worse than building a custom integration from the start.

Custom integration layer. A custom integration is built point-to-point: logic written specifically for the connection between two systems. It can implement exactly the business rules your integration requires, handle the specific data formats your ERP uses, and manage the edge cases that a general-purpose platform would not handle correctly. A custom integration layer is the right choice when the integration is complex, contains unique business logic, or connects a combination of systems that no pre-built connector addresses. The trade-off is that it does not scale horizontally: the fourth or fifth bespoke integration becomes harder to monitor and maintain as a set.

Middleware or iPaaS platform. A middleware platform — tools like MuleSoft, Boomi, Workato, or Celigo — sits above individual integrations and manages data routing, transformation, queuing, and error handling across multiple connected systems. Its value is centralisation: instead of each integration being its own bespoke system, all data flows are visible and managed in one place. The trade-off is overhead: middleware platforms require configuration, maintenance, and often licensing costs that only justify themselves at a certain integration volume and pattern.

When middleware earns its overhead

Middleware is not inherently better than a custom integration layer — it is better under specific conditions. The conditions where middleware earns its overhead:

• You have more than four or five integrations from the same ERP source. At that volume, centralised monitoring and a consistent data model pay off. Managing four separate custom integration scripts is manageable; managing twelve is not.
• The integration pattern repeats. If the same data — inventory levels, for example — needs to flow to a B2B portal, a 3PL system, and a reporting platform, middleware handles the fan-out cleanly. A set of three bespoke integrations doing the same thing from the same source is unnecessary duplication.
• Multiple teams own different endpoints. When the team managing the ERP integration is different from the team managing the 3PL integration, centralised visibility matters. Without it, diagnosing which integration failed when an order does not appear in the right place requires checking each system independently.
• You need robust retry and dead-letter handling. Building retry logic, error queuing, and alerting into every custom integration is repetitive and inconsistent. Middleware handles it once, consistently, across all flows.

When middleware is overkill: one or two specific integrations with complex business logic, tight real-time coupling where both systems need to confirm data in the same transaction, or when the integration is so specific that a general-purpose platform adds configuration complexity without adding capability.

The NZ on-premises ERP complication

Generic middleware guides assume cloud-to-cloud integrations. For many NZ businesses, that assumption is wrong. Accredo, MYOB Exo, CSB-System, and Pronto Xi are commonly deployed on-premises — on a server inside the business's network, not accessible from the public internet.

This creates an architectural step that middleware platforms do not solve on their own: getting data from inside the business's network to a cloud integration layer. The approaches are:

• Sync agent. A lightweight process running inside the business network that reads from the ERP database or file exports and pushes data outbound to the integration layer. This is the most common approach for on-premises ERPs. The agent needs to be monitored, kept running, and updated when the ERP changes.
• ERP API layer. Accredo provides a REST API that supports read and write operations for common data objects. MYOB Exo has more limited API support. CSB-System integrations typically go via direct database access or file-based exchange. The API layer, where it exists, is more maintainable than database-level access — but not all operations are available through it.
• File-based exchange. Some on-premises ERPs support scheduled file exports (CSV, XML) that an integration layer picks up. This is reliable for non-time-critical flows — end-of-day inventory sync, batch order import — but cannot support real-time or near-real-time data flows.

Whatever middleware platform sits above these, the on-prem bridge layer needs its own uptime, monitoring, and maintenance plan. Middleware that does not account for the bridge will fail silently when the sync agent stops, the ERP database schema changes, or the network connection drops.

Synchronous vs asynchronous: where integrations most commonly break

One of the most consequential integration design decisions is whether the connection between two systems is synchronous — each transaction waits for a response — or asynchronous, with a queue absorbing the message and delivering it when the receiving system is ready.

For on-premises ERP integrations, asynchronous queuing is almost always the right default for non-time-critical data flows. A B2B portal that calls Accredo synchronously at the moment a customer places an order means: if Accredo is temporarily unreachable (maintenance, VPN issue, server restart), the customer's order submission fails. With an async queue, the portal accepts the order, writes it to the queue, and the integration layer delivers it to the ERP when the connection is available.

There are cases where synchronous response is genuinely required: a real-time stock confirmation at checkout, or a credit limit check before accepting an order. These should be identified explicitly in the integration design — not assumed to be the default for all flows. Mixing synchronous and asynchronous patterns in the same integration layer is normal; the risk is making everything synchronous because it is simpler to think about, and then discovering the availability implications only after go-live.

Four questions to answer before choosing an architecture

The right integration architecture depends on your specific situation. Four questions that sharpen the choice:

1. How many integrations will you run from the same ERP source, now and over the next three years? Two integrations and a custom layer is fine. Eight integrations and a custom layer is a maintenance problem.
2. Does your ERP have a supported API, or will the integration read from the database or from file exports? Database-level access is fragile across ERP version upgrades. An API-based integration is more maintainable but only works where the ERP vendor supports it.
3. Who will maintain the integration infrastructure? A middleware platform requires someone to own it — configuration, monitoring, upgrades. If that is your development partner, factor the ongoing cost into the total. If it is your internal team, be honest about whether that capability exists.
4. Is the integration logic bespoke or repeatable? Bespoke logic — pricing resolution that follows your specific hierarchy, custom workflow rules, unusual data transformations — belongs in a custom integration where the logic is explicit and testable. Repeatable logic — routing the same data to multiple endpoints, standard format transformation — is where middleware adds value.

The architecture decision shapes the project, not just the technology

Integration architecture is not a technology decision made in isolation — it is a project decision that affects timelines, maintenance costs, and what happens when something breaks in production. Choosing a middleware platform because it sounds more professional, or defaulting to bespoke integrations because they feel more controllable, without reasoning through the specific situation, produces integrations that are either over-engineered or under-built for what they need to do.

If your business is planning to connect an ERP system to a B2B portal, warehouse system, or other operational platform, the replace vs integrate decision is usually the question that comes before the architecture question. For businesses that are clear on integration and want to understand what a project scope looks like, the custom software vs SaaS post covers the ownership economics. The Zeabyte integrations page covers the specific ERP and platform connections we build and maintain — Accredo, MYOB Exo, MYOB Acumatica, CSB-System, Pronto Xi, SAP, NetSuite, Xero, and more than twenty others. If you want to talk through what the right architecture looks like for your specific environment, reach out to the team — we build custom ERP and operational software for established NZ businesses and have designed integration layers for a wide range of on-premises and cloud ERP environments.