Application rationalization projects rarely fail loudly. They stall. The inventory gets built, the scoring workshop happens, a decommission list is produced — and then eighteen months later the same applications are still running, the savings never landed, and nobody wants to be the one to restart it.
The failure modes are consistent enough to list. Here are the six we see most often, what each one looks like from the inside, and what to do instead.
Mistake 1: Rationalizing Everything at Once
The instinct is to do it properly: full inventory, every application, every business unit, one comprehensive programme. It is the single most reliable way to guarantee nothing ships.
A portfolio-wide effort in a large organization takes months to inventory before it produces a single decision. Sponsors lose patience. Staff rotate off. By the time the scoring is finished, a third of the data is stale and has to be re-collected. The programme dies of exhaustion rather than opposition.
Instead: pick one high-impact segment and finish it end to end — a single business unit, a single capability area like project management or file sharing, or the top fifty applications by spend. A completed slice that produced real savings buys you the mandate for the next one. A half-finished portfolio-wide inventory buys you nothing.
A useful test: can you name the date your first application will be switched off? If that date is more than a quarter out, your scope is too wide.
Mistake 2: Scoring on Contract Value or Opinion Instead of Usage
Two versions of the same problem. The first ranks applications by what they cost, which finds the expensive ones but not the wasteful ones — a $400K platform used by everyone is a better investment than a $30K tool used by four people. The second runs a workshop where stakeholders rate their own applications, which reliably returns the answer that everything is essential.
Neither produces a defensible retirement list, and both collapse the moment a department head challenges the result. Without usage data you have an opinion, and opinions lose arguments to the person with the most seniority in the room.
Instead: get login and active-usage data before the scoring workshop, not after. Licence counts versus active users in the last ninety days is usually enough to change the conversation entirely — "this is provisioned for 500 and 60 people opened it last quarter" is a fact, not a position. Our scoring rubric weights business value, technical health, utilization, and cost separately for exactly this reason.
Mistake 3: Retiring an App Without Mapping Dependencies
This is the mistake that ends programmes, because it is the one that causes visible damage. An application scores low, gets approved for retirement, and is switched off — and it turns out a monthly board report was built on an export from it, or a workflow in another system authenticated through it, or the finance close depended on a file it dropped somewhere every night.
The undocumented dependency is the norm rather than the exception. Applications accumulate integrations, scheduled exports, embedded reports, and workflow automations that were built by someone who has since left and were never written down anywhere.
Instead: before any retirement, run a structured dependency check — inbound and outbound integrations, scheduled jobs and exports, reports and dashboards sourcing from it, and anything using it for authentication. Then leave the application running but access-restricted for a defined period rather than deleting it outright. A quiet month of restricted access surfaces the dependencies your audit missed, at a cost of one month's licence rather than an incident.
Mistake 4: No Stakeholder Buy-In Before the Decision
The technically correct decommission list, delivered as a surprise, generates more resistance than a slightly worse list that people were consulted on. Department heads who find out their team's tool is gone after the fact do not just object to that decision — they oppose the entire programme, and they tell their peers to do the same.
Rationalization is a political exercise wearing an analytical costume. The analysis tells you what should happen; the politics determine whether it does.
Instead: take the scoring to the owning stakeholder before it is final, and be explicit that you are asking them to challenge the data. Two things follow. They frequently supply context the data missed — a low-usage application that carries a regulatory obligation, say. And when the decision goes against them anyway, they have been part of it rather than subjected to it.
Mistake 5: Treating It as a Project Instead of a Process
A rationalization effort that runs once produces a one-time saving and a portfolio that starts re-accumulating the day it ends. Within two years the application count is back where it started, usually with a different set of redundancies, and the organization concludes that rationalization "didn't stick."
It did stick. It just wasn't given anything to stick to.
Instead: attach the outcome to a recurring control. A quarterly review of new applications, a renewal calendar with a mandatory usage check before any auto-renewal, and a lightweight intake step for new software requests will hold most of the gain. None of these is expensive; the whole point is that they are small enough to survive a change of sponsor. The complete guide to application rationalization covers what the ongoing governance layer needs to include.
Mistake 6: Underestimating the Migration Effort
Consolidation decisions get made on licence arithmetic — two tools at $120K becomes one tool at $80K, a clean $40K saving. What the arithmetic omits is the data migration, the field mapping, the historical records that have to be retained for compliance, the retraining, and the productivity dip while a team learns a new tool mid-quarter.
When that work turns out to be three times the estimate, the saving evaporates and the programme acquires a reputation for over-promising — which is far more damaging than the specific overrun.
Instead: estimate migration effort as a distinct line item before committing to the consolidation, and treat data retention obligations as a hard requirement rather than a detail. Some consolidations that look obvious on licence cost are not worth doing once migration is priced in, and finding that out in the analysis is a good outcome, not a failure.
If You're Already Stalled
Most stalled programmes we are brought into have the same shape: a large and reasonably accurate inventory, no completed retirements, and a sponsor who has stopped asking about it. The recovery is almost always to shrink the scope rather than to restart the analysis.
- Take the existing inventory — it is probably good enough — and pick the five lowest-risk retirements in it.
- Run the dependency check on those five only.
- Switch them off, in the restricted-access-then-decommission pattern, and measure what was actually saved.
- Report that number. A real, small, verified saving restarts a stalled programme faster than any amount of further analysis.
The organizations that succeed at rationalization are rarely the ones with the best scoring model. They are the ones that got something switched off early enough to prove the exercise works.
Stalled partway through a rationalization effort, or want to avoid these failure modes before you start? Our application rationalization engagements are built around finishing a first segment quickly. Book a free portfolio assessment →
