The deal closes on a date. The technology does not. For months after the announcement, the combined company runs two of almost everything: two ERPs, two help desks, two sets of vendor contracts, two ways of sending a purchase order to a supplier. Everyone knows this is temporary. Almost nobody knows how temporary, and the cost of the overlap rarely makes it into the deal model.
I led the technical cutover on one of these. A merger put 265 locations, three legal entities and more than 3,000 users on one ERP. 130 of those locations came off per-store systems that had each run on their own. The estate also included 35 distribution centres. The deadline was nine months. It was someone else's number, and it held. The conversion landed on time and on budget.
The integration as a whole was not mine to lead. The CEO led it, decisions went to a management committee, and two project leads sat above me. I owned the technology workstream: the ERP conversion and the data centre stand-up. When the system failed at two in the morning, the call came to me. That is the vantage point this piece is written from.
Two of everything costs more than two of anything
The duplication is obvious on the systems list. It is less obvious on the invoices. Each side keeps paying its own vendors until someone gives notice, and each contract has its own notice period, its own pricing basis and its own owner, who may not survive the reorganization.
Some of the overlap is cheap and can sit for a year. Some of it scales with the very thing you are trying to shrink. On that conversion, one supplier-integration vendor charged per store. Every store that moved was still a line on its invoice until the contract changed. I pushed that vendor from a per-store fee to a volume basis and got a one-year commitment in writing. Its pricing model had been built for a business that was about to stop existing.
Support is the overlap people forget. Two organizations means two queues, two escalation paths, and staff on both sides who do not know which one owns a problem. As the seller and the buyer were formally separated, I set up separate support arrangements with the ERP vendor for each organization, so nobody waited in the wrong queue. It was not elegant. It was necessary for as long as both existed.
Why the bridge always lasts longer than planned
Every integration plan has a moment where the old thing is supposed to switch off. That moment moves.
On that conversion, the original plan was to drop a third-party hub that carried electronic orders, ship notices and invoices between the stores and their suppliers. The acquirer had its own direct path. Early on I believed the hub could go. Then it became clear the direct path would not be ready in time, and would not cover every supplier when it was. By my count at the time, more than twenty vendors were at risk. I put that in writing to my boss, and the plan split three ways: the acquirer's path for its own traffic, the old hub as a bridge for everyone else, and manual entry as a short stopgap.
The bridge was the right call. It also meant paying for the old hub longer than the original plan assumed, while the new path was being built and tested. That is the real shape of two of everything. It is not a period of duplication that ends on a date. It is a series of bridges, and each one ends when the replacement works for the last edge case, not the first.
What decided the order
Nobody consolidates everything at once. The order on that conversion came from four questions, and I would use the same four again.
What does the deadline depend on? The ERP conversion was the critical path, and it needed the new data centre, so those came first. Anything the stores did not need to sell and receive on day one waited.
What cannot fail in front of a customer or a supplier? In a retailer that list includes payments, pricing and supplier orders. Those get a bridge and a parallel run, not a weekend cutover and a hope.
What scales with the thing you are shrinking? Per-store and per-user fees grow every month you leave them alone. Those contracts get renegotiated early, even when the system itself stays for a while.
Which notice date comes first? A contract you cannot exit for eighteen months is not a consolidation candidate this quarter, however duplicated it is. A contract with a notice date next month is, even if it is small.
The cost nobody puts in the model
The duplicate contracts are visible. The duplicate work is not. During that conversion my team ran the existing systems and built the new ones at the same time. They were stretched thin, and for some critical systems there was no second person who could fix a problem.
Mid-migration, the system went down on the same day every week, at peak. It took weeks, and specialists from three companies working around the clock, to prove the root cause was a flaw deep in the database. While that work went on, my team wrote a playbook that brought service back in minutes each time it failed. I also started mandatory cross-team training twice a week, because the alternative was one person being the only answer at two in the morning.
None of that shows up as a line item. All of it is part of the price of running two of everything.
How long it really lasts
Longer than the plan. The systems cut over on the deadline. The contracts, support arrangements and bridges trail behind it, each on its own clock. The deadline measures the cutover. It does not measure the end of the overlap, and if nobody owns that second number, it does not end on its own.
So measure the overlap directly. Before close, or as soon after it as you can, list every duplicated system and contract on both sides with its notice date, its pricing basis and one owner. Decide which ones end at cutover, which ones get a bridge, and the date each bridge ends. Put the bridge costs in the integration budget, not in a variance two quarters later.
Building that list and working through it, contract by contract, is what the Contract Renegotiation and Systems Consolidation Program does, including a post-acquisition variant for deals that have just closed.