Institution Code, Customer Code, Institution Name, Customer Name, Time Zone 

Codes: INST_CODE, CUST_CODE – these are filled in by Ex Libris

INST_NAME and CUST_NAME: fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium). These are mandatory and must be filled in.

Default: N/A

Time Zone: Select your time zone from the drop-down list. If your time zone is not listed, contact your Ex Libris project manager.

MARC Organizational Code 

Code: MARC_OC

Default: None; this is not mandatory

Options: Enter your MARC Organizational code, which will be used to construct the former system number in Alma. Only one code is allowed.

Further Information: The migration moves the value in the exported record’s former system number field (bibliographic system number) to the 035 $a field:

(MOC)<bibliographic record id>-<customer code>

<(moc)> is the MARC Organization code specified here. <customer code> is the customer code specified in the CUSTOMER_CODE question above.

For example: (AbC)u12345-01abc_inst

Usually the former system number can be in the 001 field of the bibliographic record. Customers should specify where the former system number is in the Bibs & P2E tab of the Generic Field Mapping form.

List Prefix for bibs from SFX or other management system 

Code: SFX_PREFIX

Default: ‘(SFX)’

Options: String. If not indicating a link resolver management system, leave blank.  Multiple strings are allowed, use a semicolon to separate: (SFX);WaSeSS;EBC

Further Information: If your catalog contains records imported from SFX or another electronic resources management system and you are also migrating bibliographic records directly from SFX or the other management system, this may result in duplicate bibliographic records in Alma. You can enter a prefix here so that the migration programs can identify these bibs and not migrate them to Alma to avoid creating duplicate SFX records in Alma. The migration programs do not make any attempt to physically merge the two records into one.

The default response to this question is ’(SFX)’, but you can enter any prefix that represents bibs that you want to exclude from loading into Alma. The migration programs search for the string in the 035 $a field of the MARC record. If you do not want to exclude any such records, leave this field blank.

If the migration programs identify bib records containing the prefix in the 035 $a and the records in your incoming records are connected to a purchase order line and/or physical items, these bib records are still migrated so that the purchase order and/or items can be migrated, but they are automatically suppressed in Alma to avoid end-user discovery duplication.

Do you use internal system numbers in Linked Entry fields? 

Indicate if you use internal system numbers in linking fields.  Internal system numbers from your legacy system are not continued in Alma, and therefore should be changed to MMSID (the Alma internal system number). 

MARC fields: $w subfield for tags 76x-78x, 80x, 81x, and/or 83x 

Unimarc fields: $1 subfield with prefix 001 for fields 423, 461, 462, 463, 464 [example: bib key 99999 in tag 461 = 461 $100199999]

Code: LINKED_ENTRY_W

Default: No

Options: If you answered Yes to this question, the internal system numbers in the subfield $w or $1001 of the specified tags are converted from the former system number to the Alma system number.

Internal record designation for Linked Entry fields $w 

Code: LINKED_ENTRY_PREFIX

Default: Blank

Options: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to be matched to identify the local system number. If the system numbers in $w or $1001 do not have a prefix, or if you answered No to the previous question, leave this question blank.

Further information on LINKED_ENTRY_W and LINKED_ENTRY_PREFIX: When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, your previous ILS may store the information in bibliographic fields 76x-78x, 80x, 81x, and 83x $w for MARC, and 423, 461, 462, 463, 464 for Unicode.  If the number in the $w or $1001 of the linking tags is the internal legacy ILS system number, these numbers must be changed to the Alma representation of the system number. If your library does not use the internal system number to link and instead relies on more general identifiers such as the ISBN, ISSN, or shared cataloging DB (OCLC or DLC), these numbers are not modified.

In Alma, the system numbers in the linking field are used to link two related bibliographic records together using the related records process. Related records can be found by clicking the More Info link on the Alma Search Results page.  For more information on configuring related records, see Configuring Related Records for Physical Inventory.

Indicate which 852 subfields to use to determine unique holding records 

Code: 852_SUBFIELDS_FOR_HOL

Default: bc (library and location only, not call number)

Options: To group all items on a single bibliographic record by library and location only, select bc here. If you have many items in the same bibliographic record in the same llibrary/ocation but different call numbers WITHIN that library/location and you want each of them to have their own distinct holding record, specify additional call number subfields.  Acceptable subfields: bchijklmp.

The library and location codes are matched after the Alma Location Mapping has been performed, meaning the match is done on the Alma version of the library/location codes.

Further Information: See Determining Groups of Holding Records and Changing the Holding Record Grouping.

Do you want to use a call number in the generated holdings records?

Code: CALL_NO_IN_HOL

Default: Yes

Options: Yes or No

Further Information:  You may choose to generate holding records without any call number, so that the 852 contains only $b (library) and $c (location) by selecting 'No' here.  When 'No', values in the incoming Item Call Number field are placed in the Alma Item Call Number.  Further, when 'No', customers should only use ‘bc’ for the 852_CALL_NO_FOR_HOL question.

Limit exported records by location 

Code: LIMIT_BY_LOCATIONS

Default: No

Options: If your export contains all of the data from a shared database, and you wish to only migrate a part of that export to Alma, then the migration programs can filter the data according to locations listed on the Location Tab. In this case, the ALMAME_VALUE_NOT_FOUND line on the location tab is not used. Inventory is filtered by locations on the Location Tab, and Fulfillment is filtered based on campus codes in the Campus Code Tab. Use this option only if agreed upon with your Ex Libris project manager.

Bib Key Prefix 

Code: BIB_KEY_PREFIX

Default: empty

Options: If you are combining data from two or more separate databases into a single combined institution in Alma, then indicate a prefix here that will be used to distinguish the former system numbers in Alma after migration. For example, the different systems likely had completely different bibs for system number 12345 and you want to be able to search for the specific bib from your own institution after go-live. The prefix does not include a hyphen so if you want a hypen in the number (e.g. PQ-12345), then include it in the string. If you are not merging institutions, leave this question blank.

See also: MERGE_PATRON_PREFIX in Fulfillment

Move 001/003 to 035 or 935

Code: 001_035_935

Default: 035

Options: If your incoming bibliographic records have a number in the 001, then the migration programs move it elsewhere as (<003>)<001>.  For example: (OCoLC)12345.  To move to the 035, which is the default, then select 035 in the dropdown. If you are part of a consortium and are using OCLC numbers to determine matching records when linking to the NZ, you may wish to move this number to the 935 so that the moved number does not interfere with another matching key you may be using.  If you are not linking to the NZ, then this question is likely not useful.  Default: 035

Further information: If an 035 exists in the record already with the identifier that was in the 001, then a second (duplicate) tag is NOT made.  Also, when checking if the identifier already exists, the migration programs compare to the $a only.  Meaning, if an existing tag contains

001 12345

003 OCoLC

035 $a(OCoLC)12345 $z (OCoLC)54321

then the existing 035 $a is considered a duplicate and a second tag is not created. 

Add institution suffix to Bib ID 

Code: BIBID_INST_SUFFIX

Default: No

Options: When moving the legacy bibliographic identifier to the 035 or 935, you can choose to add the institution code to the end of the string, like 12345-34ABC where 12345 is the legacy bib ID and 34ABC is the institution code.  This may be used in conjunction with other bib identifier options, such as BIB_KEY_PREFIX and MARC_OC.

Yes = include suffix

No = do not include suffix

Use subfield indicators in item call number (AltCallNo)

Code: ITEM_CALLNO_SUBFIELD

Default: Yes

Options: When generating an Item Call Number field (also known as AltCallNo), you can decide if the string contains subfield indicators. Default = Yes

Yes = $h PZ3.A93 Pr16 $i A975
No = PZ3.A93 Pr16 A975

For more information on when an Item Call Number is generated, see the section Changing the Holding Record Grouping, which depends on the question 852_SUBFIELDS_FOR_HOL.

Add $9 LOCAL to specified tags

Code: NZ_LOCAL_TAGS

Default: empty

Options: Add $9 LOCAL to specified bib tags, for use in consortia where an IZ environment links to an NZ. Tags marked as Local will be kept in the IZ, and not moved to the NZ.  

Format for this input: tag + indicator.  Use # for any/wildcard, and b for the space character. Separate with semicolon.  

Example: 59###; 69###;960##;970##;090b#

Alma Location Name and Alma External Location Name 

The Alma Location Name column contains the names of the location codes that are displayed in the staff interface. The names cannot be repeated in the Location Name column when the location codes both belong to the same library, but you can use the same name for two different locations, if these locations belong to different libraries. The Alma External Location Name column contains the names of the location codes that are displayed to library patrons. These names can be repeated within the column without regard for libraries. For example:

The following is acceptable:

The following is not acceptable:

The Alma library and Alma location are put in the following places in the migrated or newly created MARC holdings record:

• The Alma library is placed in the 852‡b field.
• The Alma location is placed in the 852‡c field.

Collapsing Locations 

This mapping table can be used to collapse location codes – that is, two or more location codes in your legacy ILS can map to a single location code in Alma. The Alma location and library code fields may not be empty. If you want to stop using a location code on migration, map the incoming code to an easily identifiable code such as XXX if any stray items are still in your library database.

If you collapse location codes, you may have lines in the table such as the following:

The three values in bold italic above (ReserveElec as the External Location name, and Yes for Suppress from Externalization and Electronic location) are not used in Alma. Since the locations are being collapsed, the first line for the RESERVES Alma location is used, and all subsequent lines below it use the values from the first line.

Determining Groups of Holding Records 

The permanent location and call number in Alma is only stored in the holding record. All items attached to the holding record have the same permanent location and call number. On migration, the call numbers for any new holding record created are generated from the first item found in the group of equivalent items. By default, a group of equivalent items is determined by the location of each item attached to the same bibliographic record. For example, if a bibliographic record has five items:

• Item 1, 2 in Location A
• Item 3, 4 in Location B
• Item 5 in Location C

The migration program generates three different MARC holdings records, one for each location A, B, or C. The items for each location are then attached to the newly created holding record. If there are any call numbers that differ from the holding record’s call number, the differing call number is stored in the item’s Item Call Number field.

Changing the Holding Record Grouping 

You may decide which 852 subfields are used to determine what makes items belong to the same group. The 852 subfields as mapped, described in the Library, Location and Call Number sections above, are: $b Library $c Location $h Call Number. By default, the migration programs compare $b and $c, but you may decide to change this based on items in your collection.

When the holding record group is based only on $b (library) and $c (location), some item call number information is not reflected in the holdings record call number if the call numbers differ from each other in the same library/location. However, the differing call number is stored in the item’s Item Call Number field, so the call number is not permanently lost.

For example, if there are four items on the same bibliographic record with the following call numbers, all in location main:

item 1 $b main $c stacks $h PN 567 .M4

item 2 $b main $c stacks $h PN 567 .M457

item 3 $b main $c stacks $h PN 567 .M457

item 4 $b bio $c flr1 $h PN 567 $i .M457

When only $b and $c are used to determine a holding record group, two holding records for the above items are created: Holding record $b main $c stacks $h PN 567 $i .M4

item 1

item 2 (with PN 567 .M457 stored in ItemCallNo)

item 3 (with PN 567 .M457 stored in ItemCallNo)

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

When the holding record group is based on more subfields, for example $b $c $h, three holding records are created: Holding record $b main $c stacks $h PN 567 .M4

item 1

Holding record $b main $c stacks $h PN 567 $i .M457

item 2

item 3

Holding record $b bio $c flr1 $h PN 567 $i .M457

item 4

Decide which 852 subfields will be used to determine holding record groups by answering the question in the Questionnaire tab of the Generic Migration Form, “Indicate which 852 subfields to use to determine unique holding records”.

Attaching Items to Existing Holding Records 

The algorithm described above to determine groups of items for generating new holdings records is also used to determine if an item should be attached to an existing MARC holdings record. The question Indicate which 852 subfields to use to determine unique holding records from the Questionnaire tab of the Generic Migration Form is used here as well.

For example, consider the following incoming records:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

Holding record B: $b PER $c CURRENT $h Shelved by title

item 1: PER,MFORM PN 567 .M4

item 2: PER,MFORM PN 567 .M4 2010

item 3: PER,MFORM PN 567 .M4 2011

item 4: PER,CURRENT PN 567 .M457 2012

When only location (852 $b $c) is used to determine unique holding records, the following is the resulting structure in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1 (ItemCallNo is empty because the call number matches)

item 2 (with PN 567 .M4 2010 in ItemCallNo)

item 3 (with PN 567 .M4 2011 in ItemCallNo)

Holding record B: $b PER $c CURRENT $h Shelved by title

item 4 (with PN 567 .M457 2012 in ItemCallNo)

When the entire call number (852 $b $c $h $i $k) is used to determine unique holding records, multiple additional holding records are created in Alma:

Holding record A: $b PER $c MFORM $h PN 567 $i .M4

item 1

*Holding record B: $b PER $c MFORM $h PN 567 $i .M4 2010

item 2

*Holding record C: $b PER $c MFORM $h PN 567 $i .M4 2011

item 3

Holding record D: $b PER $c CURRENT $h Shelved by title

*Holding record E: $b PER $c MFORM $h PN 567 $i .M4 2012

item 4

The holdings records with the asterisk (B, C, and E) are created new because the entire call number string of the item did not match the entire call number string of any of the existing holdings records.

Item Barcodes 

While many legacy ILS systems allow item barcodes to be duplicated, Alma does not. The item barcode must be unique in Alma, although it may be left blank.  Blank is not a unique check:  very many of the barcodes can be left blank.

The item barcode is migrated according to the following rules:

• If the barcode is empty, leave as empty in Alma.
• If the barcode exists but is not unique:
  • First item barcode encountered – migrate as is.
  • Second and subsequent item barcodes encountered – migrate as <item barcode>-<item id>

Because it is possible to use the barcode as the link between item and loan, request, fine, or order, if one of those is linked to an item with a duplicated barcode, it will be linked to the item with the unsuffixed barcode.

Material Type from Bib Fixed Fields 

The material type in Alma is a description of the type of material the item is such as book, map, issue, DVD, compact disc, etc. It is controlled by a fixed list of physical resource material types in Alma. Each item in Alma must have a material type specified.

All customers may provide a material type in a subfield of the item record, and use the Material Type tab to map them to valid Alma material types (see the explanation for Material Type tab, above). The material type you indicate determines the item's material type.

If not provided in the extract, the migration automatically assigns a material type based on Bibliographic record header fields. There is no customer input required for this part of the migration as the Alma types are fixed.  The material type in migration is derived from the resource type which is constructed by Alma based on the bib header information. To see a description of how the resource type is determined, see the Resource Type Field description.