• Upgrade to a release that is supported on both OSs. If you are lucky, the software can be upgraded to a release that works on both the current system and the future system. If so, schedule an upgrade to that release before the OS upgrade. The tests developed in step 3 can be useful here.
• An upgrade is available but works only on the new OS. In this case, you must schedule the software upgrade after the OS upgrade is complete. Depending on the customer requirements, this upgrade may be required as part of the OS upgrade, or a service gap may be negotiated if the customers do not require uninterrupted access. For example, if a host is a busy web server, the customers may request that the new web server software be installed immediately because it is a major function of the host. However, if a little-used compiler requires an upgrade, the customers may simply request that it be upgraded in the next week or before a certain development cycle is complete. This is especially true if some other host can be used for compilation in the meantime.
• The product is no longer supported. Sometimes, it is only when we are upgrading an OS that we learn that a product is no longer being supported by the vendor. This may block the upgrade, or customers may be willing to change vendors or go without this product.