Here is what I see this one as:
1. Multiple versions On Single Machine: More than one version of ReadyAPI can co-exists on single machine(use command line to use specific version rather than windows short cut which might be pointed to latest version). That makes it simple to use whatever version we want any point of time. In this case, the concern is that whether project opened / saved in latest version be compatible with previous version or not. To avoid the risk, having the projects under configuration management/repository such as git / svn etc would help to revert to any version that was compatible with older version of ReadyAPI.
2. Common Test Machine: Another test strategy is that use a separate test machine(which is common to the team), which I believe is one of the best approach, where the tests can be run / executed continuously (even using Continuous Integration). Just do the upgrades on this machine. If the tests goes fine well and good. If not, any way continue to use previous version (as per #1).
This is even helps to reduce the load on individul team members / engineer's machine; they can focus on developing the tests and execute the tests on test machine.
3. Upgrade Criteria: You may also define the process when to upgrade for your team or organization. Instead of going for the each upgrade, you can go for it on meeting your criteria such as
a. the upgrade has fixes to your critical issues
b. new feature enhancements that you might require
c. fixes for any performance bottlenecks.
Of course, you can define your own criteria.
Hope this helps.
