After a Merger: Consolidating Two Companies' Spreadsheets and Tools

The deal closed on a Friday. On Monday, leadership announced “one company, one way of working”. By Wednesday, you discovered your side tracks orders in an internal app with a tidy workflow, while the acquired company runs the same process from a shared workbook with 31 tabs, a macro nobody understands and one person called Priya who knows how it all fits together.

Post-merger consolidation is the multi-team merge from Merging Spreadsheets From Multiple Teams Into One System, scaled up and with more at stake. Two cultures, two sets of customers, nervous staff, and an executive team expecting synergies by next quarter. This post covers how to approach it without stopping either business from functioning.

First, do no harm

The most important rule in the first 60 days: do not break anything that works. Both companies were trading successfully before the deal. Their processes, however untidy, are serving customers today.

Resist the urge to consolidate quickly for the sake of a slide in a board deck. Freeze major changes to customer-facing processes on both sides until you understand them. The cost of a botched order system during a merger is not just operational. It is the customers who were already wondering whether the new owner would be worse.

Map both landscapes side by side

You need an inventory of each company’s processes and the tools that run them. Who Owns This Sheet? Mapping the Shadow Processes in Your Company gives the method; apply it to both organisations, with a person from each side doing the interviews together.

Then line them up:

This gives you three categories: processes both companies run (consolidate eventually), processes only one runs (keep, and decide later whether to extend), and processes that look the same but are not. The last group is the dangerous one. Company B’s “orders” might include repeat subscriptions that Company A has never handled.

Process First, Tool Second: Documenting a Workflow Before You Build It applies here. Document each overlapping process from both sides before comparing tools.

Choosing the surviving system

For each overlapping process, someone will have to decide which system survives, or whether neither does. This is where politics is most intense, because the losing side often hears “your way was worse”.

Make the choice against criteria agreed in advance, not by default to whichever company did the acquiring. A short scorecard helps:

• Fit: Does it handle both companies’ versions of the process, including the awkward cases?
• Data quality: Which system has cleaner, more complete records?
• Scale: Will it cope with the combined volume and users?
• Cost: What are the licences and maintenance for the combined headcount? Budgeting for Internal Tools: Licences, Build Time and the Costs After Launch covers the full picture.
• Risk: Does it depend on one person, a macro or an unsupported add-on?
• Exit: Can you get the data out if you need to? Backups, Exports and Exit Plans: Protecting Your Data in Someone Else’s Cloud has the questions.

Sometimes the honest answer is that neither system fits the combined business, and a merger is a reasonable moment to build something new. Buy, Configure, or Build? A Decision Framework for Internal Tooling helps there. Be careful, though: building new during a merger adds a project to an already overloaded period.

Publish the scorecard and the decision. People accept outcomes more readily when they can see the reasoning.

Sequencing the migration

You cannot move everything at once, and you should not try. Order the work by a mix of value and risk:

1. Shared reference data first. A single customer list, product catalogue and supplier list, with agreed IDs. Nearly every other process depends on these. Unique IDs: The Boring Field That Saves Your Migration matters enormously here, because both companies have their own ID schemes and some customers bought from both.
2. Internal back-office processes next, such as expenses, onboarding and asset registers. Lower customer risk, and early wins build confidence.
3. Customer-facing processes last, once the reference data is stable and the teams have practised migrating something less critical.

Run old and new in parallel for each move, with a clear source-of-truth date, as described in How to Run the Old Sheet and New Tool in Parallel (Without Losing Your Mind). Use Migration Day Checklist: Retiring a Business-Critical Spreadsheet for each cutover.

Protect the knowledge before people leave

Mergers cause departures, planned and unplanned. Priya, who understands the 31-tab workbook, may already be updating her CV.

Get the knowledge out early. Single Point of Failure: Getting Process Knowledge Out of One Person’s Head describes interviewing the expert, documenting the rules, and testing with someone else at the wheel. Do this in the first month, before anyone has a reason to leave, and treat the people who hold this knowledge as critical to the integration. Recognise their contribution visibly.

Keep both businesses running

While consolidation is underway, you are effectively operating two companies’ processes plus a migration project. A few things keep it manageable:

• A single integration backlog, owned by one person, so requests from both sides are visible and prioritised together.
• A short weekly update to staff on what is changing, what is not, and when. Silence breeds rumours.
• Temporary bridges where needed. If the sales teams must see each other’s customers before the CRMs are merged, a simple read-only sync or shared report may be worth building and throwing away later.
• A realistic timeline. A mid-sized merger can take 12 to 24 months to consolidate tooling fully. Say that early rather than missing a six-month promise.

Where to start this week

1. Agree a freeze on major changes to customer-facing processes in both companies until the inventory is done.
2. Pair one person from each company to begin the side-by-side process inventory.
3. Identify the three or four people on each side whose departure would leave a process unexplained, and schedule knowledge-capture sessions with them.
4. Draft the scorecard criteria for choosing surviving systems and get leadership to agree them before any specific decision is made.