CSU Millennium to Alma migration Data profiling, cataloging and lessons learned Oscar Raab CSU Morgan Library Alma Certified Admin

Data profiling - General Ex Libris – 2.5 pages of recommendations for data cleanup Ensure all records have 245 title Clean up dupe records Clean up bad Unicode Remove old codes: location, status, etc. In Hindsight Fixed OCLC MARC standard fields – Alma integrates LoC MARC standards More than 30 suggested task, from bib/holding/item data, patron, record purges, authority, and naming conventions We focused on…

Data profiling - other Other Data Migration Points Local Authorities – didn’t migrate, had to extract and import post migration DDA records – chose not to migrate, reloaded post-migration using PDA functionality Checkin records – don’t exist in Alma, not all checkin data migrated, and what did is lacking PDA functionality controls activation of the PDA records, can be ‘turned off’, expired on specific dates Checkin data was migrated into holdings records, but not cleanly. Some data not migrated at all, what did is packed into a holding 852 field

Data profiling – electronic resources Electronic Resources in Alma Records handled differently from physical resources Linking info doesn’t come out of bib, but from portfolio Proxy is institutional setting, applied dynamically Availability not defined by location code, but by library Electronic resource migration Print to Electronic (P2E) conversion – record mapping Migration didn’t happen completely – many electronic titles migrated as physical Portfolio = item record for elec titles. Also service, interface and collection, which can all affect the linking and availability P2E migration, identify and provide all bib record numbers of e-titles, and indicate what type of electronic resource it is; a package, an e-book, etc. Somewhat confusion, and misidentification resulted in some being migrated as physical, or wrhot type of resources

Cataloging Post-migration issues and adjustment New record hierarchy – holdings record in between bib and items, portfolios for electronic resources Analyzed serial titles (bound-withs) MARC validation Authority control Delayed update to public catalog Describe record relationships Bound-withs resulted in multiple records, a serial title record, monographi title record, and a “host bibliographic” which links the two. Inventory is attached to the host bib record though, so requests, and Primo searching are ugly. MARC validation done by embedded LoC standards, OCLC standards not supported, so field 019 return warnings. Concern about ‘inoculation’ to these warnings Not sure where authority control is done – it does work, we have linked heading when new records are added, just not sure where the authority records are kept We run a publishing job 3xday to send new records and updates to Primo, even then, Primo must process these update, which can take between 24 and 48 hours depending on the cloud processing demand

Two campus Complications Fort Collins and Pueblo share the same Alma instance Each campus has its own Primo instance (discovery layer) Alma integrations tend to favor a single library One holding symbol in OCLC synchronization One link resolver when exporting electronic titles PubMed provider info All records, patron, bib, item, etc. stored in the same repository, with configuration to show them on separate campuses/library, etc. Those records are served out to separate Primo instances, allowing local availability control for electronic resources

Prospector integration Bibliographic records Straightforward - MARC is MARC Inventory records Alma allows customized inventory data selection Publishing Profiles - highly customizable method for outputting records Includes inventory data (normal export does not) Can publish full sets of records, or incremental (changes since last export) Can be scheduled I did configure bib publishing to strip out the migrated Millennium record data in the 907, 945 and 998 fields Inventory customization = choosing the MARC field the data goes into, and which subfields contain which item data, as much or as little as we want. Full vs incremental publishing methods: incremental catches only changed, added or deleted records since the last update; reduced the size of the export files (not sending every record every time) possible due to nature of Alma’s logical set, which automatically adds recods that meet criteria, and removes when they don’t Schedules dependent upon publishing methods: full only 1st of the month, incremental = monthly, weekly, daily (with multiple times)

Questions? Oscar.raab@colostate.edu