What acquiring a company’s technology actually takes — and why the chaos in the middle isn’t a sign something’s gone wrong.
Think about a family outgrowing their first home. The kids need their own rooms, the garage is full, there’s nowhere left to put anything new. So they buy a bigger house across town — more space, a yard, room to grow into.
Then moving day arrives, and for a while everything gets worse before it gets better. Boxes stack up in hallways nobody can walk through. Someone’s favorite mug goes missing. For a stretch, the family is effectively running two households at once — sleeping in one, storing things in the other, driving back and forth to get the rest of it. It’s genuinely chaotic. But if the move is done with a plan, room by room, the family ends up somewhere with a real place for everything. Nobody would trade the finished home to avoid the mess of getting there.
Technology mergers and acquisitions are the same move, at company scale — and most of them handle the “moving day” part badly.
The Numbers Haven’t Moved in Decades
A KPMG study going back to 1999 found that 83% of mergers failed to boost shareholder returns. Bain & Company’s research a few years later put the figure at roughly 70%. Academic reviews of the M&A failure literature, spanning studies from the 1970s onward, consistently land failure estimates somewhere between 50% and 85%, depending on how “failure” is defined.
What’s striking isn’t any single number — it’s that the range has barely moved across three decades of deals, consulting frameworks, and “lessons learned” retrospectives. Something structural keeps getting missed. In my experience leading engineering teams through this kind of work, that something is almost never the deal logic. It’s the technology integration — treated as a line item on a project plan instead of its own engineering discipline with its own sequence.
Most guidance on post-merger integration is organizational: governance charts, synergy trackers, culture playbooks. It treats the actual technical work as a black box that “IT will handle.” Here’s what’s usually inside that box.
Start With Discovery, Not Building
The instinct under deal pressure is to start building immediately — new integrations, new features, a unified look and feel. Resist that instinct for a few weeks and you’ll save months later.
Before anything gets built, both companies’ technology needs to be inventoried independently: what languages and infrastructure are in production, where the data lives, who the identity provider is, and — critically — what carries an active compliance obligation. The acquired company’s undocumented dependencies are usually where the real risk hides, not the documented ones. Every system should get scored on compatibility, compliance exposure, business criticality, and how hard it will be to migrate. That scoring turns a fact-finding exercise into an actual prioritized plan.
Decide, System by System, Who Wins
Once discovery is done, someone has to decide whose platform survives — and it’s rarely an all-or-nothing call. A newer, better-architected payments system from the acquired company might survive over the acquirer’s own; the acquirer’s identity platform might survive because it already carries the right compliance certifications. Making this decision per-system, rather than treating the acquired company’s stack as one monolithic thing to keep or replace, is one of the biggest levers available for de risking the whole integration.
Migrate First, Then Certify — Not the Other Way Around
Designing a combined data schema is a design exercise. It doesn’t move a single record. Somewhere between “we’ve designed the target schema” and “we can trust this data” sits an actual migration — pulling records out of the old system, transforming them, and landing them in the new one. Skip that step on a slide and it becomes impossible to skip in practice.
Once the data has landed, it needs to be certified before anyone trusts it for real decisions — moving through progressively stricter checks, from basic structural validation, to business-rule validation with stakeholder sign-off, to running the new system’s output alongside the old system’s live output and watching for drift. The single most common failure at this stage isn’t dramatic. It’s quiet: a mapping rule that silently drops a record instead of flagging it, and nobody notices until a customer disappears.
Don’t Wait for Perfect Data to Start Building
Here’s the part most teams get backwards: waiting for every record to be fully certified before starting any product work on the new platform is the single biggest timeline killer in technology M&A. It’s also unnecessary. Product teams can build against the agreed structure of the combined data well before every record behind it is certified, as long as there’s a buffer layer that absorbs schema changes without breaking product code, and feature flags that keep any capability depending on uncertified data switched off until it’s ready. Everything else can ship on schedule.
The Hardest Question: When Can We Turn the Old System Off?
This is the question every executive eventually asks, and the one most often answered vaguely: while both the old and new platforms are live at once, does data flow one way or both ways?
The honest answer is that it depends on where the writes are happening, and it changes over time. Early on, the new platform might just need a read-only copy of live data to support reporting — a one-way flow. As real customers start moving over, both systems typically need to write back and forth to stay consistent, which is the highest-risk phase and needs firm rules for handling conflicts. And the moment every customer has moved to the new platform, that two-way flow should be switched off entirely, in the same breath as the old system’s write access gets revoked. Leaving it running “just in case” isn’t caution — it’s a live path for a system that’s supposed to be retired to quietly overwrite the one that isn’t.
This is the “two households at once” stretch of the move. It’s uncomfortable by design. It’s only justified by having a firm date on the calendar for when it ends.
What This Looks Like for Leaders
None of this executes itself. A few things matter more than the technical plan:
- Show the timeline, not just the risk. Executives don’t want a list of concerns; they want to know exactly when the risky period starts, when it ends, and what closes it.
- Be selective about what you gate. Not everything needs to wait for certification — only the parts with real complexity or compliance exposure. Blocking everything equally burns credibility fast.
- Treat the acquired company’s engineers as a source of knowledge, not a headcount to absorb. They usually know exactly where the undocumented risk lives, and keeping them through the messy middle is what keeps the old system safely staffed until it can finally be turned off.
The Point Was Never to Avoid the Boxes in the Hallway
It was to make sure that when the last box is unpacked, there’s a real place for everything — and everyone remembers why they wanted the bigger house in the first place. Technology M&A doesn’t fail because the strategy was wrong. It fails in the unglamorous middle: the schema decisions, the migration mechanics, the sync rules nobody puts on the steering-committee slide. Naming that middle, and giving it a real sequence, is most of the job.
| Read the full framework: the complete technical paper — including the migration architecture, schema convergence methodology, and cutover/sync mechanics referenced above — is published as a working paper on SSRN: |
About the author: Athresh Guruprakash is a Senior Software Engineering Manager with 18+ years of experience in credit risk systems, applied AI/ML, and engineering leadership. He leads Tech with AG, an AI and technology education platform, and writes on the intersection of applied AI research and hands-on engineering leadership. Connect with him on LinkedIn (linkedin.com/in/athresh-guruprakash-1a437617) or read the full research paper on SSRN.
