Siebel Database Upgrade Guide > Application Planning for a Siebel Upgrade >

Upgrade Planning for Migrating Siebel Address Data

Upgrades:

• From Siebel Industry Applications (SIA) 6.x, (except Communications, Media, and Energy) to Siebel SIA 7.7.x
• From Siebel Financial Services 6.x and 7.0.x to Siebel SIA 7.7.x
• From Siebel Business Applications 6.x and 7.x to Siebel Business Applications 7.7.x as part of upgrading to Siebel SIA 7.7.x
• From Siebel Financial Services 6.2.1 on IBM z/OS platforms to Siebel SIA 7.7.x on IBM z/OS platforms

NOTE:  This topic does not apply to Siebel Business Applications (HOR) that you are upgrading to a later release of Siebel Business Applications (HOR).

Siebel 7.7 (and Siebel 7.5 SIA) changed the way address information is stored. You must perform several tasks to ensure address migration is handled correctly.

Previous Releases

In previous releases, address data was stored as follows:

• The relationship between person and address was 1:M and was stored in the table S_ADDR_PER.
• The relationship between account and address was 1:M and was stored in S_ADDR_ORG.
• Both tables included a column ADDR_NAME, which is a computed value based on other attributes in the address table.
• The user key for S_ADDR_PER included PER_ID and ADDR_NAME.

Siebel 7.7

In Siebel 7.7, the relationship between person and address and between account and address is M:M. Address information is stored in S_ADDR_PER. The relationship between addresses and contacts and between addresses and organization is stored in S_CON_ADDR.

The upgrade process revises storage of address data as follows:

• Inserts data into S_CON_ADDR from S_ADDR_PER and S_ADDR_ORG.
• Migrates data from S_ADDR_ORG to S_ADDR_PER. The table S_ADDR_ORG is obsolete.
• Sets S_ADDR_PER.PER_ID to NULL. It is no longer used as part of the user key but remains part of the physical key.
• Uniqueness of addresses in S_ADDR_PER is enforced only on ADDR_NAME.
• The table S_CON_ADDR becomes the intersection table for data stored in S_ADDR_PER and account or contact data stored in S_ORG_EXT or S_CONTACT respectively.

How Address Data Is Preserved

Because PER_ID is no longer part of the user key for S_ADDR_PER, the ADDR_NAME must be unique for all records.

It is possible that records within or across S_ADDR_ORG and S_ADDR_PER could have the same ADDR_NAME. If this occurs, the ADDR_NAME for one of the records is preserved, and the upgrade process appends the ROW_ID to ADDR_NAME for the others. This prevents records from being deleted and preserves all records from both tables.

How to Manage Address Migration

You must perform the following tasks to migrate address data:

• Before upgrading the database, you must run a script to identify records that have the same ROW_ID between S_ADDR_PER and S_ADDR_ORG. You must eliminate duplicate row IDs.
• You must evaluate whether to modify upgrade scripts to migrate address data in custom extension columns in S_ADDR_PER and S_ADDR_ORG. Review the new schema and determine if your custom columns can be mapped to standard columns. If no matching standard columns exist, create new columns on the target tables. During the database upgrep, you do this after running the Database Server Configuration Utilities but before running the Upgrade Wizard.
• After the upgrade is complete, review the records in S_ADDR_PER and eliminate duplicate and obsolete records.

To manage address migration, follow the steps in Process of Upgrading a Siebel Production Test Environment. Each of the address migration tasks is included as a step in this process. Each step refers you to a procedure for performing the task.