Every renewal season the conversation is the same. Finance asks for a number — trim ten percent, hold flat, do more with less — and the assumption underneath the ask is that software spend is a dial you can turn down. It isn't. It's an estate. And the defining feature of the estate I have watched most mid-market companies operate is that it only ever moves in one direction. Applications get added when a team has a problem and a corporate card. They almost never get removed, because removing one is somebody's unpaid, unglamorous, faintly risky side project that no quarterly goal rewards.
So you end up with the archetype in the title. Four hundred applications — SaaS subscriptions, internal services, a couple of systems of record, the CRM nobody finished migrating off, three overlapping observability tools, a handful of apps that arrived through an acquisition and were never touched again. The bill is not your problem. The bill is a symptom. Your problem is that you have four hundred applications and no policy that ever says an application should stop existing.
That is not a budget problem. You cannot cut your way out of an estate with no exit. Give it a leaner budget and it will defer the migration, keep the legacy box alive on life support, and quietly book the difference as risk. The thing that fixes it is not a smaller number. It is a verdict on every application and a sunset policy with a default answer.
Run cost compounds silently, and nobody signs for it
The cleanest way I know to see the problem is the split the TBM taxonomy makes explicit: every dollar of technology spend is running the business, growing it, or transforming it. Run is the lights-on cost of everything that already exists. Grow and transform are the reason anyone hands you a budget in the first place. The trouble is that run is a ratchet. It compounds every time you add an application and almost never releases when you should have retired one, and because it compounds quietly — a renewal here, a support contract there, a little more integration glue every quarter — no single decision ever feels large enough to challenge.
Then one budget cycle you notice that run has eaten the portfolio. The grow work that justified the department is being funded out of whatever is left after the estate takes its cut, and the estate's cut only goes up. Nobody signed for that. There was no meeting where a leader stood and said, "I would like to spend a larger share of our capacity keeping old things alive." It happened by accretion, one defensible renewal at a time, because the org rewards shipping and is silent on sunsetting. I have never seen a job description with "decommission twelve applications this year" as a goal. I have seen a hundred with "launch" in the first line.
A verdict on every app, not another inventory
Most companies already have an inventory. It's called the CMDB, or the SaaS-management tool, or the spreadsheet the security team rebuilt for the last audit. Inventories are necessary and they are not the point, because an inventory tells you what you have and says nothing about what you should do with it. Four hundred rows with no decision attached is not portfolio management. It is a longer to-do list you will never do.
The device that turns an inventory into a portfolio is a verdict on each application, and the framework I keep coming back to is Gartner's TIME model, which sorts every app into one of four dispositions along two axes — how healthy it is technically, and how much business value it carries.
- Tolerate. It works, it's cheap enough, and it carries little strategic weight. Leave it alone — but write down that "tolerate" is a decision with an expiry, not a permanent amnesty.
- Invest. High value, healthy enough to build on. This is where new money and new integration should concentrate, and the discipline is to protect that budget from being nibbled away by the run cost of everything you refused to eliminate.
- Migrate. The business still needs the capability, but the current application is the wrong vehicle — end of life, off-platform, redundant with something better. The verdict is not "keep," it's "move, on a date."
- Eliminate. Low value, poor technical health, or fully redundant, with nothing downstream that breaks in a way you can't replace more cheaply. This is the quadrant everyone underpopulates, because eliminating is the only disposition that requires someone to do work and own the risk of being wrong.
The model is not magic. Its value is that it forces a sentence for every row — this app is tolerated, this one we invest in, this one migrates by Q3, this one dies — and a sentence is a decision, which is the thing the inventory never gave you.
Rationalization is attack-surface reduction, not just cost reduction
Here is where I get to reason from my own side of the house rather than the CFO's. The finance case for rationalization counts dollars. The security case counts blast radius, and it is usually the stronger case — it just never gets made, because the people who own the budget conversation and the people who own the attack surface are rarely in the same meeting.
Every application in that estate of four hundred is not a line item. It is an identity-provider integration, a set of service accounts and API keys, a data flow that copied some records somewhere, an OAuth grant a user clicked through in 2022, a patch surface someone is supposed to be watching, and a vendor whose own breach is now partly your problem. Retire the app and you don't just stop paying — you delete the credentials, close the data flow, remove the integration, and shrink the list of things an attacker can reach. Non-human identity is the sharpest version of this: the average retired application takes a fistful of long-lived secrets and standing grants with it, and those are exactly the credentials that show up in the post-incident timeline, still valid, still attached to a system nobody remembered was running.
The apps you can't see are worse than the ones you can. Shadow applications — the ones bought on a card and wired into your data without ever touching a review — are simultaneously the least valuable to the business and the most dangerous to the estate, which in TIME terms makes them the easiest eliminate you will ever find, if you can see them at all. This is why I argue for portfolio rationalization inside the security function and not only inside finance. A smaller estate is a cheaper estate, but more to the point it is a smaller thing to defend, patch, monitor, and answer for when an examiner asks who has access to what.
The kill decision has to be standing, not heroic
Almost every company eventually runs a rationalization project. Someone gets religion, a task force is named or a consultant is hired, forty apps get cut in a quarter, a number gets announced — and eighteen months later the estate is right back where it was, because the project was an event and accretion is a process. You cannot beat a process with an event. The only thing that holds is a standing rhythm, and the core of that rhythm is a default that runs the other way.
The default most estates run on is renewal. An application exists, therefore it renews, therefore it exists — the burden of proof falls on anyone who wants to stop it. A sunset policy inverts that. Every application carries an expiry, and at the expiry the burden of proof falls on the application: prove it should live. Not prove it's actively harmful — that bar is too high and nothing ever clears it. Just prove that someone will stand up and re-own it for another period. Most of the estate will clear that bar easily. The value is in the handful that can't, which under the old default would have renewed on autopilot forever.
- Attach a TIME disposition to every application and a review date to every disposition, so "tolerate" and "invest" both expire and have to be renewed on purpose.
- Run the review on a fixed cadence — quarterly is enough — as a standing forum with a named owner, not a fire drill before a budget cut.
- Give every eliminate and migrate verdict a date and an accountable person, because a disposition with no owner and no deadline is a wish.
- Report the estate as a trend — apps added, apps retired, run's share of spend — so the number that matters is net direction, not a one-time cut you can never repeat.
One honest complication, because it's the reason sunset gets deferred more often than any technical excuse. I'm not your controller, but the shape matters: internal-use software you built and capitalized under ASC 350-40 sits on the books as an asset, and retiring it early can force a write-off that lands in the current period. That accounting reality quietly biases the organization toward keeping capitalized systems alive past their usefulness, and it's worth naming out loud so the sunset decision gets made on total cost and risk rather than on which quarter absorbs the hit. The write-off is a one-time recognition of value that was already gone. The run cost and the attack surface are forever.
Start the rhythm this quarter
Attach a TIME verdict to every application, not just an inventory row. Give every disposition an expiry, so renewal becomes a decision instead of a reflex. Make one person own each eliminate and migrate, with a date. And count the estate the way you'd count risk — by net direction, not by the size of one heroic cut.
I'm writing this from the security-and-platform side of the house, reasoning toward a seat that owns the whole portfolio — so I'd genuinely like the pushback. If you've made a sunset policy stick, what gave it teeth: the cadence, the ownership, the security framing, or finance finally counting run as a trend? And if your last rationalization was an event that quietly decayed, tell me where it broke. Leave a comment — I read the replies, and I answer them.
