The Hardest Part of M&A Isn't the Technology. It's the People
When organizations go through mergers and acquisitions, the story that gets told in boardrooms, in press releases, in integration kickoff meetings, is almost always a technology story. Systems need to be consolidated. Applications need to be rationalized. Devices need to be standardized, networks need to be aligned, and infrastructure needs to be brought under a unified architecture. It's a compelling narrative, because it's concrete and it's measurable. You can build a project plan around it. You can assign workstreams and track milestones and declare victory when the last legacy server goes dark.
During my time at Centene, I was involved in a number of these integrations during a period of rapid growth for the company. And what I came to understand , sometimes the hard way, is that the technology story, as tidy as it looks on a Gantt chart, is almost never the real story. The real story is about people. M&A integration is a people problem that happens to involve technology, and that distinction matters far more than most organizations are willing to acknowledge.
The Illusion of a Clean Integration
When leadership announces an acquisition, the immediate instinct is to inventory the environment. Which identity provider will we use? What email platform will everyone move to? How do we consolidate the data centers? Which applications survive and which ones get sunset? These are legitimate questions that absolutely need to be answered. But they have a way of consuming all the oxygen in the room, crowding out a much more important line of inquiry: how do the people in this organization actually get their work done?
Even when the acquired company has solid technical documentation, and many don't, that documentation almost never captures the human reality inside the environment. It can tell you what systems exist. It can't tell you which ones a team of twelve people in a regional office opens every single morning before they do anything else, or which homegrown tool a department built three years ago because the official solution didn't meet their needs, or which integrations between seemingly unrelated systems are quietly holding together a critical business process. The technology environment may be documented. The human experience inside that environment usually isn't.
The Technical Debt Nobody Talks About
Almost every organization acquired through M&A is carrying some degree of technical debt. That's not a criticism, it's just the nature of how organizations evolve. Decisions that made sense five years ago leave behind artifacts. Workarounds get institutionalized. Shadow IT solutions proliferate because employees are resourceful and official channels are slow. Legacy applications stick around long past their intended lifespan because nobody fully understands them but everyone is afraid to touch them.
You see it consistently across integrations: applications that are critical to a business process but that nobody in the organization can fully explain, multiple overlapping tools solving the same problem in slightly different ways, custom-built systems maintained by developers who left years ago, and devices running configurations that were never part of any official standard. On paper, the environment can look manageable. Start peeling back the layers, and you're often staring at years, sometimes decades, of accumulated decisions, each one made with good intentions and incomplete information.
And yet even all of that accumulated complexity isn't the hardest part. The hardest part is figuring out which of those tools actually matter to the people using them, and making sure those tools are still there, still working, still accessible, when the integration is over.
Making Decisions in the Dark
Without meaningful visibility into how employees actually use their technology, integration teams are essentially flying blind. They have inventories. They have architecture diagrams. They have interviews with IT leadership and a stack of documentation of varying quality. What they often don't have is a clear picture of the digital employee experience, what the daily reality of working in this environment actually looks and feels like from the ground level.
The decisions that get made in that vacuum can look perfectly rational from an architectural standpoint and still be deeply disruptive. Applications get retired because they appear redundant on paper. Devices get reimaged and standardized on a timeline that prioritizes architectural alignment over operational continuity. New platforms get rolled out quickly because the parent company needs everything on a unified system. Sometimes those decisions go smoothly. Other times, they quietly break things that nobody knew were connected. What looks like an unnecessary legacy tool to an architect might be the first thing a team opens every morning to start their workday. Without understanding the employee experience behind the technology, integration becomes an exercise in educated guesswork — and the costs of guessing wrong fall on the people who had nothing to do with the decision.
The Compounding Effect on Employees
It's easy to lose sight of what employees in an acquired organization are already navigating when an integration begins. New leadership. New reporting structures. New performance expectations. A culture that may feel foreign in ways that are hard to articulate. The uncertainty that comes with not knowing what the future looks like for them specifically. That's a significant amount of disruption to absorb before a single system changes.
When the technology they depend on also shifts suddenly and dramatically, the disruption compounds in ways that are genuinely hard to recover from. Logins change. Familiar applications disappear or behave differently. Processes they've relied on for years suddenly stop working, and the path to getting help is unclear because the people they used to call are in a different support structure now. From an IT perspective, these can look like necessary steps in standardizing the environment — and they often are. From an employee perspective, it can feel like the ground is shifting beneath their feet in every direction at once. That's not a recipe for productivity, and it's not a recipe for the kind of cultural integration that M&A actually depends on to succeed.
Visibility Changes Everything
This is where modern Digital Employee Experience platforms and software discovery tools can genuinely transform the integration process. Rather than relying on static inventories and assumptions, organizations can develop real, data-driven insight into how the environment is actually being used. What applications are in active use, and how frequently? Which departments depend on which tools? What does device performance look like from the employee's perspective, not the infrastructure team's? Where are the biggest sources of friction in the daily work experience?
DEX platform tools or software discovery solutions such as Rayventory allow integration teams to see the digital workplace through the lens of the people who live in it every day — rather than through the lens of the infrastructure supporting it. That perspective changes the questions you're able to ask. Which applications are truly business-critical, and which are genuinely redundant? Which systems create friction that employees have learned to work around? Which environments are going to require the most remediation before they're ready for a transition? The answers to those questions don't come from architecture reviews. They come from actually understanding how work happens.
Integration as an Employee Experience
When you start from that foundation of real visibility, integration strategy starts to look meaningfully different. Instead of racing to standardize everything on a compressed timeline, teams can take a more deliberate approach that protects what's working while improving what isn't. Critical workflows can be identified and shielded from disruption. High-impact applications can be prioritized for early attention. Performance issues can be surfaced and addressed before they become the employee's daily reality in the new environment. The integration can be structured around maintaining productivity rather than simply achieving architectural conformance.
That shift in orientation, from merging systems to sustaining the human experience while systems change, is the difference between integrations that employees barely notice and integrations that become cautionary tales. It doesn't make the technology work any less complex. But it makes the outcomes significantly better, and it preserves the one thing that's genuinely hard to rebuild once it's lost: employee trust.
The Measure That Actually Matters
M&A will always involve hard technology problems. There's no version of this work that doesn't require serious effort on identity consolidation, network integration, application rationalization, and infrastructure alignment. That work is real and it matters. But it's not the goal. It's the mechanism.
The goal, the one that determines whether an integration actually succeeds, is whether the people in the acquired organization are able to continue doing their work effectively while the systems around them change. That's the standard worth holding integrations to. Not how quickly the architecture was consolidated, not how many applications were sunset on schedule, but whether employees came out the other side feeling supported rather than disrupted.
The organizations that get this right aren't necessarily the ones with the most sophisticated integration playbooks or the largest IT teams. They're the ones that understand, from the beginning, that technology serves people, and that keeping that relationship intact through a period of enormous change is the hardest and most important thing they have to do.
Thanks for reading.
