A radiology workstation from an earlier generation connected through a build server to its modern successor

Services · Legacy modernisation and takeover

Long running medical software, kept safe, current and maintainable.

Products that have been on the market for many years still need fixes, new features and security updates, while operating systems, databases, drivers and libraries reach their end of life. Silurus Software maintains and modernises these systems, takes them over from a departing supplier, fixes defects in the code and the documents, and sets up the tests and builds that show the state of the tested software in every build. Every change is assessed for its regulatory impact under your change control. We prepare the software part of that assessment, so your regulatory team can decide before the release whether the notified body (the independent organisation that certifies a device under the EU MDR) has to be informed or a new 510(k) (the FDA premarket notification for a device similar to one already on the market) is needed.

Book a 30 minute call Write to us

Languages: C · C++ · C# · Java · Python
Focus: SOUP, end of life, security
Process: IEC 62304 · ISO 13485 · ISO 14971
Route: EU MDR · FDA

What we cover

Keeping a long running product on the market

Platforms at end of life

We assess what depends on the platform and whether a move to a supported version is technically and economically feasible, then move the product and verify it there.

Outdated and vulnerable SOUP

Every third party component is checked for support status and vulnerabilities, and each update is assessed, tested and recorded.

Medical device cybersecurity →

Takeover from a supplier

We run handover sessions, take over the code, the build and the documents, and continue maintenance from the agreed handover date.

IEC 62304 gap analysis →

Code that is hard to test

We put characterisation tests around the current behaviour, kept apart from the approved requirements and with known defects logged, not frozen in, split the code into modules with unit tests that run in CI without the hardware, and measure the coverage as it grows. Hardware in the loop rigs test the modules on the real board.

Builds and regression

Builds run in CI with fixed tool versions and pinned dependencies, and regression tests run on every change.

Interfaces hospitals depend on

Real messages and datasets, anonymised, or pseudonymised where your data protection rules allow it, before they leave your environment, are turned into regression tests for each release.

Interoperability →

Field defects and maintenance

We find the root cause, fix and release under your maintenance plan, and correct the documents with each release.

User interface renewal

The interface is renewed step by step, with the full usability work IEC 62366-1 asks for on new and redesigned parts, and its Annex C route only for unchanged parts of the existing interface that were never assessed.

In practice

Situations we are asked to solve

Situation

Notified body findings on a device sold for years

A Class IIb device has been on the market since the directive era, and the notified body found gaps in the software records while the product has to stay on sale.

How we approach it

Silurus Software maps each finding to the IEC 62304 activity behind it and writes the records that the risk based gap analysis (a review of what is missing against the standard) of the legacy software route (IEC 62304 Amendment 1, clause 4.4) shows to be needed, and names the verification to be run anew where no evidence exists. Requirements recovered from the code are marked as such and reviewed by your team before approval. The product is not rewritten, and every change goes through your change control.

Situation

A supplier stops support in eight weeks

The external supplier of a Class IIa product ends support in eight weeks. It holds most of the knowledge of a C++ and Qt codebase and the build environment.

How we approach it

The first week after the team starts secures the code, the build environment and access to the supplier. Handover sessions run while the supplier is available, the build is made reproducible on our side, and the IEC 62304 gap analysis shows the state of the code and the file. By the end of the window, maintenance is with us for the agreed scope, open items are listed, and the next release follows the plan from the gap analysis.

Situation

A Qt 5 and .NET desktop product to modernise

The main product is a Windows desktop application in C++ with Qt 5 and some .NET components. It sells well and every change is slow.

How we approach it

We put tests around the current behaviour, move the logic into testable modules, assess the move to Qt 6 as a software change and, for devices still under a directive certificate, whether it is a significant change under MDCG 2020-3 (guidance from the EU Medical Device Coordination Group), then plan it step by step, each step verified and released under your change control.

Situation

Long on the market, with the original developers gone

A device has been on the market for many years. The original developers have moved on, components reach their end of life and security patches are needed.

How we approach it

We take over sustaining engineering for the long term: problem reports and CAPA (corrective and preventive action) inputs with root cause, complaint and post market surveillance support, SOUP and operating system updates, security patches and planned releases, with a named core team and a documented handover if people change.

How it runs

From the first look to steady maintenance

Step 1

Assessment

Code, build, SOUP and documents reviewed, with a list of risks such as end of life components and missing tests.

Step 2

Baseline

A build that runs on a clean machine, the SOUP list with current versions, and tests that record what the software does today.

Step 3

Modernisation

Platform updates, refactoring and fixes, module by module, each change verified and recorded.

Step 4

Maintenance

Problem reports, security updates and new releases under your maintenance plan, with the state of the software visible in every build.

Takeover

What we need from you when the takeover starts

For a takeover to start

Access to the source code repositories and the build environment, or a copy of both
The current software documentation, the risk file and the open problem reports
The list of released versions and where each one is installed
A contact at the outgoing supplier for the handover sessions
A named owner on your side for decisions and change control

What you receive

A product you can keep maintaining

D-01

SOUP and end of life report

Every third party component with its version, support status, known vulnerabilities and the plan for it.

D-02

Reproducible build

The build in a CI pipeline, with compilers, libraries and tools fixed to known versions and dependencies pinned, checked by rebuilding a released version and comparing the result with the released artefacts, with every difference explained and recorded.

D-03

Regression test suite

Tests that run on every build and show at once when a change breaks tested behaviour.

D-04

Maintained releases

Fixes, updates and features with impact analysis, release notes and updated traceability.

EU and US

Changes to a certified product

European Union

EU MDR

The software part of the change assessment for your notified body, checked against MDCG 2020-3 for devices still under a directive certificate.

United States

FDA

The software part of the decision whether a change to a 510(k) cleared device needs a new 510(k) or can be documented in your design and development records under your QMS.

Technologies and standards

What we work with

Technologies and tools

CC++QtQMLC#.NETWPFWinFormsJavaSonarQubeclang-tidyCoverityGoogleTestNUnitSquishJenkinsAzure DevOpsDockerGitCI/CD

Standards, regulations and practices

Characterisation testsSOUP listSBOMIEC 62304ISO 13485ISO 14971IEC 81001-5-1IEC 62366-1EU MDRMDCG 2020-3FDA 510(k)FDA guidance on 510(k) for software changesFDA QMSR (21 CFR 820)

Silurus Software

Silurus Software, founded in 2017, offices in Budapest, Hungary, and Singapore
More than 40 engineers, EU MDR regulatory specialists and FDA consultants
Work inside the client's ISO 13485 quality management system, with the split of tasks written down before the work starts. Where the client has no documented software process yet, we bring IEC 62304 templates for the client to adopt into its own system
Multi-year engineering partner of a European MedTech manufacturer
Founder and CTO Péter Török, in medical technology software since 1999, formerly software development director at Siemens Healthcare (syngo.via) and head of R&D at Mediso Medical Imaging Systems
ISO 9001:2015 (NQA, certificate 171041, valid until March 2027) and ISO/IEC 27001:2022 (NQA, certificate 728872, valid until August 2029)
Awarded AAA, Highest Creditworthiness, by Dun & Bradstreet in 2025
Research partner of ELTE Eötvös Loránd University, Budapest
Industrial partner of the University of Bologna, the University of Pisa, the University of Amsterdam and Masaryk University, Brno, in the EU Horizon Europe project LOGOS from 2027
Female Business Leader of the Year 2025 and The Pioneer Award 2026, awarded to CEO Dr. Linda Szántó

How we work →Quality and standards →Sample deliverables →Case studies →

Related work and pages.

Client names are withheld unless the client has agreed to be named.

Case study

Lab device refactoring and IEC 62304 documentation

Desktop application and firmware of a Dutch university medical centre's lab device refactored to be testable, with IEC 62304 documentation, in three months.

Case study

IEC 62304 feature development in a large .NET codebase

Senior developers inside a European manufacturer's lifecycle, QMS and review workflow, over several years.

IEC 62304 gap analysis Retrospective IEC 62304 documentation Medical device cybersecurity Regulatory consulting, EU MDR and FDA Established medical software vendors

FAQ

Frequently asked questions

Our product runs on an operating system that is going out of support. Can you move it?

Yes, after an assessment. We check what depends on the operating system and whether a move is feasible, then move the product to a supported version and verify and document the change under your change control. Where a move is not feasible, the risk controls and an end of life plan are documented instead.

How do you handle outdated or vulnerable third party libraries?

Each SOUP item is checked for its support status and known vulnerabilities. Updates are assessed for risk, tested and recorded in the SOUP list and the SBOM (software bill of materials, the list of every software component in the build).

Do you rewrite old software?

If you decide so, yes. We start with the smallest change that solves the problem, then set the priorities with you: which modules to keep, which to refactor and which to rewrite. The whole product rarely has to be rewritten, and every step is your decision, built under IEC 62304 and released under your change control.

Can you take over the product from our supplier?

Yes. Silurus Software is first qualified as a supplier in your quality system, and your regulatory team decides whether the notified body has to be told of the supplier change. We run handover sessions while the supplier is still available, then take over the build, the maintenance and the releases.

How do we keep a clear picture of the software?

Automated builds and regression tests run on every change, and the traceability and the SOUP list are updated with every release.

Can our own team take the product back later?

Yes. The structure, the tests and the records are written so that your own team or another supplier can maintain them.

Do you work with Qt?

Yes. Qt 5 and Qt 6 with C++ and QML, including the migration from Qt 5 to Qt 6.

How fast can you take over a product?

The first engineers start within two to three weeks of signature. The handover plan is set for the time the outgoing supplier is still available.

Do you support CAPA and post market surveillance?

Yes. Problem reports are investigated to their root cause and documented as input to your CAPA, complaint handling and post market surveillance processes.

Do you modernise WPF, WinForms and .NET Framework applications?

Yes. Our engineers have long experience with WPF and WinForms desktop applications and have migrated products from the .NET Framework to current .NET, step by step and verified at each release.

Talk to us

Tell us about the product.

The product, its platform and what needs to change. We reply with the first step.

Book a 30 minute technical call