You develop a skip-level (or multi-hop) upgrade to update your Production environment to a version of the Identity Manager product that is beyond the next major release from your current version. For example, if you are currently using Version 6.0 of Identity Manager and want to upgrade directly to Version 8.1, this upgrade path would require a skip-level upgrade.
Upgrading several versions normally requires a series of upgrades. However, many customers want to minimize the number of upgrades in the Production environment, which in turn minimizes the downtime of your Identity Manager application, minimizes the cost of retesting the Identity Manager application, and minimizes the cost of retraining the people using the Identity Manager application.
Developing a single upgrade procedure to update a target Identity Manager version is technically possible and some customers find it feasible. The key point to understand is that, even though you are performing a skip-level upgrade in your Production environment, you still must perform each hop in your Development environment. For example, you must upgrade Identity Manager from Version 7.0 to Version 7.1 to Version 7.1.1 to Version 8.0 to Version 8.1 in your Development environment. After each hop, you build up a set of artifacts that is cumulative.
The most common approach for a skip-level upgrade is to update your application baseline with configurations and customizations that have been updated to work with each Identity Manager version on the path to your target version of Identity Manager. Your baseline also includes a cumulative script to update databases and a cumulative subset of update.xml. The net effect is that you develop a single upgrade procedure that makes changes that are equivalent to the changes that performing the series of upgrades would have done.
Performing a skip-level upgrade is more complex than a standard or single-hop upgrade. Skip-level upgrades require more technical insight into the mechanisms used by the Identity Manager product upgrade. A skip-level upgrade also requires closer analysis of the upgrade content for each Identity Manager product version in the upgrade path. Closer analysis allows you to produce artifacts that are properly cumulative and yet minimal. For example, if you simply combine all of the database table upgrade scripts into one script or if you combine the subsets of update.xml from each step into one subset, then your upgrade might perform a great deal of redundant processing.
This chapter describes special considerations for a skip-level upgrade. If you are uncertain how to proceed or if these considerations seem unclear to you, contact Sun Professional Services to request assistance with planning your upgrade.
At a high level, the steps you perform for a skip-level upgrade are the same as those performed for a regular upgrade. However, some of these steps are enhanced and some steps are repeated for a skip-level upgrade.
The following figure illustrates the skip-level upgrade process.
For planning purposes, the first difference between a regular upgrade and a skip-level upgrade is in how you perform Task 2: Choose the Target Identity Manager Version. When choosing the target Identity Manager version, you must plan your upgrade path.
The next, and biggest, difference between the two upgrade processes is that you must perform Task 6: Upgrade Your Development Environment through Task 9: Perform Functional Testing for each stop in the upgrade path. You must upgrade your Development environment and your application baseline for the Identity Manager product version at each stop in the upgrade path. You probably also want to retest after each stop in the upgrade path, which requires resetting your Test environment and promoting your Identity Manager application to the Test environment after each stop in the upgrade path.
You might think that retesting after each stop on the upgrade path is unnecessary, but testing the upgrade process and testing the Identity Manager application at each stop on the upgrade path minimizes your risk because you can identify problems quickly. Working with a smaller set of changes makes it much easier to isolate the cause of any problems.
For information about Identity Manager upgrade paths, see Upgrade Paths and Support Policies in Sun Identity Manager 8.1 Release Notes.
The standard upgrade processes supplied with each full Identity Manager release generally upgrade an existing installation from any version of the previous major release.
Remember that each stop in the upgrade path requires a different version of the Identity Manager product. To plan your skip-level upgrade, you must read the Release Notes provided for the Identity Manager product version at each stop in the upgrade path.
For example, if you are upgrading Identity Manager from version 6.0 to version 8.1, you must read the Release Notes for the following versions of Identity Manager:
Version 6.0 and all its service packs
Version 7.0 and all its service packs
Version 7.1 and all its patches
Version 8.0 and all its patches
When performing a skip-level upgrade, you must repeat Task 6 once for each stop in the upgrade path.
Perform Steps 1–14 as described in Task 6: Upgrade Your Development Environment for each Identity Manager product version to which you must upgrade to reach your Identity Manager target version.
Of these steps, only Step 9: Analyze the Changes must be significantly enhanced for a skip-level upgrade. See Step 9: Analyze the Changes for a Skip-Level Upgrade for the enhanced instructions.
Each iteration that includes a sample database table upgrade script requires changes to your overall upgrade procedure. You can run the database table upgrade scripts in the correct order or concatenate the scripts, but you must modify each sample script appropriately for your environment.
You might find that it is more convenient, more efficient, and ultimately safer to write a single database table upgrade script that is cumulative. In other words, write a single script that combines all of the processing that would have been done by each of the individual database table upgrade scripts if you executed those scripts in the proper order.
Executing a single database upgrade script simplifies the upgrade procedure and gives you the opportunity of eliminating redundant processing, such as creating indexes for one version of Identity Manager and then later dropping and re-creating the same indexes for another version of Identity Manager.
You can also identify an appropriate subset of the Identity Manager update.xml in each iteration that is required to update objects in the Identity Manager repository that are not managed as part of the baseline. For a skip-level upgrade, you must ensure that this subset of the Identity Manager update.xml is cumulative.
An updater is a program supplied with Identity Manager that updates configuration objects. The updater is invoked by an ImportCommand within update.xml or within a file that update.xml includes. An updater generally works only with the version of Identity Manager with which it was shipped. Because you are writing a “skip-level” upgrade, the updater probably will not work with the target version of Identity Manager. Adding any changed configuration object to your baseline is by far the safest approach.