It is important to complete these tasks before an upgrade. Also see Jive Help > Upgrading. Customizations can be reapplied after the upgrade if they have been upgraded or are already compatible with the new version of Jive.
|1||Set up pre-production installation||If you will be upgrading on new servers (not in-place) then first complete Jive 7 On-premises Installation Checklist|
|2||Drain EAE queues||Confirm that all queue depths are zero on the admin console page, System -> Settings -> Activity Engine|
|3||Back up databases||Be ready to restore backups of core, EAE (if applicable), and analytics (if applicable) databases|
|4||Back up binary storage||If FileStorageProvider is being used for binary storage (Admin console: System -> Settings -> Storage Provider) as should is required for production installation be ready to restore binary content on the filesystem. Binary content corresponds closely with records in the core database so it important that the backups take place at the same time, or when there is no community activity.|
|5||Back up home directory||Be ready to restore /usr/local/jive/applications/sbs/home|
|6||Remove themes||Remove theme on admin console page, System -> Settings -> Themes|
|7||Remove plugins||Remove plugins on admin console page, System -> Plugins|
|8||Remove additional customizations & patches|
|9||Ensure database doesn't have more than 1 Jive schema||Other Jive schemas on the same database of the schema that's being upgraded might result in errors during the upgrade.|
|10||Understand Jive 7 differences||The Jive 7 web services do not listen on privileged ports, by default. Be prepared to make the appropriate adjustments. Before You Upgrade|
|11||Define rollback plan|
In case something goes wrong be ready to roll back at any point in the upgrade.
|12||Complete at least 2 dry runs|
At least 2 dry runs should be completed prior to the production run. The first one will help define the script to be followed in subsequent runs. The second dry run will provide confirmation of the script. The final dry run should follow the script in detail.
|13||Update TTL on DNS records||If the upgrade requires an update to DNS records ensure the TTLs are 300 seconds well before the upgrade.|
|14||Check known issues|
In-place upgrades - those performed on the same machines that are hosting the live production application - are discouraged for these reasons.
- Rollback plans for in-place upgrades tend to be more complicated because upgrade steps done on production machines cannot be undone.
- In-place upgrade plans have more risk.
- In-place upgrades do not allow some upgrade steps, such as installing the new rpm and applying configuration, to be competed before the maintenance window for the production run.
- Issues affecting the production run are less likely to be found in dry runs because they can't be done on the same machines as in the production run.