Transforming data from one database schema to another.
Transforming data to the extent required so the target application can function and navigate properly.
Converting accepted data values that represent the same information into a single, unified, recognized, and accepted structure as required by the target system (this doesn’t include misspellings). For example, standardization of all source Social Security number data to the target format of 000-00-000.
Based on predefined business rules, assigning a specific and agreed upon value to a field in the target database that is different than the corresponding value in the source database.
Reports that provide qualitative analysis of the source data and identify missing, incorrect, or incorrectly formatted data elements required by the target database or application. If the source data problems are not corrected or defaulted, the target application will be inaccurate, have limited reliability, or in some cases abort operation.
Reports that provide quantitative and qualitative analysis of the source data. For example: date fields that do not conform to an expected date format or the total number of records that meet specified criteria.
Re-run of the conversion process if above and beyond those agreed to be within scope.
Amending, correcting, removing, or defaulting inaccurate, incomplete, duplicated, or improperly-formatted source data beyond what is required by the target application to function properly.
Adding new or derived data necessary or desired in the target system but not available in the source. (Also called data enrichment). This does not include changing the intent of the source data.
Checking source data against any known or third party database to verify data accuracy. For example, comparing the data against United States Postal Service Delivery Point Validation (USPS-DPV) to verify the post office can deliver mail to a particular address.