Databases Reference
In-Depth Information
Checking the data usually is done using multiple independent audit
trails at least providing the count of data records converted and some hash
totals on certain fields. The amount of effort expended is usually commen-
surate with the cost and impact of an error. The users of the data must be
involved and have the final sign-off. Whatever audit trails are used, the re-
sults and associated statistics must be kept in archives at least for the first
few years of operation of the new application. A copy of the source data-
base used for the conversion also should be archived together with some
application code that can access the data for reporting purposes. If ques-
tions with regard to the conversion process arise at a later date, then one
has something to go back to for verification.
After a successful conversion, the last step involves decommissioning
the old application. This sounds much simpler than it actually is. It is not
unusual; in fact, it is often absolutely mandatory that the old and the new
applications be run in parallel for some specified time period. Weaning us-
ers from the old application can sometimes be a major challenge. That,
however, is not a subject for a chapter on conversions, but is more in the
realm of change management.
CONCLUSION
As the preceding discussion illustrates, conversions are not as boring
and lacking in challenges as most professionals assume. Neither are con-
versions as frightening as they are made out to be. Most systems imple-
mentations involve some form of data conversion. When the software
changes, the data model or the data itself often changes with it. Conversion
software design and development can challenge the most creative juices of
the most skilled developers. Conversions can be interesting and fun. Keep
this in mind the next time you hear the word “conversion.”
Search WWH ::




Custom Search