Women in Orange BG

Systems and Integration

Systems and Integration

You Bought the Company. Your Systems Didn't Get the Memo.

You Bought the Company. Your Systems Didn't Get the Memo.

After a food distribution acquisition, the deal closes in months but the systems take years. A practical guide to getting one view of inventory, customers, and lots across two operations.

After a food distribution acquisition, the deal closes in months but the systems take years. A practical guide to getting one view of inventory, customers, and lots across two operations.

Date:

Author:

Sameer Shaik

The five ways two systems quietly cost you money

The deal closed. The press release went out. Everyone shook hands.

Then Monday came, and the operation woke up with two ERPs, two warehouse systems, two item masters, and one set of customers who expect the combined company to act like one business.

In food distribution, acquisitions are how growth happens right now. Margin pressure, tariff churn, and a tight labor market are pushing consolidation across the industry. But the integration work that makes an acquisition actually pay off almost never gets the attention the deal itself got. The lawyers and bankers leave. The systems problem stays.

Here's what that problem actually looks like on the ground, and what to do about it.

The same product now has two identities: Our legacy operation calls it item 40218. The acquired company calls it PRD-1173. It's the same case of product from the same supplier. Until those identifiers are mapped, you can't see combined inventory, combined purchasing volume, or combined sales for a single product. Multiply that by a few thousand SKUs and you have the real reason nobody can answer "how much of this do we have across both facilities" without a phone call.

Purchasing leverage evaporates in the gap: One of the standard justifications for the deal was buying power. But if supplier spend lives in two systems with two vendor masters, nobody can see total volume with any given supplier. The leverage exists on paper and nowhere else. We've seen the combined-spend report take a week to build by hand, once a quarter, which means it never drives an actual negotiation.

Shared customers see the seams: The customer who bought from both companies now gets two invoices, two pricing structures, and two delivery schedules from what they were told is one business. Sales wants a single view of that account. Finance wants a single receivable. Neither system can give it to them, so account managers stitch it together in spreadsheets, and the customer experience the acquisition was supposed to improve gets worse for a year.

A recall now spans two systems: This is the one that keeps quality managers up at night. A supplier issues a recall on an ingredient that both facilities received. Your legacy system can trace its lots one way. The acquired system traces them another way, with different lot number formats and different receiving practices. The 24-hour clock on a traceability request doesn't pause because you're mid-integration. If you sell to major retailers, their traceability requirements don't pause either.

Month-end becomes a manual consolidation project: Finance closes two sets of books, then merges them in a spreadsheet to see the combined business. Every number leadership looks at is days old and hand-built. Decisions that should take a morning wait for the consolidation.

None of this shows up in the deal model. All of it shows up in the first year of operating the combined company.

The trap: rip and replace as the first move

The instinctive answer is to migrate everyone onto one ERP immediately. Sometimes that's right eventually. As a first move, it's usually the most expensive and highest-risk option on the table.

A full ERP migration in a food distribution environment routinely runs twelve to eighteen months, consumes your best operations people, and puts daily order flow at risk during cutover. Doing it while the two organizations are still learning each other's processes compounds the risk. The migrations that go badly are almost always the ones that started before anyone understood what the acquired system actually did all day, including the parts that lived in one person's head and a folder of spreadsheets.

There's also a quieter risk: the acquired company's system often encodes real operational knowledge. Pricing logic, customer delivery quirks, supplier lead time buffers. Rip it out too fast and that knowledge leaves with it, usually around the same time the people who held it decide to leave too.

The bridge: one view first, one system later

The pattern that works, in our experience, sequences the problem instead of attacking it all at once.

Start with a mapped item master: Before anything else, build the crosswalk between the two product catalogs, as a governed dataset rather than a spreadsheet. Every legacy item mapped to its counterpart, with supplier codes, GTINs, and customer item numbers attached. This single artifact unlocks combined inventory visibility, combined purchasing reports, and clean traceability queries. It's weeks of unglamorous work and it pays for itself faster than anything else on this list.

Then a read-only reporting layer across both systems: You don't need the systems merged to see the business as one. A reporting layer that pulls from both ERPs daily, keyed on the mapped item and customer masters, gives leadership combined inventory, sales, and supplier spend without touching either system's daily operation. Low risk, because nothing writes back. High value, because the month-end spreadsheet consolidation dies the week it goes live.

Then targeted integration where the pain is sharpest: Maybe that's a shared order feed for overlapping customers. Maybe it's lot data flowing to one traceability view so a recall query spans both facilities. These are surgical builds, not a platform migration, and each one retires a specific manual process.

Then, and only then, decide the end state: With a year of combined visibility behind you, the eventual ERP decision gets made with real data about how the two operations actually work. Some companies consolidate. Some keep two systems under one reporting layer indefinitely, and that's a legitimate answer too. The point is that it becomes a choice rather than a gamble.

The test worth running this week

If you've acquired in the last two years, or you're about to, ask one question: can anyone produce combined inventory for your top twenty products, across all facilities, in under an hour, without a phone call?

If yes, your integration is further along than most. If no, that's the gap, and it's costing you in purchasing leverage, customer experience, and recall readiness every week it stays open.

The acquisition created the value on paper. The systems work is what collects it.

Talk to an engineer

(Article)

(Article)

What kind of companies does Platsera work with?

We've outgrown our current software. What's the first step?

Do you only advise, or do you actually build?

How big a project do we have to commit to?

Can you work with the systems we already have?

How do we get started?

What kind of companies does Platsera work with?

We've outgrown our current software. What's the first step?

Do you only advise, or do you actually build?

How big a project do we have to commit to?

Can you work with the systems we already have?

How do we get started?

What kind of companies does Platsera work with?

We've outgrown our current software. What's the first step?

Do you only advise, or do you actually build?

How big a project do we have to commit to?

Can you work with the systems we already have?

How do we get started?