A Practical Example of Data Conversion - High-Performance Web Databases: Design, Development, and Deployment - page 580

Generally speaking converting operational applications is considerably
easier than converting recordkeeping applications. Populating fields nec-
essary for the operation of a particular piece of software can be done in
various ways. New information required for the effective operation of the
new application, which is not available from the old application, can be col-
lected from other repositories. This is generally the most time-consuming
and complex way of meeting the data requirements of the new application.
On the one extreme of the conversion continuum is the possibility of disre-
garding the old application completely and satisfying the data require-
ments of the new application by collecting the data from original sources.
This approach is particularly useful when the data integrity of the old ap-
plication is very suspect.
New information also can be provided as defaults based on other data,
which are available from the old application. For example, in classifying
employees for payroll purposes, give each employee the same classifica-
tion based on the department where they work. In some instances new in-
formation can be fudged if the new data are not critical to the output
required. For example, if source medium for an invoice is a required field in
a new accounts payable application and it is not a current business require-
ment to keep source medium, then it could be assumed that all invoices are
on paper and the information fudged with that indicator.
Being exhaustive and ensuring that all of the data in an old application
are converted to a new application, as a rule, is more complex than meeting
the data requirements of a new application. The complexity is not just in
the conversion. The old application must be analyzed much more thor-
oughly to ensure that all of the data are understood and put into proper
context. The converted data must be screened much more thoroughly to
ensure that everything has been converted appropriately and is in the
proper context within the new application. In addition there are still the
data requirements of the new application to consider.
Converting historical information often requires shoehorning existing
data into fields that were not designed for that data. Very often field con-
versions are required. For various reasons there may be an array of infor-
mation in the old application, for which there is only one field in the new
application. Pension administration systems are notorious for this. For ex-
ample, it is not uncommon to have numerous pension enrollment dates de-
pending on the prior plans of which an individual was a member. The new
application, especially if it is not sophisticated, may provide only one pen-
sion enrollment date.
Acquisitions, mergers, and changes in union agreements and govern-
ment legislation can cause havoc with historical recordkeeping systems.
These then result in a nightmare of a conversion when one of these appli-
cations needs to be converted to a new application system. A very