How Easy Is Upgrading?

Basically, how easy or how difficult it is to upgrade Identity Manager depends on how much you customize Identity Manager and what kind of customizations you make. Some customizations are highly backward-compatible. For example, older workflows, forms, and rules tend to work without modification on newer versions of Identity Manager. Other customizations are more volatile and require additional work to integrate them with new versions of Identity Manager. For example, you might have to recompile or rewrite integration code that invokes Java classes that are part of the Identity Manager product.

The most significant effect of customization, however, is that customization changes how you must approach upgrading Identity Manager. Note that the following discussion uses terminology and concepts described in Terminology and Concepts.

Upgrading Identity Manager can be relatively simple if you use the product as shipped—that is, if you configure Identity Manager but do not customize it. If you are unfamiliar with these terms, see Configurations and Customizations. The upgrade process that is part of each version of the Identity Manager product was originally designed to be run in each environment. The product upgrade process automatically preserves your configuration settings as it updates the Identity Manager configuration objects and other repository objects to work with the newer version of code. The upgrade process, however, does not know how to update your customizations. In fact, the upgrade process ignores most customizations. The upgrade process does save off the customized version of any file that the upgrade process intends to replace, but this is the most that the upgrade process can do automatically.

If you customize Identity Manager, as the vast majority of customers do, then you cannot run the standard Identity Manager product upgrade in each environment. You must maintain and must retest your customizations after you upgrade the Identity Manager product, and you want to be certain that exactly what you tested goes into each environment. Because Identity Manager is often customized extensively, those who deploy Identity Manager have developed sophisticated practices for managing their customizations. For more information, see Source Control and CBE.

If you customize Identity Manager, the most common approach is to manage your customizations by maintaining a baseline and then to generate and promote an image of your Identity Manager application into each target environment. See Baseline and Image. You apply the standard Identity Manager product upgrade process only in your Development environment. You then apply to your application baseline most of the changes that the upgrade makes. See Identity Manager Product Compared With Identity Manager Application. However, your upgrade procedure also must include some pieces of the Identity Manager product upgrade. For example, your upgrade procedure will include some subset of update.xml to update repository objects that are not managed as part of your baseline. Your upgrade procedure might also include database table scripts to update the Identity Manager repository table definitions.

Because the vast majority of customers do customize Identity Manager, and because many customize Identity Manager extensively, this document assumes that you have customizations and that you manage your customizations with this approach.