Upgrade Process Notes

Oracle requires customers to upgrade their RightNow (now Oracle Service Cloud or OSC) site version at least every two years. This requires an engagement with OSC's upgrade team, where the client will be assigned a "Technical Migration Manager" to facilitate. Before OSC transitioned to versioned, managed APIs and frameworks, upgrades themselves were notoriously painful for clients with a large amount of customization work, but as the years progress, this process continues to become much smoother.

For partner and client-built customizations, though, the Oracle upgrade team will not touch, assist, or test these components during the upgrade (they will only work with customizations built by Oracle's in-house professional services department). These notes and links are meant to shed some light on the upgrade process.

High-Level Process

Upgrade requests typically follow the following process. These steps are a major simplification, and are meant only for high-level reference, you should defer to your upgrade manager for details. More information can be found here: Overview of upgrade process

  1. Oracle clones the production site, creating an upgrade site (which is inaccessible to the client at this point).
  2. Oracle internally completes their 'black box' configurations to set the site up, performs the upgrade on the clone site, and tests standard functionality. The Oracle upgrade team migrates deprecated custom code onto managed APIs, for the cases where a managed API is available. If the customization is partner or customer-built, the partner or customer needs to handle this.
  3. Oracle releases the upgrade site to the client for UAT.
  4. Client tests all functionality in the upgrade site and signs-off on UAT.
  5. At a scheduled cutover date, the production site is upgraded which typically takes only a few minutes:
    1. Any DB schema changes are applied to the production database
    2. The production site's file system is essentially pointed to the upgrade site's file system
    3. Any internal 'black box' steps are completed to finalize the upgrade of the production system

File System vs Database

During cutover, because the production database is used, but the upgrade site's file system is used, there's a good rule of thumb to remember: Code, configuration, and files come from the upgrade site, data itself comes from the production site. It is highly recommended that any code or configuration changes be halted until after the upgrade is performed, but invariably there will be instances where this is not possible. Configurations are a bit of a gray area, and if they need to be changed, you should confirm with your upgrade manager specifically. This answer, Changes carried forward at upgrade cutover, provides some additional detail.

Specifically regarding customizations, here's a general synopsis of what happens during cutover:

  • CP code carries over from the upgrade site
  • Custom file manager code carries over from the upgrade site
  • AddIn code updates carry over from the upgrade site
  • AddIn additions or deletions will cause a mismatch between the file system and the production database, so DO NOT DO THIS. You must wait until after cutover is complete to add or remove AddIns.
  • CPM code: If you've taken the approach of including a CP library to encapsulate your CPM functionality, as recommended in CPMs: Custom Process Management, the CP libraries will carry over from the upgrade site. It is not recommended that the CPM file itself or its configuration settings be modified, as some components will carry over from the production site, potentially causing a mismatch.
  • Custom objects and fields carry over from the production site, but should not be modified until after cutover.
  • Business rules, workspaces, and reports carry over from the production site.

Additional Answer Links

Comments

I've also been unofficially told that when you start an upgrade, the production DB is actually immediately changed in some way. What this means is that their is really no "canceling" the upgrade. You have to move forward and eventually perform the upgrade cutover.

I was told this awhile ago, so I don't know if it's still true. Oracle is making ongoing improvements to the upgrade process so this may no longer be the case.

Zircon - This is a contributing Drupal Theme
Design by WeebPal.