For MedTech software teams, small changes are rarely small. A SOUP update, a security patch, a new integration with a laboratory instrument: each one raises questions that developers and regulatory affairs cannot answer alone.
Modernization projects stall. Not because the technical work is hard, but because no one is sure what each change actually triggers on the regulatory side.
IEC 62304 defines legacy by evidence, not by age
Under IEC 62304, legacy software is medical device software that was legally placed on the market and is still marketed today, but for which there is insufficient objective evidence that it was developed in compliance with the current version of the standard.
The definition is not about how old the software is. It's about what can be documented.
The standard grants legacy software some allowances: it essentially has to meet the requirements that applied when it was placed on the market. Risk management is the explicit exception, and it applies regardless.
Clause 4.4 requires manufacturers to perform a gap analysis and a risk analysis, and to apply the activities prescribed for new devices depending on what those analyses reveal.
The standard itself is evolving. The second edition of IEC 62304, with expected publication in August 2026, formalizes the distinction between software maintenance and software development, and introduces a dedicated informative annex for legacy software.
The framing matters: the standard is recognizing that incremental change to existing software is the real working mode for most manufacturers, not the exception.
Small changes carry the largest hidden cost
The changes that create the most regulatory exposure are the ones that look like routine engineering work.
- A patch to a third-party library declared as SOUP
- A new endpoint to integrate with a different LIS
- A refactor to migrate from an unsupported framework
Each of these, under IEC 62304, requires re-evaluating whether the risk file is still accurate, whether the safety classification of the affected components still holds, and whether existing validation evidence is still sufficient.
Teams that don't have a process to make these evaluations explicit don't avoid the work: they postpone it. It surfaces later, all at once, during an audit, a notified body review, or a regulatory submission.
We think of this as compliance debt: it accumulates silently with every undocumented change, and it compounds in the same way technical debt does.
Every change starts with three questions
Before any change reaches the codebase, we frame it with three questions.
- Does this change the safety class of any affected component?
- Does this change the risk file?
- Does this change the validation evidence we need to maintain?
The three questions don't replace the formal process required by IEC 62304. They decide how much of that process applies to this specific change.
A typo fix in a UI label and a refactor of the diagnostic algorithm trigger very different answers, and therefore very different process overhead.
The upcoming distinction between maintenance and development in IEC 62304 Edition 2 makes this calibration more explicit at the standard level. The underlying logic is already in use for teams that work this way today.
Sustainable modernization is a process, not a project
Modernizing legacy IVD software sustainably means treating each change as an opportunity to reduce the gap between what the software does and what its documentation can prove.
The gap analysis required by Clause 4.4 stops being a one-time activity at the start of a modernization program and becomes a recurring step in the development workflow.
Where parts of the legacy codebase resist incremental documentation - typically older modules with no available evidence of their development process - IEC 62304 allows manufacturers to treat them as Software of Unknown Provenance.
SOUP is not a workaround. It's a tactical decision that lets the rest of the software move forward under full process discipline while constraining the risk surface of what cannot be reconstructed.
Building software that grows with its evidence
We think the most useful thing a software development partner can do for an IVD manufacturer with legacy systems is not to rewrite everything, but to design a working mode in which every change generates the evidence it needs.
That means architectural choices that make impact analysis tractable, a risk file that is updated continuously rather than reconstructed before audits, and a development process where the regulatory implications of a change are surfaced before the change is implemented.
This is the kind of work we focus on at Aimasoft: helping IVD software teams evolve their products incrementally without turning each release into a regulatory exercise from scratch.
Modernization is less about replacing the old code and more about putting the right process around it.
