This is Part 2 of the Symptoms to Sources series, drawn from Test Double's original research report, Symptoms to Sources: Biggest Software Challenges for Healthcare in 2026.
- Healthcare software teams keep fixing symptoms: Real problems run deeper
- You are here: Legacy systems and delivery pressure: Symptoms healthcare tech teams keep treating
- The root causes healthcare teams overlook: Siloed data and misaligned priorities
- How to shift focus from symptoms to build stronger healthcare software systems
Sara Saldoff's product team set out to improve the online scheduling system for OhioHealth. "In 2016, we built an amazing front-end scheduling experience. It was beautiful. Our testing showed customers loved it. It was super easy to use–5 out of 5 stars. Then, we turned it on, and there were only a few appointments to schedule–the availability wasn't there."
Like so many in their shoes, the product team focused on the technical solution—improving the UI—but provider access was a broader systemic capacity issue.
Without the operations team in the conversation, the product team didn't understand the underlying process for generating appointments. They solved the technical problem but didn't dig deeper into the business problem. The beautiful new UI still couldn't help patients more easily schedule appointments.
Today, Saldoff and her team work in lock step with their operations counterparts, solving problems together. The most recent redesign earlier this year saw a 63% year-over-year increase in conversion—due to increased access and solutions that considered both the customer and the business.
"We always want to improve the experience for our customers, but we can't do it alone, we have to have our operations and IT partners at the table throughout the journey."
— Sara Saldoff, OhioHealth
The OhioHealth product team's learning experience is common in software development. It's human nature to solve the frictions in front of you and take action in your sphere of influence.
But failing to collaborate across teams to unearth and resolve larger issues gets in the way of achieving business goals. Everyone stays busy building another new feature or working through another legacy rewrite—but never improves the customer experience as a whole.
In fact, Pendo analyzed anonymized usage data and found that 80% of features in the average software product are rarely or never used—reflecting up to $29.5 billion in investments by publicly traded cloud companies to build these features.
80% of features in the average software product are rarely or never used
Here are some of the common symptoms that healthcare technical teams address, even while deeper issues are at play.
Technology debt in healthcare: pileup with no plan
Technical debt is often the result of good intentions. In the race to deliver new features or meet deadlines, teams solve bugs through quick workarounds, delay refactoring (creating muddier code), omit or rush through automated test suites as timelines near, and skip documentation to "just get the work done."
Over time, the result isn't just messy code or slow performance—it's a hidden tax on productivity, innovation, and team morale. Engineers spend more time troubleshooting old issues than building new functionality. Defects become visible to the customer, and the company wastes budget on maintenance.
For healthcare product and business teams, this means slower releases, higher costs, and less capacity to respond to market or regulatory changes. These are massive risks in a space where compliance and interoperability rules shift often and security stakes couldn't be higher.
Paying down tech debt isn't a quick technical fix or a one-off project. It's a transformation in thinking and approach—rooted in deeper process change, better communication, and reformed company culture. Otherwise, unclear ownership, unrealistic timelines, and prioritizing delivery speed over sustainability continue to cost the organization and customers significantly.
Legacy modernization in healthcare: updating tech for tech's sake
When release cadence slows, defects climb, or delivery targets slip, it's tempting to blame the tech stack: "Our legacy systems are slowing us down." And yes, they probably are.
Modernization can help, but only when it's tied to a specific outcome—shorter claim cycles, fewer prior-auth denials, improved schedule availability, or higher patient/member adoption—and augmented with improvements on the human side: processes and organizational systems.
Updating tech for tech's sake is a band-aid. Defaulting to a full rewrite is often a costly trap that solves symptoms, not root causes.
Instead, we recommend choosing the smallest viable change that moves your target metric: refactor, replatform, harden integrations, or (occasionally) rebuild.
The blockers we see most often live where people, process, data, and systems meet: unclear outcomes and success measures, fragmented ownership, brittle integrations and data quality, and delivery or process constraints.
If you want to enable larger business outcomes—speeding insurance claim turnaround times or reducing denied authorizations—but legacy applications are the blocker, you can't afford to ignore them. Prioritizing investments in technical systems that enable business impact can provide enormous ROI.
By improving both technical systems and process-based systems, you improve internal expertise and resources, capacity and bandwidth, trust and confidence, appropriate expectations, and autonomy to make decisions and experiment.
To keep remediation or modernization efforts from recurring every few years, teams, organizations, and processes must also shift.
Delivery pressure in healthcare software teams: speed for speed's sake
The team isn't moving fast enough. We're not producing enough in each sprint. Sound familiar?
Accelerating team velocity is a common goal for healthcare dev teams aiming to prove business contributions through productivity metrics.
"The incessant focus on delivery pace and just getting more things done is often a result of unrealistic expectations or unclear priorities. It leads to a bunch of technical debt and garbage from cutting corners, and that cycle continues to repeat–with another rewrite every two years."
— Todd Kaufman, CEO and Co-founder, Test Double
This high-pressure, unsustainable pace gets in the way of long-term progress. You want to build systems that scale with the company—not systems that later become operational nightmares.
Speed for speed's sake is never the right metric. The real question: how do you accelerate time-to-value, getting vital capabilities into customers' hands faster, without forfeiting quality?
Ironically, focusing on value, utility, and clarity over speed leads to shorter release cycles, faster delivery of working features, and measurable improvements to the customer experience. "Speed" is not a proxy for progress.
The biggest blockers healthcare executives described in our survey: limited budget and resources (79%), shortage of skilled talent and hiring challenges (36%), followed by technical debt and too many competing IT priorities (both at 21%).
All of these problems require examining not just the immediate issue, but investing in solutions that make teams more efficient and effective for years to come.
Frequently asked questions about tech debt and legacy modernization in healthcare
When is a legacy rewrite justified versus a refactor or incremental modernization?
A full rewrite is rarely the right first move. It's justified when the existing system can't support critical business outcomes—like a database that literally can't scale to handle growing patient transaction volumes, or an architecture so tightly coupled that every change introduces regressions across unrelated systems. Even then, a phased "strangler fig" approach (replacing components piece by piece while keeping the legacy system running) is usually safer than a big-bang cutover. We recommend starting by identifying the specific business metric you're trying to move—claim turnaround time, prior-auth denial rates, patient portal adoption—and choosing the smallest viable change that moves that metric. Sometimes that's a refactor. Sometimes it's hardening an integration. Occasionally, it's a targeted rebuild of one subsystem. The decision should be driven by the outcome you need, not frustration with the code.
How do healthcare engineering teams manage tech debt without dedicated budget allocation?
Most healthcare organizations don't have a line item for tech debt remediation—and waiting for one is a losing strategy. The teams that handle this well build tech debt reduction into their normal delivery cadence. That means allocating a consistent percentage of sprint capacity (typically 15–20%) to refactoring, test coverage, and documentation—not as a separate project, but as part of how the team delivers features. The cultural shift matters more than the tactical approach: leadership needs to understand that tech debt isn't a technical problem to be solved once, but a continuous cost of doing business that compounds when ignored. Framing tech debt in terms of its business impact—slower releases, higher defect rates, increased security risk—helps make the case to non-technical stakeholders.
Why does "accelerating delivery velocity" often make healthcare software teams slower over time?
Velocity as a metric measures output, not value. When teams are pressured to increase velocity, they optimize for completing more tickets—which incentivizes smaller, easier work items and shortcuts that skip testing, documentation, and refactoring. The short-term output looks productive, but the accumulating tech debt and quality degradation slow the team down within months. In healthcare specifically, this cycle is more dangerous because quality issues have compliance and patient safety implications. The teams that actually deliver faster over time focus on reducing cycle time for meaningful work—getting a feature from idea to production faster—rather than maximizing story points completed per sprint.
What comes next in this series
Tech debt, legacy rewrites, and delivery pressure are real—but they're symptoms, not the disease.
In Part 3, we explore the three root causes that sit beneath these recurring problems: siloed data, wrong metrics, and strategic misalignment. Understanding the source is the first step to breaking the cycle.
- Healthcare software teams keep fixing symptoms: Real problems run deeper
- You are here: Legacy systems and delivery pressure: Symptoms healthcare tech teams keep treating
- The root causes healthcare teams overlook: Siloed data and misaligned priorities
- How to shift focus from symptoms to build stronger healthcare software systems
Read the full report: Symptoms to Sources: Biggest Software Challenges for Healthcare in 2026
Know a leader in healthcare who cares about these things? Share the survey with them so we can expand our findings.
