Post-Merger Integration Challenges in the First 100 Days

Post-Merger Integration Challenges in the First 100 Days

Post merger integration challenges, in the first 100 days after a mid-market or PE add-on, are duplicate systems that both still close the books, a data migration that is not a file copy, identity and access that still sit with the seller, a key person who can leave with the only mental model, and a sequence that tries to do all of that in the same week.

I write this for the operating partner or the CEO who has a closed deal and a plan that still reads like the model. I build the systems that have to keep running while two companies become one. The first month is not a technology project with a kickoff. It is the company trying to collect cash, pay people, and answer a customer while two stacks both claim to be the truth.

Post-merger integration for mid-market PE portcos is the hub above this page. That page is the operating model: who decides when two systems disagree, and how the company runs while it changes. This page is the spoke under it. It is the five problems I keep finding in the first 100 days, and the mitigation that belongs to each one. I will not retell the hub's framework here.

What are the post merger integration challenges in the first 100 days?

They are operating problems with a technical face. A synergy slide can list "consolidate systems" as one line. The line hides five jobs that fight each other if you start them together.

1. Two systems can both still run the business, and neither is yet allowed to be the one the board trusts.
2. The data you meant to move has two definitions, so a copy makes the disagreement official.
3. The buyer cannot log in as the company. The seller still can.
4. One person knows how the real job works, and the plan assumed they would feel like staying.
5. The sequence does the expensive, visible step first, and breaks a dependent that was quiet.

Each one has a mitigation that is unglamorous. Name something. Put a person on something. Write something down. Move one definition. Turn a system off only after nothing important still drinks from it. The rest of this page is those five, in the order I would rather see them, not in the order a savings schedule prefers.

Duplicate systems

Duplicate systems are the challenge people can see. Two CRMs. Two accounting systems. Two support tools. Two ways to provision a user. Each team can close their own week. The combined company cannot close one number, because "active customer" and "revenue this month" are still local facts.

The mitigation is a survivor and a temporary source, named before a row moves. The survivor is the system the board's number will come from when the window is over. The temporary source is the system that is allowed to answer until then. Both can stay up. They are not equal. Equal is how every meeting re-litigates the model.

I want that pair written on one page a person who missed the close can read. Customer. Billing. The close. Support. Identity. For each, one survivor, one temporary, and the date you will revisit. A date you miss is still better than a date you never set, because a missed date is a decision you can see.

Do not start by killing the largest invoice. The expensive system is often the one three quieter tools still read. Application rationalization during M&A is the sibling for the verbs: keep, migrate, consolidate, or retire, in dependency order. This page does not replace that portfolio call. It only insists you name the survivor before you celebrate a canceled license.

Data migration

A data migration is not a file copy. I say that because the plan almost always draws it as a file copy. Export. Transform. Load. Done by week six. What actually moves is a definition. Customer. Revenue status. SKU. Employee. Location. Contract date. Each of those words already means two things, one on each side of the deal, and both meanings have been reasonable for years.

If you load both into the survivor without picking a winner, you did not integrate the data. You stored the argument, and the next report will pick a side without telling you. Sales will call an account active after a signature. Billing will call it active after an invoice. Finance will wait for recognition. All three can be right inside their own system. Only one can drive the combined number.

The mitigation is one definition per field the board will see, written in a sentence, with a person who can pause the load. Not a mapping spreadsheet with forty columns and no owner. The sentence. "Active means an invoice was paid. A meeting is not active. The owner is this person. The load stops if a row has two statuses." Then move that field. Then the next. A migration that moves every field because the tool can is how a bad definition becomes the history you will defend later.

Identity of the row matters as much as the field. Two customers who are one account, one customer who is two, a product that is a SKU on one side and a bundle on the other. Resolve the ones that hit cash and the close first. Leave the long tail in the temporary system with a label that says it is unresolved, so an agent or a report does not treat it as clean.

Identity and access

Identity and access is the challenge that shows up as a locked door, not as a roadmap item. Multi-factor authentication on a seller's phone. The domain's admin in a personal inbox. A shared login for the accounting system. A contractor who still has production because the project "might need them." On day one the buyer owns the company and cannot operate it. The seller, who may already be gone, still can.

The mitigation is a list, then a cutover of control, then a date. List the systems that touch money, customers, and the close. Accounting, billing, the bank admin, the CRM, payroll, the cloud account, the identity provider, support. For each one, write the current admin, whether the second factor is on a company device, and the date the seller's access ends. Put a named person from the buyer on that admin. Not a shared mailbox. A person.

Do this before you migrate data into a system you do not control. A beautiful load into a tenant whose owner is a personal phone is a gift you cannot revoke. I would rather see a dull week of access cleanup than a heroic migration the buyer cannot administer on Thursday.

Service accounts and integrations are the quiet version of the same problem. A nightly feed from the old billing system into a spreadsheet finance still uses. Nobody's name is on it. Turning the old system off, later, breaks the close in a way the architecture diagram did not show. Write the feed down when you write the admins down. It is the same list.

Key-person risk

Key-person risk is one engineer, one admin, or one analyst who knows how the job is actually done. The revenue report is a query they run, plus two corrections they do by hand. The release is a sequence on their laptop. The customer escalation goes to them because the ticket system is not the real queue. The integration plan has their name on twelve tasks and a hopeful note that they are excited about the combination.

They might stay. The plan cannot require it. A retention conversation is not a mitigation. A mitigation is an artifact a second person has used.

The way I do it is small on purpose. Pick the job that would stop the close or the customer. Sit with the person who knows it. Have someone else run it once, while the first person watches and corrects. Write the corrections into the run, not into a workshop recording nobody will replay. One executed run beats a knowledge-transfer week. Do that in the early part of the 100 days, while the person is still there and still willing to be corrected by reality.

If they leave before the second run happens, you do not have a documentation gap. You have an unknown. Treat it that way. Stop the migration that depended on their private map. Go find the map in the system, with the people who still touch the edges of the job, before you invent a process that feels tidy and is wrong.

Integration sequencing

Sequencing is the challenge that makes the other four worse. The model wants the license savings early, so retirement is week two. The data team wants every object in one load, so definitions get settled by whoever writes the script. Access is "IT's workstream," scheduled after the migration because it did not look like a dependency. The key person is booked into all of it.

The order I trust is the one in the figure, and it is deliberately plain.

Name both systems. Survivor and temporary, for the few processes that touch cash, the customer, and the close. Not the full application catalog. The catalog is the rationalization sibling. The name is what lets everyone else stop debating the source in the hallway.

Fix access. Company admin, company device, a date on the seller. You are about to put the combined company's data somewhere. Control the somewhere first.

Write the key person down, by having a second person run the job. If you skip this, every later date is a wish about someone else's calendar.

One meaning, for the fields the board will see. Move those. Leave the rest labeled as unresolved.

Then retire. After the dependents have a new home. The license line is a result of that order. It is not the order.

All at once is the box with the X. It feels like momentum. It is how a dependent system goes dark, how a bad definition gets a history, and how the only person who knew the correction is now the critical path for three workstreams. A slower week with a named survivor is more integrated than a busy month with two official numbers.

What the first 100 days are actually for

The first 100 days are not a finished platform. I have never seen a mid-market or add-on combination earn a finished platform in that window, and I do not plan for one. The window is for a company that can operate, report one number the board agreed to trust, and not depend on a seller's phone to do either.

That is a smaller promise than the kickoff deck, and it is the one I will stand behind. Customers still get served on the temporary system where the survivor is not ready. Finance can say which definition won. A second person has run the job that used to live in one head. The seller's admin has an end date that already happened, or a date this week that someone owns. Everything else is a later sequence, with an owner, on the hub's operating model.

A CEO guide to the first decisions in post-merger technology integration is the sibling for the person who has to pick the surviving platform and say so out loud. I link to it. I do not rewrite it. The portfolio verbs stay on the rationalization page. The operating model stays on the hub.

If you are still before the wire, do not wait for these challenges to become a schedule you can no longer change. Technical due diligence that catches integration risk before close is the read I want on the file: duplicate systems, access, the key person, and whether the data model can hold the thesis. After close, those are the 100 days. Before close, they are still a choice.

What this page will not do

I will not give you a Gantt chart of every workstream, a synergy percentage, or a story about a deal that "saved" a number I cannot show you. Those are how this subject becomes a pitch. The mitigations above are the work. They are slower than a slogan and faster than a program that tries to boil both companies in a quarter.

I will not pretend the technology is the hard part and the people are a change-management appendix. The technology is two truths and a door you do not hold the key to. The people are the only copy of the correction. Sequence those, or the rest of the plan is a status meeting.

If you already know which system, which door, or which person is the blank, start in chat. I will tell you which of the five is actually first.

Related reading

• Post-merger integration for mid-market PE portcos
• Application rationalization during M&A
• A CEO guide to post-merger technology integration
• Technical due diligence that catches integration risk before close