new system - migration strategy

[tingox]

When we have created a new control system (known as "new system" forwards) for the Shopbot (a new way of operating it) we need to have a migration strategy in place. Note: requires that an acceptance test of the new system is done, and the result accepted.

Several possible strategies comes to mind:

• run "new system" and "old system" in parallel -- cons: requires extra effort in designing the solution, might not be feasible technically -- pros: high user satisfaction (users can use the system they know), user training (see #16 ) can take as much time as we need,
• run the "old system" for production usage, but switch to the new system for "training days" -- cons: requires extra time before / after training to switch shopbot control system -- pros: high user satisfaction both with production and training for the new system
• switch to the new system at a specific point in time (a "big bang" strategy) -- cons: user satisfaction depends on the amount of users who are trained for the new system when the switch happens, requires high effort / much time to train enough users in advance, some users might be unhappy that they need to train for a new system -- pros: the easiest technical solution to design

This requires more thinking.

[CISC]

To ease the burden of picking the "big bang" strategy we should perhaps strive to document the new system as much as possible.

If the ease of use and documentation is good enough the need for training should be minimal, at least for already experienced users.

[JensDyvik]

I think it is realistic to have the new interface so easy to use that a big bang transition will be acceptable.

I also agree that good documentation is important.