Overview

The Hosted Major Upgrade Process consists of a three-step process. This article explains what happens during the third and the final phase of the upgrade. This is the phase where the actual upgrade occurs and the old instance is cut over to the new instance.

Information

1. Begin the upgrade process.
   • During this step, your site will be placed into maintenance mode and the production site is stopped.
   • If desired you can set a custom maintenance page by using the Jive Cloud Admin Tool. Please refer to the instructions in the article Customizing the Maintenance Page Message for the process.
2. Synchronize the data.
   • Your database(s) 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 to load the databases. Note that this is the new upgraded instance and not the old instance.
   • For the Test-Run phase, email addresses are blanked and replaced with nonfunctional dummy addresses. But for Go-Lives, the email addresses are not changed. Please let us know proactively 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 the 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 reviewed to make sure that the upgrade is successful.
4. Deploy the Jive supported plugins.
   • All of the Jive Supported plugins called out in the upgrade project docs from previous phases are installed.
   • Some modules, such as videos, must be disabled on the old production instance 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, a filesystem binstore migration may be performed.
5. Rebuild the search indexes.
   • The User and Search indexes are rebuilt in this step.
6. Smoke Tests are done.
   • 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. The site hand-off.
   • Once the instance is ready, you will be provided with 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 with the Account Manager.
   • 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 tasks in the Test-Run and Go-Live phases.

Important points to note

• The WAR file 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 a warning page about an invalid SSL certificate when navigating to your site during testing as the certificate URL will not match the 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 a different URL.
  • 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.

Related Articles

• Refer to the article Hosted Major Upgrade Process to learn about the process overview.
• Click on any of the following articles to learn about the other steps of the major upgrade process:
  • Hosted Major Upgrade Process Part One: New Instances Built (Launch)
  • Hosted Major Upgrade Process Part Two: Test-Run