Version 4

    It is important to complete these tasks before an upgrade. Also see 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 9 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 is required for production installations, 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 the application is stopped.
    5Back up home directoryBe ready to restore ~/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 ~/applications/sbs/home/etc/*)
    • Remove custom war (ensure ~/applications/sbs/application is a symbolic link to ~/applications/template/application)
    • Remove patches (remove non-standard jar files from ~/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 9 differencesStarting with Jive 7 the webapp does not listen on the default privileged ports, 80 and 443. 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 and attest to the expected durations of each task.

    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

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

    15Delete fix packs for previous versionsDelete fix packs (.jar) for previous versions in ~/applications/<instance_name>/application/WEB-INF/classes//classes folder


    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.