Installation Guides › Upgrade Guide › Upgrading from r12 › How the Migration Works

How the Migration Works

The following figures represent an r12.0 environment and detail the order in which each component is upgraded to r12.1. The first figure represents stages one, two, and three of the migration. The second figure represents stages four and five of the migration.

Note: Each figure depicts a single database instance as a policy/key store. Your environment may use separate database instances for individual policy and key stores.

1. In stage one, some of the r12.0 Policy Servers are upgraded to r12.1. The r12.1 Policy Server operates in compatibility mode.

   Important! The Policy Server installer replaces the Policy Server User Interface with the FSS Administrative UI during the upgrade. The r12.1 Policy Server continues to provide access control and generates log files that contain auditing information. However, you cannot administer the r12.1 Policy Server to record policy configuration information in the policy store until the Administrative UI is installed.

   Note: The FSS Administrative UI is for managing CA SiteMinder Federation Security Services and is required only if you use WS-Security SAML tokens. Although installed with the Policy Server, the CA SiteMinder Federation Security Services must be registered with the Policy Server before it may be used. You use the Administrative UI to register the FSS Administrative UI.

   • The r12.0 SOA Agents continue to communicate with the r12.1 Policy Server.
   • The r12.1 Policy Server continues to communicate with the r12.0 policy and key store.
   • The r12.0 Policy Server continues to communicate with the r12.0 policy and key store. You can continue to administer the r12.0 Policy Server to record policy configuration information using the r12.0 Policy Server User Interface.

   Important! If you are using WS-Security SAML tokens, the existing SOA Security Manager key database (smkeydatabase) must be upgraded to r12.1 or the existing keys and certificates must be migrated to an r12.1 SOA Security Manager key database. A r12.1 Policy Server can only communicate with a r12.1 key database. The SOA Security Manager installer lets you upgrade an existing key database to r12.1 or create a r12.1 key database during the Policy Server upgrade.

2. In stage two, some of the r12.0 SOA Agents are upgraded to r12.1.
   • The r12.0 SOA Agent continues to communicate with the r12.0 and the r12.1 Policy Servers.
   • The r12.1 SOA Agent only communicates with the r12.1 Policy Server.
3. In stage three, the remaining Policy Server is upgraded to r12.1. The r12.1 Policy Servers operate in compatibility mode with the r12.0 policy and key store.

   Important! Although the Policy Servers continue to protect resources and you have access to the Policy Server Management Console, you cannot administer the Policy Servers. The Policy Server installer replaced the Policy Server User Interface with the FSS Administrative UI during the upgrade. You cannot record policy information in the policy store until you have installed the r12.1 Administrative UI. Account for this time as you plan your migration.

   

4. In stage four, the r12.0 policy and key store is upgraded to r12.1.
5. In stage five, the Administrative UI is installed and configured with one or more Policy Servers. Consider the following:
   • You can install the Administrative UI before upgrading the policy store. However, you cannot register the Administrative UI until the policy store is upgraded. Installing the Administrative UI before the policy store upgrade minimizes the amount of time the Administrative UI is unavailable to the policy store.
   • Stage 5 contains r12.0 components to illustrate mixed-mode compatibility. You may upgrade remaining r12.0 components at this time.
6. The final step, which is not illustrated, is to register each FSS Administrative UI with its respective Policy Server, if required. The FSS Administrative UI is registered using the Administrative UI.