Introduction
When you're ready to convert data from your legacy system into Oracle Utilities Customer Care and Billing, you will have analyzed your CIS processing requirements according to your business and organizational needs and set up the control tables accordingly.
Fastpath: 
Refer to the Administration Guide for a complete discussion of the various control tables and the order in which they must be set up.
After the control tables are set up, you are ready to load data into the system from your legacy system. This conversion effort involves several steps as illustrated in the following diagram:
The following points briefly outline each of the above tasks:
• Map Legacy Data Into Staging. During this step, your legacy master data (e.g., account, person, premise, meter) and transaction data (e.g., bills, payments, meter reads) is migrated into the system. Notice that you are not migrating this data directly into production. Rather, your rows are loaded into tables that are identical to the production tables; they just have a different owner. Refer to Appendix B - Multiple Owners In A Single Database for information about table ownership.
Warning: 
The above diagram illustrates how the system is configured to support the conversion effort in the standard installation, i.e., the staging tables are in the same database as the production tables (each with a different owner). However, it is possible for the staging tables to be in a separate database. This option requires additional effort on your part (because you would have to copy the control tables from production into your staging database). Please refer to Appendix B - Multiple Owners In A Single Database for information about this alternative.
Mapping legacy data into the system is probably the most challenging part of the conversion process because the system is a normalized database (and most legacy applications are not).
• Validate (a). During the validation (a) step, the system validates the data you loaded into the staging tables. Two types of validation programs exist:
◦ Object Validation Programs. Each of the system's master data objects (e.g., person, account, premise, meter, etc.) is validated using the same logic that is used to validate data added by users in your production system.
◦ Referential Integrity Validation Programs. After you have successfully validated the master data objects, the referential integrity validation programs are executed to validate transaction data and to highlight "orphaned" rows. These programs check the validity of the foreign keys on all rows on all tables.
Note: 
Control tables from production. It's important to notice that the validation programs validate your staging data using the control tables that have been set up in production. Refer to Appendix B- Multiple Owners In A Single Database for a description of how this works.
• Tidy Balances. During this step, the system creates adjustments that cause each SA's current and payoff balances to equal the desired balances. The desired balances are supplied on a flat file prepared by you.
• Balance Control (a). During this step, you run the balance control program and then verify that the balances that it generates are consistent with the balances in your legacy system.
• Clear FT's Balance Control. In the previous step, the system creates a balance control and links it to the FT's. If the balance control's balances are consistent with the amount of receivables being transferred into the system, you should run the Clear FT's Balance Control program. This program simply resets the Balance Control column on the FT so that the FT's can be included in a balance control (see the last step below) after they have been transferred to production.
• Assign Production Keys. During this step, the system allocates random, clustered keys to the rows in the staging database.
• Insert Rows Into Production. During this step, the system populates your production tables with rows from the staging. When the rows are inserted, their prime keys are reassigned using the data populated in the previous step.
• Balance Control (b). During this step, you run the balance control program against production. You do this to verify the balances in production are consistent with the values of receivables converted from your legacy application.
• Validate (b). During this step, you rerun the object validation programs, but this time against production. We recommend rerunning these programs to confirm that the insertion programs have executed successfully. We recommend running these programs in random sample mode (e.g., validate every 1000th object) rather than conducting a full validation in order to save time. However, if you have time, you should run these programs in full validation mode (to validate every object).