Post-Merger IT Integration: Absorb, Connect, or Leave the Acquired Company Alone
The day a deal closes, the combined company has two email systems, two ERPs, and two different ways of closing the books. Closing happens on one day. Post-merger IT integration takes much much longer, and at a mid-sized company it lands on the same CFO, controller, and IT lead who already run the business full time.
The most important decision comes before any task list. Someone has to decide whether the acquired company's technology gets absorbed onto your systems, connected to them, or left to run on its own. That choice sets the scope, the timeline, and the workload for everything that follows.
What Post-Merger IT Integration Covers
Post-merger IT integration is the work of combining two companies' technology into an environment that serves the combined business. It usually touches six areas:
- Identity, email, and calendars
- Network and security
- ERP and finance
- CRM
- Data and reporting
- The vendor contracts and licenses behind all of it
Not all of it happens right away. Longer-term cleanup, like retiring duplicate applications, belongs on the IT roadmap once the combined company has settled.
Enterprise integrations usually run through an integration office, with IT teams dedicated to the effort for a year or more. A mid-sized acquirer rarely has either. The integration gets carried by a handful of people, sometimes with help from a managed service provider, on top of their normal jobs. That team can't integrate everything at once, so it has to choose what gets combined now, what gets connected, and what gets left alone.
The Three End States
Every acquired company ends up in one of three places, whether anyone decides it on purpose or not.
| End state | What it looks like | When it fits |
|---|---|---|
| Absorb | The acquired company moves onto your ERP, your books, your email, and your sign-in | The deal's value depends on running the two companies as one business |
| Connect | The acquired company keeps its own ERP, and financial, reporting, or customer data flows into yours | Operations differ, or speed matters more than uniformity |
| Standalone | The acquired company runs its own technology and shares only security standards, financial reporting, and access controls | The business is held and measured on its own results |
Larger enterprises formalize the connect option as a two-tier ERP strategy, with a backbone ERP at headquarters and smaller, integrated ERPs at subsidiaries. Their reasoning is that forcing a small subsidiary onto a large corporate system rarely pays for itself. A mid-sized acquirer is in a different position, because its own ERP is often a mid-tier system already. The gap between the two companies is smaller, so absorbing the acquired company is a realistic option.
Even standalone has a floor, because security standards and consolidated financial reporting are needed in every end state. Connecting can go wrong more quietly. Without a named owner and a date to revisit it, connecting becomes permanent by default and the company pays to run two systems for years. It works well as a deliberate choice, not as a decision someone postponed.
Start With Why You Bought the Company
Good M&A IT integration starts from the same place as the deal itself. If the plan is to run the two companies as one business, with shared customers, a shared supply chain, or a single back office, the systems eventually need to come together, which usually means absorbing.
The picture changes when the acquired company is a smaller business added under an existing one and run largely on its own results, a common situation when private equity owners are building a group of companies. Connecting or leaving it standalone is often enough in those cases. And if you bought a product, a team, or a way of working, protect what made it valuable before you change how it runs.
How long the owners plan to keep the business matters too. When private equity owners expect to sell within a few years, the next buyer will look for clean financials and reliable controls, not identical software across every company.
The IT plan also carries real financial weight. Gartner reports that companies expect at least 20% of total M&A cost savings to come from IT, much of it from vendor contracts. When those savings are promised before anyone has looked at what the system changes will take, the integration plan inherits a commitment it can't keep. It's one reason many acquirers connect finance and reporting first, then decide whether full absorption is worth it after the combined business has run together for a few quarters.
Merging Two ERP Systems After an Acquisition
Most layers of the technology can be connected or swapped without much disruption. Email moves, sign-ins get linked, and a CRM decision can wait. The ERP is different because it defines how orders, inventory, and money move through each company, so this is where the end-state decision really gets made.
ERP integration after an acquisition is closer to a new implementation than a data move. The acquired company's processes have to fit a system designed around yours, and some of them won't. Operators tell us again and again that even companies with a mature standard and several acquisitions behind them find each one slower than planned. Some end up partly reimplementing to make the fit work.
The hidden workload in merging two ERP systems is the data. Two charts of accounts have to become one, overlapping customer and vendor records need merging, and items and bills of materials are often structured differently. Someone also has to decide how much history moves and how much stays archived. Doing any of this well takes people who understand both businesses, which is usually the same small group already carrying the rest of the integration.
Connecting the acquired ERP instead is cheaper and faster up front, since its data feeds your reporting while operations keep running as they did. The cost shows up later, in two systems to maintain and two sets of skills to keep.
Whichever path you take, someone has to decide whose process wins when the two companies do the same thing differently. A steering group with clear decision rights keeps that from turning into a weekly negotiation.
One of our clients, a national real estate services organization, grew by acquisition and consolidated more than 120 regional offices into one operating entity with finance standardized on Oracle Cloud. The measurable gain came from the reporting and invoice-processing layer built on that shared platform, which cut invoice processing from about 12 days to about 1.5 days across roughly 20,000 invoices a month. The migration made that possible, but the payoff came from what was built once everyone was on the same system.
What to Integrate First
A post-merger IT integration checklist can run to hundreds of items. For a small team, the order matters more than the length.
- Before close, plan but don't change anything. Integration planning is allowed before a deal closes, but taking control of the other company's operations isn't. When the two companies compete, a separate clean team often handles sensitive information, with deal counsel setting what can be shared. This is also the right time to assess the acquired company's technology.
- On Day One, keep the business running and secure. People need working email and calendars across both companies, plus access to the systems their jobs depend on. Check the acquired environment's security before connecting it to your network, since a connection extends any gaps it has into your own systems.
- In the first 100 days, get one view of the numbers. Aim for combined financials within the first couple of months, even while operations still run on separate systems. Build an inventory of systems and vendor contracts, including renewal dates and licenses that don't transfer, so the end-state decision gets made with real information.
- After that, rationalize everything else. CRM consolidation, reporting tools, and retiring duplicate applications usually go better once the ERP direction is set.
Buying a division of a larger company adds one more item. The seller often keeps providing IT, HR, finance, or payroll services for a set period under a transition services agreement. When that period ends the services stop, so the agreement's end date becomes a hard deadline for everything above.
The People Side of Integration
Systems plans tend to leave out what happens to the people who use them. Someone who knew exactly how to close the month in the old system becomes a beginner again, and their work slows down while they learn. What we hear consistently is that the cutover is followed by a longer stretch of friction, workarounds, and resistance before people trust the new system.
That resistance is rarely stubbornness. In an acquisition the new system belongs to the company that bought them, so learning it carries the weight of everything else that changed, from new owners to new reporting lines. Losing their competence at the same time feels like losing control.
A few practices make the transition easier. Naming owners from the acquired company for the processes they know best gives them a stake in the result. Training people on their own daily work, rather than just mandate based on how the parent company does things, shortens the learning curve. It also helps to plan for productivity to dip before it recovers, so a slow first quarter doesn't get mistaken for a failed migration. Most of all, keep the people who know where the workarounds live. When the acquired company's controller or IT lead leaves mid-migration, a data problem becomes a guessing problem, a pattern behind many ERP and CRM implementations that struggle.
How Long It Really Takes
It almost always takes longer than leadership expects. Many consulting firms estimate that finance integration may take six to twelve months, while full operational harmonization can run past eighteen months, with process alignment mattering more than how fast the data moves. This aligns with our own full ERP implementations at this size which have run 6 to 18 months often even without an acquisition adding to the complexity.
A 100-day plan sets direction, but the heavy system work comes after it. That's a strong reason to choose the end state deliberately, because absorbing commits your team to the longest path.
Who Leads the Integration
Every end state needs one owner with authority across the systems, from deal close through the ERP decision and all the work that follows. When integration is treated as a side project shared among busy leaders, it stalls at exactly the decisions that matter most. That owner can be an existing leader given real time for the job, or outside leadership for the integration window, such as a fractional or interim CIO.
Ascendex helps acquirers decide what an acquired company's technology should become, then leads the integration from close through the ERP move with technology leadership that stays until the combined systems truly work. If you've closed a deal or are about to, contact Ascendex to talk through your integration plan.