On-premises Upgrade Checklist

Document created by Scott Romney Employee on Jul 16, 2014Last modified by Alex Evans on Jan 12, 2016
Version 14Show Document
  • View in full screen mode

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.

1Set up pre-production installationIf you will be upgrading on new servers (not in-place) then first complete Jive 7 On-premises Installation Checklist
2Drain EAE queuesConfirm that all queue depths are zero on the admin console page, System -> Settings -> Activity Engine
3Back up databasesBe ready to restore backups of core, EAE (if applicable), and analytics (if applicable) databases
4Back up binary storageIf 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.
5Back up home directoryBe ready to restore /usr/local/jive/applications/sbs/home
6Remove themesRemove theme on admin console page, System -> Settings -> Themes
7Remove pluginsRemove plugins on admin console page, System -> Plugins
8Remove additional customizations & patches
  • Remove overrides in etc directory (rm -rf /usr/local/jive/applications/sbs/home/etc/*)
  • Remove custom war (ensure /usr/local/jive/applications/sbs/application is a symbolic link to /usr/local/jive/applications/template/application)
  • Remove patches (remove non-standard jar files from /usr/local/jive/applications/template/application/WEB-INF/lib; they might have names like, a-fixpack-for... or aaa-fixpack-for...)
9Ensure database doesn't have more than 1 Jive schemaOther Jive schemas on the same database of the schema that's being upgraded might result in errors during the upgrade.
10Understand Jive 7 differencesThe Jive 7 web services do not listen on privileged ports, by default. Be prepared to make the appropriate adjustments. Before You Upgrade
11Define rollback plan

In case something goes wrong be ready to roll back at any point in the upgrade.

12Complete 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.

13Update TTL on DNS recordsIf the upgrade requires an update to DNS records ensure the TTLs are 300 seconds well before the upgrade.
14Check known issues

Review notes for your release in Jive Interactive Intranet for severe issues that should be addressed before launch.


In-place upgrades - those performed on the same machines that are hosting the live production application - are discouraged for these reasons.

  1. Rollback plans for in-place upgrades tend to be more complicated because upgrade steps done on production machines cannot be undone.
  2. In-place upgrade plans have more risk.
    1. 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.
    2. 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.