4 Dec 00


Conversion of data from our NOTIS system to our new replacement LMS is an early crucial step in the implementation process. In order to ensure a smooth transition with no loss of essential information, we need to identify the records and data elements that must be migrated from our NOTIS system to the new system. We also need to identify data irregularities within our NOTIS system that may cause problems in the new LMS.


The Data Migration Work Group is charged to:

  1. Review our NOTIS records and determine which records should be migrated to a new system. Pay particular attention to inactive, closed, paid, lapsed, expired and other non-current records. When identifying non-current records for migration, indicate why the records should be preserved. Consider records of all types across all modules.
  2. Identify data irregularities that may cause problems in the new system and will require data clean-up before migration or special handling during migration. Note that data irregularities may not cause problems in NOTIS. Examples are nulls in bibliographic records and call numbers with split classes.

Keep in mind that a database as large as Yale's will always have record errors (e.g., incorrect indicators, incorrectly set catalog status codes, paid bills that should be credited). It is neither feasible nor advisable to try to correct all record errors before migration since migration time is limited and extensive database manipulation may introduce new problems. Include only data irregularities that may cause records to be rejected during migration or to become unusable after migration.

Whenever possible estimate the number of records that will be affected and explain why the correction is required.


Data migration requirements may generate contract issues that should be explored with our candidate vendors before our final system selection. The Data Migration Work Group should produce a draft recommendation that identifies records to migrate by 22 Jan 01.

The draft recommendations will be discussed with our vendors during the evaluation demos (Jan 22-Feb 2).

The work group will continue to refine our migration requirements after our final system selection. The final due date for the data migration requirements will be determined when we establish a system implementation schedule with our Orbis2 vendor. Although the exact duedate cannot be determined now, the Data Migration Work Group should anticipate finishing this recommendation Spring 01.

Data irregularities requiring correction or special handling should be identified by 2 March 01.