DECIDE WHAT TO KEEP, CONSOLIDATE, OR RETIRE
Somewhere in the portfolio is a system nobody remembers approving, and nobody willing to be the one who turns it off.
—
Three teams are quietly running the same tool under three different names.
—
The last app you flagged for retirement turned out to run month-end. That one’s still live.
—
Finance, architecture, and the business unit each have a different list of what’s actually critical.
STALE BY THE TIME IT’S USED
Every rationalization effort starts with a list: every application, every platform, what it costs, who owns it. The list is usually right the day it's built and wrong within two quarters, because ownership turns over, a team quietly stands up a replacement, and nobody updates the record. By the time someone uses that list to decide what to retire, it's describing a portfolio that no longer exists.
The other failure shows up at the moment of the cut. An app gets flagged on cost alone, licensing looks expensive, usage looks low, and it turns out to be running something nobody mapped: the month-end job, the integration two other systems depend on. One bad retirement like that is enough to shelve the whole program, because the org remembers the outage, not the eleven apps that were retired safely before it.
Before anything gets cut
What the list says vs. what's actually true
| Question | What the list says | What's actually true |
|---|---|---|
| Owner | What the list saysA name from two reorgs ago | What's actually trueNobody currently accountable |
| Usage | What the list saysLow, based on license count | What's actually trueThree teams route through it daily under a different name |
| Dependencies | What the list saysNone noted | What's actually trueFeeds a job finance runs every month-end |
"The retirement that fails doesn't fail on cost. It fails on the dependency nobody mapped."
WHAT IT TAKES
Not a spreadsheet with everything on it. A short list, checked against what’s actually still running, with a name attached to every decision.
INVENTORY WHAT’S ACTUALLY RUNNING
Build the inventory against what’s actually running, not what was last documented, and validate ownership with the people using it today, not the org chart from two years ago.
Score what’s left on what it costs, what it’s worth to the business, and what breaks if it’s touched, so the decision is a trade-off you can defend, not a guess based on licensing cost alone.
Score cost, value, and blast radius
Start with what’s genuinely safe to retire, and put the savings in front of whoever’s funding what comes next.
sequence the cuts
That's TBM's job as much as anyone's: the taxonomy that ties every app to what it costs and what it delivers is what makes step two a real comparison instead of an argument.
WHY WE CAN SAY THAT
01
We’ve run these portfolio calls from inside Fortune 100 finance and technology organizations, not from a slide template.
We’re tool-agnostic. We’ve built the inventory and scoring model in Apptio, ServiceNow ITFM, Serviceware, Nicus, Excel, and custom-built models, whichever one your organization actually needs.
02
We don’t cut on cost alone. What travels across every engagement is checking the dependency before the app goes dark, not after.
03
IF THAT ISN’T THE ONE YOU WERE HANDED
Six assignments, one practice behind all of them. If this isn't the one you were handed, here are the other five.
BRING US THE APP NOBODY WANTS TO TOUCH
Thirty minutes with someone who’s done this before. Send the list you already have, and you’ll leave with a read on which cuts are safe and which ones need a dependency check first.
Falconbridge helps CIO and CFO teams get clear, defensible answers on technology spend, including cloud, SaaS, and AI.