Millennium and Sierra (III) to Alma Data Delivery and Migration Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Welcome to the Alma migration process! This guide will help you provide files to Ex Libris for your test load, assist in filling out the Migration Form, and answer questions you may have on how your data moves to Alma.

This guide focuses on migration from Millennium and Sierra, Integrated Library Systems produced by Innovative Interfaces, Inc (III). The two systems are so similar to each other that the same data structures are expected when exporting data which will be imported to Alma.

This document provides information on all aspects of migrating Millennium and Sierra to Alma, including:

A step-by-step guide to filling out the Millennium (III) to Alma Migration Form.
An explanation of fields mapped from Millennium/Sierra to Alma, which you will do using the Migration File Validation tool.

For specific instructions on how to use the File Validation Tool, see Migration File Validation Tool. The Further Information sections in each functional area below will help explain the functional implications of incoming fields and how they map into Alma.

Expected File Formats

Expected file formats for Millennium/Sierra data varies by file. See the descriptions below. Ex Libris expects a certain set of files to be exported from Millennium/Sierra. We have included the general expected deliveries below. The data elements listed for each are those that Ex Libris expects to use in conversion. Some data elements may exist in Millennium/Sierra but are not necessary to bring to Alma.

The scope of your specific conversion is agreed upon in your Alma contract.

For the files listed below that are not MARC bibliographic or holding records, we expect an extract using the extracting tools available with Millennium/Sierra. This means csv files, using a comma as the field separator and double quote (") surrounding the field. Use semicolon (;) to separate fields with multiple values.

"field1","field2a";"field2b","field3"

It is also acceptable to provide fields with mutiple values as follows (with double double-quotes around the semicolon).

"field1","field2a"";""field2b","field3"

This is how they are provided when III staff perform the extract for us.

When a field contains a double quote

If at all possible, replace double quotes in note fields with a single quote. In Sierra, customers can use Global Update to replace double quotes with single quote (').

If the field contains a double quote as part of the value, for example certain call number conventions in European countries, then change the double quote into two single quotes prior to migration.

Change this

"field1","mrgll-BCrit. 008(467.1)"19"(061.3)","field3"

to this

"field1","mrgll-BCrit. 008(467.1)''19''(061.3)","field3"

Then, post-migration, you can use tools to change two single quotes back into a double quote.

Checkdigits in certain internal identifiers

In some cases, the exported Millennium/Sierra identifier contains a checkdigit or does not contain a checkdigit, so the identifier may look different between two different files (example patrons and courses, which contain a patron link). Please use the files as they are exported, do not attempt to correct identifiers. Ex Libris migration programs will add or remove a checkdigit as needed, but this process relies on expecting the internal identifiers exactly as they are exported.

File Naming Conventions

The following is the default naming convention:

CustomerName+DataType+sequence+date+[.<file_extension>].

For example: centralu_bib_01_20120420.mrc, centralu_bib_02_20120420.mrc, centralu_bib_03_20120420.mrc, etc.

Ex Libris recommends a maximum of 200,000 records per MARC file, and 400,000 for other types of records (items, orders, etc).

All records in a single file must be homogenous – all of the lines in the file must have the same number of fields, and those fields must contain the same type of data.

Additionally, all of the records must be delimited in the same manner, which is quotes and commas.

Using the Migration Form Validation Tool

The Millennium/Sierra Migration Form is used by the migration programs to convert your data for use in Alma. Therefore, it is important that the data entered by the customer is valid so that the migration can continue on schedule.

Your sandbox contains an online validation tool that helps ensure that your data is valid before you submit the form to Ex Libris. Information about this online validation tool can be found at: S upport and Maintenance.

After you have completed the form, visit the link in your sandbox to begin the validation process.

Inventory

Millennium/Sierra Inventory Files

Alma has bibliographic, holding, and item records, while Millennium has bibliographic and item records, plus summary statement information (‘Library has’) in related checkin records. Additionally, Millennium and Sierra customers may use a tool which generates MARC holdings based on the serial checkin information. A third option also exists to create holding summary statements by providing bibliographic field information and mapping it to holding summary statements. This requires a III location and summary statement to exist in separate subfields of a single bibliographic Marc field.

For Millennium customers who are exporting MARC holding records, the migration process matches them to exported serial checkin records, if provided, by matching on the checkin number which is also the MARC holding record identifier. Additionally, the migration process attaches migrated items to the MARC holding record based on the location fields in 852_SUBFIELDS_FOR_HOL.

For Millennium/Sierra customers who are not exporting MARC holding records, the migration process creates MARC holding records based on information in the Millennium/Sierra item and checkin records.

Bibliographic Records

Bibliographic records are expected in MARC format. Standard MARC is preferred, but files in MARCXML format are also acceptable. The character encoding expected from Millennium is UTF-8, which is the Sierra/Millennium export standard. If your library prefers to export in a different format you must inform your Ex Libris project manager.

Bibliographic records are exported from Sierra/Millennium with a *.out filename. Customers may leave the filenames as is (using *.out as the suffix) or they may manually change the name to *.mrc, it does not make a difference.

Bibliographic records are generally migrated as is, with the following exceptions:

Contents of any 001 field are moved to and 035 along with the corresponding 003.

Customers migrating to an NZ may wish to review the Extraneous Identifiers section of the Consoria Migration document to be aware of how the 001/003 moving to 035 may affect matching
Australian customers have ALL Bibs marked for Libraries of Australia Publish, if relevant.
OCLC records (records with an 035 |a with an OCLC-official prefix) is marked for OCLC publish, if relevant.
The LDR position 9 (character coding scheme) is set to 'a', indicating Unicode.

Standard 7XX fields for linking between bibliographic records are leveraged during migration. If the linking is based on bibliographic system numbers, indicate in the Millennium (III) Migration Form which subfield contains these numbers, using questions LINKED_ENTRY_W and LINKED_ENTRY_PREFIX.

Delete any SFX MARCIt or non-SFX link resolver records from your Millennium data extracts before submitting them to Ex Libris to avoid unnecessary duplication with SFX or your link resolver migration, as described in https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/Electronic_Resource_Handling_in_Alma_Migration#Managing_Duplication_in_Alma. If such duplicate records are desired to be retained (for example, because they have open orders) ensure that a 035 |a field with (SFX) in the field content is provided, so that they can be identified and retained with a suppressed flag. Use the Migration Form question SFX_PREFIX to indicate which records should be skipped or suppressed.

Suppressed Bib Records

Provide a separate text file that contains the bib keys, one key per line, for bibliographic records that are suppressed. The suppression flag is generally stored in the BCODE3 field in the BIBLIOGRAPHIC_HEADER table in Millennium.

Additionally, you may choose to suppress an entire location from being viewed in the Primo by answering the question Suppress from Externalization? on the Alma Location tab of the Millennium (III) Migration Form.

MARC Holding Records

All Sierra and Millennium customers who are migrating to Alma may export MARC Holdings records for serials. If this is not set up on your Sierra/Millennium server, contact your Ex Libris representative to arrange. If you wish to migrate MARC holdings records for serials, submit them to Ex Libris using the Migration File Validation Tool. If you do not submit any MARC Holdings records, Ex Libris generates them based on information in the item and checkin records. On migration, Ex Libris will remove the contents of the 852 $a in MARC holdings records. If you want to preserve the information in the 852 $a, move it to a separate subfield prior to delivery for migration.

The export process from Sierra may provide 'ghost' MARC holding records, which were deleted in your system but still have a presence. The holding export process cannot be configured to exclude these 'ghost' records, but they are rejected by the Alma migration engine, so while they may be annoying they are not harmful.

If multiple 852 fields exist in a MARC holding record, the first 852 field is used and the subsequent fields are changed to 952. If a single 852 tag has multiple $b (library) and/or $c (location) subfields, only the first instances of those two subfields are used and the extra $b and $c are moved to $v and $w.

When MARC holding records are migrated from Millennium in addition to the serial checkin records, the checkin records are linked to the existing holding records using the checkin record number (like c1234567) which is also in the holding 001 field. In this case, if there is already an 866 in the MARC holding record, then a new 866 from the 'LIB HAS' in the check is not added to the MARC record.

Call Numbers

Call numbers are generated differently based on what exists in the export.

MARC Holding record exists + Items + Serial Checkins: Call numbers are taken from the migrated MARC holdings record. Items are attached to the holding record based on the location or location+call number match. If Serial checkin records are also provided, then the serial checkin is attached to the MARC holdings record.
Serial checkin exists (no MARC holdings record) + Items: Items are grouped with the serial checkin record based on the location or location+call number match.
No holdings exist, only items: When a new holdings record is created based on item information, the call number is generated from the first item found in the location group with a non-empty call number field. A location group is either based on location or location+call number.
Only serial checkins: When there is a checkin in a location that does not have any related item records in the same location, then the call number is taken from the checkin record, and a standalone holding record is created.

For information on how to specify if the migration uses location or location+call number when determining the item grouping or if the item attaches to an existing holding, see the Determining Groups for Holdings Records section and the Migration Form question 852_SUBFIELDS_FOR_HOL.

Item Call Numbers imported from the bibliographic record

In Millennium/Sierra, call numbers can be stored in a hierarchy of bibliographic tags, or in the item’s CALL # (ITEM) field or the analagous CALL #(CHECKIN) field.

During the migration process, we can take the call number from the first tag (in hierarchical order indicated in the field mapping) from the related bib record, or from the item record or checkin record CALL # field, or both. If both bibliographic tags and item/checkin CALL # are used, the CALL # from the item or checkin is always the priority. In other words, the CALL #(ITEM) or CALL #(CHECKIN) is used first if it is present, otherwise we use the bib call numbers in order of a priority that you specify.

If you derive item call numbers from the fields in their attached bibliographic records, such as 090, 086, or 050, and you want to use them in the migration process, you MUST include these call number fields in the item and/or checkin record when you export from Millennium/Sierra. Ex Libris can accommodate up to eight different bibliographic call number fields in addition to the CALL #(ITEM) field. Indicate the priority of the call number fields by selecting the local field name (for example 086|abcd) next to the expected priority field. In addition, specify the class scheme (call number type) in the corresponding class scheme field. The class scheme should correspond to the first indicator of the 852 field in the holdings record that is generated on conversion. The class scheme (call number type) in the newly-created holdings record (852 first indicator) is set based on from which field the call number came. Since the hierarchy differs from customer to customer, the migration process provides a method for individual definition of the bibliographic tag hierarchy on the Item and/or serial checkin section of the Migration File Validation Tool. If a call number from the bib hierarchy is used, only the first one is used and the rest are discarded.

When importing call numbers from the bibliographic record, the call number from the item or checkin always takes precedence over the call numbers from the bibliographic record.

When an item and a checkin record with the same location are attached to the same bibliographic record, the call number from the item is given preference. The call number in the checkin record is not separated into multiple parts with semicolons, so the entire call number is placed in the $h field.

For a description the call number fields, see field definitions on the OCLC website at http://www.oclc.org/bibformats/en/0xx.html. For the 852 first indicators, see definitions at http://www.loc.gov/marc/holdings/hd852.html. Some typical examples of how to fill in these fields are below in the notes for the first few fields.

The call numbers are delivered in the item file with the data elements separated by semicolons. The following are examples of how these data elements are transferred to 852 subfields.

Two data elements get put in $h and $i

"KF734.Z9";"J6" --> $h KF734.Z9 $i J6

Three data elements have the last two joined together in $i

"KF734.Z9";"J6";"M9" --> $h KF734.Z9 $i J6 M9

Duplicate values are removed (this usually happens by mistake if the bib has multiple tags for the incoming call number, like two 090s)

"KF734.Z9";"J6";"KF734.Z9";"J6" --> $h KF734.Z9 $i J6

Most customers need the 'remove duplicates' feature. If you do not wish to remove duplicate values in your call numbers, because some call number schemes deliberately have duplicates, then inform your Ex Libris representative.

Alternately, you may choose to export the item records with only a single call number field, in the CALL #(ITEM) field. To specify if you want the call numbers for item records to come from the tags in the related bibliographic record or if you want the call numbers to come only from the item’s own CALL # (ITEM) field, answer the question Use call number tags inserted from bib? with Yes or No.

If you will not use the call number tags from the bib, then leave the call_field* entries blank in the Migration File Validation tool. In this case, the call number type is taken only from the CALL #(ITEM), and the call number type is determined in multiple ways:

By the value in the CALL # TYPE field of the data extract (using a value like the 852 first indicator such as 0, 1, etc.)
Per location, which is specified in the Alma Location mapping tab of the Millennium (III) Migration Form.
A combination of the above two: check CALL # TYPE field first, and if no value is present then check the Location tab of migration form.

Some Millennium/Sierra systems have provided a CALL #(BIBLIO) field. This field is consulted only if no other call number field is present.

Blank call numbers

If you decide to use call numbers from the item record alone, from the CALL # (ITEM) field, there is the possibility that some call numbers are left blank when they should not be. To be able to more easily retrieve and correct these items post-migration, you may provide a default string to use as the call number instead of leaving it blank. It is difficult to create a search for an empty string. See the EMPTY_CALL_NUMBER question on the Questionnaire tab.

Call Number from Bib example

The item in Line 1 below has a single call number (KF734.Z9 J6) in field "090|ab" which was imported from the bib. Note: The semicolon (;) indicates that the call number should go into 852 subfields h and i rather than all in 852h. This call number will be assigned to the holding we generate for this item. On the field mapping form, we said that the 090|ab type is 0 (LC) so we assign the 852 1st indicator based on the type mapping in the field mapping form.

Line 2 has a single call number "KF734 .Z9 1989" in CALL #(ITEM). That call number would be used for that item. Since we don't have a CALL # TYPE field in our data (if we did, we would have a type specified in the in the item record that we could use to set the type), we instead go to the location of the item. Whatever you set as the default call # type for this location (on the migration form) will be used as the call number type for the generated holding record. The CALL #(ITEM) field does not have semicolons in Sierra, so they are not expected by the migration programs. However, if you would like to provide subfields for this field, you may provide it with actual subfields, like '$hKF734 $i .Z9 1989'

If an item record has multiple call numbers, we need to know which one to use, which is where you set priority. Line 3 has both an 050|ab and an 086|ab. On the field mapping form, we gave 050|ab a priority of 3 and 086|ab a priority of 4 so we'll use the 050|ab for this record. We'll assign the type based on the field mapping form ('0' for LC).

Partial Truncated File:

"RECORD #(ITEM)","CALL#(ITEM),"099|ab","090|ab","050|ab","086|ab" Line 1: "i1000001x","","","KF734.Z9";"J6","","" Line 2: "i11688920","KF734 .Z9 1989","","","","" Line 3: "i1114743x","","","","KF2432.A2";"C58","C 31.211";"CAB 1.21"

Sample Validation Tool mapping below. Be sure to check the 'imported from bib' boxes on the right.

Determining Groups for Holding Records

The permanent location and call number in Alma are only stored in the holdings record. All items attached to the holdings record have the same permanent location and call number. Th section describes how the migration process determines groups of items for placement on a single shared holding record.

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 attached items:

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

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

It is possible to change the default grouping of location to use the location and call number, as described in the following section: Changing the Holding Record Grouping. However, be aware that if you use the location and call number, and your call numbers differ by even a little bit, you may have more holding records than you expected. See the section Attaching Items to Existing Holding Records for an example of this.

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 from Millennium and described in the Library, Location, and Call Number sections above are: $b Library $c Home Location $h Call Number. By default, the migration programs compare $b and $c, but you can decide to change this based on items in your collection.

When the holdings record group is based only on $b (library) and $c (location), some item call number information will not be reflected in the holding record call number if the call numbers differ from 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 .M4

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 holdings records for the above items are created:

Holding record $b main $c stacks $h PN 567 $i .M4 (Call number taken from item 1)

item 1

item 2

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

Holding record $b bio $c flr1 $h PN 567 $i .M457 (call number taken from item 4)

item 4

When the holdings record group is based on more subfields, for example $b $c $h $i, three holding records are created:

Holding record $b main $c stacks $h PN 567 .M4

item 1

item 2

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

item 3

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

item 4

Indicate which 852 subfields will be used to determine the holdings record groups by answering the Indicate which 852 subfields to use to determine unique holding records question in the Questionnaire tab of the Millennium (III) Migration Form.

Attaching Items to Existing Holding Records

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

For example, consider the following records from Millennium:

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 holding 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 holding records.

Attaching items to checkin records

In Millennium/Sierra, checkin records become MARC holding records when they are migrated to Alma. The items attach to the newly created holding records in the way described above. If you wish to be sure that your item records attach to the correct holding, make sure that the checkin location and the holding location map to the same location in Alma.

For example you may have

checkin location: per

item location: mper

if you want the items to attach to the checkin, these two locations should map to the same thing in Alma.

per -> LIB,PER

mper -> LIB,PER

where LIB is an example library code and PER is an example location code.

Serial Prediction

While it is not a standard Sierra/Millennium export, customers may undertake programming to provide serial prediction information in the MARC holding and item records.

Customers may provide 853/863 in the MARC holding records, which are available as part of the standard MARC holdings export, without providing the Recently Received Item and Next Predicted Item. In this case, when the 853/863 prediction patterns are provided alone, they are simply transferred as part of the MARC holding and they are not automatically used in Alma prediction. Customers may use these migrated 853/863 tags as a base for setting up prediction in Alma, post-go-live.

If you want to provide the Recently Received Item and/or Next Predicted item, you must provide all three elements below, complete with links between them as described.

As of this writing, no customer has provided the Recently Received Item or Next Predicted Item, so providing them means you will query the Millennium/Sierra database yourself and construct the files using programming tools. If you will do this, you must inform your project manager as soon as possible and the files must be provided at or before testload.

Here is a description of the information required:

Patterns in the MARC Holding Record (853/854/855) – Patterns should be delivered in the MARC holding record, in tags 853/854/855, as described in the MARC21 Format for Holdings data: http://www.loc.gov/marc/holdings/hd853855.html. Multiple patterns can be included for the same holding record. Patterns can be active or inactive.

Subfield $8 is used to link between the 853 and 853X, 854 and 854X, or 855 and 855X subfields when there is more than one pattern on a single holding record. When there is only one pattern on a holding record, the $8 subfield should be 0 (zero).

Patterns in the MARC holding record are provided as part of the standard MARC holdings export, and are usually provided by customers migrating from Sierra or Millennium.
Most Recently Received Item (853X/854X/855X) – Generate a new tag, 853 first indicator X, 854X, or 855X in the same MARC holding record, which contains information about the last predicted item of the holding. While this is a lot like an 863, it is not exactly the same. Use the following guidelines:
- $a - Enumeration first level (a)
- $b - Enumeration second level (b)
- $c - Enumeration third level (c)
- $d - Enumeration fourth level (d)
- $e - Enumeration fifth level (e)
- $f - Enumeration sixth level (f)
- $g - Alternative numbering scheme, first level of enumeration (g)
- $h - Alternative numbering scheme, second level of enumeration (h)
- $i - Chronology first level
- $j - Chronology second level (j)
- $k - Chronology third level (k)
- $l - Chronology fourth level (l)
- $3 - Issue date YYYYMMDD (3)
- $8 - CopyID: If there are more than one occurrence of the 853/4/5 fields, a subfield 8 should be maintained in both the 853/4/5 and the 853/4/5X fields (occurrence counter in the 853/4/5 and a reference counter in the 853/4/5X).
Next Predicted Item (Item Record) – Customers should also submit item records that have not been received. There should be only one predicted (unreceived) item per pattern. Additional fields have been added to the Millennium item record format: RECORD #(ORDER), RECORD #(HOLDING), EXPECTED DATE, RECEIVED DATE, MARC LINK, and PATTERN. See below in the item section for more information on these fields.

Checkin Records

The Millennium/Sierra checkin record is used as a tool to facilitate checking in serials. The serial check in portion of the checkin record does not migrate to Alma, but three values from the record do: the library has statement, the checkin notes, and the call number if there is no corresponding call number in an item record with the same location attached to the same bibliographic records.

All library has statements, also referred to as summary holdings statements, are added to the newly created holdings record in an 866, 867, or 868 field. One of these fields is added for each summary holding statement. Please note that 866/7/8 are not added when a checkin record is merged with the corresponding MARC holding from Millennium/Sierra. See 'Checkins merged with MARC holdings' below.

The checkin notes are added to the 952 $x field (non-public note) or 952 $z (public note) of the new holding record, depending on your responses on the checkin tab of the Millennium Data Delivery form. One $x or $z field is added for each note.

Boundwiths are not accepted in the checkin file and should be manually corrected by the site before submitting the file to Ex Libris.

For more information on how the call_number_n fields work in checkin records, see the description for call number hierarchy in the Call number section above.

Checkins merged with MARC holdings

When MARC holding records are migrated from Millennium in addition to the serial checkin records, the checkin records are linked to the existing holding records. When this happens, the summary information from the MARC record is preferred over the information from the checkin. Very often, the summary information in the MARC holdings comes from individual item tags (853 and 863 pairs) instead of a static 866 tag. 853/863 pairs can be converted to an 866 summary statement using information found in this Knowledge article: https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Create_Summary_field_866867868.

If there are any tags which are duplicated, the merge programs attempt to deduplicate. For example, we do not want to identical 856 tags with the same linking information (one from checkin, one from MARC holding).

Additionally, the notes from the checkin record are added to the matched MARC holding record.

Checkins and MARC holdings when there are multiple checkins in the same location on the same bib

The migration programs do not handle the following special situation, of two checkin/holding in the same location on the same bib:

bib 123, checkin c123, MARC holding c123, location PER

bib 123 checkin c234, MARC holding c234, location PER

The information from the checkin record does not properly get added to the corresponding holding record.

Since Alma does not actually allow multiple holdings on the same bib in the same location, and they will have to correct this in Alma anyway, customers are encouraged to correct this in Sierra prior to migration.

Serial issues (Checkin cards)

To date, no customer has succeeded in providing a valid export of checkin cards from Millennium/Sierra. Generally speaking, if provided, the checkin cards would be transferred to item records in Alma, since that is how serial issues are handled in Alma. The LIB HAS statement which transfers to an 866 $a is enough to indicate the serial holdings for a title in the absence of a migrated checkin card.

Checkin record exported file

Export checkin records from Millennium/Sierra with a single location (do not repeat locations in the same checkin record). Provide the checkin records in comma delimited format, as a standard Millennium extract. The fields in the following table are expected.

Field Name	Notes
RECORD #(CHECKIN)	Alphanumeric, not repeatable. This may link to a MARC holding record number, if MARC holdings are provided.
RECORD #(BIBLIO)	Alphanumeric, repeatable.
LIB HAS(CHECKIN)	Repeatable. This is the primary functional purpose of the checkin record. There are three options for tags here: LIB HAS 866 - string is placed in 866 $a of holding record LIB HAS 867 - string is placed in 867 $a of holding record LIB HAS 868 - string is placed in 868 $a of holding record
CALL #(CHECKIN)	Not repeatable, this field comes directly from the checkin record.
PREFIX	Used in $k of call number along with call number fields (ITEM_CALL_NO and also call numbers imported from bib)
SUFFIX	Used in $m of call number along with call number fields (ITEM_CALL_NO and also call numbers imported from bib)
LOCATION	Not repeatable. Use in Alma Location mapping tab on the migration form. Multiple locations are not technically allowed here; if you do have multiple locations for a single serial, for example, 'main' and 'per', then they will be listed in the file as 'main,per'. Include 'main,per' in the Location map as if it is a single location, and map that to a single ALma library/location.
P2E_LINK	URL access to this material. This value is transferred to the holding record 856 subfield u, and then is used during the p2e process. Do not import this from the bib.
P2E_NOTE	This value is transferred to the holding record 856 subfield z, and then is used during the p2e process. Do not import this from the bib.
PUBLIC_NOTE	The public note, which is placed in the 952 $z of the holdings record, does not have the field name prefix since it displays to the public.
NON_PUBLIC_NOTE	The non-public note is placed in the 952 $x of the holding record, with the field name prefix included before each note.
call_field_1	First priority (Use a semicolon (;) separator between Call Number parts to be optionally parsed to holdings 852 \| h ; 852 \| i). Example: 090\|abcd
call_field_1_type	Manually enter in the data delivery form the 852 first indicator (type) for the first priority call number field. Example: 0
call_field_2	Second priority. Example: 092\|abcd
call_field_2_type	Manually enter the call number type for second priority. Example: 1
call_field_3	Third priority. Example: 086\|abcd
call_field_3_type	Manually enter the call number type for third priority. Example: 3
call_field_4	Fourth priority. Example: 050\|abcd
call_field_4_type	Manually enter the call number type for fourth priority. Example: 0
call_field_5_type	Manually enter the call number type for fifth priority. Example: 1
call_field_6	Sixth priority.
call_field_6_type	Manually enter the call number type for sixth priority
call_field_7	Seventh priority.
call_field_7_type	Manually enter the call number type for seventh priority.
call_field_8	Eighth priority.
call_field_8_type	Manually enter the call number type for eighth priority.

Any additional fields not listed above may be put into notes.

Holding Records from a Summary Statement in a Bibliographic Record

If you have summary statement information about a journal, such as 'Vol. 1 (1990) - present', in your bibliographic records, these are usually better used if they are moved to a holding record. Often the field is in the 866 tag, but any tag can be specified. If you use this feature, the migration programs will generate a holding record from the summary statement. Fill in the values of the following fields in the Migration Validation tool.

If the location code provided in SUMM_LOC_CODE matches an existing holdings record on the same bibliographic record then the summary holdings statement will be attached to that holdings record, regardless of call number. In other words, the summary holdings will be placed on the holdings record with the same location, even if 852_SUBFIELDS_FOR_HOL algorithm includes additional call number information which might not match.

Example:

Bib record contains: 866 $a Vol 1 (1990) - present $l MAIN $m STACKS

Holding record generated from item contains: 852 $a MAIN $b STACKS $h PN 56.7 $i .B345

Even though the summary statement doesn't have any call number information, the summary tag will be added to this holding record because MAIN/STACKS matches.

If there is no existing holdings record on the bibliographic record with the same location, a new holdings record is generated.

Note that all values below must be in separate subfields of the same MARC field. We cannot take the summary statement from one tag and the location from another. They all have to be in the same main tag.

Expected File Name	Value	Notes
SUMM_TAG		Five characters; tag+2 indicators. May use # as wildcard, for example, 866## or 86#3#. Wildcard allowed for third digit and indicators but not first two digits. To indicate a space character, use b, for example 866b1.
SUMM_SUBFIELDS		Multiple subfields allowed, e.g. abz. May use # to indicate all subfields.
SUMM_CALLNO		Textual call number to be used in all newly generated holdings records if desired.
SUMM_LOC_SUBF		A single subfield code (like 'a') that contains a location code in local ILS format. Do NOT enter a different bib tag: the migration program searches for a subfield within the SUMM_TAG bib tag.
SUMM_LOC_CODE		If SUMM_LOC_SUBF is not provided or the subfield is not found, this is used for all records as a default. Provide a location code in local ILS format.
SUMM_PUBLIC_NOTE_SUBF		Public note, placed in 952 $z of the generated holding record
SUMM_NON_PUBLIC_NOTE_SUBF		Non-public note, placed in 952 $x of the generated holding record

Item Records

Item records that do not have a bib key, or the related bib record is not present, are not migrated. Items must be linked to bibliographic records in Alma.

The only tags that may be imported from the bibliographic record to the item record are the call number fields described in the Call Numbers section below. Do not import other fields, such as electronic links, from the bibliographic record. Electronic links in should be used as is from the bib record.

See the Call Number section above for more information about how call numbers are generated in migration.

The table below lists the expected fields for item migration. If your item fields have different names, indicate the field mapping in the Items section of the Migration File validation tool.

Boundwiths file structure: field order

Items that are shared by multiple bibliographic records (called Boundwith items) have multiple RECORD #(BIBLIO) fields. The RECORD #(BIBLIO) fields are exported by Millennium, separated by a comma. This makes the fields appear to be off, but the migration programs expect boundwiths in this manner:

regular item:

“b123”,”i22334”,etc.

boundwith item:

“b456”,”b789”,”b223”,”i55667”,etc.

It is also acceptable to provide boundwith records in a second file, separate from the regular items file(s), where the bib keys are separated by semicolon like this:

“b456"";""b789”,”b223”,”i55667”,etc.

This is how boundwith items are provided if III staff deliver files for us.

All of the call number fields are repeated for each instance of the bibliographic record. Ex Libris merges these values into a single field of semicolon separated bibliographic ID values. See the Boundwiths section below for more information on how these records are migrated.

When exporting item records, the call number fields which are imported from the bib must be listed immediately following the item call number. This is because when an item is boundwith, each imported item field is repeated once for each bib in the exported item record. In order for the migration validation tool and the migration

engine to handle these repeated fields appropriately, they must be be listed in the following order: RECORD #(BIBLIO),RECORD #(ITEM),CALL #(ITEM),[CALL_FIELD_N],[Item fields] etc. The order of fields which come after the [CALL_FIELD_N] is not important, but they must come directly from the item and should not be imported from the bib.

The CALL_FIELD_N fields which are repeated for each bib present should ALSO be separated by commas, just like the repeated bibs are expected. So a full boundwith record which has three bibs and two call number fields imported from the bib will look like:

“b456”,”b789”,”b223”,”i55667”,"CALL#ITEM","BIBCALL1a","BIBCALL2a","BIBCALL3a","BIBCALL1b","BIBCALL2b","BIBCALL3b",REST_OF_ITEM_FIELDS

where

BIBCALL1a is the first call number from the first bib.
BIBCALL2a is the first call number from the second bib.
BIBCALL1b is the second call number from the first bib.

P2E Link and P2E Note

These two fields are intended ONLY for fields which are native to the item or checkin record in Sierra/Millennium. Do not try to import links from a bib record into the item or checkin field. 856 tags which are in the bib record will only be utilized by the migration programs from the bib record itself.

Any P2E_LINK or P2E_NOTE which has been imported from the bib record will result in the entire item files being rejected by the migration team.

Expected Field Name	Notes
RECORD #(BIBLIO)	Alphanumeric, repeatable in the case of boundwiths.
RECORD #(ITEM)	Alphanumeric/not repeatable, mandatory.
CALL #(ITEM)	Highest priority call number, higher even than the first bib call number. This field is usually expected as a text string, e.g. 'PN56 .K44', but may also include subfield indicators if desired, e.g.'$h 823.89 $i B869 $i J1 $i X $i 7 $i A'
call_field_1	First priority (Use a semicolon (;) separator between Call Number parts to be optionally parsed to holdings 852 \| h ; 852 \| i). Example: 090\|abcd
call_field_1_type	Manually enter in the data delivery form the 852 first indicator (type) for the first priority call number field. Example: 0
call_field_2	Second priority. Example: 092\|abcd
call_field_2_type	Manually enter the call number type for second priority. Example: 1
call_field_3	Third priority. Example: 086\|abcd
call_field_3_type	Manually enter the call number type for third priority. Example: 3
call_field_4	Fourth priority. Example: 050\|abcd
call_field_4_type	Manually enter the call number type for fourth priority. Example: 0
call_field_5	Fifth priority. Example: 082\|abcd
call_field_5_type	Manually enter the call number type for fifth priority. Example: 1
call_field_6	Sixth priority.
call_field_6_type	Manually enter the call number type for sixth priority
call_field_7	Seventh priority.
call_field_7_type	Manually enter the call number type for seventh priority.
call_field_8	Eighth priority.
call_field_8_type	Manually enter the call number type for eighth priority.
PREFIX	Used in $k of call number along with call number fields
SUFFIX	Used in $m of call number along with call number fields
CALL # TYPE	The call number type for the call number in CALL#(ITEM). If no value is listed here, then the type is assigned from the Call Number Type column on the location mapping tab of the migration form
VOLUME	Enumeration and chronology in display format – comprises Alma's description. Not used for sorting. Since Volume is free text in Millennium, parsing into enumeration and chronology is not possible, so instead the volume information is sent to the item description.
COPY #	Numeric, repeatable but not likely.
BARCODE	Alphanumeric, repeatable. If repeated, the first barcode is used for the actual item barcode, and the second/subsequent are placed in an item note. The default behavior for migration is to remove spaces from item barcodes. If the barcode on your item has actual spaces on it, meaning spaces are part of the barcode and should be retained, inform your Ex Libris representative. Some barcode readers have a capability to remove spaces from barcodes while scanning.
LOCATION	Alphanumeric, not repeatable. Use in Alma Location map in the Migration Form.
STATUS	Single character, not repeatable – functions as a temp location, availability flag, and visibility flag.
I TYPE	Alphanumeric, not repeatable – circulation policy.
CREATED(ITEM)	Date, not repeatable. This is placed in the 'Receiving date' (arrival date) field in the item.
UPDATED(ITEM)	Date, not repeatable.
AltCallNo	An item’s optional Item call number. This field may also be filled if the 856_SUBFIELDS_FOR_HOL question is bc and some items' call numbers need to be saved. See Changing the Holding Record Grouping for more information.
INVDA	Inventory Date, not repeatable. Hours and minutes not accepted here.
INVNO	Inventory Number, not repeatable
STORAGE_LOCATION_ID	Storage location ID, not repeatable
TOT_CHKOUT	Total number of loans for the item. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'. Alma increments the loan count for items currently on loan, so it is recommended that you send (loans - 1) for currently loaned items.
DATE_LAST_RETURN	Last date the item was loaned/returned (YYYYMMDD). Hours and minutes not accepted here. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
PIECES	Alphanumeric
IN LIB USE	Number of in-house uses. To see this value in Alma, search for the item under 'Physical Items' and on the results list click 'Other details'.
P2E_LINK	Include an III field name here that contains a link used for electronic resources. Do not import any tags from the bibliographic record for this. This value is transferred to 856 subfield u in the holding record, which can then be used in the p2e process.
P2E_NOTE	Include an III field name here that contains information about the p2e_link. Do not import any tags from the bibliographic record. This value is transferred to 856 subfield z in the holding record, which can then be used in the p2e process.
PROVENANCE_CODE	For the Provenance item field in Alma. This is not a typical III item field, but it is possible to put some other III value here.
RECEIVE_NUMBER	In order to use the Receiving Number in Alma, you must configure an item sequence of type Receiving Number (Config menu -> Resources -> General -> Item Sequences). See Configuring Physical Item Sequences.
MATERIAL_TYPE	Exact Alma code for material type required; no map is used in migration. See the Material Types section below for more information. Note: do not extract this from the bib as a linked field; when you do this, for boundwith items, multiple fields will be included in the item reocrd and the item record will be rejected because of too many fields. The only fields which can be included from the bib are the call number fields above.
PhysicalCondition	A field which indicates the condition of the piece. See the description for the Item Physical Condition map below to see the options for values in Alma. This is not a typical field in Sierra/Millennium, so many customers will not provide any value here.
PRICE	Both fields may be filled with the local ‘price’ field from III/Millennium if desired. The REPLACEMENT_COST will be used to assess fines if the item is lost. To provide this value in the Migration Validation Tool twice, click the plus sign (+) to the left of the incoming field. This will allow you to assign the value to two different expected fields.
REPLACEMENT_COST
FULFILMENT_NOTE	Pop-up note which displays during circulation transactions.
PUBLIC_NOTE	Note which shows to the public
NON_PUBLIC_NOTE_*	NON_PUBLIC_NOTE_1, NON_PUBLIC_NOTE_2, and NON_PUBLIC_NOTE_3. These are internal notes which do not display to the public. Multiple incoming fields can be assigned to these notes. Use a field label to distinguish values if desired.
STAT_NOTE_*	STAT_NOTE_1, STAT_NOTE_2, and STAT_NOTE_3. Statistic notes are usually codes that are used to retrieve items of a particular category for statistics purposes. Item Statistics Notes can use controlled vocabulary when statistics_note_controlled is set to true. For more information, see Configuring Item Statistics Notes.
The following fields are used for a predicted item and are not typically provided. See the Serial Prediction section within the holding records heading above for more information.
RECORD #(ORDER)	Used for a predicted (unreceived) item: a link to the order associated with the prediction pattern
RECORD #(HOLDING)	Used for a predicted (unreceived) item: a link to the MARC holding record that contains the prediction pattern
EXPECTED DATE	Used for a predicted (unreceived) item: expected arrival date. If this value is later than today, the item is marked ‘predicted’.
RECEIVED DATE	Arrival date
MARC LINK	Used for a predicted (unreceived) item: tell us which Holding tag in the linked MARC record has the pattern. if tag in MARC record is 853: then put ‘3’ here 854: 4 855: 5
PATTERN	Used for a predicted (unreceived) item: pattern linking number. When there is only one pattern in the attached holding, use 0. If there are multiples, use 1, 2, 3. The same/linking number should be stored in the $8 of the 853/4/5.

Bound Withs

Bound withs are items that are attached to two or more bibliographic records. A single volume on the shelf contains two or more pieces of bibliographic information, but only one barcode. Examples of this are pamphlets that are bound together in one volume, or journals where an entire year is bound together but the journal changed its name in the middle of the year.

When providing boundwith records in the item file, do not use the semicolon delimiter for repeated bib records. Leave the boundwith record as is after exporting from Millennium. For further information on exporting boundwiths, see the section 'Boundwiths file structure: field order' in the Item Records section above.

For migration, all linked bibliographic records are converted as is, with no additions or changes.

The shared items are not linked to any of the original bibliographic records so that there is no direct link from the shared item to any of the linked bibliographic records. Instead, a new bibliographic record is created, which has the migrated shared item and new holding record attached to it. The new bibliographic record is linked to the linked bibliographic records via the 774 $w linking field.

The new bibliographic record has title “Host bibliographic record for boundwith item <item’s barcode>.” and multiple 774 tags with the following information:

774 1_ $t <title of linked bib> $w [Alma internal MMS ID]

One 774 field is created for each bibliographic record that is linked to this item. The 774 field links the new bibliographic record with the linked bibliographic records via the related record's functionality in Alma.

It is possible in Millennium that multiple items are linked to the same group of boundwith bibliographic records. This situation is handled during migration to Alma. The multiple items are all linked to the host bibliographic record.

The 'Host Bib' situation is not intended to be the final record structure for boundwith records in Alma; rather, it is the best that migration can do in order to preserve links between records with the resources available. In order to correct the boundwith records so that they display properly in Alma, customers should move the shared item to one of the bibs, and link the bibs to each other. After that, the host bib can be deleted.

Item Barcodes

While Millennium/Sierra allows item barcodes to be duplicates, Alma does not. The item barcode must be unique in Alma, but it may be left empty.

The item barcode is migrated according to the following:

If the barcode is empty, leave as empty.
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>.

Item Record Keys - checkdigit

The final checkdigit of the Millennium/Sierra item key (for example, i123459) are removed, so the migrated item key is i12345.

Material Type

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. While there is a field called Material Type in Millennium, it does not directly translate to the Alma material type, and the default material type mapping is used.

Customers who have programming staff/skills may add their own (non-III) material type to the item extract in order to bypass the material type mapping based on the bb header information.

The migration automatically assigns a material type on migration, based on Bibliographic record fixed fields. There is no input required from you for this part of the migration since 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.

You can choose to provide a material type using the exact Alma material type code in the MATERIAL_TYPE field in the incoming item. See the chart in the link below for the list of possible material types. If the material type is not provided in this item record, then the mapped material type (from the bib header) is used.

An explanation of material types is found on the following page: Configuring Physical Item Material Type Descriptions. Consult the Alma menu option under Configuration -> Resources -> Physical Material Type Descriptions for a list of Alma material types in use.

All items are migrated as physical items, even those which will eventually be transformed to an electronic resource with p2e. See the P2E section for more information.

Secondary Item File

You may want to provide item descriptive information in a secondary file, because the data coming from Sierra/Millennium is not separated into the various Enum and Chron fields. For example, you have a description in the format Vol. 12 No. 2 (2015 February), but Alma recommends that enumeration and chronology information are without labels and are in separate fields. You can provide your description in a secondary item file.

With the exception of the item_key and barcode, all other fields will force blank if an empty field is provided. In other words, if you have an item description in Alma, and you provide a blank description in this file, the incoming blank will be 'written' to Alma, meaning the Alma description will be deleted.

We recommend that EnumX and ChronX fields contain only numbers, for example '12' instead of 'Vol. 12' and '2' instead of 'Feb'. However, it is programmatically time-consuming to distinguish between an invalid use (Vol. 12) and a valid use (12A), so in the interest of processing quickly, we allow any string in EnumX and ChronX fields. Do not provide a full date in a single field. Split any dates into three, for example 4 Feburary 2020 is ChronI=2020, ChronJ=2, ChronK=4.

Even though it is not recommended, if for any reason you need to provide a full date in a single field, put a tick (') before the date in the Excel cell so that it is treated like text (instead of the Excel date format).

Provide the secondary item file in Excel format (xls or xlsx) format, with the following fields:

Expected Field Name	Notes
item_key	Provide either item_key or barcode, but not both. If both are provided, item_key is preferred Always provide both fields, even when one is empty. For example:
barcode
description	Provide in a format such as: Vol. 12, No. 6 (February 2015)
enumA	For example, “12”.
enumB	For example, "6".
enumC
enumD
enumE
enumF
enumG
enumH
chronI	For example, "2015"
chronJ	For example, "2".
chronK
chronL
chronM

Migration Form - Inventory

The following sections will help you to answer the migration form questions related to inventory processing.

Questionnaire Tab

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

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

INST_NAME, CUST_NAME – These are mandatory and must be filled in.

Default: N/A

Options: This question is mandatory.

INST_NAME, CUST_NAME: Fill in these fields with your institution’s name and your customer name (this is different from the institution name only if you are part of a consortium).

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 incoming ILS 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 the 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 ILS 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.

There is no check for sequence of the 035 field - the migration programs check all 035 $a fields in the record for the specified string. Also, if you are unable or do not wish to remove these duplicates, some see the section Managing Duplication in Alma in the Electronic Resources Handling in Alma guide.

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 907 $a field (Millennium bibliographic system number) to the 035 $a field:

(MOC)<Incoming ILS 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)b123456-01abc. For more information on the MARC organization code or to request a code, see http://www.loc.gov/marc/organizations/.

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.

Use call number tags inserted from bib?

Code: CALL_NUM_HIERARCHY

Default: No

Options: If Yes, include the bibliographic fields with call numbers in the item extract, and the migration determines the call number based on the hierarchy of the fields.

If No, only include the call number in CALL # (ITEM) in the item extract. The type of call number (852 first indicator value) is determined either from the CALL # TYPE field in the item or, if this field is blank, from the Call Number Type field in the Alma Location tab, based on the location of the item.

Further Information: see the description about how the migration programs determine the call number, in the Millennium Inventory Files section above, specifically about holding records and items.

If CALL # (ITEM) field is empty, fill it in with the following text

Code: EMPTY_ITEM_CALLNO

Default: blank

Options: String or blank.

Further Information: You may decide to rely only on the CALL # (ITEM) field from the item record by replying No to the question Use call number tags inserted from bib? However, there may be cases where this field is empty or blank. If you consider a blank call number field to be a problem, you can use this string to retrieve and correct these records after they have been migrated to Alma. The string that is placed here is put in the call number field for any empty call number field. The advantage of using a string instead of leaving it empty is that a string is easier to search for. If you want to leave the call number fields blank, leave this question blank.

See section: see the description about how the migration programs determine the call number, in the Millennium Inventory Files section above, specifically about holding records and items.

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/location only, indicate bc here. If you have many items on the same bibliographic record in the same library/location 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.

See sections: Call Numbers from MARC holdings, serial checkins, and/or items, Determining Groups for Holding Records, Changing the Holding Record Grouping, Attaching Items to Existing Holding Records

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. Bib records without location information (standalone bibs) are included.

Inventory and Acquisitions are 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. For further information about the LIMIT_BY_LOCATIONS question, see Appendix B.

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 and FUND_PREFIX

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

Ex Libris marks the moved 035 or 935 with $9 ExL to indicate that the migration programs generated this field.

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#

The wildcard works only for the third digit of the tag and the indicators. Examples:

CORRECT: 95###

INCORRECT: 9####

Also, 900-949 cannot be used here, as described in the Migration Considerations for Consortia guide

Alma Library Tab

Use this tab to create a list of Libraries in Alma. At least one library is mandatory.

Alma Library Code: Maximum 10 characters. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character. These characters are allowed in Alma but they interfere with the migration mapping programs so they are not allowed during migration.

The Alma Library Code may not be the same as the Alma Customer Code nor the Alma Institution Code .

Alma Library name: Maximum 255 characters. Visible to the public. This must be unique. For example, you cannot have two libraries with code LIBA and LIBB and have them both called 'Library'. They must have different names.

Address/phone/email: Provide address information here if desired; otherwise you can fill it in Alma post-migration.

Default language: Indicate the language of patrons and/or staff members if it differs for each library. Use two-letter codes as defined in ISO 639-1. Consult the codes at https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Further Explanation: Millennium has one level of location, and Alma has two levels: library and physical/shelving location. Locations in Millennium are generally analogous to the physical/shelving locations in Alma. Libraries are higher level units which contain groups of locations. A list of Alma libraries must be created with locations on migration to Alma. Alma libraries serve as higher-level repositories for physical records and also determine policy groupings for their management and fulfillment. The lower-level physical location does not determine policy for an item and is only the physical shelving location or collection. All physical resources in your institution must belong to a library.

During the migration process, group your Millennium locations into library groupings. The first step is to determine the list of libraries, using this tab. Next, map locations into Alma libraries and locations using the Alma Location Tab.

If you use an error library (for example “EMPTY”) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, be sure to list that library here on the Library Tab.

Alma Location Tab

Use this tab to map your incoming ILS locations to libraries and locations in Alma. Mandatory.

Include ALL locations of ALL types, including electronic types that may ultimately be deleted in Alma. They still need to be provided in the location tab mapping.

III Location Code: Value from the LOCATION and the RLOC field in the item extract or the 852$b in the MARC holdings extract from Millennium. The ALMAME_VAL_NOT_FOUND line is required to catch any location codes you may have missed. See the section 'Receiving Location RLOC' for more information on the use of RLOC.

III Location Description: A description of the location, for assistance in filling out this form. This column is not used in the mapping routine.

Alma Library Code: The Library which will contain this location in Alma. This code must be present on the Alma Library Tab, column A. The match is case-sensitive.

Alma Location Code: The new location code for this location in Alma. It can be a maximum of 10 characters. You can use the same location codes in Alma that you used in Millennium, but this is not required. You may also use this form to collapse locations if desired, for example refa and refb in Millennium both map to ref in Alma. Mixed case is valid, but not recommended. Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character. These characters are allowed in Alma but they interfere with the migration mapping programs so they are not allowed during migration.

Call Number Type: List the call number type for any newly created holdings records, based on the values for the 852 first indicator. (http://www.loc.gov/marc/holdings/hd852.html). This column is used when we are taking the call number from the CALL #(ITEM) or CALL #(CHECKIN) field, and there is no CALL # TYPE found. We first try to get a call number type from the mapped CALL # TYPE field in the item, but if it is not present or there is no map, we use this type instead. There is no CALL # TYPE specified for checkins so we use this column each time we use CALL #(CHECKIN).

Alma Location Name: A description for this location as seen/used by library staff members. The same location name cannot be used for different locations in the same library, but the same location name can be used for different locations in different libraries. See the examples after the Further Information section below for what is acceptable and not acceptable. Maximum 255 characters.

Alma External Location Name: A description for this location as seen/used by the public. The same name can be used for as many different locations as desired. For example, the location names may be Archives A and Archives B, but the external location names can both be Archives. Maximum 255 characters.

Electronic Location? (Yes or No): Used by the P2E migration process to determine if a holding/item/order should be converted to electronic. See the Physical to Electronic (P2E) Processing section for more information.

Suppress from Externalization? (Yes or No): Indicate if the location should be suppressed from being visible to the public. The items are not marked as suppressed, but no holdings or items with this location code are exported to Primo.

Further Information: Do not leave the Alma location and library code fields blank. If you wish to stop using a location code after migration, map the Millennium code to an easily identifiable code such as XXX or unused just in case any stray items are still in your Millennium database.

ALMAME_VALUE_NOT_FOUND

The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, in case any location codes were overlooked when completing this map. For example, you may think you do not have any items left in a certain collection, so you leave it off the location map. However, there may be one or two items left, or a stray holding record, etc.

By default, the location code for the ALMAME_VALUE_NOT_FOUND line is “UNASSIGNED”, which is the default catch-all in Alma in production mode. Ex Libris recommends that you select your primary/largest library as the library code for the line, for example “MAIN” as in the example line below. In this case, the items inherit the configurations for the MAIN library.

III Location Code	III Locn Desc	Alma Library	Alma Location Code	Alma Location Desc	Alma External Loc Desc	Suppress from Externalization
ALMA_ME_ VALUE_NOT _FOUND		MAIN	UNASSIGNED	Problem location from Migration	Problem: See Library Staff	Yes

Post-migration, search for items in the “UNASSIGNED” location and correct the records appropriately.

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:

Library	Alma Location Code	Alma Location Name	Alma External Location Name
Library A	stacks	Main Stacks	Main Stacks
Library B	stacks	Main Stacks	Main Stacks
Library A	archa	Archives A	Archives
Library B	archa	Archives B	Archives
Library A	archstk	Archives Stacks	Archives
Library A	archref	Archives Reference	Archives

The following is not acceptable:

Library	Alma Location Code	Alma Location Name	Alma External Location Name
Library A	archstk	Archives	Archives
Library A	archref	Archives	Archives

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 III 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 III code to an easily identifiable code such as XXX if any stray items are still in your III database.

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

III Location Code	Alma Library	Alma Location Code	Alma Location Name	Alma External Loc Name	Suppress from Externalization	Electronic Location
reserves	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesElec	MAIN	RESERVES	Reserves	*ReserveElec*	Yes	*Yes*
reservesShort	MAIN	RESERVES	Reserves	Reserve	Yes	No
reservesPerm	MAIN	RESERVES	Reserves	Reserve	Yes	No

The two values in bold italic above (ReserveElec as the External Location name, and Yes for 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.

Item Base Status Tab

Use this tab to map your item statuses to Alma. This tab is not mandatory if you do not want to migrate your item statuses to Alma.

STATUS: The value in the status field from the Millennium item extract. The status typically indicates what is happening to the item, such as in binding, in repair, lost, etc.

Description: The description of the STATUS code. The text in this column is written to the internal note 1 in the item in Alma. Maximum 255 characters.

baseStatus: In Alma, the base status indicates whether or not the item is on the shelf. Indicate whether or not an item with this status is on the shelf. For example, lib use only is on the shelf (1), but withdrawn is not (0).

Further Information: Alma has a process type that indicates the status of an item depending on the Alma workflow (item is on loan, item is sent to the bindery, etc.), but the process type is dependent on the corresponding Alma workflow. For migration, all item statuses that are indicated as not on the shelf (0) from Millennium are given the process type of TECHNICAL. Further, the item status description field is written to internal note 1 for all items where there was a status, regardless of the shelf/not on shelf designation.

Post migration, you can search for and re-route items with values in the internal note 1 to the appropriate handling or department in Alma. This process can also be used as a configurable criterion for suppressing items from display in the Get It services screens from discovery systems. See Appendix A - Post-Migration Process Statuses for more information.

Available ('-').

When something has no status at all, Alma just does not provide a status. In Sierra, something with no status was given a status of '-'.

During migration, we want to transform the '-' into nothing. In order to do that with this tab, you should include the '-' in column A, but give it an On Shelf status (baseStatus = 1) and also leave the mapped description column (column B) blank.

This is how that looks:

If you do not include the '-' in column A, it will be caught by the ALMAME_VAL_NOT_FOUND line, and the migration will think you forgot about it and give it a 'Not Found Status'.

Duplicated workflows: On Loan, On Hold Shelf

There are some statuses which are duplicated by an Alma workflow. Examples of this are: On loan and On Hold Shelf. The loan and the request record from Sierra will migrate and consequently the item will be listed as not available because of the presence of the loan and/or request record in Alma.

You may or may not want to make a Technical Migration Status for 'On Loan' or 'On Holdshelf'.

Not making a Technical Migration Status: If you do not want to make a Technical Migration Status for the On Loan and On Holdshelf statuses, then items will only get a status if a loan or hold/request record was successfully migrated. To not make a Technical Migration Status for these, follow the exapmle given for Available ('-') above. Meaning, include the status in column A, give it a '1' meaning on shelf, and leave Description blank.
Making a Technical Migration Status: You might still decide to make a Technical Migration Status for the On Loan and On Holdshelf statuses. The reason you could do this is if for some reason Sierra thinks this item is On Loan or on Holdshelf, but no Loan or Hold/Request record was migrated. In this case, there are two categories of records
- Items with an attached Loan or Hold record. In this case, the item technically has two statuses: one from the attached record, and one Technical Migration Status. You will need to remove the Technical Migration Status from these items.
- Items without an attached Loan or Hold record. In this case, there was some mismatch in migration, and no Loan or Hold record was migrated. This group of records will ONLY have a Technical Migration status. These records can be used as a sort of pick list to remove from the hold shelf or mark as lost, or whatever.

Item Type Tab

Use this tab to migrate the Millennium Item Type to the Alma Item Policy. This tab is optional. The item policy in Alma is not required, so if you leave this tab blank, no item policies in Alma are created. For more information about how item policies are used in Alma Fulfillment, see the Physical Fulfillment page.

III Item Type: The value in the item type field of the Millennium item. The item type is used to differentiate between items when determining how something circulates.

III Description: The description of the III item type, for information only. This column is not used during the mapping process.

Alma itemPolicy: The Alma value for the item type. This sheet can be used to collapse item types if desired. Do not use special characters, for example, slashes (/) or spaces in the code. The limit for this code is 15 characters.

Alma Description: This description is loaded into Alma as the display text for the item types. These values can be changed after migration. Maximum 255 characters.

You can optionally include an ALMAME_VAL_NOT_FOUND line at the top of the map. If this line is included, any value not found or any blank value is assigned the value in the ALMAME_VAL_NOT_FOUND line. If the ALMAME_VAL_NOT_FOUND line is not included, any value not found, including blanks, is left as blank in Alma.

Item Physical Condition Tab

Alma will map an incoming value from the item record to the Physical Condition field in Alma. This is not a typical field in Sierra.

Incoming Physical Condition field: The values in the incoming Physical Condition field, from Sierra/Milennium..

Description: A description or note for the incoming value. This column is not used in migration.

Alma Physical Condition Code: The code for the physical condition in Alma. Customers can add their own list of conditions, in addition to the predefined conditions: Damaged, Deteriorating, Fragile, Brittle.

Alma Physical Condition Description: The description for the physical condition, used to generate a code table in Alma.

Further Information: You may use an ALMAME_VAL_NOT_FOUND line here if you wish. This value will only be used if there is an incoming value and it was not found in column A the table. If you do not want an incoming value to be shown/used in Alma, leave column C blank.

If there is no incoming value, then no value is migrated to Alma.

Fulfillment

Patrons

Extract all patrons. Patron records without a RECORD # (PATRON) are skipped.

All patron identifiers MUST be unique across all users, as required by Alma. If they are not, the migration program disambiguates them by giving them a hyphenated extension (-1, -2, etc).

Provide the patron files in comma delimited format as a standard Millennium extract. The following fields are expected. Indicate the local field names in the Migration File Validation Tool.

Field Name	Notes
RECORD #(PATRON)	Not repeatable.
UNIV ID	Alphanumeric, repeatable. See User Identifiers section below.
P BARCODE	Alphanumeric, repeatable. See User Identifiers section below.
EXP DATE	Date, not repeatable. May be left empty. To change an expiry date post-migration, see User Expiry Date
P TYPE	Character not repeatable.
HOME LIBR	Alphanumeric not repeatable.
HOME INST	Alphanumeric not repeatable.
MBLOCK	Alphanumeric not repeatable.
MONEY OWED	Ex Libris makes a single Fine/Fee record for the outstanding balance owed. If you are providing a separate fine/fee file, do not map this field to Alma.
BLK UNTIL	Date not repeatable.
PATRON NAME	Alphanumeric repeatable. Expected in format: "Smith, John B" where Smith goes to last name, John goes to first name, and B goes to middle name.
PREF_FIRST_NAME	Alternate form of name. Added for the Japanese market but anyone can use.
PREF_MIDDLE_NAME
PREF_LAST_NAME
PREFERRED_NAME_FULL	If this is provided, the expected format is "Smith, John B", and the string will be parsed as: PREF_LAST_NAME = Smith PREF_FIRST_NAME = John PREF_MIDDLE_NAME = B
PREF_FIRST_NAME_ORIG	Alternate form of name. Added for the Japanese market but anyone can use. If at least one of these fields is filled and other(s) are empty, the empty field(s) are filled with the comparable regular name. For example, if you provide PREF_FIRST_NAME and PREF_LAST_NAME, but PREF_MIDDLE_NAME is empty, then the PREF_MIDDLE_NAME is filled with the value (if any) of MIDDLE_NAME. For more information, see Managing Users, search for the description for 'Preferred first / middle / last names'.
PREF_MIDDLE_NAME_ORIG
PREF_LAST_NAME_ORIG
CREATED(PATRON)	date not repeatable
BIRTH_DATE	Date not repeatable
LANGUAGE	Use in User Language map. If no values are here, use the PATRON_LANG question on Questionnaire tab of the migration form
USER_TITLE	Mr, Mrs, Ms, etc
JOB_TITLE	Alphanumeric string
GENDER	Male or Female. For other, like institutional patrons, leave blank
PURGE_DATE	date not repeatable. If this is empty, then migration uses the expiry date
ADDL ID 1	Alphanumeric repeatable. See User Identifiers section below.
ADDL ID 2	Alphanumeric repeatable. See User Identifiers section below.
ADDL ID 3	Alphanumeric repeatable. See User Identifiers section below.
ADDL ID 4	Alphanumeric repeatable. See User Identifiers section below.
ADDRESS_PREFERRED	There may be a number of addresses, phone numbers, and email addresses in the Millennium patron record. You may decide which addresses, phone numbers, or email addresses are the preferred ones in Alma. If the preferred entry is empty, the secondary one is preferred. Additionally, select an address type for each address: Home, School, Alternative, Work, All. Phone types are: Home, Mobile, Office, OfficeFax, All. Email types are: Personal, School, Work, All. Millennium has two fields each for Address, Phone, and Email. You can select which of the two fields is the preferred address by mapping to either the PREFERRED or SECONDARY field in the Migration Validation tool. Additionally, you can select an address/phone/email type for each field or assign them a type of ALL, meaning that the specified address/phone/email may be used for all types such as home, work, or school. See the Millennium to Alma Data Delivery Specification document for more information. In addition, Millennium does not have separate fields for city, state, or postal code so the addresses are migrated as is from lines 1-5 in Millennium to lines 1-5 in Alma. If the country code or name is included in this address, the migration programs do not standardize it.
ADDRESS_SECONDARY
PHONE_PREFERRED
PHONE_SECONDARY
PHONE_MOBILE
EMAIL_PREFERRED
EMAIL_SECONDARY
USER_STAT_CATEGORY	See explanation below, in section 'User Stat Categories'
LIBRARY_NOTE	Fields which are not expected can be placed in a patron note. Multile fields can be palced in notes; use the field label to add a prefix to data values if desired.
BARCODE_NOTE
ADDRESS_NOTE
CIRC_NOTE	CIRC_NOTE is marked by the migration programs as a popup note. This is the only user note which migration marks as a popup note.
OTHER_NOTE	OTHER_NOTE is set as user viewable by the migration programs. This is the only note which migration marks as user viewable.

User Stat Categories

There may be a number of fields in the patron record that function as a statistical category only, for example, a student’s department or major. The way the student borrows can be determined by the P TYPE, but you may want to track the department, so that you can get more detailed statistics on how Law students borrow, for example. Since Millennium has a large number of fields that are customizable, we provide you the option to map the data from any field to the User Statistical Categories in Alma.

If you have categories which overlap, such as LAW as department and LAW as major, you can prefix the category in the Migration File Validation tool, using the 'prefix' input box to the right of the mapped field. For example you can say DEPT: LAW and MAJ: LAW. The validation tool will not provide a colon, so if want the colon be sure to include it , e.g. 'DEPT:', but it does provide a space between the label and the value.

If you use this prefix, be sure to use the prefix again in the Migration Form Mapping tab for User Stat Categories, in column A (incoming data).

You may provide up to 10 statistical categories.

In the Migration File validation tool, provide labels to the right of the field:

Then, in the migration form, use that label as a prefix to the values in the field. Be sure to put a space between the label and the code:

In the case above, you can see that if there were no prefix to the fields, it would not be possible to distinguish between 'UN' from PC1 and 'UN' in PC2.

User Identifiers

The migration program allows for six different types of user identifiers: University ID, Barcode, and Additional ID 1, 2, 3, and 4. Select one of these identifier types as the primary ID – the primary unique identifier for the patron. You may map multiple identifiers from your previous ILS. You may also consider mapping email address, a common matchpoint in authentication systems, to an additional ID field.

The identifier selected as the primary ID is not also written to the patron identifier section in the Alma patron record. The identifiers that are NOT selected as the primary ID are written to the patron identifier section in Alma, and they must be unique as well - even across identifier types. The identifiers are disambiguated in the same way that the primary identifier is - by placing a suffix of -1, -2, -3 etc after the subsequent identifier found.

Identifiers may not be duplicated, even within the same patron record. See the questionnaire question DUP_ID_SAME_PATRON for options.

If the identifier selected for the primary ID is not present, the migration program creates an identifier for the patron based on the patron original ID, prefixed with ID. The migration programs do not fill in the primary ID with a non-selected identifier.

To select the appropriate primary identifier as the Primary ID, answer the PATRON_PRIMARYID question on the Questionnaire tab of the Migration Form. For more information about how identifiers are used in Alma patrons, see the Managing User Identifiers page.

If multiple identifiers of the same type are provided, the first identifier is migrated as the identifier type and is Active, and the subsequent identifiers are migrated as the same identifier type but are Inactive.

Loans/Circ Transactions

Extract only current circulation transactions.

Extracted data is skipped if it has:

a missing OUT DATE
multiple Patron record numbers

If there are loans in your database that do not have an associated patron, for example, an InterLibrary Loan (ILL) record, provide a III patron ID (p12345656 number) in the LOANS_EMPTY_PATRON question on the Questionnaire tab of the Millennium and Sierra (III) Migration Form.

Provide the loan files in comma delimited format as a standard Millennium extract. The following fields are expected.

Items with Status Loan or Lost

Some previous systems keep track of the item's status in two places: by the presence of a loan record and by an item status which indicates the item is on loan. Alma only keeps track in one way: by checking the presence of the loan record. Therefore, do not migrate item status where the item is out on loan - this will only serve to confuse patrons when that loan is returned, because Alma will not remove the item status of type loan. When checking the migration, be aware that a technical migration status will display *instead* of a loan status. So, if an item is both lost and on loan, the item will not appear to be on loan and only the lost status will display.

Field Name	Notes
RECORD #(ITEM)	alpha/numeric
OUT DATE	date
RECORD #(PATRON)	numeric
DUE	date. This is mandatory in Alma, but not mandatory in the MFVT (migration file validation tool). If you will provide loans without a due date, let your Ex Libris representative know what the default due date for all loans should be.
#OVERDUE	numeric; If the number of overdues for a loan is 4 or more, then the loan is declared LOST. If you wish to retain the actual number of overdue notices sent, then also put this field in a note. To add a field to multiple expected fields, use the plus sign (+) to the left of the field name.
ODUE DATE	date
#RENEWALS	numeric; the number of renewals is checked to determine renewal status; if you wish to retain the number of renewals, also put this field in a note. To add a field to multiple expected fields, use the plus sign (+) to the left of the field name.
RECAL DATE	date
NON_PUBLIC_NOTE	Multiple incoming fields can be placed in the note; use the field label to distinguish if desired.

Requests (Holds)

Extract only those hold requests where the item is waiting on the hold shelf for pickup. It is possible to limit the hold request extract file to these kind of requests by linking to the item and only retrieving those hold requests where an item hold status value = ‘!’.

Because the only hold requests that we migrate are those that are on the hold shelf waiting for pickup, by definition there cannot be

- two requests for the same item

- a loan and a request(s) for the same item

Providing either of the above will result in the second request (or first request in the case of the loan) being rejected by the migration program.

The migration program will automatically update the item to have a 'Hold Shelf' status based on the existence of a hold record, so be sure to indicate that (!) 'On Holdshelf' is marked as 'on shelf'. See the description in the Item Base Status tab for more information.

Provide the request files in comma delimited format, as a standard Millennium extract. The following fields are expected.

Field Name	Notes
RECORD #(ITEM)	Alphanumeric
HOLD(ITEM)	Contains P# - patron number I# - item number (again) P - date hold placed NNB – not needed before RLA - [not used] NNA – not needed after: If NNA is > 30 days from conversion date, Expire_date is set to conversion date + 30. ST – Status TP - [not used] PU – Pickup Location
NON_PUBLIC_NOTE

Field Name

Notes

RECORD #(ITEM)

Alphanumeric

HOLD(ITEM)

Contains

P# - patron number

I# - item number (again)

P - date hold placed

NNB – not needed before

RLA - [not used]

NNA – not needed after: If NNA is > 30 days from conversion date, Expire_date is set to conversion date + 30.

ST – Status

TP - [not used]

PU – Pickup Location

NON_PUBLIC_NOTE

Separate Fine/Fee File

Most IIII/Millennium and Sierra customers do not provide a separate fine/fee file. Usually, the patron field contains a ‘MONEY OWED’ field and the migration programs make a single fine in Alma based on that field.

However, if you are able to extract a separate fine/fee file with exact fines for specific patron and item combinations, use this format described here. It is our understanding that certain Sierra versions support this separate fine/fee file. For more information, see the entry in the Ex Libris Developers’ portal on Sierra fine export: https://developers.exlibrisgroup.com...ra-III-to-Alma.

If you provide a separate fine/fee file, then be sure to NOT map the ‘MONEY OWED’ field in the patron record, so that duplicate fines are not created. When a separate fine/fee extract is not provided, a single fine/fee transaction is created in Alma based on the outstanding balance at the time of conversion from Millennium. The outstanding balance is a field in the patron extract. Customer may select the Fine Fee type for these transactions in the FINE_FEE_TYPE question on the Questionnaire tab, and a note is placed in the fine record, Outstanding balance at conversion from Millennium.

Extract only current fines and fees. Only outstanding amounts are migrated – for example if the original fine was $20, and the patron paid $5, then a fine is generated of amount $15.

Provide the fine/fee files in comma delimited format as a standard Millennium extract. The following fields are expected.

Field Name	Notes
RECORD #(PATRON)	matches patron ID in patron file
RECORD #(ITEM)	matches item ID in item file
ASSESSED DATE
TOTAL CHARGES
PAID AMOUNT
CHARGE TYPE	use Fine Fee Type map
CHARGE_LOCATION_CODE	sent through Alma Location map to get Library
FF_COMMENT	This is a note field associated with the fine/fee. Multiple fields can be placed here; use the field prefix to distinguish between fields if desired.

Courses

Provide the course files in comma delimited format, as a standard Millennium extract. The following fields are expected.

Field Name	Notes
RECORD #(COURSE)	alpha-numeric; also added as a searchable ID
BEGIN DATE	mm-dd-yy; also used to determine if course is active. This is required in Alma; if not supplied the migration date is used.
END DATE	mm-dd-yy; also used to determine if course is active. This is required in Alma; if not supplied the migration date + 1 year is used.
BRANCH	alpha-numeric
CCODE1	alpha-numeric; added as a searchable ID
CCODE2	alpha-numeric; added as a searchable ID
CREATED(COURSE)	mm-dd-yy
UPDATED(COURSE)	mm-dd-yy
REVISIONS(COURSE)	numeric
COURSE	There are multiple options for providing this field. After you select the field in the Migration File validation tool, choose one of the following from the dropdown on the right: course code : the field contains only course code, for example "BIO 101" course code ; course code : the field contains one or multiple course codes, for example "BIO 101";"MED 101" course code ; course name (duplicate = Y) : the field contains course code and course name together, for example "BIO 101";"Introduction to Biology". If the input is "BIO 101";"MED 101";"Introduction to Biology", then we will duplicate the line to make multiple courses: "BIO 101";"Introduction to Biology" and also "MED 101";"Introduction to biology" course code ; course name (duplicate = N) : the field contains course code and course name together, for example "BIO 101";"Introduction to Biology". If the input is "BIO 101";"MED 101";"Introduction to Biology", then we will not duplicate the information, but will only make a single course: "BIO 101 MED 101";"Introduction to Biology" course name ; course code : the field contains course name and course code together, for example "Introduction to Biology";"BIO 101"
COURSE NAME	alpha-numeric
READING_LIST (ITEM_ID)	Ex Libris expects this field to be exported directly from Millennium/Sierra in the format they export with no manipulation after export. Typical data for this field looks like this: "i1594908:06-30-17:a";"i1595108:06-30-17:a";"i1594907:06-30-17:a";"i1595110:06-30-17:a";"b1595280:06-30-17:a"
INSTRUCTOR_ID	Put your instructor field here only if the field contains an actual identifier which can be used to link to a migration patron record. If the instructor field includes just a name/text, then move that field to a note.
COURSE_NOTE

Reading Lists Linked to Multiple Courses

In Alma, a reading (reserve) list may be assigned to only one course. In Millennium, a reading (reserve) list may have multiple courses specified for it (for example cross-listed courses). On migration, reading lists that have multiple linked courses are duplicated, once for each course. For example, if Reading List A is linked to both HIS 200 and SOC 200 it is created twice in Alma, once under HIS 200 and once under SOC 200.

Duplicate Course Codes

Course names must be unique in Alma. If a course code is duplicated in Millennium, the subsequent course code is suffixed by the COURSE_ID on migration to Alma. For example, if you have two courses with HIS 400 as the code, the first is migrated as HIS 400, the second is migrated as HIS 400-2, and the third is migrated as HIS 400-3, etc. This is done to ensure uniqueness on migration.

Reading List Items -> Bibs

Elements of the reading list in Millennium are stored at the item level so that the individual item record is attached to the reading list. In Alma, the reading list stores information at the bibliographic record level. During migration, we swap the item key with the related bib key, so it looks like titles are on reserve instead of items. As a result, if a reading list contains multiple items from the same bibliographic record, only a single link to the bibliographic record is migrated.

Faculty/Department

The Prof/TA in Millennium is a free text field to specify the instructor of the course. In Alma, this field is linked to the user record itself so that the instructor of the course is linked to the instructor’s Alma user record. Since there is no way to parse the free text in Prof/TA, the professor/instructor text is mapped to a note on migration to Alma.

Migration form - Fulfillment

Questionnaire Tab

Which identifier should be used as the patron's Primary Identifier?

Code: PATRON_PRIMARYID

Default: UNIV ID

Options: Using the Migration File validation tool, map the identifiers exported from Millennium into the following list: UNIV ID, BARCODE, ADDL ID 1, ADDL ID 2, ADDL ID 3. Then, select here the identifier which should be used as primary for all patrons.

Further Information: The identifier selected here is used as the match point for externally managed patron records to match up with an external authentication system such as LDAP or Shibboleth. There is no password for external users. Additionally, this identifier will be the primary identifier for internally managed patrons. It is highly recommended to use the Primary Identifier as the identifier for authentication. Notice that Primary Identifier is not case-sensitive, as opposed to all other identifiers, which are case-sensitive.

See also: Identification Numbers, Internal? question on the User Group tab. Passwords are not migrated for any patrons.

How should we handle duplicate identifiers in the same patron?

Code: DUP_ID_SAME_PATRON

Default: DISCARD

Options: Alma does not allow duplicate identifiers anywhere, even in the same patron. If the patron has the same number in two or more different identifier types, we can either not migrate the second one, or disambiguate it with -1, -2 etc.

DISCARD: do not migrate the second and subsequent identifiers
ADD_SUFFIX: add -1, -2, etc

Default: DISCARD

Enter a two-letter code for the default conversational language for your users (for example en or fr)

Code: PATRON_LANG

Default: en

Options: Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes. Additionally, the language code zh-tw (Taiwanese Mandarin) is accepted.

Patron ID for loans without a patron

Code: LOAN_EMPTY_PATRON

Default: (none)

Options: A Millennium or Sierra patron ID (e.g. p1234567).

Further Information: In certain cases such as ILL, Millennium allows a loan to be performed without an actual patron identifier. For these loans, Alma must have a patron assigned to them. Make a new patron in your III system (such as “ILL Patron”), and put the p-number (for example, p1234567) of that patron here. All loans without a patron are assigned to this patron. If no patron is provided, loans without a patron will be rejected.

Currency for patron fines

Code: PATRON_CURRENCY

Default: USD

Options: Use the three-letter code for the currency used for patron fines. For a list of valid codes, consult http://en.wikipedia.org/wiki/ISO_4217.

Fine Fee Type for patron fines

Code: FINE_FEE_TYPE

Default: Overduefine

Options: III Millennium delivers the outstanding fine/fee balance for patrons as a single amount. In Alma, this is represented by a single fine/fee, with no link to an item. Select the fine type for all of these migrated fines from the drop-down list.

This is only for debit (owed) balances. Credit balances are migrated as Credit.

Use a map for the HOME LIBR to campus code migration?

Code: CAMPUS_CODE_MAP

Default: No

Options: Select Yes for this option only when you maintain and use different values in the Millennium HOME_LIBR field to distinguish between different user groups for resource sharing activities like ILL borrowing. When Yes, fill in the mapping from the HOME_LIBR to the Alma CampusCode field on the Campus Code tab. When No, all users are simply considered part of the same group for resource sharing activities.

Use Course Reserve BRANCH to Course Unit Map?

Code: COURSE_UNIT_MAP

Default: No

Options: Yes or No. Answer Yes to this question if you are migrating courses and you have multiple staff units which manage different groups of courses. For example the Law Library maintains a separate course reserve list from the Main Library and there is no sharing of courses or staff between them. When Yes, also fill out the mapping from the Millennium BRANCH field to the Alma Course Unit field, on the Course Unit tab. When No, all courses are assigned the same course unit, accessible by all staff who are allowed to work with courses.

Request Default Destination Library

Code: REQUEST_LIBRARY

Default: ALMAME_VAL_NOT_FOUND

Options: Select a library which will be assigned as the request pickup location if the incoming request does not have one specified.

Merge Patron Prefix

Code: MERGE_PATRON_PREFIX

Default: No

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 incoming patron record original IDs. This prefix is only added to the internal patron identifier, it is not added to barcodes or usernames or UNIV_ID. If you are not merging institutions, leave this question blank.

See also: BIB_KEY_PREFIX and FUND_PREFIX

User Group Tab

The user group is used to distinguish groups of patrons from each other in determining different levels of circulation policies. Typical user groups are faculty, staff, undergrad, etc.

If patrons are being migrated, then this mapping table is mandatory.

III P TYPE: The Millennium patron type code, found in the P TYPE field of the patron extract.

III Description: A description of the Millennium patron type code, here for information only. This column is not used in the mapping to Alma user group.

Alma userGroup Code: The mapped group code in Alma. You may choose to use the same codes that you used in Millennium, or you may choose to use different codes. You may also choose to collapse groups if desired, for example, having Freshman and Sophomore both map to Undergrad in Alma. Do not use special characters, for example, slashes (/) or spaces in the code.

Alma userGroup Description: The description of the Alma userGroup. This description is loaded into the Alma code table as the description seen in the user interface. This description can be changed easily after migration.

Internal? Y or N: Alma categorizes users as either external or internal. External patrons are managed and authenticated by an external system, such as through a regular load from the bursar’s office/campus student information system. Internal patrons are created and managed internally. Examples of internal patrons would be minority cases where community borrowers or alumni use library services. When Y, all of the patrons in the Alma userGroup are categorized as internal. When N, all of the patrons in the Alma userGroup are categorized as external.

External users are fully external (except patron notes), including all user identifiers, authentication, and address information. See the User Identifier section above for more information.

User Block Tab

A user block is assigned to patrons that have a temporary suspension of borrowing privileges. Millennium stores patron blocks in the MBLOCK field in the patron record.

This mapping table is not mandatory.

When a patron has no blocks in Millennium, the MBLOCK field has OK in it. Do not include OK in the mapping table. When the patron is OK, there should be no block at all.

III MBLOCK: The Millennium patron block code as found in the MBLOCK field in the patron extract.

III MBLOCK Description: A description of the Millennium patron block code, for information only. This column is not used in the mapping.

Alma userBlock code: The block code desired in Alma.

Alma userBlock description: The description of the block code in Alma. The value in this column is loaded to the server in the userBlock code table. This description can be easily updated after migration.

This mapping table has a line for 'DATE'. If the field BLK EXPIRY has a date in it, then the migration engine will act as if a block with value 'DATE' is coming from Millennium/Sierra. You may not change the incoming 'DATE' but you may change the Alma code table value for this block in the mapping tab.

Campus Code Tab

Use this tab only if you answered Yes to the question on the Questionnaire tab: Use a map for the HOME LIBR to campus code migration? This mapping is not mandatory if you do not maintain separate patron campuses.

The Alma User Campus field is used to determine a patron’s affiliation for ILL or cross-campus borrowing. If your library maintains the HOME_LIBR field in Millennium for a similar purpose, map the HOME_LIBR value to the Alma Campus Code value with this map.

III HOME_LIBR: The value of the patron home library as found in the HOME_LIBR field of the patron extract.

III HOME_LIBR Description: A description of the HOME_LIBR field, for information only. This column is not used in the mapping.

Alma campusCode: The Alma campusCode desired. You may map the codes 1-to-1, or you may use this map to collapse codes if desired.

Alma campusCode Description: A description of the Alma campusCode, for informational purposes only.

Further Information: Unlike other mapping tabs, the campus code and description are not loaded as a code table to Alma. Customers should set up campuses in Alma.

User Stat Categories Tab

Use this tab if you use statistical categories in your patron records and you want them to migrate to Alma. In Millennium, it is possible to have multiple fields that contain statistical codes. Some examples are: HOME_INST, DEPT and SCHOOL.

Before filling in this tab, specify in the Patrons tab of the Generic to Alma Field Mapping form which fields from your legacy ILS are migrated to statistical categories in Alma. You can include a label before each category to distinguish between categories in different fields. For example, you can have LAW in USER_CATEGORY1 and also LAW in USER_CATEGORY2. If desired, use a prefix to distinguish between the two, for example, CAT1: LAW and CAT2: LAW.

The migration engine adds a space between the label you specified in the Field Mapping form and the value. So if you included a label 'CAT:' in the field mapping, then use 'CAT: a' here (if 'a' is an incoming value).

Millennium Statistical Category: List all of the values from all of the fields you chose to put into the statistical category mapping. For example, if you used all three fields HOME_INST, DEPT, and SCHOOL, list all values from all three fields in Millennium. Include the label applied if it is important to distinguish between values in different fields.

Statistical Category Description: A description of the individual categories, for information only. This field is not used in the mapping to Alma.

userStatCategory Code: The Alma Statistical Category code desired. This code is used to retrieve groups of patron records with various reporting tools.

userStatCategory Description: The description of the Alma Statistical Category Code. This value is loaded into the code table for userStatCategories. This description can be easily updated after migration.

User Language Tab

If your institution stores a language code for communication preference, you can map that code to the Alma patron language field. Provide the list of available language codes from Millennium with their description, along with the language code as it should be in Alma. Use the two-letter codes as defined in ISO 639-1. Consult the codes from https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.

This mapping table is not mandatory. If fields are left blank, all patrons are assigned the default patron language as defined on the Questionnaire tab (PATRON_LANG).

III LANGUAGE: The value of the patron preferred communication language as found in the LANGUAGE field of the patron extract.

III LANGUAGE Description: A description of the LANGUAGE field, for information only. This column is not used in the mapping.

Alma Language Code: The language code desired in Alma.

Alma Language Description: The description of the language. This column is not used by the migration programs.

Fine Fee Type Tab

Most Millennium customers send the patron fine in a single value in a field in the patron record. In this situation, this mapping tab is not needed.

Some Sierra customers have the ability to export fines/fees in a separate export file. In this situation, use this mapping tab to translate the Sierra fine fee type to an Alma fine fee type.

III Charge Type: The incoming (III) fine fee type, when fines are provided in a separate file.

III Charge Type Description: A description of the fine fee type, for information only. This column is not used in the mapping.

Alma Fine Types: The corresponding fine type in Alma. Select from the drop-down list.

Course Unit Tab

Use this tab only if you answered Yes to the question on the Questionnaire tab: Use Course Reserve BRANCH to Course Unit Map? This mapping is not mandatory if you do not have administratively separate course maintenance operations.

The Alma Course Unit is used to assign separate editing privileges to staff members who maintain course reserves information in administratively separate sections of the library. It is strongly recommended to use a single course unit unless there is a pressing need for multiples.

III BRANCH: The value of the Millennium branch library, found in the BRANCH field in the course reserves extract.

III BRANCH Description: A description of the BRANCH field, for information only. This field is not used in the mapping.

Alma service_unit/code: The desired code value for the course service unit in Alma. You can collapse the BRANCH values, if desired.

Alma service_unit/name: The name for the course service unit in Alma. This field is used to create a code table that is loaded into Alma.

Course Faculty Tab

Use this tab if you are migrating data to the COURSE_FACULTY field on the Courses section of the Migration File validation tool.

In Alma Course Reserves, the Course Faculty field is a controlled field, meaning that you cannot enter free text in the field – it is controlled by a back-end code table. The Course Faculty field is also called Academic Departments.

III customers can generate a code table by using the COURSE_FACULTY field in the Migration File Validation Tool and filling in the Course Faculty Tab.

III Course Faculty: The value in the Millennium Course Faculty field or other field that you put in the COURSE_FACULTY line of the Course Tab of the Migration File Validation Tool.

III PROF/TA Description: A description of the value in the incoming Course Faculty field, if necessary.

Alma Course Faculty code (Mandatory): The code of the academic department or course faculty in Alma

Alma Course Faculty Name: The name of the academic department in Alma

Acquisitions

Vendors

Provide the vendor file in comma delimited format, as a standard Millennium extract. The following fields are expected.

Vendor accounts are mandatory in Alma, so the migration programs generate a single vendor account for each vendor migrated from Millennium/Sierra.

Alma’s orders require a vendor. Any order with a dummy vendor (the dummy vendor commonly used in Millennium is none) or no vendor is rejected, so you must supply a real vendor. Make a vendor of code none in your Sierra/Millennium system prior to export, and we will assign any order with no vendor to this none vendor.

Since Sierra/Millennium does not provide a list of currencies which can be used by a vendor, all vendors are assigned 'ALL' in the vendor currency field. Therefore, all currencies which are defined for use by the institution can be used by each vendor.

Field Name	Notes
RECORD #(VENDOR)	alpha/numeric
CLAIMCYCLE	alpha/numeric
DISCOUNT	Numeric
CREATED(VENDOR)	date
VENCODE	alpha/numeric
VENNAME	alpha/numeric
ACCTNUM	alpha/numeric
ALTCODE	Financial System Code/ERP
CONTACT	alpha/numeric, not repeatable. If this comes in parts, like "John Smith$Account Rep$777-555-1212", the parts are not split - the string is moved to the contact last name as is. Post-migration, customers should move contact information to the appropriate address in Alma.
ADDRESS_PREFERRED	If a vendor address has more than five lines, the sixth and subsequent lines are put in the vendor note. All addresses, phones, and emails are migrated to Alma with type 'ALL'.
ADDRESS_SECONDARY	If a vendor address has more than five lines, the sixth and subsequent lines are put in the vendor note. All addresses, phones, and emails are migrated to Alma with type 'ALL'.
PHONE NUM	alpha/numeric. All addresses, phones, and emails are migrated to Alma with type 'ALL'.
FAX	alpha/numeric. All addresses, phones, and emails are migrated to Alma with type 'ALL'.
EMAIL	alpha/numeric. All addresses, phones, and emails are migrated to Alma with type 'ALL'.
VENDOR_NOTE	Regular internal vendor notes

Funds

Fund records are collected in an Excel migration form and then exported to CSV format and submitted to Ex Libris. Funds are not extracted from Millennium directly. All funds must be listed in the first tab of a spreadsheet before exporting to CSV. Files in Excel format are not accepted by Ex Libris. Also, since the file must be exported to CSV before submitting, there is no possibility of having multiple Excel tabs in the submitted file. Each csv file must contain a header line with the field names as described below.

In the fund file, LEDGER CODE, LEDGER NAME, FUND CODE, and FUND NAME are mandatory. Ledgers are mandatory and if your institution does not have ledgers in the legacy ILS, define one general ledger for use in Alma.

Note that fund codes, summary codes, and ledger codes are unique across the entire fiscal period, not just within specific hierarchies – so in the spreadsheet submitted, there should be no fund or ledger code duplication since all of the funds and ledgers go into a single active fiscal period. This uniqueness restriction applies across ledger codes, summary fund codes, and fund codes. See the section 'Uniqueness examples' below for further explanation on this point.

Funds are grouped under summary funds, and summary funds or allocated funds are grouped under ledgers. Only one level of summary fund is allowed in the extract; however, you can create a new summary fund in Alma after migration and drag other summary funds underneath it in the hierarchical fund structure.

You can use the LIBRARY field to differentiate the funds of multiple campuses or libraries from one another. (The library code must be a valid III location code.

The FUND CODE in this file must match a fund code used by Millennium’s order records to make an encumbrance transaction in Alma that links the order to the fund.

Field Name	Notes
LEDGER CODE	May be repeated across lines to group funds under a single ledger.
LEDGER NAME	May be repeated across lines to group funds under a single ledger.
SUMMARY FUND CODE	Not mandatory, may be repeated across lines within the same ledger. See the section 'Uniqueness examples'
SUMMARY FUND NAME	Not mandatory, may be repeated across lines within the same ledger. See the section 'Uniqueness examples'
FUND CODE	Alphanumeric, not repeatable (This is the fund code that links to the fund code in the Millennium order record.) THis must be unique, even across ledgers. If providing invoices and therefore funds across multiple fiscal years, all funds must still be unique. In that case, codes should be like this: Current year fund code unsuffixed, like BOOKS Previous year fund codes have a suffix of the year, like BOOKS-2020, BOOKS-2019. You may only submit previous year funds if you are also submitting invoices. Submit only single-year funds if you are submitting orders but not invoices.
FUND NAME	Alphanumeric, repeatable.
LIBRARY	The field is named LIBRARY, but contains Millennium III incoming location codes. The values must be in the Millennium location list from the Millennium Migration Form. Matching is case sensitive. There can be multiple locations in this field, separated by a semicolon. This field can be left empty, which means that all locations in the institution can use the fund. If the central order library is used in the migration form, this field is ignored and all funds are set to the institution level, meaning that all libraries in the institution can use the fund.
EXT ID	External ID for linking to an external source, if one exists.
ALLOCATION	Allocation, in local currency, of the current fiscal year’s funds. Enter only the numbers with decimal places, not the currency symbol. For example: 10000.00.
FY	Fiscal Year YYYY. Typically this is the active fiscal year. If providing invoices, you can provide funds for multiple fiscal years.
NOTE	optional note for the fund

Uniqueness Examples

When creating funds, the fund codes must be unique. The only exception to this is the summary fund code, which may be repeated but only within the same ledger to indicate a hierarchy. See the table below for more examples of uniqueness in fund codes.

Ledger code	Summary fund code	Allocated Fund Code	Fiscal Year	Comment
L1	ARTS	MUSIC	2021	"ARTS" may be repeated here because this indicates a single summary fund ARTS in the ledger L1, which contains two allocated funds below it (MUSIC and DRAMA).
L1	ARTS	DRAMA	2021
L1	SCIENCE	BIOLOGY	2021
L2	ARTS	PERFORM	2021	"ARTS" may not be repeated here in the L2 ledger because it is already being used in the L1 ledger.
L2	ARTS	TACTILE	2021
L2	SCITECH	BIOLOGY	2021	"BIOLOGY" may not be repeated here since it is already in use in the L1 ledger
L2	SCITECH	BIOLOGY_L2	2021	Either come up with a completely different fund code or put a ledger suffix on the fund code.
L1	ARTS	MUSIC	2020	both "ARTS" and "MUSIC" may not be used here since they are being used in Ledger L1 in FY 2021. Codes may not be repeated even in different fiscal years.
L1	ARTS_2020	DRAMA_2020	2020	This is a correct use of fund codes for funds in different fiscal years. Funds in different fiscal years is only available for customers who provide invoices.
L1	BOOKS	L2	2021	"L2" as an Allocated Fund Code is not allowed here because it is already being used as a ledger code.
L1	BOOKS	ARTS	2021	"ARTS" as an Allocated Fund Code is not allowed here because it is already being used as a Summary Fund Code.

Purchase Orders

The Alma Purchase Order consists of a PO header, which includes one or more PO lines attached to it. The PO lines represent the items ordered.

In Millennium, there is a single order for each item ordered. As a result, on migration, the structure is a PO header and a single attached PO Line for each order encountered.

All orders from Millennium are migrated to Alma, but only the active orders (NEW, SENT, and WAITING_FOR_INVOICE) in the current fiscal year have a link to the fund via an encumbrance transaction. The fund and price information is put in a note for all orders so that the information is not lost.

Active continuous orders may have a subscription start date, but open orders/subscriptions do not have an end date in Alma (they are open-ended). Set the renewal date with the RENEWAL_DATE question on the questionnaire tab.

Payment information is associated as a referenceable note on the purchase orders that were paid, when payment information is provided.

Customers can provide closed historical orders, but fund transactions are only created for open orders in the current fiscal year.

The Purchase Order Material Type is a recommendation that is available for open OT orders only, because OT orders can have linked items in Alma. Unfortunately, Millennium and Sierra do not provide a link from the item to the order or vice versa. Therefore, there are no PO Material Types in the Millennium/Sierra migration. CO/SO orders do not get a material type during migration since there is only the possibility of linked holding records, which do not contain a material type.

Provide the order file in comma delimited format, as a standard Millennium extract. The following fields are expected.

Field Name	Notes
RECORD #(BIBLIO)	Alpha/numeric. Required: a purchase order in Alma must be related to inventory.
RECORD #(ORDER)	Alpha/numeric; must be unique per vendor in Alma
LOCATION	Alpha/numeric. Multiple locations and multiple copies acceptable, like 'main(2),bio'. This means two copies were ordered for main and one for bio.
COPIES	Numeric
ACQ TYPE	Alpha/numeric; use in PO Acq Type tab
CLAIM	Alpha/numeric; use in PO Claim Tab. The mapped value for this claim field is also used as the subscription interval for CO and SO orders.
E PRICE	This is the estimated price if the order is using local currency, used to generate an encumbrance for the order. If the order is using a foreign currency, FORCURR is used (below).
FUND	Location/Fund/Copies: repeatable, for example: eacr(33.00%),bbelr(33.00%),tterr(34.00%). There must be a comma separating the repeated funds. If multiple funds are provided there must be a percentage included also, as shown in the example.
ODATE	Order date, used for PO_SEND_DATE and PO_APPROVE_DATE
ORD TYPE	Alpha/numeric; use in PO Acq Type tab and PO Line Type tab
RACTION	Alpha/numeric; if you want to use this field to indicate Rush = Y, list those value in the Rush Order Indication question on the Questionnaire tab of the Millennium and Sierra (III) Migration Form.
RDATE	Date; this date plus the claim value from the migration form is the purchase order’s expected delivery date. If this is empty, then we use the migration date + claim value.
RLOC	Alpha/numeric; be sure to include these RLOC values on the Alma Location Tab, along with the LOCATION values. This field may be used to determine the ordering library and also the location for the order's associated inventory. See the section 'Receiving Location RLOC' for more informaiton on how this field is used.
STATUS(O)	Alpha/numeric
VENDOR	Alpha/numeric
CREATED(ORDER)	Date that the order record was generated in the ILS. This has nothing to do with the send date, just the date the actual record was created. This is not actually saved in the 'create date' in ALma - if you want to retain it, place it in a note.
UPDATED(ORDER)	Date that the order record was updated in the ILS. This is not actually saved in the 'modified date' field in Alma - if you want to keep it, put it in a note.
FOR CURR	This is the esitmated priece if the order is using a foreign currency. The first three characters must be a valid ISO currency. Format must be like: eur29.99, where eur is Euro and 29.99 is an amount in Euros. If you do not want Ex Libris to maintain a foreign currency, then put this field into a note.
SUB FROM	Date (SUB TO is not valid for open orders in Alma – open orders have no end date)
REQUESTOR	Place a local field here ONLY if the value in the field is an identifier that can be linked to the patron record. Otherwise, put the REQUESTOR field in a note.
ERP NUMBER	alphanumeric
POL_INV_STATUS	If not providing invoices, leave this blank. If providing invoices, NO_INVOICE or INVOICE. See 'PO Invoice Status' section below for more information.
FORM	Use the PO Reporting Code map to map values to the Alma Reporting Code field. The values in columns C and D are used to make the 1st Reporting Codes code table. No prefix is necessary here since the PO Reporting Code map allows only one incoming value. Note: this needs to be manually filled in until the Migration File Validation Tool is updated.
FORM2	Use the PO Reporting Code 2 map to map values to the Alma Reporting Code 2 field. The values in columns C and D are used to make the 2nd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code 2 map allows only one incoming value. Note: this needs to be manually filled in until the Migration File Validation Tool is updated.
FORM3	Use the PO Reporting Code 3 map to map values to the Alma Reporting Code 3 field. The values in columns C and D are used to make the 3rd Reporting Codes code table. No prefix is necessary here since the PO Reporting Code 3 map allows only one incoming value. Note: this needs to be manually filled in until the Migration File Validation Tool is updated.
POL_VEND_REF_NUM	The contents of this field are placed in the PO Line Vendor Reference number. This line cannot be duplicated; place only one local field name here.
POL_ADDL_NUM	The contents of this field are placed in the PO Line Additional Number field. This line cannot be duplicated; place only one local field name here.
POL_RECEIVING_NOTE	The contents of this field are placed in the PO Line Receiving Note field. This line cannot be duplicated; place only one local field name here.
POL_NOTE_TO_VENDOR	The contents of this field are placed in the PO Line Note to Vendor field. This line cannot be duplicated. Place only one local field name here.
PO_NOTE	Multiple fields can be placed in the PO_NOTE. THis is the note on the PO Header.
POL_NOTE	Multiple fields can be placed in the POL_NOTE. This is the note on the PO Line level.

Order Payments

In addition, extract a separate file of order payment records. The record contains the payment history of orders, which are put into the order note.

Field Name	Notes
RECORD #(ORDER)	matches the order number in the regular order file
Notes	Include all notes in the same line per single order. For example, if order o12345 has three groups of notes, they all need to be in a single record/line in the file, with the different note elements separated by a semicolon.

PO Invoice Status

Most customers do not migrate invoices from Millennium. When there are no incoming invoices, the migration programs must still determine the invoice status of the purchase order.

For the Millennium migration with no invoices, the invoice status is determined by checking if any Order Payment lines are present for the Millennium order and the PO Line Type of the migrated order.

If there are no order payment lines, then the invoice status is NO_INVOICE.

If there are order payment lines and the order is OT (one-time), then the invoice status is FULLY_INVOICED.

If there are order payment lines and the order is SO or CO (continuous), the invoice status is PARTIALLY_INVOICED.

For customers who manually create invoices (see the invoice section below for more information), customers must provide the field POL_INV_STATUS in the purchase order file to indicate the invoice status of the purchase order: NO_INVOICE or INVOICE. The migration program will determine if the order is PARTIALLY_INVOICED or FULLY_INVOICED based on the order type (OT, CO, or SO).

Receiving Location RLOC

The Millennium/Sierra Receiving Location (RLOC) may be used in multiple places in the migration process, along with the LOCATION field.

1. When determining the order library for the purchase order, we use the following:

a) Central Order Library if set

b) If Default Order Library is set, then we do:

- use RLOC if map found

- use LOCATION (from PO) if map found

- else use value from Default Order Library

2. When determining the intended inventory location for the order

- use LOCATION (from PO) if map found

- use RLOC (from PO) if map found

else use default location ALAME_VAL_NOT_FOUND

Linked Inventory/Receiving Location for Monographic Orders

Monographic orders in Alma are linked to item records. Orders from III Millennium do not link to the item record, even though there may be an item on the linked bibliographic record. When an order does not have a linked item record, there is no real place in Alma to put the expected inventory location that migrates from III Millennium. To indicate the expected inventory location in lieu of a linked inventory item, the migration programs place the inventory location codes into the PO line receiving note, which appears at the top of the summary screen on the Alma PO line.

After go-live, the receiving operator should do one of the following:

1. In the case that there is no item on the linked bibliographic record, and the expected item arrives, generate an item using the information from the receiving note prior to receiving the order.

2. In the case that there is an existing (migrated) item on the linked bibliographic record: these items do not appear on the Receving workbench. These items will have to be manually received by updating the item receiving date and then link the item to a POL.

Linked inventory for Continuous Orders

Continuous orders (standing orders and subscriptions) are linked to holdings records. Generally there are holdings records for most continuous orders, so an order can be linked to an existing holdings record.

Alma allows only one order to be linked to a holdings record, while III Millennium can allow multiple orders linked to the same holdings record. The first order found links to the holdings record, and subsequent orders are simply linked to the bibliographic record with no linked inventory (holdings).

When an order does not have a linked holdings record, the receiving operator should either link the order to an existing holdings record or generate a holdings/item record prior to receiving the order in Alma.

Encumbrances

Transactions from active purchase orders are created as encumbrances in Alma when the orders fund reference is valid and exists. An active purchase order is defined as one in which the mapped PO entry point is NEW, SENT, or WAITING_FOR_INVOICE and is in the current fiscal year.

Encumbrances are not generated for orders in previous (inactive) fiscal years. The fund code is preserved in the PO Note for reference.

Transactions of Amount 0.00

Millennium allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, encumbrances or open orders of amount 0.00 are changed to 1.00. The following types of orders (Acq method) can be open with amount 0 on the order, but with with no transaction/link to fund: GIFT, DEPOSITORY, EXCHANGE, TECHNICAL, and orders with the 'no charge' flag set to Y.

Purchase Order status of 'In Review'

The migration programs fill out the following elements based on incoming data:

PO Line type
PO Entry Point
PO Invoice Status
Send date
Expected receiving interval/date

Alma can have a further status of 'In Review'. Migration does not set the 'In Review' status, but rather the 'In Review' status is set by a series of rules using the elements above and possibly other elements. The initial set of rules used to determine these further statuses is not controlled by the customer; it is controlled by Alma Development. Customers are often frustrated by the statuses set for NEW orders:

when NEW and OT (one time), the status is set to 'In Review'
when NEW and CO or SO (continuous), the status is set to 'Waiting for Renewal'

You can find out more about the PO Review Rules, and how to turn rules on or off, by consulting the page Configuring Purchasing Review Rules.

Invoices

Millennium/Sierra does not provide a standard Invoice extract. Some customers who have direct access to their Sierra database and a programming team have provided invoices for migration to Alma. See the recommendations from a previous customer here: https://developers.exlibrisgroup.com...nnium-to-alma/

The following fields are expected:

Invoice header

Field Name	Notes
Voucher	The link between the invoice header and invoice lines file; also, the Payment identifier for "Waiting for Payment"and "Closed" invoices
FY	Fiscal year
VCode	Vendor code
AltCode	Placed in Invoice Reference Number
InvNum	Invoice number; also used in the link between header and lines
InvDate	Invoice date
DatePaid	Payment date for 'Waiting for Payment" and "Closed" invoices
Taxes	Overhead Amount. If Pro Rata = Y, then 'Overhead Amount' is shown on the invoice header in Alma. If Pro Rata = N, then the Overhead amount is shown as an invoice line.
Shipping	Ship Amount. If Pro Rata = Y, then 'Shipment Amount' is shown on the invoice header. If Pro Rata = N, then the Shipping amount is shown as an invoice line.
ServiceCharge	Insurance Amount. If Pro Rata = Y, then 'Insurance Amount' is shown on the invoice header. If Pro Rata = N, then the Insurance amount is shown as an invoice line.
InvoiceTotal	Total amount of the invoice
Currency	Must be delivered in three-character ISO format, e.g. USD, EUR, etc
ProRata	Y/N
paymentStatus	PAID or NOT_PAID
INV_ENTRY_POINT	if provided, must be one of the following: NEW, WAITING_APPROVAL, WAITING_SEND, WAITING_PAYMENT, CLOSED. if not provided, will default to CLOSED.
INV_NOTE

Invoice Lines

Field Name	Notes
Voucher	Use this as the link to the Invoice Header file
InvNum	also used in the link between header and line
FY	Fiscal Year
POL	links to the purchase order, using the 'o' number (e.g. o99999999). This order number should include the checkdigit so that it matches the order number in the POL.
LibFund	A fund code provided in the fund file
LineTotal	The amount of the invoice line
Taxes	Taxes, Shipping,and Service Charge are placed in the VAT field for invoice lines.
Shipping	Taxes, Shipping,and Service Charge are placed in the VAT field for invoice lines.
ServiceCharge	Taxes, Shipping,and Service Charge are placed in the VAT field for invoice lines.
Total	The sum of the LineTotal plus Taxes, Shipping, and Service Charge
INVL_NOTE
Additional Information	Notes, used in invoice lines which are linked to ContinuousPO lines. This is required if Subscription From and Subscription To date fields are empty.

Migration Form - Acquisition information

Questionnaire Tab

ACQ mode

Code: ACQ_MODE

Options: Select Yes or No depending on whether or not you have contracted with Ex Libris to migrate any Acquisitions data.

Central Order Library or Default Order Library

Code: CENTRAL_ORDER_LIB

Default: None

Default Order Library

Code: DEFAULT_ORDER_LIB

Default: First library found on the Alma Library list

Options for Central and Default Order Library: The RLOC field specifies the order location for orders in Millennium. The migration attempts to map the RLOC field to the corresponding Alma Library. If you wish to override this RLOCfield and instead assign an order library to all orders migrated, then fill in a value for the Central Order Library question. Otherwise, if you want to use the RLOC field to determine the order library, leave the Central Order Library blank and fill in a value in the Default Order Library question. In this case, the migration attempts to determine a library based on the RLOC field and only when a library is not specified or a mapping is not found does it use the Default Order Library as a second choice.

If you choose to use DEFAULT_ORDER_LIB, and therefore attempt to map the RLOC field to an Alma location, this requires that your RLOC values be included in the Alma Location Tab map in the Migration Form. RLOC values are often not the same values as inventory LOCATION fields.

What is your currency?

Code: ACQ_CURRENCY

Default: USD

Options: List the currency used for all of your funds. Orders can have other currencies and be translated to the default currency, but funds must have a single base currency.

The currency should be a three-letter code, as listed in http://en.wikipedia.org/wiki/ISO_4217

Fiscal Period Cycle Pattern

Code: FISCAL_PERIOD

Default: 01-07-1 (fiscal period starts on July 1 (01-07) and lasts for one year (-1).

Options: To have functioning ledgers, fiscal periods are required. Specify your fiscal period as DD-MM-C (Day-Month-Cycle). For example, a one year fiscal period starting on January 1 is indicated by: 01-01-1. A one year fiscal period starting on July 1 is indicated by: 01-07-1.

Alma currently supports one-year fiscal period cycles.

Which year do you use to name the fiscal year?

Code: FISCAL_PERIOD_NAME

Default: second

Options: Specify if the fiscal period is named with the first year or the second year.

second – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2015.
first – if fiscal period runs July 1 2014 through June 30 2015, then the fiscal year is named 2014.

If your fiscal period runs from January 1 through December 31, this question is not necessary.

Current Fiscal Year

Code: CURRENT_FISCAL_PERIOD

Default: determine by date of conversion

Options: This question is important around the fiscal period close, depending on whether or not you have run fiscal period close in your legacy ILS or if you will run it in Alma after migration. If you do not know how to answer this, select determine by date of conversion. The options are:

Determine by date of conversion – The conversion program uses the fiscal period that includes the date of conversion.
2013-2014 – Select this option if the date of conversion is later than the fiscal period to which you want your orders to migrate. For example, if the migration date is July 3, 2014, and the previous fiscal period ended on June 30, 2014, select this to put all of your orders in the fiscal period that ended on June 30, 2014. Select this option if you want to run fiscal period close in Alma instead of in your old system.
2014-2015 – If the date of conversion is earlier than the start date of the desired fiscal period, select this option. For example, if the migration date is June 15, 2014, and the next fiscal period begins on July 1, 2014, select this option to put all of your orders in the next fiscal period. Select this option if you want to perform the fiscal period rollover in your legacy ILS prior to conversion.

Accrual Accounting

Code: ACCRUAL_ACC_FY

Default: No – do not make an additional fiscal year

Options: If your library uses accrual accounting, you can instruct Ex Libris to make an additional fiscal year. When an additional fiscal year is created, it will be after the current fiscal year. For example, if the current active fiscal year is 2016, then the additional year, also active, will be 2017. The options are the following:

No – do not make an additional fiscal year.
Yes-No Funds – make an additional fiscal year but leave it empty. The library will then need to create funds for this fiscal year after go-live.
Yes-duplicate funds – make an additional fiscal year and also fill it with funds that are the same codes as the funds in the current fiscal year. No allocations are made.

Default claiming period

Code: ORDER_CLAIM

Default: 90

Options: Default claim used for vendors and orders (if applicable), in days.

Renewal Date for Serials Subscriptions

Code: RENEWAL_DATE

Default: none, see explanation below

Options: Renewal date for subscriptions. All active continuous orders have the renewal date specified here. If this field is left empty, the date is calculated in the following order, until a date is found:

the order send_date + one year
the order approve_date + one year
the order create_date + one year

Rush Order Indication

Code: RACTION_VALUES

Default: a, e, r

Options: Enter the values of the RACTION field which indicate a rush order. Typically, the values are a, e, or r, but this may change from customer to customer. List values separated by commas.

Fund Prefix

Code: FUND_PREFIX

Default: none/blank

Options: If you are combining data from two or more separate databases into a single combined institution in Alma, indicate a prefix here that will be used to distinguish the former fund codes in Alma after migration. A hyphen is NOT provided. For example, if your fund code is SCIENCE-MONO, and you put UWS- here, the final fund code is UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.

See also the similar BIB_KEY_PREFIX and MERGE_PATRON_PREFIX

PO Reporting Code Tabs

Use these tabs if you wish to map values from the III FORM, FORM2, and FORM3 fields to the Alma Reporting Code 1, Alma Reporting Code 2, and Alma Reporting Code 3 fields. These tabs are not required.

When an encumbrance transaction is created in Alma, the acquisitions staff can classify the transaction with a reporting code. Later, reports can be used to retrieve transactions with the same reporting code. Reporting codes are often (but not always) used to classify a purchase as serial, monograph, or electronic, for state or nation-wide reporting purposes.

III FORM: The value of the Millennium order format, found in the FORM field in the order extract.

Form Description: A description of the FORM field, for information only. This field is not used in the mapping.

Alma Reporting Code: The desired code value for the reporting code in Alma. You may choose to collapse FORM values if desired.

Alma Reporting Code Description: The name for the reporting codes in Alma. This field is used to create a code table that is loaded into Alma. This value can be easily changed after migration.

Further Information: Alma has three Reporting Code code tables: 1st Reporting Code, 2nd Reporting Code, and 3rd Reporting Code. The three mapping tabs correspond to the respective code tables.

FORM -> PO Reporting Code Tab -> 1st Reporting Code code table

FORM2 -> PO Reporting Code Tab 2 -> 2nd Reporting Code code table

FORM3 -> PO Reporting Code Tab 3 -> 3rd Reporting Code code table

Since each incoming field from Millennium/Sierra maps to a single mapping tab and code table, a prefix is no longer necessary to distinguish between different incoming values.

PO Claim Tab

Use this tab to set different claiming periods for orders migrated to Alma. Millennium determines the claim period by different receiving categories. In Alma the claim intervals are simple numbers stored on the order. Additionally, Millennium can have different expected receiving intervals based on whether or not the order is marked as Rush.

This tab is mandatory if migrating orders. However, if you do not wish to map claiming information from Millennium, fill in the default values in the ALMAME_VAL_NOT_FOUND line only. The mapped value is also used as the subscription interval for continuous (CO/SO) orders.

III CLAIM: The value of the Millennium receiving category, found in the CLAIM field in the order extract.

Rush: The desired claim period, in days, for rush orders.

Regular: The desired claim period, in days, for regular orders.

PO Entry Point Tab

The entry point value is used to determine where PO falls in the workflow in Alma. The PO entry point is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any STATUS (O) values that may not have been found in the map.

Additionally, since all possible values for the STATUS (O) field in Millennium cannot be accommodated, every original STATUS (O) value is placed in the note field for each individual migrated order for reference after migration.

STATUS (O): The possible values for the order status in Millennium, found in the STATUS (O) field in your order extract. Description: The description of the STATUS (O) field, for information only. This field is not used in the mapping to Alma.

poEntryPoint: The desired order status in Alma. Select from one of the values in the drop-down box. The following options are available:

NEW – The order has been created but not sent to the vendor yet. Orders can have status NEW for years while librarians are reviewing what to order, or they can be NEW for just a short while if the acquisitions staff created the order to send to the vendor immediately.
SENT – The order has been sent to the vendor and funds have been encumbered/committed. The item has not been received yet for one-item orders, or the item has been received for continuous orders. Continuous orders that continue to be invoiced/received remain with SENT status (which can be considered as a sub-status of waiting for renewal within Alma) until they are closed. A SENT continuous order is set to waiting for renewal if the subscription to date is earlier than the renewal date.
WAITING_FOR_INVOICE – Use only for one-time orders. The item has been received, but not the invoice. Invoice status must not be FULLY_INVOICED.
CLOSED – The order has been received and invoiced. Nothing else will be received on this order. (Do not use for open continuous orders that you are still receiving.)
CANCELLED – Cancelled order.

PO Line Type Tab

Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times, and may remain open indefinitely.

This tab is mandatory if you are migrating orders. Include a line for ALMAME_VAL_NOT_FOUND since this field is mandatory in Alma.

ORD_TYPE: Value of the order type field in Millennium, found in the ORD_TYPE field in your order extract.

Order Type Description: A description of the ORD_TYPE field, for information only. This field is not used in the mapping to Alma.

poLineType: The Alma line type value. Select one of the following line types from the drop-down list:

PRINT_OT – printed book one time. This is used for one time or infrequent orders of specific items, for example, a printed book, E book, or a musical score, that is not published repetitively. The order is at the item level.
PRINTED_BOOK_OT: Print Book One Time
PRINT_CO – journal/continuation. This is used for orders that are repeated on a regular basis. An example is monthly subscriptions to physical or electronic material such as journals. The order is at the holding level, and items in the holding record are received periodically.
PRINTED_JOURNAL_CO: Print Journal - Subscription
PRINT_SO – standing order monograph. This is used for orders that are not repeated on a frequent or regular basis. For example, this type of PO line is used for purchasing all the printed books by a particular author when they are published, or where a series of books are being published, but not necessarily on a regular basis. The receipt of new material involves a new bibliographic, holdings, and item record.
PRINTED_BOOK_SO: Print Book - Standing Order
PRINT_SO_NONMON - Standing Order Non-Monograph – Similar to continuous orders.
OTHER_SERVICES_OT: - Other Services One Time – Various non-inventory orders for services purchased from a vendor. Both one-time behavior and repetitive behavior are available. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.
OTHER_SERVICES_CO: Other Services Subscription. This should only be applied to orders without inventory. For electronic resources, see Line Types and Electronic Orders.

Further Information: Use this tab to define the line type of the migrated order. The PO may move through Alma workflows differently according to what type of item is on order. For example, a monographic order is opened, sent to the vendor, received, invoiced, and closed. However, a serial order may be received and invoiced many times and may remain open indefinitely.

Alma does have other PO Line types but they are not available for use in migration.

Line Types and Electronic Orders

The above line types are all descriptions based on a print order. All orders are stored in Millennium as print, and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process.

PO Acq Method Tab

Use this tab to determine the Acquisition Method of an order in Alma. The acquisition method is an indication of how the order is acquired. Possible values for the acquisition method are PURCHASE, APPROVAL, GIFT, VENDOR_SYSTEM, DEPOSITORY, EXCHANGE, TECHNICAL, and LEGAL_DEPOSIT

For migration from Millennium, the acquisition method is determined by looking at values in the ACQ TYPE field, plus the ORD TYPE field if it is necessary to distinguish orders with the same ACQ TYPE.

The PO Acq Method is mandatory in Alma, so the ALMAME_VALUE_NOT_FOUND line is required to catch any values that may not have been found in the map. Also, since all possible values for the ACQ TYPE field in Millennium cannot be accommodated, every ACQ TYPE value is placed in the note field for each individual migrated order.

III ACQ TYPE: The value of the ACQ TYPE field in Millennium, found in your order extract.

III ACQ TYPE description: Mandatory. A description of the Acq Type in Millennium, for information purposes only. This field is not used in the mapping to Alma.

III ORD TYPE: This field is not mandatory for mapping and may be left empty if not needed. All ORD TYPES must be listed in order to be used in the map; * is not possible here.

III ORD TYPE description: A description of the ORD_TYPE field in III, used for information only. This field is not used in mapping to Alma.

poLineAcqMethod: The Acquisition method in Alma. Select one of the following values from the drop-down list:

PURCHASE – normal workflow
GIFT – not sent to vendor and no invoicing or payment
EXCHANGE – not sent to vendor and no invoicing or payment
APPROVAL – pre-established delivery plan - normal workflow except not sent to vendor
VENDOR_SYSTEM – the order is placed at the vendor site so that sending it to the vendor is not required. The normal workflow is followed except that the order is not sent to the vendor.
DEPOSITORY – usually from the government. The order is not sent to vendor and there no invoicing or payment.
TECHNICAL – no fund or amount required
LEGAL_DEPOSIT – does not require fund or price, and uses a special version of the PO Line order letter

It is the combination of ACQ TYPE and ORD TYPE that determines poLineAcqMethod. Each combination of these two fields in your order data must be listed; otherwise, default ALMAME_VAL_NOT_fOUND is invoked.

Vendor Claim Tab

The default claim cycle for vendors in Alma is set by mapping the CLAIMCYCLE field from Millennium.

This tab is mandatory if you are migrating vendors. However, if you do not want to map claiming information from Millennium, fill in the default values in the ALMAME_VAL_NOT_FOUND line only.

III CLAIMCYCLE: The value of the Millennium claim cycle, found in the CLAIMCYCLE field in the vendor extract.

Description: A description of the III Claimcycle field, for information only. This field is not used in the mapping to Alma.

Alma Claims: The amount of time in days before sending a claim. This value is used as a default for orders opened for this vendor.

Physical to Electronic (P2E) Processing

In Millennium, all resources are categorized as physical in the database, even if the record represents an electronic item. All records are converted to Alma as physical initially. A second process converts records identified as electronic to the electronic format. You provide a list of records that are identified as being electronic, as part of the data delivery, in the following format:

b123475,portfolio

b12346,DB

There is no header required for this file.

During the P2E process, all resources must either be categorized as a portfolio or a database (DB). It is not possible to generate packages during P2E processing, since packages require at least one portfolio. A database is essentially a zero-title package. Post migration, when you add portfolios to the db, you can change them to type 'package'.

The words portfolio and db are not case-sensitive; for example, both portfolio and Portfolio are acceptable.

If you provide a bibliographic record in the P2E file, the migration programs will generate an electronic resource for the bib, even if there is no valid URL. An example of an invalid URL might be an 856 tag with an indicator which does not match the specific indicator in the question P2E_LINK, below. For example, if you say that we use 85641u for the P2E_LINK, and you provide a bib record *without* a 85641u but that bib record is in the p2e file, then we will generate a local e-resource without any link at all (an empty resource). Be careful which bibs are placed in the bib file. The P2E process attempts to identify an order related to the identified inventory for conversion to electronic. Details about the selection of the order can be found in the guide: https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides_and_Tutorials/Electronic_Resource_Handling_in_Alma_Migration

Migration Form - P2E

Questionnaire Tab

For each of the following three questions (P2E_LINK, P2E_NOTE, and P2E_PROVIDER), you can use indicators in the following manner:

Specific indicators: 85641u – only tags with 41 as the indicator is used.
No indicator (# is used for a blank character, for example: 8564#u) – only tags with 4 <blank> as an indicator are used.
All possible indicators: 8564*u – tags with 4 as the first indicator are used. The second indicator is not taken into account.

The space character operates the same way as an asterisk (*), for example: 8564 u is the same as 8564*u.

Special Request: If you need to specify multiple specific indicators, for example 85641 and 85642, it cannot be coded in the migration form but your ExL representative can make a special request to the migration team.

Which Holding or Bib field stores electronic link information

Code: P2E_LINK

Options: Provide a Marc field code + subfield: 856u. Only one subfield is allowed.

Recommendation: 856 u

Default: If this is left empty, no tag is used.

Which Holding or Bib field stores electronic link public note

Code: P2E_NOTE

Options: Provide a Marc field code + subfield: 856z. Only one subfield is allowed.

Recommendation: 856 z

Default: If this is left empty, no tag is used.

Which Holding or Bib field stores electronic provider name information

Code: P2E_PROVIDER

Options: Provide a Marc field code + subfield: 856 x. Only one subfield is allowed.

Recommendation: 856 x

Default: If this is left empty, no tag is used.

Alma Location Tab

Electronic Location Column

Identify which locations indicate an electronic holding or item record. A single bibliographic record may contain holdings for multiple locations, but only the holdings/items for electronic locations need to be identified. Identify the locations in the in the Electronic Location? column in the Alma Location tab of the Millennium (III) Migration Form.

PO Line Type Tab

Line Types and Electronic Orders

The PO line types are all descriptions based on a print order. All orders are stored in Millennium as print, and so are migrated to Alma initially as print using the above line types. The physical to electronic (P2E) process identifies orders attached to electronic bibliographic records and transforms the order to electronic. In other words, if an order migrates as PRINT_SO, is attached to a bibliographic record that you identify as electronic and is in an electronic location, it is changed to the corresponding electronic standing order line type by the P2E process.

Further Information

If you have multiple 856 links in a single bibliographic record identified as electronic, a different inventory link for that bibliographic record is created for each URL found in the record. In addition, if you have two item records with electronic locations attached to the same bibliographic record, a different inventory link is created for each location, as well.

For more information on the electronic migration approach to Alma, refer to Electronic Resource Handling in Alma Migration.

Appendix A – Post-Migration Process Statuses

The process statuses (codes) from Sierra/Millennium are mapped to the indexed internal note 1 field of the Alma item. These items are considered not available after migration when process = Technical – Migration.

These fields are currently indexed in the item keyword and advanced searches.

When searching for physical items, a staff user can search by item process status code with the general keyword search and then by facet if before searching, Process type = Technical – Migration and with the advanced search filter when Process type = Technical – Migration.

In order to give items real Alma statuses or remove the Technical – Migration status, scan the barcode of the item to various configured departments (via receiving, for example), request a move to various departments/temp locations, or just scan the item for return, which removes the status from the item. You may also use the ‘Scan In’ API, described here: https://developers.exlibrisgroup.com...le-of-barcodes.

Additionally, it is also possible to configure the GetIt (Primo) services to display or not display items with this process status in the GetIt Item list.

Appendix B - Limit by Location

When the LIMIT_BY_LOCATION question on the questionnaire form is set to Yes, which can only be done after approval from Ex Libris, then the incoming data is split according to locations listed on the following tabs in the Alma Migration Form:

Alma Location tab: locations listed on this tab will control which inventory is migrated. Do not include the ALMAME_VAL_NOT_FOUND line, since there will be many locations that are 'not found'. If the location is not found on the tab, the inventory will not be migrated.
Campus Code tab: locations listed on this tab will control which patrons are migrated. Do not include the ALMAME_VAL_NOT_FOUND line.

Inventory: Bibliographic records are migrated if there is at least one: holding, item, or order with the included location attached to the bib. Standalone bibs are included. Items and holdings are included only if their locations are included on the Location tab

Fulfillment: Patrons are migrated if their campus code is listed on the Campus Code tab. Loans and hold requests migrated if they are associated with an item in a listed location and patron in a listed campus. Fines/fees can be migrated without item information so the patron is the dependent factor here.

Acquisitions: If the order location for the order is listed on the location tab, then the orders will be migrated. Funds are migrated if the LEDGER_LOCATION library is listed on the library tab of the Alma Migration form.

Related Documentation

Migration General Overview

Data Files

Expected File Formats

When a field contains a double quote

Checkdigits in certain internal identifiers

File Naming Conventions

Using the Migration Form Validation Tool

Inventory

Millennium/Sierra Inventory Files

Bibliographic Records

Suppressed Bib Records

MARC Holding Records

Call Numbers

Determining Groups for Holding Records

Changing the Holding Record Grouping

Attaching Items to Existing Holding Records

Attaching items to checkin records

Serial Prediction

Checkin Records

Checkin record exported file

Holding Records from a Summary Statement in a Bibliographic Record

Item Records

Bound Withs

Item Barcodes

Item Record Keys - checkdigit

Material Type

Secondary Item File

Questionnaire Tab

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

List Prefix for bibs from SFX or other management system

MARC Organizational Code

Do you use internal system numbers in Linked Entry fields?

Internal record designation for Linked Entry fields $w

Use call number tags inserted from bib?

If CALL # (ITEM) field is empty, fill it in with the following text

Indicate which 852 subfields to use to determine unique holding records

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

Limit exported records by location

Bib Key Prefix

Move 001/003 to 035 or 935

Add institution suffix to Bib ID

Use subfield indicators in item call number (AltCallNo)

Add $9 LOCAL to specified tags

Alma Library Tab

Alma Location Tab

ALMAME_VALUE_NOT_FOUND

Alma Location Name and Alma External Location Name

Collapsing Locations

Item Base Status Tab

Item Type Tab

Item Physical Condition Tab

Fulfillment

Patrons

User Stat Categories

User Identifiers

Loans/Circ Transactions

Requests (Holds)

Separate Fine/Fee File

Courses

Reading Lists Linked to Multiple Courses

Duplicate Course Codes

Reading List Items -> Bibs

Faculty/Department

Migration form - Fulfillment

Questionnaire Tab

Which identifier should be used as the patron's Primary Identifier?

How should we handle duplicate identifiers in the same patron?

Enter a two-letter code for the default conversational language for your users (for example en or fr)

Patron ID for loans without a patron

Currency for patron fines

Fine Fee Type for patron fines

Use a map for the HOME LIBR to campus code migration?

Use Course Reserve BRANCH to Course Unit Map?

Request Default Destination Library

Merge Patron Prefix

User Group Tab

User Block Tab

Campus Code Tab

User Stat Categories Tab