On this page
Acquisition-led growth is a proven strategy. Buy a competitor, enter a new market, absorb a capability you'd take years to build on your own. Done well, it compounds into something genuinely valuable. Done poorly, the synergies everyone celebrated at close quietly bleed out over the next 18 months, and the technology integration is usually where the bleeding starts.
If your company is growing through acquisition, or you've just landed somewhere that is, this post is for the person who will eventually own the question: what do we actually do with all these systems? There's a clear sequence of work. Here's what it looks like.
Why Tech Integration Is Difficult
The acquisition rationale is usually clean. The technology reality almost never is. Executives focus on financial synergies and market positioning, and the reality of combining disparate IT systems, data architectures, and operational processes becomes the hidden obstacle that derails otherwise promising acquisitions.
IT integrations fail or encounter major issues 84% of the time, and fewer than 1 in 5 acquirers improve IT costs post-close. Those numbers aren't outliers. They describe the median outcome.
The core reason is timing. Post-merger tech integrations usually run into trouble because architecture decisions happen too late, system ownership is unclear, data migration is underestimated, and teams are expected to work together before their tools, processes, and responsibilities are actually aligned. By the time someone asks "what are we doing with their CRM?", the team is already six months behind.
The Diagnostic Work Comes First
Before you can build an integration plan, you need an honest picture of what you're integrating. That means a structured assessment of both sides, and it needs to happen before the pressure to "just get things connected" takes over.
The assessment covers a few specific areas:
- System inventory. What applications are running, who owns them, and are there duplicate functions across the two companies? Two CRMs, two ERPs, two billing systems all create decisions you'll need to make explicitly.
- Data quality and structure. Clean, consistent data is the prerequisite for any integration that actually works. Acquired companies often carry years of messy records: duplicates, inconsistent formats, fields that were used differently by different teams. You want to know that before you start moving things.
- API availability. Some systems connect cleanly through documented APIs. Others don't expose one at all, and that changes the build approach significantly. We've solved the no-API problem with screen-scraping in two weeks when an overseas firm quoted six weeks on an approach that assumed an API existed. The right answer depends on what's actually there, not what you assumed would be.
- Hidden dependencies. Legacy systems are full of undocumented connections that only surface when you try to touch them. The biggest risks in any integration are data loss, broken integrations, unclear system ownership, hidden legacy dependencies, poor documentation, API mismatches, security gaps, and team misalignment. Surfacing these early is the whole point of the diagnostic.
- Infrastructure costs. Acquired companies frequently carry cloud waste they never audited. Before folding their infrastructure into yours, it's worth knowing what you're absorbing. A one-hour cloud audit can surface 20-50% savings, some of it fixable immediately, some of it a structural constraint worth understanding before you commit to a direction.
To successfully complete the post-merger integration process, buyers need to start the planning process during due diligence, before the deal closes. The assessment work is not post-close cleanup. It's the foundation everything else sits on.
Three Integration Decisions You Have to Make Explicitly
Once you have a clear picture, you're making one of three calls on each system. Whether to merge systems or keep them separate depends on the business goal, technical debt, system stability, and long-term maintenance cost. Some systems should be merged, some should be wrapped with adapters, some migrated later, and others may be better left alone until there's a clear reason to change them.
Those three paths, made concrete:
- Consolidate. Pick one system, migrate the data, retire the other. This is the right call for duplicated point solutions where one is clearly better. It takes longer than people expect and needs a solid data migration plan, not a spreadsheet export.
- Integrate. Keep both systems running and build the connection between them. This is right when both serve distinct functions and the cost of consolidation outweighs the benefit. Requires ongoing maintenance, so going this route means committing to own that bridge.
- Isolate. Leave the acquired system alone and run it independently, at least for now. This is the right call when the acquired entity operates as a standalone unit, or when touching the system creates more risk than value. Isolation is a deliberate choice, not a failure to decide.
The worst option is forcing a full rewrite just because the old system looks messy. That instinct is common and expensive. The mess is usually manageable. A rewrite is a 12-month commitment that delays everything else.
What a Realistic Integration Sequence Looks Like
Integration work doesn't happen in a single sprint, and skipping steps creates problems that compound. There's an immediate need for easier and more efficient communication with new colleagues joined through acquisition, and the time and complexity of building bridges between the two organizations varies depending on the modernity of the technology stack.
A practical sequence looks like this:
- Day 1-30: Stability and visibility. Connect communication systems. Establish shared access where teams need it immediately. Don't touch anything structural yet. The goal is operational continuity, not integration progress.
- Day 30-60: Full system assessment. Map every application, owner, cost, and dependency. Make the three decisions above for each system. Surface the data quality issues before they become data migration disasters.
- Day 60-90: Integration plan with sequencing. Build the roadmap based on what you found, not what you assumed pre-close. Prioritize by business impact, not technical elegance. The systems that touch revenue or customer experience move first.
- Day 90+: Phased execution. Build connections, migrate data in tested batches, and retire systems with a clear cutover plan. When the discovery phase was thorough, this phase moves faster because the scoping is accurate.
Companies that track integration milestones from day one do materially better. Acquirers tracking synergies from Day 1 achieve 92% success rates. The plan is the variable, not the ambition.
The Build vs. Buy Question Comes Up in Every Integration
At some point in the integration, you'll hit a gap. Two systems that don't connect well, a workflow that neither system supports, a reporting need that spans both companies and currently lives in someone's spreadsheet. That's when the build-vs-buy question surfaces.
The honest answer: it depends on how specific the requirement is and how long you need it to last. Off-the-shelf middleware works well for standard integrations between common platforms. Custom connectors are the right call when the systems are unusual, the data transformation is complex, or the connection needs to hold for years without a vendor relationship attached to it. The build vs. buy vs. partner analysis is worth doing explicitly, not defaulting to whichever option the loudest person in the room prefers. The wrong choice at this stage tends to stick around for a long time.
If AI or automation is part of your integration roadmap, whether that's consolidating reporting, surfacing anomalies across the combined entity, or automating workflows that straddle both systems, the data foundation has to come first. AI surfaces patterns in clean data. In messy data, it surfaces noise. The sequence matters.
Inheriting a stack of acquired systems and not sure where to start? Talk to us