Modernization in healthcare is usually measured by what gets implemented next: an ERP platform replaced, EHR systems consolidated, a database moved to the cloud. But a successful go-live does not equal successful modernization. The full value of a new investment is only captured when the legacy system it replaces is permanently shut down.
The “shutting off” is where the work often breaks down. The team responsible for the new implementation is understandably focused on getting the replacement system up and running. Success is measured by launch, adoption, stabilization, and business continuity.
Meanwhile, the old system is put on life support. The modernization initiative moves forward, but the operating expense, security exposure, support burden, and data access challenges that justified the replacement in the first place continue in the background. Research from industry leaders like McKinsey and Deloitte confirms that organizations spend up to 40% of their IT budgets maintaining technical debt.
The Core Challenge: The Illusion of Safety
CIOs and CFOs understand it’s expensive to keep these legacy systems alive. In a recent CHIME survey, 76% of CIOs recognized application rationalization as critical to their application portfolio management strategy, and more than a third identified it as a major driver of cost savings. Yet 80% admitted they have not yet fully implemented a program. A Forrester report found that 75% of technology decision-makers expect technical debt to rise to a “severe” level in 2026. The question is why?
A core challenge is that the status quo distributes cost and risk across the organization. Hosting, support, licensing, and security monitoring often reside in different budgets, making it difficult to see the full picture. Keeping an old system running may be inefficient, but it feels safe. After all, no one gets punished for delaying retirement, but someone may get blamed if records are unavailable after shutdown. Leaders fear the downside of turning them off more than they value the savings.
Today, that risk-vs-reward calculation is getting harder to justify. Financial pressure is making hidden operating expenses less tolerable. As hospital margins decline, healthcare finance leaders continue to prioritize cost control and operational strength. An increase in cyberattacks has made every unnecessary system another asset to defend. Analysts highlight that legacy technology is expanding attack surfaces while reactive risk management leaves providers vulnerable to costly recovery efforts and legal exposure. And as health systems invest in analytics, automation, and AI, fragmented legacy data is becoming a barrier to the clean, governed foundation those initiatives require. All of this makes the business case for decommissioning much harder to ignore.
The Deeper Problem: A Crisis of Governance
Yet, even with this mounting pressure, progress remains stalled. In fact, only 20% of healthcare executives say their organizations have a good program in place. That is because the financial and technical hurdles mask a deeper problem: organizational misalignment.
The reality is, decommissioning and archiving are typically treated like IT projects when they are actually enterprise decisions that require governance, funding, ownership, risk acceptance, and operational change. The work often involves many stakeholders but lacks a single decision-making structure. And without a repeatable process, every application retirement becomes a bespoke project with its own politics, delays, and exceptions. And because there is no established operating model, the true scope of retirement programs is almost universally underestimated.
The Hidden Complexity of Archiving
One of the first places this shows up is in defining the archive scope. Does the organization need to preserve the full application record, or only the legal medical record? What about billing history, audit trails, images, reports, search workflows, or application-like functionality? Should the data be retained strictly for compliance and release-of-information needs, or should it also be structured for future analytics and AI?
Getting the data out of a retired system is also harder than IT teams expect. If the organization has a 90-day termination window and misses the archive timeline, it loses leverage and may have to go back to the vendor for more time at a higher unit cost. Some vendors, once they know the customer is leaving, hold data in proprietary formats and require their own services to extract it into a usable SQL or Oracle database, which becomes expensive and difficult. Or exports may arrive incomplete, in proprietary formats, or missing the documentation required to understand the data relationships.
Older, unsupported applications can be particularly problematic. If the people who built it are gone, the organization is left to reverse-engineer how the system worked before it can safely preserve what is inside it. We once had a medical image system where the vendor said the version was 15 years out of support. The client had lost their credentials, and the images were in a proprietary binary format. In another scenario, the retirement target was a 22-year-old MUMPS application. The vendor had been acquired twice and dropped support; the people who built it were gone. No data dictionary, no documentation. We had to reverse-engineer the model — a naive extract would have looked clean while silently dropping linked records.
What’s more, extraction is still not the finish line. The archive must be validated, connected to release-of-information and audit workflows, approved by security and compliance, and updated through final data loads before the source system can be completely shut down.
What It Takes to Reach the Last Mile
The solution is not to ask implementation teams to take on more work. Decommissioning requires its own operating model, with clear ownership, decision rights, funding, governance, and playbooks that move applications from rationalization through retirement and archiving consistently.
This is a role Gartner has described as the “application undertaker”: a function responsible for governing the policies, procedures, services, and decisions required to retire applications in a controlled and lawful way. The term may sound unglamorous, but that is precisely the point. Decommissioning is rarely the work that gets the most attention. It is the work that determines whether modernization delivers the savings, risk reduction, and simplification it promised.
For many health systems, building that capability internally is difficult. The same teams needed for decommissioning are already supporting EHR optimization, cloud programs, cybersecurity, AI initiatives, application support, and day-to-day operations. That is why a managed services model is increasingly relevant. Health systems already rely on specialized partners for infrastructure, revenue cycle, cybersecurity, and cloud operations. Application decommissioning is becoming another area where dedicated expertise, capacity, and repeatable processes can make a meaningful difference.
A managed decommissioning service does not replace enterprise decision-making. Health systems still need governance, clinical input, compliance oversight, and executive sponsorship. But it can provide the structure, playbooks, technical expertise, and sustained project discipline required to keep retirements moving. In today’s environment, that matters. The cost, security, and data-readiness pressures are too high for decommissioning to remain a side-of-desk effort.
The Bottom Line
Modernization does not finish when the new system goes live. It finishes when the old system is no longer needed, the data remains accessible and trusted, and the organization can finally stop paying to support what should already be gone. The last mile of modernization is decommissioning — and health systems need a model built to finish it.
About Jonathan Cook
Jonathan Cook is Chief Technology Officer at Clearsense, where he leads product, engineering, security, and R&D for the company’s healthcare data enablement platform. With more than 25 years in healthcare technology, he has built and launched dozens of healthcare applications and products across quality measurement, value-based care, and population health, and is a recognized expert in health data aggregation, interoperability, and governance. Cook specializes in bridging business and technology strategy, with expertise spanning cloud architecture, AWS, cloud migrations, enterprise architecture, information security, software development, vendor management, and change management — including cloud cost and efficiency transformations at multiple healthcare technology companies that delivered millions in annual savings. He is a pioneer in HITRUST certification in the cloud — selected to speak at AWS re:Invent on cloud security — and is architecting an archive-first generative AI strategy to help health systems retire legacy applications while building an enterprise intelligence foundation for their data.
