If you are switching ERP or connecting many suppliers, do not leave the interfaces inside the ERP core. You will build the same connections twice — and live data exchange becomes the cutover risk.
How to connect systems, which path fits which case, and how to judge cost already has a methods guide. This article takes the next step. It answers the architecture question before you switch: where should interfaces live so the core stays stable?
The answer is an integration layer outside the ERP. Middleware as a Service puts that layer in place before the system change. Suppliers, carriers and trading partners do not notice the switch. The ERP stays the system for orders, stock and finance — not the routing desk for every mapping.
That is what owners and managing directors want when they refuse a second IT construction site in-house. It is also what IT leads want when they keep the core clean while the partner network keeps running.
Middleware as a Service keeps connections outside the ERP
Middleware as a Service is the integration layer between your ERP and every connected system — designed, run and monitored as an ongoing service.
Three models sit on the table. They look similar on the first connection. They diverge as soon as systems, partners or the ERP itself change.
- Point-to-point connects two systems directly. That is fast for a clear 1:1 case. Every extra application needs another line. Logic is scattered. Nobody has the picture when a file stalls.
- A classic integration project builds mappings and hands them over. Operations then sit with you. New suppliers, format changes and failures hit the same internal team again.
- Middleware as a Service builds the same layer — and keeps running it. Monitoring, exception handling and onboarding of new partners stay in one place. iPaaS names the platform category: an integration platform as a service. Middleware as a Service means platform plus ongoing operations.
You license the Lobster Data Platform from Lobster. We take on architecture, profiles, mappings and the managed service.
The difference does not show at kick-off. It shows in month twelve: a new carrier, a changed IDoc, a second warehouse. In a project model you raise a ticket and wait for capacity. In a service model that work is part of operations.
Every direct interface inside the ERP turns the next update into a risk
Every direct interface inside the ERP raises maintenance work and turns the next update into a risk.
The ERP runs orders, stock and postings. Once it also translates formats, speaks partner protocols and catches carrier-file errors, every release becomes a trial. One field change in the new cloud ERP does not break a single connection. It breaks many.
Point-to-point does not grow in a straight line. The number of connections follows n(n−1)/2. Three systems need three lines. Five systems need ten. Eight systems need 28. Each line has its own mapping, its own tests and its own owner.
| Systems | Direct connections | What that means for the ERP core |
|---|---|---|
| 3 | 3 | Manageable. One direct line can still be acceptable. |
| 5 | 10 | Maintenance and failure patterns spread. Updates cost more. |
| 8 | 28 | The core now carries a partner network. The next ERP switch hits all 28 lines. |
The rule of thumb from the methods guide still holds: from three systems onwards, middleware usually pays off. It holds even more tightly when an ERP switch is planned or the supplier network is growing. System count alone is then not the measure. The question is whether the core should absorb every partner change.
A move to the cloud, a version jump or a second ERP at another site does not change this logic. Whether the target is SAP Cloud, Microsoft Dynamics 365 or another system: partners still speak EDIFACT, VDA, IDoc, XML or JSON. The new ERP often speaks differently. Without a layer you translate the same network a second time.
Ownership follows the same split. If the logic sits in the ERP, the business team, the ERP partner and internal IT share every failure. If it sits in the layer, you see mapping, protocol and timestamp in one place. That shortens analysis. It also protects the core from quick fixes nobody documents.
Build the integration layer before cutover
Build the integration layer before cutover. Then data exchange keeps running while the ERP changes.
Many migration programmes treat interfaces as leftover work in go-live week. That is the expensive path. Suppliers still send orders and despatch advices. Carriers still report status. The shop or WMS still expects stock. If those flows are rebuilt only with the new ERP, operations stand on two building sites on cutover day.
The better sequence splits the questions. The layer comes first. The ERP changes after that. Partner endpoints stay the same.
- Inventory: which connections are critical — suppliers, carriers, WMS, shop, finance? Which formats, which cadence, who owns the record?
- Build the layer and move existing flows onto it. The ERP hangs off one connection only.
- Dual run: legacy ERP and new ERP share the same layer until the data matches.
- Cut over the ERP connection only. Partners send and receive as before.
- Stabilise and keep operating the layer. New partners join there, not in the core.
The inventory sets the scope. Do not list systems only. List documents: purchase order, order acknowledgement, despatch advice, invoice, stock movement, shipment status. Note direction, cadence and what happens when a file is missing. What is business-critical goes on the layer first. The rest follows without blocking cutover.
In the dual run you check the same document on both sides. Do quantity, partner number and time window match? If a field drifts, you fix the mapping in the layer — not the processes in the new ERP. Only when the sample holds across several days do you switch the ERP connection.
What suppliers notice decides the risk. Same address. Same format. Same cadence. The switch stays internal. You test that before cutover, not after.
One line on the market, not on your project plan: mainstream maintenance for SAP Business Suite 7 / ECC ends on 31 December 2027. Anyone still moving should not put the interface question behind the licence question. The same applies to every other ERP switch that has no public deadline.
New suppliers connect to the middleware, not to the ERP
New suppliers and carriers connect to the middleware, not to the ERP.
A growing partner network is the most common reason a stable ERP turns noisy. Each new supplier brings a format, a protocol and a test cycle. If that work sits in the ERP, risk grows with every connection. If it sits in the layer, the core stays unchanged.
Onboarding follows a fixed path. You agree documents and cadence. The middleware translates into the structure the ERP expects. Tests run against the layer. Go-live changes one connection — not the core system.
EDI and API belong in the same layer. Suppliers often send EDIFACT or VDA. Carriers and shops speak REST, SFTP or AS2. The ERP should not have to tell those worlds apart. The layer accepts both and delivers a stable structure to the core.
The same applies to internal systems beside the ERP: WMS, TMS, PIM or webshop. Each of them can hang off the layer. None of them needs its own point-to-point line into the core just because a new module goes live.
For owners and managing directors that means the supplier network can grow without stretching the ERP programme. Monitoring sits in one place. When a file fails, you see it in the layer — not first as a missing order in the ERP.
That also takes load off the ERP project itself. The implementation partner builds the core. The layer holds the market. Both workstreams run in parallel instead of blocking each other in the same week. For a family-owned firm with a lean IT team, that is often the difference between a planned switch and a switch that stops despatch.
A direct line is enough for the 1:1 case — not for the switch
A direct connection is enough for a clear 1:1 case. Once you have several systems, an ERP switch or a supplier network, the logic belongs in the layer.
| Situation | Architecture | Why |
|---|---|---|
| Monthly finance export, one target | Direct | One path, fixed cadence, no partner network. |
| Shop, CRM, WMS and carriers on the ERP | Middleware | Four systems. Central mappings and one monitoring point. |
| ERP switch plus suppliers and carriers | Middleware as a Service | Layer before cutover. Partner endpoints stay. |
A mix is common. A single batch export can stay direct. As soon as partners, formats and a system change land together, you pay for the direct architecture twice: once today, once in the new ERP.
This is not a matter of taste. Count systems, partners and planned switches. If more than one criterion sits above the 1:1 case, the logic belongs in the layer. Then the ERP stays replaceable. The partners stay reachable.
You license Lobster. We run the layer.
You license the Lobster Data Platform from Lobster. We take on architecture, mappings, supplier onboarding and day-to-day operations.
W4 has been in the market since 1994. As a Swiss family business and a certified Lobster Integration Partner and Value Added Reseller, we run the platform as a managed service on the Lobster operating model. In practice that means thousands of profiles under monitoring. New suppliers and carriers are onboarded in a structured way. Your team does not need its own Lobster bench in-house.
Data sits on infrastructure in Switzerland or Germany. Location and compliance stay your decision.
A discovery call does not need a finished specification pack. Useful inputs are the list of connected systems, the critical documents, the planned ERP switch and where operations sit today. From that we draft an architecture sketch and a realistic first scope — not a promise to cover the entire partner network on day one.
What we do and how the start looks is on the Middleware as a Service page. The next step is not a workshop marathon. A technical discovery call clarifies your landscape, the planned ERP switch and a sensible scope for the layer.
Frequently asked questions
What is Middleware as a Service?
Middleware as a Service is the integration layer between the ERP and connected systems, including ongoing operations. You buy the Lobster Data Platform licence from Lobster. We design the architecture, build profiles and mappings, and monitor the data flows.
What happens to interfaces during an ERP migration?
Without a layer you rebuild the connections in the new ERP. With an integration layer the partner endpoint stays the same. You change only the ERP connection into the layer. Suppliers, carriers and trading partners do not notice the system switch.
When does middleware beat point-to-point ERP connections?
A direct line is enough for a clear 1:1 case. From three systems, an ERP switch or a growing supplier network onwards, the logic belongs in middleware. Effort then stops growing inside the core with every new connection.
How do we connect suppliers without touching the ERP each time?
Suppliers connect to the middleware. Mapping, tests and go-live run against the layer. The ERP receives a stable structure and stays decoupled from partner format and protocol changes.
Do we need in-house Lobster specialists?
Not by default. We take on mapping, orchestration, onboarding and support. If your team wants to run part of that itself, we train exactly that part. Operations do not have to hang on a few people in-house.
Where is the data hosted?
On infrastructure in Switzerland or Germany. You keep control of location and compliance. That is part of the setup, not a later add-on question.
Next step: settle the layer before the ERP changes
Interfaces do not belong in the ERP core if you are switching the system or connecting many suppliers. The integration layer comes first. The ERP follows.
How the layer is built and operated ahead of an ERP migration is on the Middleware as a Service page.
Tell us what the current system landscape looks like and which switch you plan. In a technical discovery call we clarify whether Middleware as a Service fits and what the next step is.
.png?width=250&height=250&name=Jonas_Kr%C3%BCttli%20extended%20(1).png)