Conversion Strategy

Overview

Data conversions are required to transfer Student Administration data from the central Student legacy systems to the PeopleSoft 8.9 system to satisfy core business processes. Successful data conversions are critical to allow the legacy student systems to be decommissioned and all central Student business processing to be accomplished from the PeopleSoft system. Data conversions must be accurate and comprehensive to enable the university’s business to be conducted with the integrated Student Administration PeopleSoft system. The specifications for data conversions will be developed in the interactive design and prototype sessions (IDPs).

Goals and Benefits

Goals:

• The primary goal of data conversion is to transfer legacy data to the PeopleSoft Student Administration system while preserving the integrity of the data.
• A checklist template will be developed to assess and track a data conversion. As part of the IDP the template will be filled out for each data conversion.
• Early conversion of as much data as possible – this will help each functional area analyze and test the functionality provided by PeopleSoft.
• Preservation of the information that maps legacy data to PeopleSoft data to help users understand how PeopleSoft functions. This information is also needed by the Data Delivery team to help develop ETL scripts and a more comprehensive data dictionary.
• Optimization of the conversion scripts to minimize the time required for conversion.
• Identification of erroneous data. Each functional may choose to correct the errors. The corrections will be made to data in the legacy system wherever possible.
• Comprehensive testing to ensure that Student data conversions do not impact other functional areas.

Deliverables and Tools

The most appropriate developer tool provided as part of the PeopleSoft software suite will be used to implement a conversion. In many cases this will be SQR scripts. Whenever possible PeopleSoft component interface will be used to ensure business logic is executed when the data is imported into PeopleSoft. In some cases a manual conversion could be the most cost effective and efficient conversion approach. Wherever possible existing tools and technology will be used or refined to perform the conversion.

Conversions usually consist of a four step process:

1. Extracting the data form the mainframe system to a data staging area Mapping the data to the format required by the PeopleSoft system
2. Loading the data into PeopleSoft
3. Testing and validation
4. Numerous methods will be used to check the converted data including row counts, control totals and specific data spot-checking. Test scripts will be developed to validate the converted data in PeopleSoft. The acceptance criteria will be defined by the data stewards as part of the IDPs.

Assumptions and Risks

 A comprehensive data conversion plan will be created. The plan will identify all database instances required to conduct the conversions and detail contingency plans to allow roll back in case the conversion corrupts production data. The conversion plan must identify critical go/no-go decision points. The criteria will be specific to each conversion and will be established as part of the IDPs. The timing of conversions into the production system is dependent on the sequence of the Student module implementations and the production operations schedule of HR, Payroll and Contributor Relations.

HR, Payroll and Contributor Relations staff will be responsible for testing their PeopleSoft functionality to ensure that Student conversions have not impacted their data. Their review of the conversion plan is critical.

Some conversions may have a datamart or other archival mechanism as their conversion target. The business process defines the need for historical data. For example the Office of the University Registrar needs to generate transcripts from historical enrollment data.

Risk

Conversions into a shared production environment are inherently high risk. Comprehensive testing and review by all functional areas will help reduce problems. In some cases it may be necessary to ‘back out’ a conversion – this has to be planned for as part of each conversion implementation.

Roles and Responsibilities

Legacy and PeopleSoft functional experts are responsible for identifying data elements, analysis and mappings for data that needs to be converted to PeopleSoft.

PS 8.9 functional experts in conjunction with the data stewards are responsible for identifying the PeopleSoft target tables and data elements and to verify that the converted data is correct.

Data Delivery developers and DBAs will help validate conversion by writing queries against the Student RDS. The Extract Transform Load (ETL) process can also be used to identify integrity issues with the converted PeopleSoft data.