When a CX migration goes sideways, the post-mortem almost always points the finger at technology.
If this were a whodunit, technology would be the butler, the obvious but usually innocent culprit.
You’ll likely hear things like ‘The platform wasn’t ready,’ ‘The integration was more complex than expected,’ or ‘The vendor overpromised.’
It’s a comforting narrative because it keeps the responsibility at arm’s length. But it’s usually wrong.
McKinsey research puts the failure rate for major transformations at 70%. In CX specifically, the pattern is well-established: projects run over time, over budget, or simply never deliver what was promised.
And while technology tends to carry the blame, practitioners who have seen the inside of enough challenging migrations will tell you the real culprits were waiting in the org chart long before a single workload moved.
“The thing that most organizations that struggle get wrong, is that they don’t fix how they work before they start fixing the technology,” says Rupert Adair, Director of Product Management at Enghouse Interactive.
“They focus on the tools and the platform and the cloud, but they never really agree on who owns the customer experience, who makes the decisions, and how IT and the business are supposed to work together.”
The result, he says, is entirely predictable;
“Things take longer, people pull in different directions, and you end up redoing things.”
The Ownership Problem
Unfortunately, gaining universal agreement on exactly who should own a CX modernization project is also something of a Herculean task.
Adair has seen this indecision undermine projects more than almost any technical failure.
“Too often, IT drives the solution without the ownership of other people,” he says.
“It should be rounded ownership. Call center leaders, the people driving the teams, the people responsible for the KPIs – they should have a key part.”
Many failures come down to a lack of alignment between IT and CX teams on priorities, ownership, and success metrics. When this gap opens, even well-funded programs stall or fragment.
The alternative is a migration that gets technically delivered but operationally rejected. In other words, a system that works on paper but frustrates everyone who uses it in practice.
Getting there takes real effort before anyone even opens a project plan. Adair’s view is that the companies that succeed don’t start with the technology at all:
“They start with getting alignment on ownership, priorities, and what good actually looks like. They nail down exactly what they are aiming to achieve before they hammer out how they are going to do it.”
It’s only once the objectives are agreed on that the technical decisions start to make sense.
The Integration Blindspot
One of the more expensive surprises in CX migration projects is the discovery of integration complexity – not before go-live, but during it.
By that point, the budget is committed, the timeline is fixed, and unwinding decisions are going to be costly. In addition, someone could end up losing face. Indeed, saving that face is another reason why some projects continue when they shouldn’t.
Adair traces this back to the same root cause of a project designed around the technology rather than around the business.
“If you don’t fully understand what your business is doing to provide customer experience – how the contact center teams work, what the engagement with the customer looks like – you’re not going to be prepared for any impact of any change.”
The pull toward focusing on what can be controlled technically is understandable, he acknowledges, but it carries a real cost:
“Tech-led teams understand the tech, but not really the workflows or the impact on the people and the customer.
“The question of how your customers expect service from your business, and what might impact that, that’s less easy for them to consider from a technical perspective.”
His advice is practical. He advocates bringing the right people in early enough that their understanding of the business shapes the design, not just the sign-off.
What Good Migration Practice Actually Looks Like
At Enghouse, the response to this pattern is deliberate early involvement. The company’s pre-sales team aims to be in conversations before technical scoping has hardened, helping clients think through design from the outset rather than inheriting decisions that create problems later.
“It’s about having a real consultation at the beginning,” says Adair. “Getting them to talk, getting them to think differently, and making sure decision-makers are fully aware of feasible options before locking in a path.”
That early consultation also shapes Enghouse’s principle of advising caution and due diligence before any migration, including a wholesale move to cloud.
“There are some organizations who will never move to full cloud for reasons such as data sovereignty, regional or industry regulatory compliance, internal control and governance–or just plain risk aversion”
When you strip away the complexity, Adair’s summary of what separates successful migrations from failed ones is almost disarmingly simple.
“The successful teams design what they need first and then only move what actually needs to move. That’s the baseline.
“But behind that is a whole heap of understanding needed to get to that point.”
For IT and operations leaders, the instinct is to treat ownership alignment, workflow mapping, and integration planning as boxes to check before the project kicks off.
This is where a vendor like Enghouse adds value.
Not only does its experienced presales engineering team fully review and explore each customer’s needs and priorities, but it also brings to the table a balanced product portfolio that allows organizations to choose whatever is right for them and their business obligations, rather than being stampeded into decisions they may come to regret.
In practice, that groundwork doesn’t just precede the migration; it determines whether the migration succeeds or fails.
