Your Software Platform Is Falling Behind Your Own Devices

Here’s what to do about it

AI in medtech has moved beyond experimentation. Today, it’s embedded across clinical workflows, You built a best-in-class device. Then another. Then a full portfolio. And somewhere along the way, the software platform holding it all together quietly became the most expensive problem on your roadmap that nobody is talking about out loud.

The conversation is happening, though. In boardrooms and engineering offsites, it sounds something like this: “We have AI capabilities we want to push across our device portfolio, but our platform was not built for that. Half our devices run on different codebases, some in languages our current team barely uses, and none of them were designed to talk to each other.” That is not an edge case. It is the rule.

The data confirms the scale of the problem. According to the HIMSS Healthcare Cybersecurity Survey, 39% of healthcare cybersecurity professionals cite legacy technology as one of their biggest operational security challenges, with legacy medical device operating systems specifically flagged as a risk factor by 25% of respondents.¹ And according to 2024 Best in KLAS research, more than 60% of healthcare executives identify outdated technology infrastructure as their single largest barrier to achieving digital transformation goals.² The medtech device developer faces the same structural reality, often at higher stakes.

The specific challenge runs deeper than outdated code. When a company builds products over years or decades, it accumulates a portfolio of devices that may share a brand but not a software foundation. Different programming languages, different data structures, different versions of the same platform, none of them originally designed with interoperability in mind. Even the board-level architecture can be a barrier. Now layer on the expectation that AI-enhanced data capture, cloud connectivity, and real-time analytics will work seamlessly and securely across all of it. That is not a software update. That is an architectural problem.

And it has to be solved in an FDA environment.

That distinction is what separates this from a standard enterprise IT modernization. You cannot refactor a codebase, push an update, and ship it. Every software change in a Class II or III medical device triggers design control requirements. Verification and validation must be documented, traced, and fixed at specific submission points. Interoperability between legacy and current platform versions must be formally assessed. The compliance burden does not shrink because the engineering is hard. It compounds it.

This is where most companies stall. The internal team knows the clinical product deeply, but may not have the architectural bandwidth to execute platform modernization across a heterogeneous device portfolio while keeping active programs on track and submissions clean. The temptation is to defer: ship what works today and revisit the platform question next cycle. But the gap widens with every deferral. Each new device added to an aging architecture is technical debt that will eventually come due, usually at the worst possible moment.

The right approach is to treat platform modernization as a program, not a project. That means starting at the architectural level: mapping the full device portfolio, identifying where software versions, languages, and data structures diverge, and designing a modernization path that preserves what is working, builds interoperability where it is missing, and creates a foundation capable of supporting AI-enhanced capabilities in an FDA-traceable way. Done correctly, this work runs alongside active development. It does not require stopping the program to fix the foundation.

At Suntra, this is work we do at the architectural level, inside FDA Class II and III environments. We have guided clients from legacy platform architectures to containerized, AI-ready systems, across multi-language, multi-device portfolios, without disrupting what is already in the field.

If your roadmap includes AI, connected data capture, or new capabilities pushed across an existing device portfolio, the platform question is not a future consideration. It is a current one.

Sources
¹ HIMSS Healthcare Cybersecurity Survey: https://www.himss.org/resources/himss-healthcare-cybersecurity-survey/
² 2024 Best in KLAS Awards, Software and Services, KLAS Research: https://klasresearch.com/report/2024-best-in-klas-awards-software-and-services/3413