Acquisition, new channel or ERP migration: why the foundation beneath your integrations matters

Does this sound familiar? Tens of thousands of products, a dozen or so key accounts with their own price agreements, a webshop you run yourself and a few larger customers who would rather have a direct system integration. Last year you acquired a competitor that runs on a different ERP. And now marketing wants a separate webshop for one segment as well.

Each step is manageable on its own. Together, though, they feel like a string of separate projects, with the same questions every time: which data goes where, who is allowed to see what, and what happens when something changes?

That is not the exception. It is the day-to-day reality of mid-sized and large wholesalers. And the root of the problem is almost always the same: not the number of systems, but the lack of a foundation that connects them.

Why point-to-point integrations do not scale

An integration links two systems. That works well, until one of them changes. A webshop that talks directly to Exact Globe stops working the moment you move to AFAS. Every integration is in effect a contract between two systems, and that contract lapses at the first major change.

With one webshop, that is manageable. With five channels, two entities and a handful of customer integrations, it becomes a web of dependencies. You make every change several times, you build every new integration several times, and costs rise without the value growing in step.

What a foundation does differently

A foundation is a central layer between your ERP and the outside world. Systems no longer connect to each other, but to that one layer. In the landscapes we orchestrate, PLGGR | HUB is that central connection layer. As a result, four things change fundamentally.

Several entities under one layer. A Dutch and a Belgian entity, two brands or a recent acquisition: each keeps its own connection, but what goes out is controlled in one place. You set up a new webshop once, even when it draws data from several entities.

An ERP migration becomes a configuration change. Once data is in the central layer, it is standardised. What sits behind it is no longer visible to your webshop, your customer portal or your feeds. Move to a different ERP and only the connection at the back changes. Everything else stays in place.

Data moves with every change. Traditional integrations rely on scheduled exports, often once a night, so external systems always work from an outdated picture. A central layer that actively passes changes on narrows the gap between what you know internally and what your customer sees.

Access is a setting, not a matter of trust. A supplier sees only their own products, a customer only their range and contract prices, a logistics partner only stock levels. You set this per relationship, and you revoke it without the rest of your landscape noticing.

Where orchestration makes the difference

A foundation is a precondition, not a guarantee. It only works when someone decides what goes on it, in what order and on what terms. That is where our work comes in. We always start from the business goal and work in four layers.

1. Insight. We map your business model, your growth path and the bottlenecks. Which systems lead, and which data flows cost the most time today?
2. Functional design. We turn that into a design in which data sources, systems and workflows connect logically.
3. Delivery. We build the integrations, interfaces and workflows, scalable and manageable.
4. Continuity. A dedicated team stays responsible for support and further development, also as your landscape keeps growing.

The acquisition, step by step

An example to make this concrete. A wholesaler acquires a company in the same sector that runs on a different ERP.

Without a foundation, there are two routes, and both are heavy. You rebuild every integration for the new entity, or you make that entity move to your ERP first. Either way it takes months, just when the synergies are needed.

With a central layer, it looks different. The new entity joins as an additional entity, with its own connection to its own ERP. The existing webshop, customer portal and feeds can then show its data too, filtered and routed the way you set it up. An order from Belgium goes to the Belgian entity, and product data from both systems comes together in one catalogue. Whether the new entity later moves to your ERP is a decision you can take in your own time.

Frequently asked questions

Do you have to move to one ERP straight after an acquisition?
No. With a central connection layer, several ERP systems can run side by side while your channels present them as one whole. Whether and when you consolidate is a business decision, not something your integrations force on you.

What is the difference between an integration and an integration platform?
An integration links two systems directly. An integration platform is a central layer that every system connects to, so a change in one system no longer disrupts all your other connections.

How long does it take to add a new channel?
That depends on the channel and on your data. The difference from point-to-point integrations is that you do not start from scratch: the data, the access rules and the connection to your ERP are already in place.

Why does Utilize work with PLGGR?
Utilize orchestrates the landscape, PLGGR provides the platform for product data, integrations and order entry. That brings design and technology together, without you having to coordinate two parties yourself.

Further reading

Want to go deeper into the technology behind such a foundation? The whitepaper from our partner PLGGR explains how the central layer is built, from access and data distribution to multiple entities and AI.