Windows 10 and Qt 5 are out of support: migrating without recertification

A lot of certified medical software is a Windows desktop application. Viewing stations, planning tools, the PC next to an ultrasound or a laboratory analyser, service software for a device. Many of them were written ten or fifteen years ago and still run on the platform they were written for. In the last eighteen months two parts of that platform have run out of support, and the third is close behind.

Medical desktop software moving to a supported platform in small, verified steps

The dates

Platform	End of support	Paid extension
Windows 10	14 October 2025	Extended Security Updates for organisations until October 2028, price doubles every year
Windows 10 IoT Enterprise LTSC 2021	January 2032	not needed yet
Qt 5.15	26 May 2025	security patches by subscription only
.NET Framework 4.8.1	as long as the Windows it runs on
.NET 8	November 2026	none
SQL Server 2016	14 July 2026	Extended Security Updates until July 2029
SQL Server 2017	October 2027
Windows Server 2012 and 2012 R2	paid updates ended 13 October 2026	none
Windows Server 2016	12 January 2027	Extended Security Updates through Azure Arc

The supported targets today are Windows 11 or Windows 11 IoT Enterprise LTSC, Qt 6.8 (supported until October 2029) and .NET 10 (until November 2028).

Why an end of support date is a regulatory problem

An operating system without security updates is a known vulnerability that nobody will fix. For the FDA, a device with software that can connect to the internet by any means, a USB or serial port included, can be a cyber device. The premarket cybersecurity guidance (last updated in February 2026) asks for the level of support and the end of support date of every software component in the SBOM, and for information on how the manufacturer handles end of support. An unsupported platform in the SBOM is a finding waiting to be written. Under the MDR, Annex I asks for software built to the state of the art, with risk management that includes information security, and a notified body auditor reads an end of support date as plainly as anyone else.

Hospitals push from the other side. A hospital IT department that retires its Windows 10 machines will either isolate or replace a device PC that cannot be patched. A product that only runs on that PC becomes hard to sell.

Keeping the certification

A platform migration does not have to restart the certification, if the work is planned as a series of controlled changes. A change of operating system or framework that leaves the intended use, the functions and the risk controls as they were is a design change the quality system handles: an impact assessment, verification, updated documents. The FDA's guidance on when a software change needs a new 510(k) asks whether the change could significantly affect safety or effectiveness, and it names changes of libraries, drivers and the operating system as infrastructure changes to evaluate with care. The Medical Device Coordination Group (MDCG), where the national authorities and the European Commission agree how the MDR is applied, covers this in its guidance MDCG 2020-3 on significant changes to legacy devices. Notified bodies work from it, although it is not legally binding. It lists updates of a standard third party operating system as non significant, but a new operating system version that requires changes to the device software, or a major change of any component, as significant. For a device still sold under an MDD certificate this decides a great deal: a significant change ends the device's transitional status under Article 120 of the MDR, and the changed version can only be placed on the market with an MDR certificate. The framework step has to be checked against that list before the work starts. For a device already certified under the MDR, a substantial change has to be reported to the notified body before it is implemented, and the notified body decides whether the certificate still covers it. The answer has to be argued and written down, and that argument is much easier to make for a small change than for a large one.

So the plan is built to keep every step small enough that the argument stays simple.

How we would plan it

Inventory first. Before anyone picks a target, list what the application really depends on: the Windows version and edition, the framework version, the database engine and the server it runs on, every third party library and driver with its exact version, the installer, the hardware it talks to. The SOUP list in the file is the starting point, and in our experience it is never complete. The real list comes from the build environment and the installed files on a production PC.

Tests before changes. The evidence that a migration changed nothing is a regression run that passes before and after. If the application has automated tests, good. If it has a manual test protocol that takes a week, that is the first thing to fix. We write characterisation tests around the current behaviour, especially the parts that carry risk controls, and run them on the old platform to record the baseline. Sometimes this needs a small refactoring so the hardware can be simulated.

Operating system before framework. Qt 5.15 lists Windows 11 among its supported platforms, and .NET Framework 4.8.1 comes installed with current Windows 11 releases, so many of these applications can run on Windows 11 or on Windows 11 IoT Enterprise LTSC without code changes. Moving the platform first, with the same binaries, is the smallest change with the largest security gain. It gets its own impact assessment and its own regression run, and it can be released on its own.

Framework second, in its own release. Qt 5 to Qt 6 changes enough to need real work: removed modules, changed APIs in strings, containers and graphics, a different build system if you move to CMake. .NET Framework to .NET 10 is straightforward for most WinForms and WPF code and painful for anything that used WCF services, remoting or app domains. These are code changes, so they go through the normal development process: design review, code review, unit and system tests, updated architecture and SOUP documentation.

No new features in the same release. This is the rule that keeps the certification argument short. A release that moves to Qt 6 and also redesigns the user interface is a design change to the product. A release that only moves to Qt 6 and passes the same regression suite is a platform change with evidence behind it. Whether it counts as a significant change is still decided in a change assessment under MDCG 2020-3. New features come after.

Update the security file with each step. New SBOM, new vulnerability review of the components, a note in the threat model where the platform changed.

What it costs to wait

Paid Windows 10 updates and Qt maintenance subscriptions buy time, and for a product near the end of its life that can be the right answer. For a product that will be sold for five more years, the cost of waiting is that the migration happens later, under more pressure, with fewer people who still remember the old code. I have also seen the opposite mistake: a team that decides to rewrite the whole application on a new stack, and two years later still ships the old one because the new one is not certified.

Where we come in

We work on several medical codebases whose foundations were laid fifteen or even twenty years ago, and keeping them modern is a permanent part of our job. We review and update libraries, SOUP components, platforms, databases and whole operating systems, inside the client's IEC 62304 lifecycle. On one large .NET medical imaging codebase we have done this for more than eight years, with CI pipelines, signed builds and overnight regression suites. We know C++ and Qt from imaging and device work. A modernisation project for us starts with the inventory and a test baseline, and ends with a release the notified body or the FDA can follow step by step.

If your product is on one of the platforms above, I am happy to look at what it depends on and tell you how many steps the move would take. You can write to me at tamas.fodor@silurus-software.com.