System Migration IS 551 Fall 2005 Dr. Dania Bilal

Definition System migration is the change from one automated system to another. Migration takes on many forms: Change to a new software package Change to a new interface (DOS to GUI) Change to a new platform (Windows to Unix)

Reasons for Migration An interface is being phased out by the software vendor (e.g., DOS interface) Existing system does not support recent communications protocols, such as TCP/IP to allow for Internet presence. Existing system performance is unsatisfactory.

Process of Migration Assess needs Assess weaknesses and strengths of existing system and unresolved problems Select a new system RFP

Process of Migration Find problems with current circulation module and data Find problems with current bibliographic data

Process of Migration Provide vendor with sample circulation and bibliographic data. Ask vendor how certain problems with some data will be handled in the system under consideration.

Database Cleanup Clean up circulation records Clean up bibliographic records (i.e., MARC) Clean up other existing records (e.g., acquisitions, serials)

Database Cleanup Inventory the collection Weed the collection Delete records for which you have no holdings and for which items are lost or missing.

Database Analysis Evaluate existing databases (circulation, cataloging, etc). No need for shelflist analysis. Familiarize yourself with current practices: MARC tags and fields, location codes, copy information, call number, holding codes, circulation periods, barcode symbology, etc.

Database Analysis Learn about the nature of each data record and the database structure of the entire system. What is the relationship between a bibliographic record and an item record, for example?

Database Analysis If you do not know the database structure, data relationships, and current practices, you will not be able to communicate to the software vendor how certain data should be handled in the system under consideration.

Data Completion Make decisions about items that are not cataloged in the existing system or files that are not established for some items, such as authority files. Decision: Will you wait until the new system is in place to complete these activities, or will you perform these activities in the current system?

Data Completion Make sure you stipulate vendor promises in the contract, if the vendor decides to take care of the odds and ends you have in the current system.

Data Migration Extract data from different modules and send to vendors under consideration to test in their systems at their sites. Vendors should identify records that do not load and determine the reason for failure to load.

Data Migration Implement the new system Back up the old system prior to switching to the new system. Test data loads in each module available to determine how accurately they map into the new system.

Data Migration Develop a checklist of potential problem items to examine during implementation. Load the entire database ( patron records in the circulation database, MARC records in the cataloging database, etc.) once the sample data load has been implemented successfully (i.e., mapped correctly into the new system).

Data Migration Run the old and new system in tandem for a while until everything goes to your satisfaction. Do not discontinue the support for the old system too soon, especially before completing the migration of all data from the old into the new system.

Testing Data When testing data, look for: Long MARC records with 520 and 505 field tags Bibliographic records for multi-volume items Bibliographic records for multiple copy items

Testing Data Short MARC records Long and/or complex call numbers MARC records with attached item records Patron records (fines, overdues, etc.)

Data Migration The accuracy of data migration depends on adequate preparation, data extraction for testing, testing data, developing a plan to map records from the old system to the new one, and testing the accuracy of data after migration.