Go-Live Data Cleanup Recommendations

Created by Catherine Busselen
May 05, 2021
7 min read

The following recommendations on how to handle your data cleanup for Go-Live have been made in response to some of the Decisions approved by the Policy and Practice Group and in consultation with Ex Libris Migration Guides. Many of these cleanup tasks have already been implemented for test load. This blog post summarizes the Decisions, so be sure to review the linked pages for full details.

**It is recommended that any large-scale data cleanup needs be communicated to systems administrators since timing may need to be coordinated.  Your systems administrator may also be able to advise on whether the data cleanup should be done on the system records or within the extracted records that will be sent to Ex Libris.

(Go-Live - Migration) - Migration Updates from AEFG - P2E, Already-Alma E-Resources, Purchase Order Types

Decision: Recommending local adjustments pre-migration to electronic resources as capacity allows: P2E for migrating, assigning standalone portfolios to collections for already-Alma.

Actions:

All campuses: Split electronic and print to separate records, to the extent possible

III, WMS, Voyager:

  • Identify/mark each record with one of the following Alma e-resource types: portfolio or database (the majority will be portfolio). Note: “Package” is not longer an option for this process, as it was in earlier migration testing.

  • For more information about the P2E process and definitions of portfolio and database, see Physical to Electronic (P2E) process

Current Alma campuses:

  • To the extent possible, link standalone portfolios to electronic collections; this may require the creation of new electronic collections

 

(Go-live) Bibliographic records to leave out of the NZ during migration

Decision: Records for local equipment, suppressed records, records for non-library reserves resources (i.e., personal copy), records marked for deletion, on-the-fly records, records lacking inventory/orders, and records with sharing limitations should not be added to the Network Zone.

Action: Remove or prefix any OCLC record number, including invalid OCLC record numbers (i.e. 019 or 035 $$z) with something that will not be interpreted as an OCLC number. For non-Alma libraries, do consider the possibility of 019 being converted into 035 $$z. See https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/010Alma_Migration_Considerations_for_Consortia#Matching for detailed guidance. Note: Ex Libris documentation does not explicitly state that the 019 should be considered, however, in the test load it was determined that 019 numbers must be removed or prefixed to avoid being added to the Network Zone.

Examples: Change (OCoLC)123456 to (UCD)123456 ; or change (OCoLC)123456 to (OCoLC-UCD)123456

Current Alma campuses:

To facilitate identifying SCP/MARCIVE records we recommend the following:

  • SCP records: Change (OCoLC) to (SCP)

  • MARCIVE records: Change (OCoLC) to (MARCIVE)

 

(Go-live) Preparation of Campus SCP Data

Decision: SCP records will no longer be managed by individual campuses.

Actions: 

All campuses (except SCP)

  • Identify SCP bibliographic records in local catalog

    • If holdings are SCP-only, and there are no other record types attached, do not send for data extract. For Alma campuses, replace the (OCoLC) prefix with (SCP) so these records won’t get into NZ by accident.

    • If holdings are SCP and local, remove all data related to SCP (599, 793, 856, 9xx fields; 035 SFXObjID for SCP in bib record and remove related holdings record, if applicable).

    • Campuses can migrate bib records with local access that duplicates CDL access into the NZ if needed but if possible are asked to leave them out.

  • If order records are attached to an SCP bib record in the local ILS: 

    • Send with ILS data extract since order records should be migrated to IZ. 

    • If bib only has SCP access points and CDL order record:

      • Suppress bib record.

      • Include bib on P2E. Expected migration outcome: E-inventory will not be created. Order will convert as electronic order type.

      • Leave record out of the NZ (all traces of OCLC data in 001, 003, 019 and 035 fields need to be deleted or prefixed)

    • SCP+local orders (i.e., bib includes 856 for local holdings and a campus order record is attached):

      • Remove SCP data as noted above

      • Don’t suppress the bib.

      • Include bib number on P2E. Expected migration outcome: Local e-inventory created and most recent order will be converted to electronic order type.

      • Bib can be migrated to the NZ if needed, should be left out if possible

 

(Go-live) MARCIVE Bibliographic Records in the NZ and campus data preparation

Decision: SCP will use UCSD’s MARCIVE bibliographic records for electronic resources (not composite records) as a base file for the entire system. The records will be loaded directly into the NZ. To the extent possible, campuses other than UCSD should not migrate their non-composite e-resource MARCIVE records. If non-composite e-resource MARCIVE records need to be migrated for any reason, they should not be added to the NZ.

Action:

  • If possible, remove Marcive records for non-composite e-resource records prior to migration.

  • For campuses that cannot remove the records prior to migration, mark or group the records in some way to allow you to identify them for deletion post go-live. Remove or prefix any OCLC record number, including invalid OCLC record numbers (i.e. 019 or 035 $$z) with something that will not be interpreted as an OCLC number from your non-composite e-resource Marcive records. See https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/010Alma_Migration_Considerations_for_Consortia#Matching for detailed guidance. Note: Ex Libris documentation does not explicitly state that the 019 should be considered, however, in the test load it was determined that 019 numbers must be removed or prefixed to avoid being added to the Network Zone.

 

(Go-live) Local 856 bibliographic data

Decision: For NZ-linked records, RMFG will request that CDL remove 856 40 fields on or shortly after August 15. For NZ-linked records, RMFG will check with campuses on September 1 about the status of their 846 41 fields and will request that CDL remove them from any campuses that are ready. For NZ-linked records, RMFG will request that CDL remove remaining 856 41 fields starting September 15. 856 42 fields do not need to be removed after migration, campuses can choose which ones to retain.

Actions:

All campuses (except SCP): Copy any 856 that you want to protect from being lost in migration to 956; add $$9 LOCAL

SCP: Copy all 856 data to 946; add $$9 LOCAL

Note: 856 fields are needed during the P2E process to generate portfolios, do not remove 856 fields from records that need to go through the P2E process. 856 fields are also not “local” fields so they risk being lost during the NZ build/linking process.

 

(Go-live) Non-OCLC IDs in 035 fields in bibliographic records

Decision: 035 fields without any prefix need to have some local prefix added to prevent having them treated as OCLC numbers in certain situations. There is no functional need to move/remove fields that have non-OCLC data in them but all 035 $$a and 035 $$z fields should start with a parenthetical prefix.

Action: Prefix all identifiers in 035 fields with a parenthetical prefix. If you want to protect any 035 identifiers that are on records that will be added to the Network Zone, you must move or copy those identifiers to a locally protected field.

 

(Go-live) Local bibliographic data (5XX-9XX)

Decision: Fields 900-949 are reserved for the Network Zone. Campuses must move data out of this range prior to migration. The rest of the mapping can be adopted by the end of Phase 4.

Actions:

  • Unrelated data that currently resides in any of these mapped fields should be identified and moved to a different field and protected with a Local Extension (i.e. $$9 LOCAL)

  • Move local 5XX data to either a 590 field(s) or the 590-599 field range

    • Note:  Campuses are encouraged to look for local data not tagged as such in 500, etc. fields and change them to 59x fields. Techniques could include looking for specific library names, fields coded with $$5 [campus MARC code], etc. Campuses may also decide to just focus on the data they consider most important (e.g. Special Collections data).

  • Move local 6xx data to the following fields

    • 690 Local Subject Added Entry - Topical Term

    • 691 Local Subject Added Entry - Geographic Name

    • 694 Local Index Term - Genre/Form

    • 695 Added Class Number

    • 696 Local Subject Added Entry - Personal Name

    • 697 Local Subject Added Entry - Corporate Name

    • 698 Local Subject Added Entry - Meeting Name

    • 699 Local Subject Added Entry - Uniform Title

Note: fields 692 and 693 are reserved for future use; move any 692 or 693 data to a different local field

  • Move additional local data to the following 9XX fields

    • 969 Course reserved field

    • 970 Local Added Entry - Personal Name

    • 971 Local Added Entry - Corporate Name

    • 972 Local Added Entry - Meeting Name

    • 973 Local Added Entry - Uniform Title

    • 992 System IDs that pre-date the current migration (not your current system ID). Note: This field is optional for campuses who want to use separate 9xx fields for their current ID and other IDs from previous migrations.

    • 996 System IDs (both current IDs and previous IDs if only one field is desired)

Note: The Alma/MarcEdit integration uses the 999 field, so you may want to avoid moving other local data to the 999 field.

 

MARC Tagging

  • Action: Verify that bib records to be included in migration have a MARC 245 field

  • Purpose: Correct migration of bib  records

  • Ramifications if not done: Inclusion of a bib record lacking a 245 field causes the migration to reject records in that file

Empty Data Fields

  • Action: Identify records lacking data in MARC Bibliographic 245 $a and provide a title

  • Purpose: Include record in migration

  • Ramifications if not done:  Bib records lacking 245 $a data will not migrate

Other Local Data in Bibliographic Records

  • Action: Identify local data to be retained and:

    • Move the data to one of the following Ex Libris-defined local MARC tags: 

      • 09x

      • 59x

      • 69x

      • 77x/78x

    • Add “$9 LOCAL” to the end of each of those fields (no punctuation or other characters)

Millennium Libraries with Holdings records  852 field $a data

  • Action: Move any 852 $$a data to a separate 852 subfield prior to data extract.

  • Purpose: Migration removes 852 $$a data

  • Ramifications if not done: Data loss

Millennium Libraries: Multiple Check-in Records with Single Location

  • Action: Collapse/delete/merge check-in records that have the same location so there is only one check-in record per location

  • Purpose: Holdings data for multiple check-in records with identical locations will be migrated to a single holdings record

  • Ramifications if not done: While all check-in records will migrate, all the items records with matching location codes will attach to the first holdings record, leaving all the other holdings records with no items attached.

Millennium Libraries: Order records with Improper Frequency or Format Coding 

  • Action: Review active order format codes (order type, status, format): ensure order codes for e-resource purchases are accurately reflected in codes, and ensure order codes for print purchases are accurately reflected in codes. 

  • Action: Review active order frequency codes (order type, status, format): ensure order codes for recurring/continual payments are for continual orders (serials, database, packages, or other continuations), and ensure order codes for one-time purchases (serial one-time, mono one-time, multi-volume one time) are for single or one-time orders. 

  • Purpose: Ensure order records are migrated with appropriate PO-Line Type. 

  • Ramifications if not done: Orders, once made in Alma, cannot have their frequency or format changed for the PO-Line Type. Orders would have to be closed, and new orders created post-migration, in order for inventory and orders to fully function in Alma Receipt Bench or E-Activation Task List workflows. Old order data would be split between multiple order records, and difficult to retrieve or collate in Alma/Analytics. Order data would have to be re-sent to vendors for invoicing (specifically for EDI invoicing). 

 

The SILS mission is to transform library services and operations through innovation and collaboration. The future is shared!

Question? Contact AskSILS-L@ucop.edu