Author: Jason Rose, CEO, Clearsense

Most application decommissioning programs underdeliver for a reason that has nothing to do with effort or intent. They start with the wrong applications.

Teams tend to gravitate toward what is easiest to retire rather than what will generate the greatest financial return. They spend scarce internal capacity decommissioning smaller, lower-cost systems while the applications carrying the largest licensing, support, infrastructure, and maintenance costs remain untouched.

A classic demonstration offers a helpful analogy for this problem. An instructor sets a glass jar on a table next to a pile of large rocks, a bucket of gravel, a bag of sand, and a pitcher of water. Pour in the sand and gravel first, and the rocks will not fit. Place the rocks first, and everything else settles around them. Nothing about the jar or its contents changes except the order, which determines whether everything can fit.

Stephen Covey popularized the demonstration in his 1994 book First Things First, where he put the lesson bluntly: if you do not put the big rocks in first, you never get them in at all. Eight years later, writing in A List Apart, Jeremy Wright gave it the name that stuck, the Pickle Jar Theory. I have always just called it jar theory, and I have not found a better description of what goes wrong in healthcare application rationalization.

The rocks are the applications with the greatest potential for permanent cost removal. If you do not prioritize them first, smaller projects consume the capacity required to get to them.

1. Health systems fill the jar with sand

Cost optimization is no longer a line item on the IT agenda. It is the agenda. In Gartner's 2026 CIO Agenda for Healthcare Providers, 59 percent of provider technology leaders named cost reduction their top outcome priority for 2026 to 2027.¹

Health systems also recognize application rationalization as part of the answer. A recent CHIME survey found that 76 percent of health IT leaders consider application rationalization important or critical to their overall application portfolio strategy. Yet only 20 percent have a fully implemented, ongoing program.² The mandate is clear, and so is the execution gap.

The gap is less about awareness or capability than about attention, because retirement rarely competes well against the next implementation.

Part of the reason is where the work starts. When an organization commits to retiring applications, it almost always begins in the easiest place, with small departmental systems that have a single owner, no clinical dependency, and a maintenance contract nobody will defend. A year of those retirements can look like real momentum.

Then finance looks at the recurring spend and finds that almost nothing changed.

A relatively small number of systems can carry an outsized share of the licensing, hosting, and support burden. It is usually the same short list: the EHR replaced and never turned off, the imaging archive, the legacy ERP, and the lab system that arrived with the last acquisition.

Those are the "big rocks." They are also the applications an organization is least willing to touch, because they are large, technically complicated, politically owned, and full of data somebody still needs.

So, the sand goes in first, the jar fills, and the rocks never make it in.

2. Knowing which rocks are truly big

You cannot prioritize the portfolio if you do not have a clear view of what is in it.

Many health systems lack a single reliable list of every application they run. The picture is usually split across a contract management system, IT asset management systems, the general ledger, and separate lists kept by individual hospitals, departments, and acquired organizations. Some applications appear on none of them.

A list of application names is not enough on its own. A useful inventory also shows what each application truly costs, what functions it duplicates, who still depends on it, and how difficult it will be to retire.

Application portfolio modernization (APM) is the discipline that provides that fuller view. It maps every application in the portfolio, scores each one against the same criteria, and assigns it a disposition using Gartner's TIME (Tolerate, Invest, Migrate, Eliminate) model. The model weighs business value against technical fit. Retirement is one of four outcomes, not the goal in itself.

Few health systems apply that kind of assessment consistently. In a CHIME survey, 60 percent of respondents said they had no formal process for reviewing applications for archive and decommissioning or reviewed them only as needed.²

When the assessment is done consistently, it reorders the portfolio, and the systems that rise to the top are rarely the ones already queued for retirement. Gartner finds that roughly 20 percent of applications drive 80 percent of an organization's cost, complexity, and risk.³

If a system is expensive, difficult, and carrying data that cannot be lost, that is not a reason to defer it. That is the definition of a big rock, and it belongs in the jar first.

3. Capitalize expenses for the application retirement implementation

Once you know which applications are the big rocks, the next question is how to pay for retiring them. The answer is often sitting in a budget that is already open.

Health systems routinely use capital budgets to fund major EHR, ERP, cloud, and other modernization initiatives. What they often fail to do is include the related extraction, archiving, and decommissioning work in that same program while that funding is still in place.

That is a costly miss, because the implementation for each application can be capitalized. The project management, data acquisition, archival, and decommissioning work required to move an application onto a modern archive platform can be bundled as a single one-time implementation expense. That expense can be funded as capital rather than absorbed into the operating budget. What that one-time investment buys is the permanent removal of recurring operating expense for software licenses, hosting, infrastructure, and support. Just make sure your vendor’s contracting template supports this model as most do not.

4. Big rocks get more expensive the longer you wait

Big rocks resist retirement for real reasons, and each of those reasons is an argument for starting sooner rather than later.

Decommissioning a legacy clinical, financial, or operational system is rarely as simple as turning it off. The organization must confirm that the system no longer supports active workflows, determine what data must be retained, who still needs access to it, and how that access will be maintained for clinical, legal, and compliance purposes.

For a growing number of organizations, the archive is where that access lives. Gartner expects that by 2031, 70 percent of large enterprises will treat archives, rather than production applications, as the primary home for historical data, up from 40 percent in 2026.⁴ When clinicians, auditors, and legal teams can reach the records they need in a governed archive, there is no reason to keep paying to run the application that created them.

Then there are contracts to unwind, data extracts to obtain and validate, and infrastructure to retire, with stakeholders across HIM, legal, compliance, and finance who need confidence that nothing critical will be lost.

This is why decommissioning programs stall. Retiring a big rock takes governance, technology, operational discipline, and dedicated execution, and it cannot be done as side-of-the-desk work.

That complexity is not a reason to push these applications to the back of the queue. It is a reason to put the hardest, most expensive work at the front of the schedule while there is still time to plan it properly, because the longer a health system waits, the more institutional knowledge disappears and the less leverage it has with vendors, until end-of-support dates turn into emergencies.

5. No one owns retirement

Knowing which applications to retire, how to pay for the work, and why it cannot wait still leaves one question unanswered: who is accountable for it. Health systems have spent decades building the governance, budgets, and project teams required to bring new technology in. Far fewer have created the same discipline around taking it out.

Gartner calls the person who carries that responsibility the "Application Undertaker." The role is accountable for decommissioning old applications, eliminating the infrastructure and recurring costs around them, and ensuring historical data remains accessible and compliant.⁵

Almost no health system has an Application Undertaker.

Implementation projects have owners, budgets, and steering committees. Retirement is assumed to be a byproduct of implementation, which means it belongs to everyone and therefore to no one. Every shutdown becomes a negotiation, and the big rocks,  which require the most negotiation, often lose or get deprioritized. Naming a single accountable Application Undertaker is what makes retirement someone's job rather than everyone's assumption, and it is what finally clears the legacy applications and the technical debt that comes with them.

The jar is the same size for everyone

Every health system is working with the same constraints: limited staff capacity, capital, and only so much change the organization can absorb in a year. Financial return from application rationalization does not come from having more room in the jar. It comes from being deliberate about the order.

Put the big rocks in first. Everything else fits around them.

References

1. Gartner, 2026 CIO Agenda for Healthcare Providers. Gartner document ID to be confirmed before publication.

2. CHIME survey, application portfolio strategy and decommissioning practices. Survey name, fielding date, and sample size to be confirmed before publication. Confirm whether the 76/20 percent and 60 percent figures come from the same instrument.

3. Gartner, application cost and complexity concentration, G00797456.

4. Gartner, Use AI to Modernize Data Retention and Archiving, Apurva Singh, 18 August 2026, ID G00859449.

5. Gartner, Appoint an Undertaker to Decommission Applications, Andy Kyte, Gartner Symposium/ITxpo. gartner.com/smarterwithgartner/appoint-an-undertaker-to-decommission-applications