Version 29

    Also See:

     


    Overview

    This document will go over the entire upgrade process and provide you with all the general details you need to know before beginning an upgrade. Please read through this document carefully, in its entirety, before beginning the upgrade process.  It outlines in detail what the process is, what you can expect, when you can expect it, and what we expect from you.

    Getting Started

    The first step is to determine what type of upgrade you need and what version you want to move to. There are two kinds of upgrades which involve two very different processes:

     

    Point Upgrades

    A point upgrade involves keeping your existing instances and upgrading them to a new point-version of Jive, for example from 5.0.1 to 5.0.3.  If you are happy with the version you have but want to take advantage of bugfixes or minor improvements, you'll want to do a point upgrade.

     

    Major Upgrades

    A major upgrade involves building a new set of instances with a newer version of Jive on them while your existing instances are unaffected and can continue to be used until you officially cut over to the new instances. An example of a major upgrade would be from 5.0 to 6.0. If you want to move to a new feature set and take advantage of bug fixes, you'll want to do a major upgrade.

     

    For a full list of previous releases and a schedule of upcoming releases, please visit the Jive Release Schedule (Historic).

     

    Requesting an Upgrade

    Once you have determined the version and type of upgrade you want, you'll need to submit a case in your company support group here on JiveWorks. If you don't have access to your support group, a current member will need to invite you.

     

    If you have multiple communities hosted by Jive, it is very important that you submit your case in the correct group on JiveWorks which is relevant to the site you wish to upgrade to minimize delays in processing time.

     

    We recommend that you submit your upgrade case as soon as your team begins planning for an upgrade so Jive Hosting can begin the environment assessment process. This assessment may take 1-2 weeks to complete, and must be finished before any scheduling can take place. We also advise against delaying to notify us of your intent to upgrade while performing any internal development work on your custom artifacts; once the assessment is complete we will work with you to determine the timelines for your customizations work and schedule the upgrade.

     

    The following details must be included in your case to request an upgrade:

    • The exact version you wish to upgrade to. If a version is not specified in your case, we will assume you want the latest one available.
    • The timeframe in which you would like the upgrade to happen. Though we cannot always guarantee a specific date you request, this will greatly assist with planning.
    • The instance you would like to upgrade. This helps eliminate potential confusion by clearly identifying the instance to upgrade. Please note:
      • Point upgrades are always performed on UAT before Production to ensure proper testing and help prevent issues.
      • A new set of instances including a Production and UAT are always built as part of a major upgrade.

     

    Point Upgrade Process

    The point upgrade process is typically fairly straightforward and does not require a large amount of time.  It's important to note before you decide to upgrade that Jive Hosting is unable to perform a rollback to an earlier version, should you encounter issues with a new version after an upgrade.

    For this reason, testing any customizations against the new version in your Internal Development instance before moving forward with a UAT upgrade is critical. This will limit the amount of time your UAT and Production sites are out of sync due to issues encountered on UAT.

     

    Scheduling

    • Point upgrades will be scheduled during Jive regular business hours, from 9 am to 1pm PT, Monday thru Friday.
    • Point upgrades outside these hours can be accommodated for an additional fee. Please discuss these options with your Account Manager.
    • The entire process can take anywhere from 30 minutes to several hours or more, depending on the database size. Most communities are within the 1-2 hour range.
    • Once UAT is upgraded, Hosting will coordinate the timing of the Production upgrade with you. We typically require 2-4 weeks notice to secure a preferred time slot for the Production upgrade/Go-Live.

     

    Hosting Process Overview

    1. Site is put into Maintenance Mode.
      • During this time users visiting the site will see a simple message stating the site is currently undergoing maintenance.
      • If desired you can set a custom Maintenance page by using the Jive Cloud Admin Tool; instructions can be found here: Uploading a Custom Maintenance Page.
    2. Hosting performs a database backup.
    3. RPMs on the instance are upgraded. This is required.
      • If your RPMs are not upgraded, core functionality of your site will not work until they are.
    4. WARs are installed.
      • This pertains to stock WARs or custom WARs provided by our Professional Services team.
      • A series of upgrade tasks are performed and the database is usually backed up automatically by the WAR deploy process.
    5. Instance is restarted.
      • Any plugins which need to be updated in order to be compatible with the new version are also installed during this step.
    6. Site is taken out of Maintenance Mode.
    7. Hosting notifies you that the process is complete and invites you to test and validate the instance.

     

    Note: The Production upgrade follows an identical process to the UAT upgrade, and depending on how consistent the two instances are, you should see similar timings.  If you are in doubt, please request a "Prod to UAT Data Refresh" in a case before moving forward with the upgrade process.

     

    Major Upgrade Process

    Major Upgrades follow a slightly similar but considerably longer process to Point Upgrades.  There are two reasons for this disparity which are both fairly time intensive:

    1. A New set of Production and UAT instances are created to support the major upgrade.
    2. Existing data and settings must be transferred from your existing instance to the new instance.

     

    There are three main parts to a major upgrade:

    • New Instances Built
      • The first phase is when the new instances are built. This happens behind the scenes and is mostly invisible to you.
      • We also perform a Data Copy, where data from your existing Production instance is copied to the new Production instance, and any available Jive-supported modules are installed. The purpose of this is to give you time to explore and get familiar with the changes in the software, while having your existing data available. During this initial phase, customizations will not be carried over. At this point your original instances remain active and untouched.
    • Test-Run
      • The Test-Run phase includes another refresh of the data from your existing Production instance. The purpose of this phase is to flesh out any issues resulting from the difference in Jive versions (particularly in regards to customizations). At this point your original instances remain active and untouched.
    • Go-Live
      • The Go-Live is the actual transition from your previous Production instance running as your live site, to the new Production instance taking it's place. This happens after all the necessary testing and tweaks have been made during the Test-Run phase.

     

    These last two phases can take weeks or months to complete depending on various factors (e.g.: customizations / authentication changes / functionality testing).

     

    Below is a diagram which helps depict the unique phases your instances go through as you launch and undergo a major upgrade.

    HostedEnvironmentsDiagram.png

    Scheduling

    • Major upgrades are performed by Jive Hosting during the following hours: Monday thru Friday from 9am to 1pm PT.
    • Major upgrades outside these hours can be accommodated for an additional fee. Please discuss these options with your Account Manager.
    • The entire process can take anywhere from 90 minutes to several hours or more, depending on the database size. Most communities are within a 2-6 hour range.
    • Once a Test-Run of your Production upgrade is completed, we will coordinate the timing of the Go-Live with you. We typically require 2-4 weeks notice to secure a preferred time slot for the Go-Live.

    Part One: New Instances Built

    Your existing data is copied to the new instances during this stage. If you would like to test the software before there is any data on the new instances please include a request in your upgrade case. The purpose of this is to give you time to explore and get familiar with the changes in the software, while having your existing data available. During this initial phase, customizations and some plugins will not be carried over until you let us know that you are ready to schedule the Go-Live, at which point we will schedule a Test-Run. This is in the interest of expediency while providing you with your new version.

    Part Two: The Test-Run

    The Test-Run process begins as follows:

    1. Once you create a case you will be placed in the upgrade queue.  This queue can be a couple of weeks out, or it can be months, depending on the number of instances in the queue ahead of you. During major releases of the product the upgrade queue can grow quite large depending on demand.
    2. The case you create is first assigned to the Account Support team who will begin gathering some necessary details to support your upgrade.
    3. It is then transferred to an Environment Manager who will begin to plan and coordinate your upgrade and continue to gather more technical details pertaining to your instances.
    4. Lastly, the case is assigned to a Hosting engineer who will work to coordinate the process with you and provide more information.
    5. On the day of the test run, the Hosting engineer will run through a quick checklist to determine what kind of custom configurations your instance has, such as SSL Certificates, VPN tunnels, custom apache configurations, etc. Each custom configuration is noted and a separate case is created when applicable to make sure the configuration on your new instances matches the existing instance.

     

    Hosting Process Overview

    The Test-Run and the actual upgrade, or Go-Live, are very similar and both consist of the following steps:

    1. Begin Upgrade (This step only applies to Go-Live events)
      • During this step your site will be placed into maintenance mode and the Production site is stopped.
    2. Synchronize Data
      • Your database(s) is/are dumped off of the old instance and moved to the new instance.  This always includes the system database, and typically includes the analytics and EAE databases as well (if appropriate).
      • Your new Production instance is turned off.
      • The databases are loaded into the new instance.
      • For Test-Runs, email addresses are blanked and replaced with nonfunctional dummy addresses.  For Go-Lives, they are not.
        • Please let us know if you want to make any exceptions to this.
      • If applicable, your filesystem binstore is copied to your new instance.
        • During the initial Test-Run this item can take several days to complete; on subsequent Test-Runs and the Go-Live, only the delta is copied which typically decreases the duration of this process.
      • Pre-upgrade steps are performed.
    3. Run Jive Upgrade Console
      • Your new instance is turned on and the upgrade tasks are run through.
      • Once the upgrade tasks are run through, the instance is given a review to make sure the upgrade is successful.
    4. Deploy Jive Supported Plugins
      • All of the Jive Supported plugins called out in the Upgrade Project Doc are installed.
      • Some modules, such as Video, must be disabled on the old Production instance in order to continue using the same data in your new community. Therefore, they will be installed in the new Production but will not be fully enabled until your Go-Live.
      • In certain cases (generally upgrades from a pre-4.0 version) a filesystem binstore migration will need to be performed.
    5. Rebuild Search Indexes
      • The User and Search indexes are rebuilt at this time.
    6. Smoke Test
      • During this step Jive will perform a limited Smoke Test of the environment. Because of the many different ways our customers use Jive we do not perform an exhaustive test of the upgraded environment.
    7. Site Hand-Off
      • For Test-Runs, the instance is handed over to Account Support for final configuration via a new case.  Once the instance is ready they will update that new case to give you, the customer, the access credentials and module information.  Customers do not have access to the instances before this hand-off process occurs unless special arrangements are made.
      • For Go-Lives, the instance is handed over to the customer for validation. The site will remain in maintenance mode until validation testing is complete and is disabled by the customer via the Jive Cloud Admin tool.
      • Timings are recorded in the Upgrade Project Document created in your space by the hosting engineer performing the Test-Run or Go-Live.

    Important Notes

    • WAR deploys and theme deploys are not affected by this process.
    • The theme is not copied during Test-Runs.  It is your responsibility, either on your own or by engaging Jive Professional Services, to ensure that your theme works with the upgraded instance.
    • Any changes you have made to the pre-live site will need to be done again during Go-Live.
    • SSL:
      • As of Jive 7, using Forced SSL is a requirement, so if this is not currently implemented on your site our Environment Managers will work to coordinate this setup with you.
      • If your site has SSL enabled you will see an warning page about an invalid SSL certificate when navigating to your site during testing as the certificate URL will not match site URL.  The error is caused when you navigate to your instance using the <customer>.hosted.jivesoftware.com URL and your SSL certificate <vanity.url.com>  has been applied. Essentially this warning states that you tried to get to one URL, however you reached a site identified as as a different URL. Screen Shot 2013-05-16 at 4.37.10 PM.png
      • If your site has both SSO and SSL enabled we will deploy a wildcard certificate for the testing period; this will be replaced with your actual SSL certificate at Go-Live. This wildcard certificate will allow you to configure and test SSO, and will not show the invalid certificate warning page.

     

     

    Part Three: The Go-Live

    On the day of the Go-Live, the same process above occurs, with the following differences:

    1. Your old site is put into Maintenance Mode first.
    2. At the end of the process, a DNS cutover occurs (either on your side or ours) to cut your old instance over to the new instance.

    This will complete your upgrade. If DNS is not updated at the time of Go Live things such as SAML, Video, and Mobile will break or function incorrectly causing serious risk to your Go Live.

     

    After the upgrade...

    • Your old instances are turned off, and are decommissioned fairly quickly.  Typically trying to revert back after the cutover leads to data loss, so we operate under the assumption that a revert will not happen.  We ask that you operate under the assumption that as soon as you give the go-ahead and the cutover happens, rolling back is not possible.  Any time before that, we just turn on the old instance and you're rolled back for another try.
    • It is not unusual to see small issues that were not picked up on the Test-Run or in validation after the upgrade.  Please open a case with the appropriate Priority to Jive Support, and they will assist you in resolving any lingering issues.

     

    Regarding Customizations

    Most Jive instances have some level of customization in the form of themes, plugins, and/or core platform customizations. Please be aware that most customizations require some level of development effort to upgrade. If you have worked with Jive to deliver customizations in the past, please discuss your upgrade plans with your Account Manager to understand the impact. If you manage the customizations internally or with a privately contracted third party you will need to make arrangements to ensure the customizations are properly upgraded and tested before upgrading. Customizations not developed by Jive or Jive Representatives are the responsibility of the Customer or Customer Representative to deploy during the Test-Run and Go-Live.

     

    Regarding Enhanced Disaster Recovery (EDR) Sites

    If you have an EDR site it will be upgraded during the Go-Live process for both Minor and Major upgrades.

    Questions?

    Please see the Hosted Instance Upgrades FAQ.  Feel free to open a case with any remaining questions you might have, or reach out to your account manager.  We are here to help you succeed, but your success requires your active participation.