Most digital transformation budgets are approved on a promise and later buried by a statistic: the majority of programs miss the goals they were funded to hit. Before you sign off on a multi-year replatforming, it helps to know what that risk actually is, where it comes from, and how early you can see it coming. A digital transformation failure is rarely a technology problem. It is almost always a problem of ownership, sequencing, and honest reporting, and every one of those shows up long before the software does.
This guide breaks down where the widely quoted failure rate really comes from, how the industry decides what counts as a failure, what recent programs got wrong, and the warning signs that appear at each stage. The examples here are real and sourced, and the patterns behind them are the same ones we see when a client asks us to take over a program that has already stalled.
Where the Failure Rate Number Really Comes From
You have probably seen the claim that seventy percent of digital transformations fail. It gets repeated in vendor decks, board memos, and conference keynotes, usually with no source attached. The number works as a rough signal, yet the precise digital transformation failure rate is softer than it looks, because almost every study measures something different.
Part of the confusion is definitional. Some research counts a program as failed only if it is scrapped outright. Other research counts any program that misses its stated business targets, which sweeps in the large group of projects that shipped, work, and still underdelivered. The seventy percent figure also echoes decades-old change-management estimates that predate cloud, mobile, and modern delivery, so it travels much further than its evidence.
The more useful signal comes from recent data. In a 2025 survey of more than a thousand enterprises, S&P Global Market Intelligence found that the share of companies abandoning most of their AI initiatives jumped to 42 percent, up from 17 percent a year earlier, with the average organization scrapping 46 percent of its proofs of concept before production. That is a narrower question than the old headline, and it points in the same direction: a large fraction of ambitious technology programs quietly stall between pilot and production.
How the Industry Defines a “Failed” Transformation
Which brings up the question that matters most to a budget owner: why do digital transformations fail when the technology usually works? The answer starts with how failure is defined, because the label covers three very different outcomes.
Analysts generally sort transformations into three buckets:
- Cancelled. The program is stopped before it delivers, often after costs overrun the original estimate several times over.
- Delivered but underwhelming. The system goes live, then misses the adoption, revenue, or efficiency targets that justified the spend.
- Delivered and abandoned. Users route around the new system and quietly return to spreadsheets, shadow tools, or the old process.
The middle and third buckets are where most of the money goes. A program that ships and then fails to change behavior looks like a success in a status report and a loss on the balance sheet. Closing that gap between shipped and adopted is why a clear digital transformation strategy built around the outcome, rather than the software, matters more than the platform choice.
Recent Digital Transformation Failures and What Went Wrong
Public programs make the clearest digital transformation failure examples, because their budgets and post-mortems become public record. Two recent cases show how the same root causes repeat across very different organizations.
Birmingham City Council in the UK moved off its old system to Oracle Fusion in 2022 and let the implementation drift into heavy customization. Costs climbed from an original estimate of around 19 million pounds toward a projected 216.5 million pounds by 2026, and the failure helped push the council into effective bankruptcy. The root cause was organizational. The council kept bending the software to fit old processes instead of adapting the processes, and every customization added cost and fragility.
Quebec’s auto insurance board launched its SAAQclic platform in 2023 with a chaotic rollout and a cost overrun of roughly 500 million Canadian dollars. By March 2025 total costs had reached about 1.09 billion dollars, and a public inquiry concluded that officials had concealed the overruns for years. The inquiry’s own summary of the problem was blunt: the project was too much, too big, too fast, with too few checks in place to keep it honest.
Both programs had money and talent. What both lacked was a mechanism to surface bad news early and the discipline to change process instead of customizing around it. Those two gaps show up again and again, whatever the industry or the vendor.
Red Flags at Every Stage of a Transformation
Most digital transformation pitfalls are visible well before they become expensive, if you know which stage to watch. The warning signs cluster into three phases, and the cost of ignoring them rises sharply as you move through them.
Before You Commit Budget
The riskiest decisions happen before a single line of code is written. Watch for a business case built on cost savings alone with no adoption target, a scope that lists features instead of outcomes, and the absence of a phased transformation roadmap that would let you stop after the first release and still have something usable.
A second early red flag is a vendor or internal team that promises to deliver against vague requirements without ever pushing back. Comfort with ambiguity is genuinely useful. The team you want is the one that is also willing to name the unknowns out loud in month one and price the risk honestly.
Business case built on cost savings alone
No adoption or outcome target is tied to the number
Scope defined as a feature list
No feature is tied to an outcome statement
No phased transformation roadmap
Months of spend pass before anything usable ships
Vendor accepts vague requirements without pushback
No unknowns are named or priced in month one
No single owner for the adoption target
Nobody is accountable when usage lags the plan
While the Build Is Live
Once delivery starts, the signals shift from planning to momentum. The clearest warning is a growing pile of customizations, each one reasonable on its own, that collectively turn a supported product into a bespoke system only your vendor understands. Rising customization is the single strongest predictor of the Birmingham pattern.
Other mid-build red flags include status reports that stay green for months and then jump straight to red, integration work that keeps slipping to a later phase, and a test suite that never quite catches up to the code. When these appear together, an independent software audit costs far less than discovering the same problems at go-live.
After Go-Live
The most expensive red flags appear after launch, because by then the budget is spent and the political cost of admitting problems is at its highest. Watch adoption numbers rather than uptime. A system with 99.9 percent availability that only 40 percent of staff actually use has failed at the job it was funded to do.
The other post-launch signal is the quiet return of shadow processes. When people rebuild the old spreadsheet next to the new system, they are voting on it, and that vote tells you more than any satisfaction survey.
Where AI Raises the Stakes
AI has become the headline feature of many current transformations, and it magnifies every weakness above. The same organizational gaps that make broad digital transformation projects fail also sink AI initiatives, only faster and more visibly, because AI pilots are cheap to start and hard to operationalize.
The 2025 numbers are stark. An MIT report on enterprise AI found that around 95 percent of generative AI pilots delivered little to no measurable impact on the bottom line, with only about 5 percent reaching real revenue acceleration. The report traced that gap to weak integration into real workflows and the absence of a learning loop, which is the same adoption problem that sinks non-AI transformations.
AI also introduces failure modes that pure software projects avoid, from unpredictable outputs to workforce resistance. We covered the people side of this in detail in why AI workforce transformations stall, and the short version is that tools which change how people work need the same change management as any other transformation, plus a tolerance for probabilistic results.
What Makes Transformations Stick
The programs that succeed look boring from the outside. They ship in small, usable increments, they measure adoption from day one, and they treat honest status reporting as a feature rather than a threat. None of that depends on picking the perfect platform.
Three habits separate the transformations that stick:
- Sequence for early value. Deliver something usable in the first few months so the program earns trust and can be stopped without wasting the whole budget.
- Change the process, not the product. Adopt the software’s standard workflow wherever you can, and reserve customization for genuine competitive differentiators.
- Report bad news fast. Build a route for problems to reach decision-makers in days, because the cost of a hidden problem compounds.
This is also where an experienced partner earns its keep. When a program has already stalled, the fastest route forward is usually a senior team that can ramp in days, audit what exists, and restart delivery around outcomes rather than a full rewrite. That takeover-and-stabilize approach is the core of how we run digital transformation services, especially for mid-market retail and operations teams that cannot afford to start over.
A transformation does not fail on the day it is cancelled. It fails in the quiet months when the warning signs are visible and nobody acts on them, so the most valuable thing any leader can do is shorten the distance between a problem appearing and a decision being made. If you want a second set of eyes on a program that feels like it is drifting, contact our team and we will talk it through.
FAQ
See how Redwerk took over core development of an AI optimization platform and carried it through to a successful product launch
