Product engineering and modernization for MedTech, built on the actual reason regulated software calcifies.
Engineering teams in device companies know exactly what is wrong with their product. The architecture is understood, the debt is documented, and the improvements have been proposed repeatedly. They do not happen because in a validated product every change carries assessment, testing and documentation overhead that an ordinary refactor does not, which means improving the code frequently costs more than leaving it alone. That calculation is correct each time it is made, and over a decade it produces a product nobody can safely change.
Refactoring a function in ordinary software is an afternoon. In validated software it is an afternoon plus an impact assessment, a risk review, updated requirements traceability, verification evidence, a documentation update and a release record. The overhead is proportionally enormous for small improvements, which means small improvements stop being made. Teams defer them, batch them, and eventually stop proposing them, and the product accumulates a decade of changes nobody made because each one individually was not worth the paperwork.
The second problem is what happens when somebody finally proposes fixing it properly.
Small improvements carry disproportionate overhead
Which makes the rational local decision to leave the code alone, every time.
The debt compounds into immobility
Eventually the product cannot absorb a required change, which is when it becomes urgent and expensive.
Nobody remaining understands all of it
The original engineers have gone and the documentation describes the design rather than the system.
Dependencies reach end of support
A framework, a library or an operating system stops being maintained and the clock starts without anybody choosing.
Scalability limits arrive before anybody planned for them
A product designed for hundreds of customers meets thousands and the architecture was never the constraint until it was.
The product cannot be stopped
Customers depend on it clinically, which removes the option of a pause while it is rebuilt.
Measure what a one-line change actually costs you. Take a recent trivial fix and total the hours: engineering, impact assessment, test development, verification, documentation, review, release. In many device companies that number is an order of magnitude above the engineering time and nobody has ever calculated it. Once it exists, two things follow. The business case for reducing that overhead becomes concrete rather than theoretical, and the team can see which parts of the process are protecting patients and which are habits nobody has questioned since the last audit.
The highest-return early work in a calcified product is usually not refactoring, it is making change cheaper: automated verification that replaces manual test execution, traceability that is generated rather than maintained by hand, a build pipeline that produces release evidence as a by-product. Those reduce the overhead on every subsequent change, which is what makes incremental modernization viable at all.
Step 1
Measure the current cost of change, since that number determines which modernization strategy is even available.
Step 2
Reduce that cost first, through automated verification and generated evidence, before touching the architecture.
Step 3
Separate the regulated core from everything around it, so most of the product can move at ordinary pace.
Step 4
Map the debt against risk and change frequency, because debt in stable code that nobody touches is not urgent.
Step 5
Prefer strangling to rewriting, replacing bounded pieces behind stable interfaces rather than everything at once.
Step 6
Keep the product shippable throughout, since customers depend on it clinically and cannot wait for a rebuild.
Step 7
Agree the validation approach for each step with your quality function before the work rather than after.
Step 8
Deal with end-of-support dependencies on their timeline rather than yours, since that clock is already running.
Step 9
Capture knowledge from the engineers who understand the system while they are still available.
Step 10
Prove the improvement in the cost of change, which is the outcome the programme was funded for.
The rewrite is usually proposed because incremental change has been made impossible. When a team concludes that the product must be rebuilt from scratch, the reason is rarely that the architecture is beyond repair. It is that the overhead on each small change is so high that incremental progress is invisible, so a single large project feels like the only way to get the budget and the permission. In a regulated product a rewrite means re-verifying everything simultaneously, carrying two products for years and betting the business on a date. Reducing the cost of change first frequently makes the incremental path viable again, and that comparison should be run before the rewrite is approved rather than after it is late.
Integration estate modernization is covered on our Integration Platform Modernization page, and device-embedded software on our Medical Device Software Engineering page. These are the capabilities for the product itself.
Assess
Cost of Change Analysis
What a small change actually costs end to end, which determines which modernization strategies are economically available.
Architecture and Debt Assessment
Debt mapped against risk and change frequency, since the parts that matter are the ones you need to touch.
Dependency and End-of-Support Review
Frameworks, libraries, runtimes and platforms approaching end of maintenance, which set timelines you do not control.
Knowledge Capture
Documenting what the remaining engineers understand, which is the dependency most programmes discover too late.
Make Change Cheap
Verification Automation
Replacing manual test execution with automated suites that produce evidence, which is the largest single overhead reduction available.
Evidence as a Build Output
Traceability, test results and release records generated by the pipeline rather than assembled by hand each time.
Regulated Boundary Separation
Isolating the components inside device scope so the remainder can release at ordinary software pace.
DevSecOps and CI/CD for Regulated Products
Pipelines designed to satisfy a quality system rather than retrofitted to it, covered further on our DevOps pages.
Modernize and Scale
Incremental Replacement
Bounded components replaced behind stable interfaces, keeping the product shippable throughout.
Architecture Modernization
Service decomposition, API design and cloud-native patterns applied where they reduce the cost of change rather than for their own sake.
Cloud Migration
Where it serves scalability, cost or capability, covered on our cloud platform pages and assessed against regulated constraints.
Performance and Scalability Engineering
Addressing the limits a growing installed base exposes, before they become the reason a customer leaves.
The third column is what a change costs in each, which determines the modernization strategy more than the technology does. A product spanning several of these should not be treated as one codebase with one process.
| Product type | What it is | What a change costs |
|---|---|---|
| Device-embedded software | Running on the device itself | Highest. Full verification, and delivery requires a field campaign |
| Device-adjacent cloud | Computing values or behaviour the device depends on | High, and frequently underestimated because it looks like infrastructure |
| Clinical applications | Used by clinicians to make or support decisions | Substantial, with workflow disruption on top of verification |
| Connected platform services | Fleet management, telemetry, device operations | Moderate. Operational rather than clinical in most cases |
| Commercial SaaS products | Analytics, portals, administrative tooling | Ordinary, if the boundary from the regulated parts is real |
| Internal tooling | Build, test, support and operations systems | Low, and the right place to prove new practice before applying it |
Each of these is sometimes right and frequently applied because it is current rather than because it addresses the constraint. The third column is what it genuinely improves, which should be compared against the problem you have before committing.
| Move | What it involves | What it actually buys |
|---|---|---|
| Verification automation | Replacing manual test execution with automated suites | The largest reduction in cost of change, and the usual first step |
| Regulated boundary separation | Isolating device-scope components from the rest | Most of the product released from the heaviest process |
| Service decomposition | Breaking a monolith into independently deployable parts | Independent release, at the cost of distributed-system complexity |
| API layering | Stable interfaces around components you intend to replace | The ability to strangle rather than rewrite, which is usually the point |
| Cloud migration | Moving hosting and adopting managed services | Scalability and operational cost, rarely the cost of change itself |
| Stack replacement | Moving to a current language, framework or runtime | Hiring, support and security, and it is the most expensive option here |
Microservices will not fix a product you cannot test. Service decomposition is the most frequently proposed modernization move and it addresses deployment coupling, which is rarely the actual constraint in a device company. If the problem is that any change requires weeks of manual verification, splitting the product into fifteen services multiplies the number of things requiring verification and adds distributed-system failure modes to a team that was already struggling. Automated verification first, decomposition afterwards and only where independent release genuinely helps, is the order that works. The reverse is how organizations end up with a modern architecture that is slower to change than what it replaced.
The product operates in a validated state and every modernization step is a change to it. What evidence each step requires, whether behaviour equivalence is an acceptable argument and how much can be grouped into one assessment are determinations for your quality function, and they shape the sequencing rather than following it. A programme planned without them produces work that cannot be released.
There is also a sequencing consequence. If each step needs its own assessment, the number of steps matters as much as their size, which argues for fewer and larger increments than ordinary software practice would suggest. Finding the grouping that satisfies the quality function while keeping each increment small enough to verify and roll back is the planning work that determines whether the programme runs at a reasonable pace or spends most of its budget on process.
Validation
- Treated as change to a validated state, with the evidence approach agreed per step before the work begins
- Behaviour equivalence used as the validation argument where the step is a replacement rather than an improvement
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
Traceability and evidence
- Requirements traceability generated from the pipeline rather than maintained by hand, which is where the overhead sits
- Verification evidence produced as a build output so it is current rather than assembled before a release
- Configuration and version control across code, tests, evidence and the regulated boundary definition
- Change history preserved across the modernization, since an investigation may span the boundary
Cybersecurity
- Component inventory maintained, since legacy dependencies are where unpatched vulnerabilities accumulate
- End-of-support components treated as a security timeline rather than a technical preference
- Secure development practice applied to the modernized components, covered on our device cybersecurity page
- Patient data handled to the obligations your counsel defines, including HIPAA where applicable
Operations
- The product kept releasable throughout, since clinical customers cannot absorb a pause
- Customer-visible change communicated and scheduled, because interface change disrupts learned workflows
- Rollback available per step rather than per programme
- Knowledge captured from departing engineers before the modernization depends on it
A product with comprehensive automated verification can be refactored, decomposed, migrated and rewritten in pieces, because every change can be shown not to have broken anything. A product without it cannot be safely changed at all, which is the actual condition most legacy MedTech software is in. Everything else in a modernization programme depends on this, and it is routinely scheduled after the architectural work it makes possible.
Building that suite against a system nobody fully understands is itself the hard part, and the honest approach is characterization testing: generate the suite from observed behaviour rather than from the specification. Recording what the system actually does across real inputs, and asserting that, captures the undocumented behaviour the specification omits. Some of what it captures will be defects, and those are preserved deliberately until the modernization is complete, for the same reason they are preserved in an interface migration: the only variable in a step should be the step.
Behaviour of the system as it is
Including the undocumented behaviour, since that is what customers depend on.
Evidence in the form the quality system needs
So automation replaces the manual process rather than running alongside it.
The integration points
Because unit coverage of a monolith proves very little about whether it still works.
Performance under realistic load
Since scalability limits are frequently why modernization was funded.
Regression across supported configurations
Versions, platforms and customer-specific options, which multiply quietly.
The rollback path
Tested with real data, because step-wise modernization depends on being able to stop.
Modernization programmes are usually reported as components migrated and technologies adopted. The outcome that matters is whether the organization can now make a change it previously could not afford, which is both the point and the only measure that survives scrutiny.
| Category | What we measure | Why it matters |
|---|---|---|
| Cost of a representative change | Total hours end to end, trended across the programme | The outcome being bought, and almost never measured before or after |
| Verification automation coverage | Proportion of verification executed and evidenced automatically | What determines whether any further modernization is affordable |
| Release frequency by component | How often each part ships, separated by regulated boundary | Shows whether the boundary separation actually released anything |
| End-of-support exposure | Components past or approaching vendor end of maintenance | The timeline nobody controls, and a security position as much as a technical one |
| Product releasability | Whether the product could ship today at any point in the programme | Long-lived branches are how modernization programmes fail |
| Deferred change backlog | Improvements proposed and not made, trended | The leading indicator of recalcification after the programme ends |
We will measure what a representative change actually costs, identify how much of that is regulatory and how much is manual process, map the debt against risk and change frequency, review your end-of-support exposure, and test whether the incremental path is viable before any rewrite is approved.
CaliberFocus is a MedTech engineering partner delivering product engineering and modernization for regulated software that has become too expensive to change. From cost of change measurement and verification automation to regulated boundary separation and incremental replacement, we make change affordable again before touching the architecture, and keep the product releasable to clinical customers throughout.
- Cost of change measured before any modernization is planned
- Verification automation and evidence generated by the pipeline
- Incremental replacement preferred over risky full rewrites
- Product kept releasable at every step of the programme
Security & Compliance
