There’s a machine like this in a lot of plants. It sits at the end of the line, it has tested every unit that shipped for the last ten or fifteen years, and everyone has quietly agreed on one rule: don’t touch that PC.
The test stand still works — mostly. But the computer runs an operating system Microsoft no longer supports. The data acquisition boards inside it haven’t been sold in years. The LabVIEW code behind it was written by an engineer who retired, changed jobs, or left behind a folder of VIs with no documentation and no version control. When it hiccups, production stops, and nobody is completely sure they could bring it back.
If that sounds familiar, this post is for you. Our team at Dynamic Engineering LLC has spent nearly two decades building and modernizing automated test systems for manufacturers, and aging test stands are one of the most common — and most fixable — problems we see. Here’s how we think about test stand automation in Ohio plants and beyond: when to modernize, what the path looks like, and how to do it without gambling your production schedule.
Why aging test stands became urgent, not just annoying
For years, the safest-feeling option was to leave a working test stand alone. Three things have changed that math.
Windows 10 reached end of support in October 2025. Microsoft ended free security updates for Windows 10 on October 14, 2025. A test PC that can’t be patched is a liability on any network — and many test-stand PCs can’t simply be upgraded in place, because the software and drivers they run won’t carry over to a new OS without engineering work. Plants that already went through this with Windows 7 and XP machines know how the story goes: the “temporary” air-gapped PC becomes a permanent single point of failure.
Legacy hardware is genuinely running out. NI (now part of Emerson) has published obsolescence plans for several legacy product families, and older DAQ boards, controllers, and interfaces that were workhorses in the 2000s and 2010s are no longer manufactured. When a board fails, the choices are the secondhand market, a shelf spare — or a redesign under emergency conditions, which is the most expensive possible time to do one.
The people who built these systems are leaving. The engineer who wrote the original code and knew every quirk of the fixture is retiring or has already moved on. Undocumented LabVIEW code isn’t a problem while it runs. It becomes a very large problem the day it doesn’t.
Any one of these is manageable. All three together mean an aging test stand isn’t a “someday” item anymore — it’s an operational risk with a timeline.
Warning signs your test stand is on borrowed time
A few patterns come up again and again when manufacturers call us:
- The “don’t touch it” PC. An old desktop running an unsupported OS, often deliberately kept off the network, with no clean way to get data off it.
- No source code, or no known-good copy. The application runs, but nobody can find the current LabVIEW project — or there are six copies and nobody knows which one matches the machine.
- Discontinued hardware inside. DAQ boards, GPIB interfaces, or controllers that are end-of-life, with no spares on the shelf.
- One person holds all the knowledge — and that person is a contractor, near retirement, or already gone.
- Quiet workarounds. Operators have learned to restart the software twice, ignore a certain error, or re-run a failed test “because it always passes the second time.” Each workaround is a measurement you’ve stopped trusting.
That last one matters more than it seems. A test stand exists to protect your customers from bad product. When nobody fully trusts or understands it, it’s no longer doing its real job.
A practical modernization path (that doesn’t stop production)
Modernizing a test stand doesn’t have to mean ripping everything out over a shutdown weekend. The approach we’ve refined across projects looks like this:
1. Assess and document what you actually have
Before anything is replaced, we inventory the system: instruments, DAQ hardware, wiring, fixtures, the software version tree, and — critically — what the test is actually supposed to measure and to what tolerance. Often the original requirements live only in someone’s memory. Writing them down is the single highest-value step in the whole project, because it turns tribal knowledge into an asset your company owns.
2. Recover and stabilize the code
Legacy LabVIEW applications can usually be recovered, brought into a modern LabVIEW version, and put under source control so there is always a known-good copy. From there, the code can be cleaned up incrementally — you don’t have to rewrite everything on day one to get out of the danger zone.
3. Migrate the hardware deliberately
Obsolete boards get mapped to current platforms — in our work that’s typically NI cDAQ and cRIO hardware, which cover most data acquisition, control, and instrumentation needs with a long support horizon. Because we handle cRIO and cDAQ programming in-house, the hardware swap and the software update happen as one coordinated change, not two separate risks.
4. Cut over in phases, and validate against the old system
Wherever possible, the new system runs alongside or is validated directly against the old one before it takes over. Correlation between old and new measurements is documented, so quality and certification records hold up. As an ISO 9001 and ISO 17025 certified lead internal auditor, I care a great deal about this step: a modern test stand you can’t defend in an audit isn’t finished.
What this looks like in practice
Two examples from our own project history, described generically:
We built and supported a water-heater test lab that grew to more than 45 stations. At that scale, “the PC died and we lost a bench” is not an acceptable failure mode — standardized, documented, maintainable LabVIEW systems are what make a lab that size operable by a normal-sized team.
We’ve also delivered ENERGY STAR appliance certification test stations, where measurement traceability isn’t optional: the data behind a certification has to stand up to scrutiny years later. The same disciplines — documented requirements, calibrated instrumentation, source-controlled code — are exactly what an aging production test stand needs, just applied earlier.
Modernize or replace? A quick rule of thumb
If the fixture and measurement approach are still right for the product, modernization — new PC, current DAQ hardware, recovered and refactored code — usually preserves the most value. If the product line has changed so much that the test itself no longer reflects real failure modes, that’s the moment to step back and design a new test stand rather than paying to preserve the wrong measurement. An honest assessment up front tells you which situation you’re in before you spend real money.
Talk to us before it breaks
The cheapest time to modernize a test stand is while the old one still runs. If your plant has a “don’t touch that PC” machine — in Northeast Ohio or anywhere else — our team can assess it, document it, and lay out a phased path to current hardware and maintainable code. Dynamic Engineering LLC has been building custom test systems from the Cleveland area since 2008, and as a LabVIEW consultant Cleveland manufacturers can reach directly, we’re happy to start with a straightforward conversation about what you have and what’s at risk.
Contact Dynamic Engineering — or learn more about Joe Zarycki and our background in test stand automation, data acquisition, and instrumentation.
