What lands on the operations desk after a wholesale acquisition
In wholesale, the ERP is the operational core. It holds the customer master, the price agreements, the assortments each customer is allowed to order, and the stock that every order depends on. After an acquisition, all of that exists twice, often structured differently.
Orders keep arriving through both businesses' channels: a B2B portal, EDI from larger customers, and sales reps entering orders by hand. Each channel is wired to its own ERP, and each ERP to its own WMS. Customers who buy from both businesses appear in both systems under different account numbers, and the same product may carry two article numbers and two prices.
A business bought from a larger group comes with a deadline. Under the TSA, the acquired business can use the seller's systems only until a fixed date. Every order, price, and supplier flow has to run somewhere new before then. In a buy-and-build model, that M&A integration work repeats with every deal.
Where does a big-bang ERP consolidation go wrong?
A full move onto the group ERP is usually right in the long run and wrong as a first step. As an end state, one ERP is simpler to run and audit.
The risk sits in the cutover. Every customer-specific price agreement, discount structure, and assortment has to be rebuilt in the target ERP and tested before go-live. In wholesale, a mistake there reaches the customer as a wrong price on an order, a product missing from the portal, or a rejected EDI order.
A TSA deadline compresses that testing into whatever time the seller allows. The migration also leans on the few people who understand both ERPs, the same people needed to keep orders moving. Avoiding that risk starts with what the group needs while both ERPs still run.
What a wholesale group needs while both ERPs keep running
Until ERP consolidation is complete, the two businesses have to work as one wherever customers and the central team can see it. Orders placed through the group's portal must reach the ERP that holds each customer's price agreement. Customer-specific prices and assortments must appear correctly in every ordering channel. Stock from both warehouse systems must add up to one view, and EDI orders must keep arriving in the format each trading partner already uses. If the business was bought from a larger group, all of those flows also have to leave the seller's systems before the TSA ends.
The usual ways of providing that each fall short. Nightly exports and spreadsheets hold only until volume grows. Point-to-point connections between the two ERPs work, but each is custom, depends on its developer, and needs rebuilding when either ERP changes. Building the connections into the target ERP ties them to a migration the group has not finished.
What the group needs is an integration layer: a separate system that sits between the ERPs, WMS, portal, and EDI flows rather than inside any one of them. Both ERPs can then keep running while the business operates as one.
How Alumio supports a wholesale group through ERP consolidation
An iPaaS is a cloud-based, central hub that systems connect to. It transforms each system's data into the format the other systems expect and automates the exchange in real time or on a schedule.
For a wholesale group, how the integration platform is organised matters too. A shared environment lets one business's migration disturb everyone's flows. Separate setups per business leave the group without oversight and force it to rebuild the same connections with each deal.
While integration platforms typically focus on connecting systems and automating the exchange between them, Alumio, a config-first integration platform, has developed a proposition specifically for groups of companies. With Alumio Spaces Core, each company runs its integrations in its own isolated environment, while a central team oversees all of them. For a wholesale acquisition, that comes down to four things:
The acquired business gets its own environment: its ERP, WMS, portal, and EDI flows connect through one of 180+ connectors or a custom connection. A later migration or separation stays inside that environment, away from the rest of the group.
One translation between the businesses: each ERP stays the system of record for its own data. Alumio provides Transformers that map customer accounts, article numbers, and price lists in transit, so orders reach the ERP that holds each customer's price agreement.
Group-wide oversight, entity by entity: the central team sees the status, logs, and monitoring of every entity's integrations in one place. Role-based access, an audit trail, and configuration history show who changed which flow and when, and the platform is ISO 27001 certified.
Shared standards with local flexibility: flows built for this deal become templates for the next acquisition or warehouse location. The mapping can differ per entity or partner while the architecture stays the same, and rollout happens in phases.
The group no longer has to choose between a rushed migration and two businesses that cannot see each other's orders.
Where to start when the acquired business still runs its own ERP
For an Operations Director, connecting now rather than migrating now is often the difference between a smooth first quarter and a stalled one. Customers judge the deal by whether their next order arrives at the right price, and a TSA deadline does not move.
The practical start is the flows customers feel first: orders and customer-specific pricing for shared accounts, then stock. Connect the acquired business in its own environment, and move any flows still on the seller's systems while the TSA runs. On an integration platform like Alumio, integrations typically go live in weeks, not months.
ERP consolidation stays open as a choice. The group can migrate one business at a time without putting the others at risk, or keep two ERPs where they serve different markets well. The next acquisition then connects to an integration layer and templates that already exist.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
