I have been working on a large project for 10 years now.
The main program is called "HDT" which does data acquisition (so it must have DAQ hardware), and there is a subprogram "DFV" which is a data file viewer/analysis program, which can run on an engineer's desktop (with no DAQ hardware). Each DAQ installation includes a PXI (real-time) box, attached to a host (Windows) computer.
We stayed with LV 2010 for a while, and upgraded to LV2013 last year. We are now doing a large re-vamp of the whole thing.
I mentioned to my client yesterday that LV 2014 was coming out soon, and that it might (MIGHT) include some new UI widgets that would simplify a UI issue we are working on.
Here is is response, verbatim:
{...} but there are still a lot of tasks that come up when we do such upgrades.
There are 26 installations of HDT as DAQ and over fifty other installations of the standalone DFV. For each HDT and DFV installation (>76), I would need to run an installer to update the runtime engine. For each HDT DAQ install, I would also need to reinstall the runtime engine on the RTOS. For all of these installs, there is a LOT of scheduling involved and a fair amount of labor.
IOW, we need to have very good/strong justification for upgrading LV versions.
The "scheduling" he refers to is finding time in between tests (which use the equipment) to bring it down and do the upgrades.
QUESTION: What can I do to reduce the pain and suffering of a mass migration from one version of LV to another?