Executing Conversion

In Student Financial Aid (SFA), data is converted by sending the relevant payloads to the applicable web service interfaces: the Message Processing Gateway (MPG) and the Vocado USDE Gateway (VUG).

Conversion is conducted in iterative steps starting with the institution identifying the location and type of legacy data that needs to be migrated to SFA and ends with Oracle validating the data migrated to SFA successfully. Upon completion of the last step, the SFA support team transitions maintenance and further execution of conversion to the institution's support resources.

Executing conversion includes the following steps:

Identify Conversion Data
Cleanse Legacy Data
Extract Legacy Data
Validate Legacy Data
Transform Legacy Data
Load Legacy Data into SFA

Identify Conversion Data

Oracle is focused on ensuring financial aid continuity for all students migrating from a legacy system to SFA rather than persistence of historical student data.

As a best practice, it is recommended to only convert data necessary to continue a student's going-forward financial aid, without converting historical academic years for two reasons:

Once financial aid is established for a prior academic year in the legacy system, it is not advised for SFA to attempt to re-state historical packages, disbursements, or returns.
Not having the data in SFA inherently prevents accidental user errors in editing historical data.

Instead of converting historical data to SFA, it is recommended that historical data be exposed by means of a data warehouse solution, reporting engine, and so on in order to make the information available to users or auditors when necessary. As a byproduct, the implementation process is typically shorter and less costly.

Note: SFA does not support Financial Aid Award Years prior to 2012-2013. Although it is possible from a technology perspective to bring over all historical data, the level of effort and cost may be prohibitive to build the tools required to do so. Therefore, as a rule, it is recommended to focus on financial aid continuity rather than history, especially because closed out award years should be read-only.

Cleanse Legacy Data

The school should make every effort to detect and correct corrupt or inaccurate records from a record set, table, or database. If the school identifies incomplete, incorrect, inaccurate or irrelevant parts of the data they should replace, modify, or delete that data prior to the execution of converting it to SFA.

Extract Legacy Data

To lessen the burden on the institution and/or implementer as it relates to data extraction and data cleansing, SFA's standard data conversion tools leverage as much data directly from the U.S. Department of Education as possible such as ISIR rebuild files and NSLDS Financial Aid History.

For a Campus Solutions (CS) installations, SFA can convert all data (in most common scenarios) without requiring any custom data extraction. All data comes directly from the ED's Electronic Data Exchange (EDE) Systems or through a delivered interface between CS and SFA.

For a non-CS installations, SFA's standard data conversion tools leverage as much data directly from ED as possible. This includes Institutional Student Information Report (ISIR) rebuild files from the Central Processing System (CPS), Common Origination and Disbursement (COD) rebuild files, Pell Year-to-Date files, Master Promissory Notes (MPNs), Credit Decision files from COD, and Financial Aid History files from the National Student Loan Data System (NSLDS). Furthermore, the conversion tools also attempt to leverage as much integration XML payloads as possible, including the standard Student Initiation, LOA and Breaks in Attendance, and SAP Information event messages.

Load Data

Loading data to SFA entails sending relevant payloads to the applicable web service interface: the Message Processing Gateway (MPG) or the Vocado USDE Gateway (VUG).