There’s a pattern in how IT transformation projects go wrong, and it’s worth stating plainly because the pattern holds across sectors, platforms, and delivery models.
The parts that get the most attention, the most governance, and the most executive focus – the platform selection, the system configuration, the vendor relationships, the overall project plan – rarely cause the failures. The parts that cause the failures are the ones that happen underneath those headlines. Data that arrived in the new system in worse shape than anyone tested for. Integrations that behaved differently under real transaction volume than under simulated load. Legacy content that nobody quite knew what to do with and that ended up being deferred until it couldn’t be deferred any longer. User workflows that depended on nuances in the source environment that nobody fully documented before it was switched off.
These aren’t unusual problems. Gartner’s widely cited research indicates that[1] around 70% of ERP implementations over the next three years will fail to fully meet their business case objectives – and when you actually look at what went wrong, the answers tend to be remarkably consistent across failures. It’s not usually the platform. It’s the data, the integration, and the preparation that sits beneath it.
Which is why the question of who handles that part of the work – the unglamorous, under-attended, project-critical layer – is the question that most often determines whether a transformation succeeds or quietly unravels.
Where transformation risk actually concentrates
If you mapped the points on a typical transformation programme where things are most likely to go wrong, the map would look nothing like the project plan.
The project plan treats the work as a sequence of linear phases: design, build, test, deploy, stabilise. The risk map is very different. It concentrates in a few specific places – and those places are, consistently, the least understood and least resourced parts of most projects.
The first is legacy data. Every transformation involves data moving from existing systems to the new one, and existing systems almost always contain far more mess than the initial assessment suggested. Duplicate records. Fields that were supposed to be mandatory and weren’t. Formats that don’t map cleanly. Decades of accumulated workarounds that nobody thinks to document because they’ve become invisible to the people who use them daily. Gartner’s data migration research puts the failure-or-overrun rate at around[2] 83%, and the cause is almost always the same: underestimated complexity in the source data, discovered too late to address properly before go-live.
The second is integration behaviour under real conditions. Integrations that work in test environments – where data volumes are small, transaction patterns are simulated, and timing is forgiving – can behave very differently when they’re handling live transactions at production scale. The edge cases that nobody anticipated surface exactly when the business is depending on them not to. This is the classic “it worked in UAT” failure mode, and it’s responsible for a disproportionate share of post-go-live instability.
The third is the unstructured side of the legacy environment. Documents, records, scans, correspondence, and the various content stores that tend to accumulate around core systems. These are often treated as out of scope for the main migration, which means they either get deferred to a separate project that never quite materialises, or they arrive in the new environment carrying their existing problems forward. Around[3] 80% of enterprise data is unstructured, and in regulated sectors the figure is often higher – which means leaving the unstructured estate out of scope usually leaves a majority of the relevant information unaddressed.
None of these is the kind of risk that gets surfaced in a steering committee presentation until it’s too late. All of them are the kind of risk that determines whether a transformation lands well.
The problem with generalist delivery
Most transformation teams are built around the core platform being deployed. The capability is strong on configuration, strong on the target system, and strong on the visible parts of the project that executives ask about.
The challenges described above aren’t usually where that capability is strongest. They’re specialist disciplines in their own right – data migration, legacy integration, document digitisation, multi-system reconciliation – and they require depth that builds over many projects, not across one. A team that’s excellent at configuring the target platform isn’t necessarily excellent at cleansing two decades of accumulated data inconsistencies across three legacy systems. They’re different skills, and the market tends to under-price the second because the first is more visible.
When those specialist capabilities aren’t present – either internally or through partners – the gaps tend to surface at exactly the wrong moment. Late in the project, under time pressure, when the cost of fixing something is significantly higher than it would have been if it had been addressed earlier. The people capable of fixing it quickly are the ones who’ve seen the same problems across multiple projects and know what to do; the people discovering the problem for the first time, on a live programme with executive scrutiny, tend to spend longer than anyone planned and still produce a less robust result.
This is where the absence of specialist partnership becomes visible, and it tends to be visible to the client long before it becomes visible in the project documentation.
What specialists actually contribute that generalists can’t
The value of a specialist partner isn’t just technical. It’s structural, and worth being specific about.
Experienced partners have seen the same classes of problem across many projects. They know where the risks concentrate, what the early warning signs look like, and how to intervene before issues become critical. More importantly, they know what doesn’t work – approaches that sound reasonable in planning but fall apart in execution, assumptions that hold in theory but break under real data, patterns that have gone wrong enough times that they don’t need to be tested again on a live programme.
That accumulated judgement is genuinely hard to replicate. It doesn’t come from documentation or methodology frameworks. It comes from having been present when things went wrong before, and understanding why, and knowing the specific warning signs to watch for on the current project. A partner who can say “we’ve seen this pattern three times, here’s what happens if you don’t address it now” is bringing something that no amount of internal capability can substitute for in a compressed timeline.
Concretely, this shows up in work that’s easy to miss if you’re not looking for it. Data being profiled and assessed at a level of detail that reveals problems before migration rather than after. Integration dependencies being mapped against known failure patterns. Document estates being brought into scope early rather than deferred. Cutover sequences being planned with enough precision that they can be executed under pressure rather than improvised in the moment. Governance layers being built in from the start rather than retrofitted after go-live when the regulator starts asking questions.
None of this is visible to an executive sponsor reviewing a project dashboard. All of it determines whether the dashboard tells a good story or a bad one six months later.
The commercial case for consultancies
For IT consultancies, specialist partnerships have become a structural part of how growth works in a market that’s getting more complex and harder to staff.
The skills shortage is the obvious driver. Roughly[4] 67% of digital transformation initiatives are being delayed by IT skill shortages, and consultancies are competing for the same scarce specialists as their clients. Building permanent capability around intermittent demand is expensive, and even when it works, the specialists become generalists within a year of joining because a varied project portfolio doesn’t sustain deep specialism.
The buying side has caught up with this. Enterprise clients increasingly expect that the lead consultancy on a transformation programme will orchestrate specialist capability rather than manufacture it internally. The expectation is credible delivery across the whole scope of a programme, not a single firm pretending to have depth in every component. Recent research suggests that around[5] 54% of enterprises now actively prefer multi-vendor digital strategy engagements – the single-firm model is no longer the default.
Consultancies that use specialist partnerships well don’t treat them as a fallback for when internal capability runs out. They treat them as a deliberate delivery strategy. The client relationship, the architecture, and the accountability stay with the consultancy. The depth on specific components – particularly the data layer, where so much project risk concentrates – comes from partners who do that work every day.
Why the impact is asymmetric
The value of specialist partnership has an unusual property: it’s hardest to see when it’s working well.
When a transformation lands cleanly – data migrated accurately, integrations stable, go-live smooth, adoption strong – the specialist contribution tends to be invisible. Nothing went wrong, so nothing attracts attention. The success gets attributed, reasonably, to the overall programme leadership and the visible parts of the delivery.
When it doesn’t land cleanly – when data issues embed in the new system, when integrations misbehave under load, when unstructured content gets forgotten and then has to be dealt with after go-live – the absence of specialist capability is suddenly very visible. But by then it’s too late to address cheaply. The cost of fixing things at that stage is typically several times what it would have been to prevent them.
This is part of why specialist partnership tends to be under-invested until an organisation has experienced what happens without it. The value is most apparent in hindsight, and most abstract in planning.
Where Dajon fits
Dajon Data Management works alongside IT consultancies and transformation teams as a specialist data partner.
When a programme involves data migration, integration, document digitisation, or structured data preparation – the components that sit beneath the surface of most transformation projects and cause most of the difficulty – we provide the depth of expertise that makes those elements work. We operate as part of the delivery team, focused on the data layer, so that the consultancy can hold the client relationship and the architectural direction while the components where project risk concentrates are handled by people who do that work every day.
For organisations managing complex programmes, that separation of focus is what allows each side to perform at its best. For regulated clients, it also means the data work stands up to audit and regulatory scrutiny long after the project closes.
The invisible foundation
Transformation success stories tend to focus on outcomes. The system that went live. The efficiency gained. The capability created.
Behind each of those stories is a foundation that was either built properly or papered over. Data that was ready, integrations that held, unstructured content that was brought into scope, cutover that was planned rather than improvised. Specialist partners are usually somewhere in that foundation, doing work that is rarely the headline and that the projects they support are better for.
The question worth asking isn’t whether your transformation programme has impressive platform selection or strong executive sponsorship. It’s whether the parts of the programme where risk actually concentrates – the parts nobody will remember if they go well and nobody will forget if they don’t – are being handled by specialists.
Are the critical components of your transformation projects being handled by people who’ve seen them go wrong before – or is that being left to chance?
Dajon Data Management works alongside consultancies and transformation teams as a specialist data partner. Get in touch to find out how we support the data layer of complex programmes.
References
- ERP Implementation Failure Statistics: 2025 Research Gartner via Godlan[↩]
- Top Data Migration Challenges & How to Overcome Them Gartner via Kanerika[↩]
- Unstructured Data: The Hidden Bottleneck in Enterprise AI Adoption Gartner via CDO Magazine[↩]
- Digital Transformation Consulting Services Market Business Research Insights[↩]
- Digital Transformation Strategy Consulting Market Size Business Research Insights[↩]