Moving instrument software off closed and aging platforms

The software usually still works. The problem is what it is tied to. The acquisition path runs through a vendor's closed protocol, so no other software can reach the hardware. Or the platform it was built on is aging, and the application survives on one machine, one license, and whoever last understood it.

The risk is lopsided. The old system's measurements are trusted, and a replacement has to show it measures the same thing before it earns the same trust. Without a way to show that, nobody wants to be the one who switched the old system off. Proprietary acquisition suites tied to their own interface hardware are a common starting point.

Before any new code is written, record what the existing system actually does: the channels it reads, the sample rates, the scaling and calibration, any filtering, and the files it writes. Then capture its output against inputs you can describe exactly.

The point is to turn "measures what the old system measured" into a written acceptance criterion rather than an impression. Where the old path can still run, the reference comes from it. Where it cannot, or where it is the thing being disqualified, the reference has to come from known signals instead.

A physical sensor is a poor reference, because its input is whatever the world happens to be doing. A known signal is a good one. Inject a synthetic waveform of known amplitude, frequency, and shape into the acquisition input, and check that the application acquires and displays exactly that.

On the current medical device program, a second LabJack, a T4 driven by the development laptop, feeds synthetic waveforms into the analog input of the LabJack T7 that does the acquisition. Acquisition and display are verified against known signals independently of the physical sensor.

A rig like this becomes the regression check for every later change, and it is what lets the old system be retired with confidence. Nothing is switched off until the new one has been checked against signals whose answer is known in advance.

Hardware choice comes before application code. Write the requirements down first, split into hard requirements that disqualify a candidate and soft requirements that rank the ones left, and explain each disqualification rather than asserting it.

This is an offering with one engagement behind it, and that engagement is in progress. The current program is replacing an incumbent third-party acquisition path. We have not completed a platform migration, and we would rather say so here than on the call.

What carries over is the method: reference data first, hardware chosen against written requirements, and verification against known signals before anything is retired.