Additional note: In my software days I often moved legacy data from an
old system to a new database - same problems.  

In most cases you can't build a one-for-one conversion file because the
meaning of a field may have changed from one system to another.  It's
not the bits and bytes so much as the changes in the logic of a field
that cause the most problems.  

For example a very simple date range could suddenly mean something
slightly but radically different.  The field in the old system that
indicated the due date for a loan (or the disposition date for a record)
now indicates the beginning of a review period (because of a new
regulation or because staff wants more reviews.)  This means that there
are other things that have to change as well, calculations based on the
dates or date ranges based on the dates.  

Moving data from one system to another is never easy - well never say
never.  In most cases, with very few exceptions, you have to check,
check and recheck and then check some more.  

Susan Fitch Brown
202-493-6142


Dustin - I have similar experiences as Bernard outlined.

In one instance, I had the new vendors global support organization
perform the migration.  They extracted the data from the old system, had
a transformation process to reformat and change codes to match their
system and then used their bulk loader to store in the new system.  You
need to validate with record counts, validate data such as legal holds,
etc.  We always went into a test environment that was a copy of
production and validated there before re-running the migration in our
production environment.  If we had problems in test, we corrected and
re-ran until we got it right.

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]