OSvC Upgrades in 5 Steps

I have been noticing that the Oracle Service Cloud (OSvC) upgrade process is still a bit of an unknown (to used a light term… as some call it “nightmare“) for some people, and hopefully this post will help put things in perspective and demystify it.

Since May 2014 release, Oracle decided to auto-enrol all new OSvC clients to the Auto Upgrade Programme (AUP). Nonetheless there are still many of you out there on the old model, only upgrading when you feel like, and request.

Even though it is not mandatory for you  to upgrade each time Oracle releases a new version of OSvC – i.e. every quarter (February, May, August, November) – it is recommended that you stay as current as possible.

This will ensure that your OSvC environment is as safe and stable as possible; any issues discovered in production sites are fixed; and that you face no delays when you are ready and willing to roll-out, and adopt, new features.

It is also important to know that once an environment is 1 year behind the latest release (i.e. 4 releases without upgrading) it will no longer receive Service Packs. And after 2 years without upgrading (i.e. missing last 8 releases) you will lose Oracle’s support.

So, with or without AUP, when you request or accept an upgrade, here are the 5 main steps of the upgrade, which you should look out for and/or carry out.

• Step 1 – When a new release is out, Oracle will send you an email notification…
  • Announcing of General Availability of the new release
  • Confirming the date on which your site will be cloned into an Upgrade Site
  • Advising that the upgrade cutover will occur 14 days after the Upgrade Site creation

Note: If you have any ongoing projects, changes or developments that may interfere with the upgrade, then you should contact Oracle to reschedule or skip the upgrade, and you can do that by raising a Service Request in the support site.

• Step 2 – On the agreed date, Oracle will create the Upgrade Site and send you an email notification…
  • Sharing the Upgrade Site URLs (usually domain–upgrade.custhelp.com)
  • Confirming the Cutover date (which should be set two weeks in the future)

Note: If you do not have availability to perform the necessary User Acceptance Testing (UAT) within the next two weeks, you should reschedule the upgrade Cutover using the Hosting Management System.

• Step 3 – You should perform any necessary regression and user acceptance testing in order to assure that the upgrade did not impact any standard or custom functionality.
  • Prepare the upgrade site for testing by re-configuring mailboxes (point to test mailboxes), integrations (point to test web service end points)
  • Test core functionality
  • Test channel interactions (email, chat, social)
  • Test customisations (add-ins, custom scripts, etc.)
  • Test customer portal
  • Test automation (business rules, workspace rules, etc.)
  • Test integrations (real-time, batch, etc.)
  • Test new functionality made available in latest release

Note: If you have any questions or find any problems in the Upgrade Site you should report them to Oracle following the normal support route, raising a Service Request in the support site.

• Step 4 – Oracle will perform Cutover and upgrade your production site to the new version.
  • During the cutover your site is inaccessible for both Agents (Console) and Customers (Portal). Customers will see a general message indicating that the site is undergoing maintenance. And it is possible to have a custom splash page display (see Answer ID 1306)
  • Customer won’t be able to access answers or submit incidents via the Customer Portal. However, emails can be sent to a Service mailbox, and will be queued in the mailbox(es) and incidents created when the Techmail utility runs for the upgraded site. Therefore, no incidents submitted via email are lost during the upgrade process
  • When your production site is upgraded the database from the existing production site is merged with the configuration files of the upgrade site. Please check Answer ID 1925 to see which changes are carried from the production and the upgrade site.

Note: You can request an adjustment of the cutover date and time. Oracle will send email notifications to confirm cutover start and completion.

• Step 5 – You should perform any necessary final checks, tests, etc.

Note: If you have any questions or find any problems you should report them to Oracle following the normal support route, raising a Service Request in the support site.

Depending on how much time you need to do the regression and user acceptance testing, the upgrade process may take between 6 and 8 or 10 weeks. And there is a crucial period you must not forget: the code freeze – from the moment Oracle creates the Upgrade Site (Step 2) until the upgrade itself is complete (Step 4).