Overview

OCS applications have 3 types of upgrades that are identified by its release number. The 3 upgrades are:

Full Release

These releases are identified by the first digits of the release number, eg 208.00.000 identifies the 208 OCS full release. These release are usually made around every 6 months or greater. A full release supercedes all previous full releases, service release and hot fixes (to install them no previous releases are required).

Service Releases

These releases are identified by the next 2 digits in the release number, eg 208.03.000 identifies the 208.03 service release. These release are usually made every 2 to 3 months. A service release supercedes all previous service releases and hot fixes ( to install them no previous service releases or hot fixes are required).

Hot Fixes

These releases are generally to resolve critical problems only (occasionally an urgent enhancement may be released in a hot fix) . The are identified by the last 3 digits of the release number, eg 208.03.002 identifies the 208.03 service release with the 002 hot fix installed. To install a hot fix all previous hot fixes from the service release must also be installed.

The actual upgrade procedure for all types of releases is exactly the same. The following are the only factors that alter the upgrade procedure:

1. If the OCS release requires a Build Professional upgrade. (This is normally only ever be done with a full release, but occasionally may be done with a service release) Generally these will only occur every 12 months or greater.
    
2. If the OCS release contains a new OCS Client. (This can be done with any type of release, is always done with a full release and service release and only occasionally done with a hot fix)
    
3. Any extra instructions in the releases notes.

NOTE: The following upgrade procedures will generally need to be altered to meet specific site conditions. They have been written with the assumption of 1 test area and 1 production area.

NOTE: The upgrade procedures below do not include times but as an indication most upgrades should take less than 1 hour on most systems (or less time if the upgrade is broken up into separate steps eg the OCS Client can be installed prior to the actual upgrade of the applications are performed) The factors that may increase this time are:

1. BuildProfessional Upgrade (The time required to do this is beyond the scope of this article as operating system or database upgrades may be required)
    
2. Tables that need upgrading. Release notes identify any tables that are automatically upgrades with the release. The time taken to upgrade these tables will be variable based upon the amount of data in the table and the performance of the machine. The time taken to do the test upgrade will indicate this time if done on the same sized machine.
    
3. Any manual tasks identified by the upgrade. (This will have to be evaluated on each case)

Upgrade Procedure
 

1. Identify when a test upgrade is to be performed. These will dictated by your preferences on whether upgrades should be installed as soon as possible or if they should be batched together and performed on some predetermined interval. eg. Installing all hot fixes every 2 weeks.
    
2. Download the required release files from the TODAY Web Site. Read the release notes for the upgrades.
    
3. Plan the upgrade/determine procedure for the test upgrade. This upgrade procedure will have to be altered in each individual case based upon all the factors outlined in this document. Of particular importance is determining any special/manual tasks outlined in the release notes.
    
4. Notify all OCS users capable of running the test system of the planned upgrade. This will generally be done by email and/or an OCS login message. See the OCS message knowledge base article: OCS Login Messages
    
5. Identify if the release requires a Build Professional Upgrade. If it does you will need to refer to the Build Professional Upgrade Document Installing Upgrading Build Professional OCS. Of particular importance is to identify whether the upgrade requires an operating system and/or a database upgrade. This information can be found on the TODAY Systems Web Site. If an operating system/database upgrade is required then the testing phase may need to be performed on an independent machine. OCS should always be consulted prior to performing any upgrade which requires a BuildProfessional upgrade.
    
6. Identify/create a roll back point (this is usually a full system backup).
    
7. Ensure all users are logged off from the system and disable logins to the application. See the OCS message knowledge base article: OCS Login Messages
    
8. Identify if the release requires a new OCS Client. If it does you should install the new OCS Client as per the OCS client knowledge base article: OCS Client The OCS client should be installed in a new directory. We suggest using the release number of the client as part of the directory name eg.<ProgramInstallationFolder>\OCSClient\20803001 Configure the OCS client as per the knowledge base article.
    
9. Upgrade the OCS applications. This is performed by unzipping the upgrade files into the OCS setup directory, then running the setup application.
    
10. Change any icons/startup scripts/published application to use the new OCS client (if a new client was installed)
     
11. Test the applications. The test plan should consist of 2 parts. The first is to test any specific problems/enhancements contained in the release. The second is a standard test plan you should use for every upgrade. This should include testing the critical system functions you require to operate the software.
     
12. If problems are found during the test phase that stop you being able to install the new release then these must be logged with OCS. Once OCS puts out a new release fixing these reported problems then these upgrades procedures must be started again with the newer release.
     
13. If required, train users on any changes made to the system.
     
14. Plan the upgrade/determine procedure for the production upgrade. Please see notes for test upgrade plan in point 3 above. Generally this plan will be similar although changes may have been made because of problems in the test upgrade and/or because some tasks may have already been performed. eg. installing the new OCS client.
     
15. Notify all OCS users of the planned upgrade. This will generally be done by email and/or an OCS login message. See the OCS message knowledge base article: OCS Login Messages
     
16. Identify/create a roll back point (this is usually a full system backup).
     
17. Ensure all users are logged off from the system and disable logins to the application. See the OCS message knowledge base article: OCS Login Messages
     
18. Install the OCS Client if required. As per point 8 above. If the test and production systems are on the same machine then the OCS client will already be installed.
     
19. Upgrade the OCS applications. As per point 9 above.
     
20. Change any icons/startup scripts/published application to use the new OCS client (if a new client was installed)

After upgrading the applications some sites may require some post installation steps (eg. some systems may require the permissions on any upgraded tables to be reset)

The successfulness of the upgrade should be checked by testing some parts of the application or getting a production user to do some work. This is especially important if the upgrade is being done late at night or outside of the IT departments normal work hours, otherwise the system may be down/unusable for an extended period of time.