Voyager to Alma Migration Guide

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

The purpose of this document is to explain:

The information that you need to supply to Ex Libris regarding each Voyager component that is to be migrated to Alma
The rules that are applied to the information for each Voyager component when this information is migrated to Alma, which will be helpful in determining where your data went after it migrates to Alma.
Prerequisites: Basic knowledge of Alma and Voyager key concepts and architecture, and the requirements (including the migration-related approach) described in Getting Ready for Alma and Discovery Implementation as well as the Electronic Resource Handling in Alma Migration.

This document is intended to be used as a complementary piece to the Voyager Migration Form that provides further information regarding the migration process and steps required for Alma.

The Voyager migration form is initially generated by the Ex Libris migration program with specific values from your database.

Ex Libris migrates your acquisitions and course data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.
It is recommended that you view the Introduction to Alma Configuration session before completing your migration form, as the mapping and migration of libraries and locations has implications for subsequent configuration.

Recommendations for Using this Guide

This document is divided into four areas:

Inventory
Fulfillment
Acquisitions
Physical to Electronic

Each area has the following sections:

Questionnaire Tab – Instructions for individual questions asked on the Questionnaire tab of the Migration Form.
Individual Tabs – Instructions for how to fill out individual tabs on the Migration Form. (Examples: Alma Libraries Tab, Location Mapping Tab).
Further Explanation – Explanations of migration processes that need more explanation and/or do not need customer input.

We recommend that you look at the Questionnaire Tab section and the individual tabs in each area to assist in filling out the Migration Form. If you have further questions about any of the data input or about the migration in general, see the more detailed explanations in the Further Explanation sections.

Inventory

Alma requires bibliographic, holdings, and item records.

Customer Input

Questionnaire Tab

Institution Code, Customer Code, Institution Name, Customer Name, INST_ID

Codes: INST_CODE, CUST_CODE – fill in with values provided by Ex Libris.

INST_NAME, CUST_NAME – fill in these fields with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium). This is for informational purposes only and is not used in Alma.

INST_ID – fill in this field with ID value provided Ex Libris.

Default: N/A

Options: This question is mandatory.

Voyager DB name to migrate

Code: VOYAGER_DB

Default: N/A

Options: Limit to one DB name. This is usually the name of your database on your Voyager server, for example, yyydb.

This string that will be used as the suffix on all Voyager identifiers which move to Alma. Two examples the former bib system number in the 035, and the purchase order line number, e.g. 123455-voyagerdb.

Time Zone

Code: TIMEZONE

Default: N/A

Options: This question is mandatory. If your time zone is not listed in the drop-down list, contact your Ex Libris project manager.

Limit data exported by location

Unless instructed otherwise by your Ex Libris project manager, leave this as No.

Code: OWNING_LIBRARY_OR_LOCATIONS

Default: No

Options: No/Yes/owning libraries

No (default) = migrate all of the data in the listed db

Yes = migrate data only from the list of locations on the location tab, where "Use in Location Limit?" = Yes

List value(s) from LIBRARY.LIBRARY_NAME table in Voyager, for example “OWN:lib1 OWN: lib2”, where lib1 and lib2 are valid LIBRARY_NAME values.

Further Information: If your institution shares a Voyager database with another institution, you may have contracted to have Ex Libris extract only part of the Voyager database. Most customers do not have this situation and should leave the response as No. See Appendix B: Limiting By Location for more information on how this question is implemented.

The limit by location list must have fewer than 1000 locations.

Include NZ Match Key

When limiting by location, include an NZ match key in 035$a?

Code: INCLUDE_NZ_IDENTIFIER

Default: empty

Options: Include this identifier if the Voyager database was shared by multiple institutions and will also be sharing a network zone (NZ) in Alma. The identifier here will be used as the identifier to match bib records when linking from the IZ to the NZ. The identifier is structured: <bibkey>-<dbcode>, or 12345678-yourdb.

Limit data exported by patron: Unless instructed otherwise by your Ex Libris project manager, leave this as blank.

Code: PATRON_LIMIT

Default: blank

Options: Blank, a list of circulation cluster codes, or a list of patron groups

Blank (default) = do not attempt to limit the database extract by patrons

Circ Cluster: List the circulation cluster code from the circulation_cluster configuration in Voyager prefixed by 'CC:', for example “CC:circ1,circ2”, where circ1 and circ2 are valid circulation cluster codes. Patrons in this/these circulation clusters will be included in the export.

Patron group: list the patron group codes in Voyager prefixed by 'PG:', for example "PG:fac,staff,undg,other" where fac, staff, undg, and other are valid patron group codes. Patrons with these codes will be included in the export.

Further Information: If your institution shares a Voyager database with another institution, you may have contracted to have Ex Libris extract only part of the Voyager database. Most customers do not have this situation and should leave this field blank See Appendix B: Limiting By Location for more information on how this question is implemented.

Limit courses by department: Unless instructed otherwise by your Ex Libris project manager, leave this as blank.

Code: COURSE_LIMIT

Default: blank

Options: list of department codes for inclusion in export; if empty, all courses are migrated.

List the prefix for SFX or other link resolver system record numbers

Code: SFX_PREFIX

Default: (SFX)

Options: List the string that indicates bibliographic records from an electronic link resolver system. If not indicating a link resolver, leave blank. Multiple strings allowed: separate by a semicolon, for example: (SFX);ssj;ebrary

Further Information: In order to allow online journal subscriptions to be discoverable in the Voyager OPAC, some Voyager customers imported bibliographic records from SFX or another electronic link resolver system into Voyager, with the link resolver system’s unique number denoted in the 035 field. When the link resolver system is SFX, the unique number is prefixed by "(SFX)". Other link resolver systems may have a different prefix.

If the migration also harvests online subscription information from the link resolver system, this may result in duplicate bibliographic records in Alma. That is, you may have bibliographic records in Alma that came directly from your electronic link resolver system like SFX, and also the same bibliographic records in Alma that came by way of Voyager.

The migration programs check for the string listed in the 035 $a field of the bibliographic record. If the bibliographic record has the exact string listed, then:

If the bibliographic record has no orders attached or it has only items in an electronic location, then the bibliographic record is not migrated.
If a purchase order is associated with the bibliographic record, the bibliographic record is still migrated, but is automatically suppressed to avoid end-user discovery duplication.
If a non-electronic (physical) item is attached to the bibliographic record, the bibliographic record is migrated as suppressed. Non-electronic items means items that have a location that is specified as No in the “Electronic Location?” column in the Locations tab of the Alma Migration Form.

Migrate E-Items?

Code: MIGRATE_EITEMS

Default: No

Options: No/Yes. This question is mandatory

Further Information: Decide if you want to migrate e-items, which are used for course reserves.

In general, e-items in Voyager are migrated as physical items in Alma with a material type of LINK. The e-link (http address) that is currently stored in the e-item is moved to the holdings record as an 856 link. The 856 link is structured as follows:

856 40 ‡u <e-item link> ‡x converted Voyager e-item ‡y <e-item caption>

Migrate Serial Issues?

Code: MIGRATE_SUPP_SERIAL_ISS

Default: Only Unsuppressed

Options: Three options:

All - migrate all serial issues, both suppressed and unsuppressed

Only Unsuppressed - only migrate the unsuppressed serial issues, those that are viewable to the public

None - do not migrate any serial issues at all. Issues that are linked to proper item records are still migrated.

Further Information: Decide if serial issues that are flagged as suppressed from OPAC view should be migrated to Alma. In the Voyager client, this in specified on the Receipt History tab, with a button called Display in OPAC. When Display in OPAC = No, then this issue is suppressed from view in the OPAC in Voyager.

For the All option, serial issues marked as OPAC suppressed in Voyager are migrated to Alma with a note indicating that they were suppressed in Voyager.

If you answer None or Only Unsuppressed, the relevant issues are not moved to Alma. Be aware, however, that the issues may have a receipt history that is also not moved to Alma.

Note that serial issues in Voyager can be suppressed at the serial issue record level. This question does not check any suppression flags at the bibliographic record or holdings record levels.

Generate a Barcode for Serial issues?

Code: SERIAL_ISSUE_BARCODE

Default: Yes

Options: Yes/No.

Further Information: The migration programs can generate an item barcode for Voyager issues, based on the serial issue and component identifiers. However this barcode is not mandatory and the items created from serial issues can remain without a barcode if desired. A barcode is required when an item is loaned, but may serial issues are never loaned so a barcode is not necessary. Default: generate a barcode for serial issues (Yes).

Include Serial Issues in P2E?

Code: SERIAL_ISSUE_P2E

Default: No

Options: Yes or No

Yes = include serial issues in p2e calculation, generate an e-resource for each serial issue
No = do not include serial issues in p2e calculation, generate an e-resource at the holding level

Further Information: If you have serial checkin records for electronic resources, and you want to generate only a single e-resource for the group of serial issues, then answer No to this question. Answering No will generate a p2e e-resource at the holding level. If you have many serial checkin records for electronic resources and you answer Yes to this question, you will get a p2e e-resource for each serial issue.

MARC Organizational Code

Code: MARC_OC

Default: blank

Options: This question is not mandatory and can be left blank.

Further Information: Fill in your MARC organization code for inclusion in the former system number as it is migrated to Alma. http://www.loc.gov/marc/organizations/. Institutions that have more than a single MARC Organization code should choose one for use in conversion. Typically, there is one that represents the institution as a whole. Any institution that does not have a MARC organization code can apply for one. Ex Libris strongly recommends that all customers use their MARC Organization Code when migrating to Alma, as it helps identify the owner of the record. If you do not have a code or do not want to use one, fill in the word Voyager.

The migration moves the value in the exported record’s 001 (The voyager record ID) to the 035:

035 __ $a (MOC)<Voyager record id>-<Voyager database code>-Voyager

Where:

<MOC> is the MARC Organization code.
<Voyager record ID> is the system number of the Voyager bibliographic record, stored in the 001 on export from the database.
<Voyager database code> is the database code in the form yyydb.

Include "-Voyager" in 035

Code: INCLUDE_035_SUFFIX

Default: No

Options: No/Yes. Optional. Fill in No if you answered Voyager to the previous question.

Further Information: Optionally, decide if you want to include -Voyager as the source system in the 035 field.

If you fill in Yes, the final number looks the following:

(AbC)000123456-yyydb-Voyager

If the default No is left, the final number looks like the following:

(AbC)000123456-yyydb

Note that this number is placed in a new 035 field in all bibliographic records.

Bib tag (9xx) for owning library information

Code: TAG_FOR_OWNING_LIB

Default: blank

Options: optional

Further Information: Provide the 9xx tag in which you would like the ownership information stored in the bibliographic record when it is migrated to Alma.

Catalogers are able to assign an owning library to a bibliographic record in the Voyager cataloging client. Assignment of an owning library to a bibliographic record limits who can edit that bibliographic record. In Alma, this information is stored in a 9xx tag in the bibliographic record. However, if there is only one owning library for a database, no owning library is assigned to any bibliographic record, since the Alma institutional ownership is implicit.

The 9XX field is not used in any functional way in Alma. Post-migration, you may want to include bibliographic records in a set by searching on the 9XX tag specified + the value of the owning library. Once the set is generated, the records may be modified or marked using Alma tools.

Move 852$c to another subfield

Code: MOVE_852C_SUBF

Default: k

Options: optional

Further Information: If you have data in your Voyager holdings record 852 $c, it must be moved to a different subfield to accommodate the two levels of location in Alma – Alma Library and Location are in 852 $b and $c. Decide to which subfield you want the $c information moved. If nothing is specified or the response is incorrect (such as Yes or No instead of specific subfield), the default subfield is $k. Subfield $c is only moved for the relevant 852 tag. This means that if there are multiple 852 tags in the same holding record, the $c is only moved for the first 852 tag to make room for the sublocation in $c in Alma.

For further information, see the Further Information section of Alma Location tab below.

Do you use internal system numbers in $w of Linked Entry fields?

Code: LINKED_ENTRY_W

Default: No

Options: Yes/No. Optional

Further Information: Indicate if you use the local system number in $w of the 76x-78x, 800, 810, 811, or 830 linking fields.

When bibliographic records are related to each other, such as a journal title that is superseded by a second journal title, Voyager stores the information in bibliographic tags and relies on tag indexing to create a link between the records. Some Voyager customers use the Voyager system number in $w to make a direct link between the two records, while others rely on more general identifiers specified in other subfields such as ISBN ($z) or ISSN ($x).

The linking tags, 760 – 787, 800, 810, 811, and 830, are migrated from Voyager to Alma as they currently exist, but if you answer Yes to this question, $w are converted from the Voyager system number to the Alma system number.

In Alma, the system numbers in $w (along with $z and $x) are used to link two related bibliographic records together using the related records process.

Internal record designation for Linked Entry fields $w

Code: LINKED_ENTRY_PREFIX

Default: blank

Options: optional

Further Information: If you answered Yes to the previous question and the internal system numbers have a prefix, enter the value to which we will match to identify the local system number. If the internal system numbers do not have a prefix (or you answered No to the previous question), leave this question blank.

Prefix for 019 Cancelled OCLC Number

Code: PREFIX_019

Default: blank

Options: optional

Further Information: Provide a string to put as a prefix to the number in 019 when it is copied to 035 $z. Nothing will be added to the prefix you provide, so if you want the new number to be (OCoLC)12345, then put (OCoLC) here. The migration programs use the parentheses in the match, so be sure to include them. The contents of the field are copied, not moved, so the original 019 field stays in place. All of the 019 values, if there are multiples, are copied to a single separate 035 tag with separate $z subfields. If there is only one 019 value, that is placed in a separate 035 tag with a single $z subfield. The field is copied regardless of the value that is placed here.

Item.Price field as Replacement Cost

Code: REPLACEMENT_COST

Default: No

Options: Yes/No

Further Information: If the price in the item record is an actual replacement cost that will be used to assess a fine for a lost item, then answer Yes here. The cost will be used in the calculation of fines if the item is lost by a patron. Otherwise, if the item price should not be used in the fine replacement cost and is only kept for historical acquisition purposes, leave this as No.

LOCAL tags for Consortia

Code: IZ_LOCAL_BIB_TAGS

Default: blank

Options: bib tags + indicators (5 characters) separated by semicolons (e.g. 69###; 590b#; 595##)

Further information: If you are part of a consortium, you may specify bib tags to be marked as local in your Alma Institution Zone (IZ). You may specify tags plus indicators. Use '#' to specify any value, and 'b' to specify a space. Separate multiple tags by semicolon.

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 Inventory Number

Code: INV_NO

Default: blank

Options: FREETEXT, CAPTION, SPINE_LABEL, or ITEM_ID

Further Information: There is not a specific field in Voyager which holds an inventory number, so customers who use an inventory number have put them in various fields. If you want to move a number from Voyager to the Alma Inventory Number field, you can specify one of the fields listed here. If the field you used to store an inventory number is not listed, contact your Ex Libris representative to make a request to add the field to the list of available options.

Move 001/003 to 035 or 935

Code: MOVE_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.

Alma Library Tab

During the migration process, you need to provide your preferences for migrating the single-level Voyager location information into the two-level Alma structure of library and physical location. The first step is to determine your list of libraries in Alma.

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. Mandatory.

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

Alma Library name: Maximum 255 characters. Visible to the public. Mandatory. 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 lines: Alma allows you to specify address, phone, and e-mail information about each library. Each library in Alma has the possibility for multiple contact addresses, phone numbers, and email addresses. It is mandatory for a library to have a shipping/billing address in order to place orders in Alma. The migration process sets the designated address provided with all possible types in Alma. At least one address line for a single library is mandatory. Other libraries should have an address, but it is not required, and customers will receive a warning if there is no address for the other libraries.

Email: The migration process sets the email address provided with all possible email address types in Alma. An email address is required to submit orders in Alma, and is highly recommended. Not mandatory.

Phone: The phone number must contain dashes (nnn-nnn-nnnn). A phone number with no dashes is not accepted by the migration program. Not mandatory.

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. Not mandatory.

Further Explanation: Voyager has one level of location, and Alma has two levels: library and physical/shelving location. Locations in Voyager are generally analogous to the physical/shelving locations in Alma. Libraries are higher level units that 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 and a location.

In Voyager, there is only one level of location – the Voyager location. It may be a storage location, a happening location, or a print location. In addition, Voyager has policy groups that combine locations that share the same policies. An Alma library can be viewed as a combination of the Voyager policy and the Voyager happening location, but it is also a locational entity (where the item is located). Ex Libris recommends that your list of libraries closely mimic your policy groupings together with your happening locations – which often represent a grouping of locations from an organizational perspective.

If you use an error library (for example EMPTY) in the ALMAME_VALUE_NOT_FOUND line of the Location Mapping tab, list that library in the Library Tab.

Alma Location Tab

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

The Ex Libris migration program prepopulates this tab with your existing Voyager Location Codes. The sheet will contain all of your Voyager locations, including the happening locations.

You need to fill in the Alma Library code for each location and modify the Alma Location Code, Location Name, and External Location Names.

Voyager Location Code: This column is filled in with codes from your Voyager database to make filling out this form easier. Voyager location codes are case-sensitive. As a result, 'Code' and 'code' are two different entries.

Alma Library Code: Mandatory. Fill in the library that contains this location in Alma. This code must be present on the Alma Library tab, column A. The match is case-sensitive.

Alma Location Code: Mandatory. Fill in 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 use in Voyager, but this is not required. You may also use this form to collapse locations if desired, for example, refa and refb in Voyager both map to ref in Alma. Mixed case is valid, but not recommended, to emphasize the fact that Alma is case-insensitive with codes. In Voyager, 'Code' is different from 'code', but in Alma, they are considered the same.

Do not use special characters or spaces. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character.

Provide a location code for all locations listed, even the happening locations.

Alma Location Name: Mandatory. 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 in 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 several different locations. 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, along with a file of bibliographic identifiers, 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 individually marked as suppressed, but no holdings or items with this location code are exported to Primo.

Use in Location Limit? (Yes or No): Indicate if the location should be used as a limiting factor when Questionnaire question OWNING_LIBRARY_OR_LOCATIONS is set to Yes. When that question = Yes, then locations on the location tab are used to limit which bibs, holdings, items, orders, and invoices are migrated. If you are exporting your entire database, meaning OWNING_LIBRARY_OR_LOCATIONS = No, then you do not need to answer this question.

Because customers who need to limit locations work as part of a larger location group, it is possible that an item in the included limit has a temporary location which is not part of the list of locations used for limiting. For example, the item is permanently housed in library MAIN, but it is stored temporarily in the storage area (STORAGE). You want to include the item, so indicate that MAIN = Yes in this column. You don't want all of the STORAGE items, so you don't want STORAGE to be set to Yes. However, if you don't include STORAGE in the list at all, that temporary location of STORAGE will be caught by the ALMAME_VAL_NOT_FOUND line, which usually indicates an error. In order to display the STORAGE temporary location correctly, include the STORAGE location in this table, but set it to No.

ALMAME_VALUE_NOT_FOUND (mandatory): The ALMAME_VALUE_NOT_FOUND line must be included at the top of the list of locations, if any location codes were not included when completing this map. For example, you do not include a location on the location map because think that there are no items in a certain collection, but actually, there are 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.

Voyager Location Code	Alma Library	Alma Location Code	Alma Location Name	Alma Loc External Name	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.

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

Collapsing location codes: This mapping table can be used to collapse location codes – that is, two or more location codes in Voyager 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 Voyager code to an easily identifiable code such as XXX ife any stray items are still in your Voyager database.

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

Voyager 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.

Further Explanation – Inventory

Alma Structure

The following diagram illustrates the Alma structure for inventory:

The Voyager structure is very similar to the Alma structure. Voyager requires a holdings record for all item records, issue records, and e-item records. For each bibliographic record, the related holdings record is retrieved, and for each holdings record, the related item, issue, and e-item records are retrieved and made into a physical item records in Alma.

The following diagram illustrates the Voyager structure:

It is not possible to have a holdings record without a bibliographic record. That is, a bibliographic record is required in order to have a holdings record. Also, it is not possible to have an item, issue, or e-item without a holdings record. As a result, a holdings record is required for items, issues, and e-items.

In all cases, Voyager migrates what is available. There may be a single bibliographic record with nothing below it, or a bibliographic record and a holdings record with no items, issues, or e-items. In these cases, no attempt is made to create holdings, items, issues, or e-items where there are none.

Alma allows only one 852 field in the MARC holding record. Voyager should also, but we have seen some cases where there are multiple 852s in a holding record in Voyager. If your library has MARC holdings with multiple 852s, these should be corrected prior to migration to Alma.

The Alma to Voyager migration programs migrate the holding and item structure in Voyager as is, meaning that if there are multiple holdings records with the same location on the same bibliographic record, these are migrated to Alma as multiple holdings records with the same location on the same bibliographic record. We do not attempt to collapse/group holding or item records by location. If you have multiple holding records with the same location/call number on the same bib, these holding records will need to be corrected post-go-live in Alma. See the Validation Exception Profile List in Configuring Cataloging.

Suppress in OPAC

Both the bibliographic and the holdings records can be set to be suppressed in the OPAC in Voyager. When the Suppress in OPAC flag is set in either Voyager bibliographic or holdings records, the record is transferred to Alma as suppressed. Records can be batch suppressed or unsuppressed in Alma after migration.

When holdings records are suppressed in Voyager, they transfer as suppressed records to Alma (as explained above). Suppressed holdings records are not considered in the P2E process – that is, if a Voyager holdings record is suppressed, it is not converted to a portfolio in the Alma P2E process.

Export OK

The bibliographic records in Voyager can be set with an Export OK flag. When the Export OK flag is set in Voyager bibliographic records, the record is transferred to Alma as tagged for export. These records can be sent to OCLC to be enriched with the local institutions' holdings information. Records can also be batch flagged or unflagged for export in Alma after migration.

Note, in addition to Export OK:

Australian customers have ALL Bibliographic records marked for Libraries of Australia Publish, if relevant.
OCLC records (records with an 035 |a with an OCLC-official prefix) are marked for OCLC publish, if relevant.

Unreadable Content/Foreign Characters in Bib Record

Sometimes the migration team will report that some bibliographic records (and subsequently all of their sub-records like items, orders, etc) did not migrate because of unreadable content or foreign characters in the bib record.

The bibliographic records are stored in MARC format, and in order for the migration programs to read them correctly, the stated length of the record (in leader positions 0-4) must match the actual record length. If this is off for any reason, the migration programs cannot read the record.

A reason these might not match is that some diacritics use two characters to represent a single character, and the leader wasn't updated - it is possible this situation was created during the Voyager upgrade to Unicode. Another reason is there is some unreadable character in the text somehow that is counted in one way but not the other.

There are two ways to fix this

1. open the record in cataloging, see if you can find the bad char and remove it, then re-save. As stated above, it’s not always possible to see the bad character. But sometimes re-saving helps (even if no character was removed) because then the leader re-calculation happens correctly anyway
2. get the record from your cataloging source and overlay it again

If you want to check to see if something you did worked, the dummy export will list these errors also.

Boundwiths

Boundwiths are items that are attached to two or more different bibliographic records. A single volume on the shelf contains two or more pieces of bibliographic material but only one barcode. Voyager handles this by allowing the addition of an additional bibliographic links to a single item. When this happens, Voyager automatically assigns the item's MFHD to the additional bibliographic record.

Voyager also allows customers to create boundwith MFHDs, where the MFHD does not have any attached items.

For migration, all linked bibliographic records are converted as is, with no additions or changes. (See the diagram below for an illustration of this explanation.) The shared item and/or MFHD, which in Voyager are linked to all of the linked bibliographic records, will not be linked to any of the original bibliographic records – that is, there will not be a direct link from the shared item or MFHD to any of the linked bibliographic records. Instead, a new bibliographic record is created, which has the migrated shared item and/or migrated MFHD attached to it. The new bibliographic record is linked to the linked bibliographic records using the 774 $w linking field.

The new bibliographic record will have the following tags:

LDR: ”00096nam a2200049 i 4500”
245 00 $a Host bibliographic record for boundwith item <item’s barcode>
774 1_ $t <title of bib> $w (new Alma MMSID of the related record)

One 774 is created for each bibliographic record that is linked to this item. The underscore in the 774’s second indicator (_) indicates a blank.

The 774 links the newly created bibliographic record with the linked bibliographic records using the related records functionality in Alma.

Item Creation

Items are created in the following ways:

Directly from the item record
Directly from the issue record
As a combination of issue and item (see Item Creation from Serial Issues (Check-ins))
Directly from e-items (that are only used in Voyager course reserves)

Item Barcodes

Voyager allows duplicate item barcodes, and Alma does not. Both Voyager and Alma allow empty barcodes.

The item barcode is migrated according to the following:

If the barcode is empty, leave it as empty when moving to Alma.
If the barcode exists but is not unique, migrate but disambiguate the barcode by putting the internal item_id after the barcode: <item_barcode>-<item_id>.
If multiple barcodes exist, take the most recent active barcode and put the others in a note in the item with extra barcodes.

Since the migration program may modify certain barcodes (duplicates), customers may wish to correct these prior to migration.

For information concerning the issue barcode, see Item Creation.

Alma Item Policy

The Voyager Item Type Code is migrated without change to the Alma Item Policy.

Temporary item policy alone

If there is a temporary item type code in Voyager but no temporary item type location, the migration engine cannot set the temporary item policy in Alma. In Alma, the temporary location in use flag can only be set if there is a temporary location set; it cannot be set if there is only a temporary item policy. Therefore, if there is a temporary item policy in Voyager but no temporary location, then the temporary item policy is placed in a note.

Item Statuses

Voyager has a system of item statuses that indicate what is happening to the item. For example, an item may be charged, on hold, lost, missing, in transit, in cataloging, etc. In addition, multiple item statuses can be applied to an item at any one time.

In Alma, there are two indicators of the item status: the base status and the process type.

The base status indicates whether or not the item is on the shelf. For migration, the base status is calculated based on Voyager item status values or by the presence or absence of a migrated loan record or an on-shelf hold request record in Alma.

The following statuses in Voyager are set to baseStatus of Not On Shelf in Alma:

Code	Description
12	Missing
13	Lost – library applied
14	Lost – system applied When an item has status 14, an overdue loan should also be migrated which has the status of Lost – system applied. Migration also assigns the status of Technical – Migration (with no status in the note) to all items with status '14', in case the lost loan was not migrated for some reason. If the loan is migrated, then when the loan is returned in Alma the status is removed. If it is not migrated, the item can be identified as lost by searching for items with Technical Migration and no status in the note.
15	Claims returned
16	Damaged
17	Withdrawn
18	At bindery
19	Catalog review
20	Circulation Review
22	In Process

The following in transit statuses are put in a note with the date that they were sent in transit, but are marked as on shelf, without a process status:

Code	Description
8	In transit
9	In transit discharged
19	In transit

In transit statuses can expire without the staff member touching the item again.

If the item status is not listed in one of the above tables, then it is not migrated at all. Examples of non-migrated statuses are: Hold Request (because a hold request is migrated so we don't need this status), and Overdue (because a loan with an overdue indication is migrated).

The process status indicates the status associated with the item that is not based on the presence of another record, for example, a hold record or a loan record. Examples of this are “In Cataloging” or “Missing”. Since the technical status cannot be directly migrated to Alma, if there is such a technical status, the process status in Alma is set to TECHNICAL. The item statuses from Voyager are written to the Alma item internal note 3 that can then be searched and re-routed to the appropriate handling or department in Alma. See Appendix B: Limiting By Location for more information.

Item Statistical Categories

There may be a large amount of item statistical categories in Voyager, but there are only three places for statistical notes in Alma. If there are more than three statistical categories on a Voyager item, the fourth and subsequent categories are placed in the third statistical note, separated by a pipe (‘|’).

Item Creation from Serial Issues (Check-ins)

Serials issues are also called check-ins in Voyager. Some customers also use the serials check-in module to track receipt of monographic standing orders, and while these are not technically issues, they are migrated the same way. In this documentation, we refer to the issue check-in record as an issue.

The following are considerations regarding serial issues:

If an issue is linked to an item, a single item record is migrated that is a combination of the issue and the linked item.
Issues that have been collapsed are not migrated.
You need to decide if you want to migrate issues that have been marked as suppress in OPAC. See the Questionnaire question MIGRATE_SUPP_SERIAL_ISS. If you do not migrate them, then all check-in information are lost. If you do migrate them, a note is placed on the Alma item record (“CONV – suppressed”) so that you can search for these items and place them in an appropriate Alma status.
Barcodes for the issues are generated based on the internal issue key in Voyager because the item barcode is highly recommended in Alma. The following is the format of the generated barcode: ‘ISSitm’ + <serial_issues.component_id>.<serial_issues.issue_id>.
For migrated serial issues whether they are linked to an item or not, the receipt date is placed in the item's arrival date, and the expected date is placed in the item's expected date field.
Serial issue and item enumeration and Chronology: The various levels of enum and chron in the Voyager serial issue record migrate directly to enum and chron levels in the Alma item. The serial issue’s Enumeration/Chronology field, which comes from the database field SERIAL_ISSUES.ENUMCHRON and which looks like 'v. 2, no. 21 (2004 Sept.)', goes to the Alma item's description field.
When a serial issue is linked to an item, the item's enum and chron fields are preferred over the the issue's enum and chron when generating the description field in Alma, but the serial issue's enum/chron fields are used for EnumX and ChronX. In addition, the item's enum, chron, plus the year field are moved to the Internal Note 1.
In some cases, the serial issues' Enum/Chron fields do not match the description of the serial issue, because there are hidden fields which cannot be corrected by the user in Voyager. Please review the description of this in Appendix C: Item Secondary File. The customer may correct these with the Item Secondary file as described there.
For items that are not linked to serial issues, the Alma description field is comprised of the item fields Enum and Chron (MFHD_ITEM.ITEM_ENUM and MFHD_ITEM.CHRON). The first enum and chron fields in Alma are filled with MFHD_ITEM.ITEM_ENUM and MFHD_ITEM.CHRON. The other enum and chron fields in Alma are left empty.

Serial issues migration preparation

Consider reviewing your serials check-in histories and using the Collapse function to move received issue data into the MFHDs. Each Collapse action creates a new 86x field. Repeat for all issues you wish to collapse. These new holdings fields will be pulled into the MFHD. If you do not want individual item records for each issue but still wish for the holdings to reflect owned issues, this will allow you to update the holdings with summary information.

Enum, Chron and Arrival Date for non-issues

Regular items (not linked to serial issues) can have enumeration and chronology. The fields are filled as follows:

Enumeration A: item enum

Chronology I: item chron and also item year. If both fields are present, put them both in the same field with a pipe between them.

Description: item enum and item chron

Regular items require an arrival date. There is no official arrival date in Voyager, so the arrival date in the Alma item is set to the item's create_date. Items which are linked to orders which are incomplete do not have arrival date. Arrival dates are set for items linked to orders in the following states: Invoiced, Invoice Pending, Received Partial, or Received Complete. There may be some items linked to 'Received Partial' which are not yet received, but most will be in the case of continuous orders.

Material Type Mapping

Material type in Alma is a description of the type of material of which the item consists, such as book, map, issue, DVD, compact disc, and so forth. It is controlled by the physical resource material type code table in Alma. Each item in Alma must have a material type specified even though the functionality behind it is minimal.

Because of the minimal functionality in Alma, the migration automatically assigns a material type, based on Bibliographic LDR and 007 fields. There is no customer input required for this migration.

The Alma codes and names identified in the mapping table are also used to create a code table file for loading into Alma. The Alma material type code is an internal identification and the corresponding Alma material type description may be used to display in the OPAC for patrons.

LDR Pos 6	LDR Pos 7	007 pos 00	Alma Material Type Code
a	a c d i m	h	MICROFORM
a c d	m s	c	ELEC
a	a c d m		BOOK
a c d e f g	b i s		ISSUE
c d			SCORE
e f			MAP
j i			RECORD
m			ELEC
t			MANUSCRIPT
o			KIT
k			GRAPHIC
p g r			OTHER
<default>			BOOK

Alma Location Name and Alma External Location Name

The Alma Location Name column on Location Mapping Tab 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. See the examples below for more illustration.

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

Location codes with diacritics (uncommon)

Usually Voyager does not allow location codes to have diacritics in them. However, a few customers do have diacritics in the location code - for example BÜCHER as the actual LOCATION.LOCATON_CODE. If you have locations with diacritics in them in Voyager, notify your Ex Libris project manager prior to your test load. The migration team will install a special kit for exporting. This is not part of the normal Voyager export kit because it causes too much overhead when it is not needed.

Generation of Holdings 852

All items are assigned a library and a physical location in Alma. During the migration process, the Alma library and Alma location are put in the following places in the exported MARC holdings file:

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

The modified MARC holdings record is imported for use in Alma using the multi-level hierarchy of 852‡b and ‡c.

In Voyager, the MFHD location is stored in the 852‡b, but the two-level Alma location is stored in 852 ‡b and ‡c. Consequently, if you have anything stored in Voyager in 852 ‡c, it must be moved to a different subfield. To specify to which subfield you want to move this information, answer the following (refer to the question MOVE_852C_SUBF above).

MFHD Versus Permanent Location

Voyager allows for three different locations for an item:

Holdings location (stored in the MFHD/holdings record’s 852‡b)
Permanent location (stored in the item record)
Temporary location (stored in the item record)

In Alma, there are two different locations for an item:

Permanent physical location (in the Alma version of the MARC holdings record). The holdings record always determines the permanent location of the item.
Temporary physical location – the item level temporarily overrides the current location information, while the permanent location remains managed in the item’s holdings record.

The temporary location is a one-to-one mapping from Voyager to Alma, but the MFHD location and permanent location must be reduced to a single permanent physical location.

When the item’s location and its MFHD/holdings location are equivalent, the item and its MFHD are migrated with the same relationship as they had in Voyager. However, additional holdings records are made during the migration extract process if there are items with permanent locations that differ from their MFHD/holdings location.

Also, if all of the items on a MFHD have the same permanent location that is different than the MFHD location, the MFHD location is converted to the permanent location during migration.

For example, where:

MFHD location = MAIN and one item with permanent location = MAIN
then export a holding record and item record, both with location MAIN
MFHD location = MAIN and one item with permanent location = JUV
then export a holdings record and item record, both with location JUV
MFHD location = MAIN and two items, one with permanent location = MAIN and one with permanent location = JUV
then export the existing holdings record and item record with location = MAIN and create a new holdings record with location = JUV and attach the item record with location = JUV to the new holdings record
MFHD location = MAIN and one item with permanent location = JUV and any number of issues attached to the original holding record
then export the existing holdings record with MAIN and attach all of the issues to it, and create a new holding record JUV and attach the item to it.

The number of subsequent holdings records created is determined by the number of items with a permanent location different from the MFHD location. For example, where:

Holdings = MAIN

For items A and B, where permanent location = MAIN

For items C and D, where permanent location = JUV

For item E, where permanent location = MAPS

Three holdings records are created:

One with MAIN as the location
One with JUV as the location
One with MAPS as the location

The items with the same location are attached to each holdings record.

The first holding record created receives the original holding record ID. The subsequent holding records receive the original holding record ID plus a sequence: 12345, 12345.1, 12345.2, etc. The additional holding record(s) is actually an exact copy of the original holding record, so fields like 866 are copied to the new holding record. If the original holdings record has only items of the same permanent location, the original holding record is modified to have the permanent location of all of the items and the holding record ID does not change (for example, 12345).

Additionally, after this algorithm has been applied, all holdings and item locations are sent through the location/library mapping as described in the Location Mapping section above.

E-Items and issues do not have a permanent or temporary location in Voyager – they always inherit the MFHD location. On migration to Alma, they always are attached to the original holding record.

Mfhd, perm, and temp location corrections

As described above, it is possible to have different location codes in Holdings and Items. When data is migrated to Alma, these discrepancies lead to multiple holdings records getting created in Alma – one for each location. Some customers may not find this desirable. One solution is to update item or MFHD records to make sure they have matching location codes, using Pick and Scan. Pick and Scan can update either the MFHD or item location.

Some considerations:

If items have multiple locations, should some items have their location edited, or should a new MFHD be added?
If items have a single location different than the MFHD, which location is the appropriate one?
Pick and Scan can use item barcodes, an item key, or a holding record key for processing
Be sure you know your data before performing any mass changes!

Locations in Issues

As described in the previous section, Voyager allows items to have a different (permanent) location than the MFHD to which it is attached. Issues do not have their own locations in Voyager, so when they are migrated to items in Alma, the items in Alma are attached to the issue’s original holding record. Therefore, the issue/item in Alma has the location of the holding record to which it is attached.

This is generally not confusing unless you have a large amount of items and the item permanent location does not match the MFHD location.

For example:

MFHD (id 123), mfhd location = main

Items attached to this mfhd: perm location = mainper

Issues attached to this mfhd: <no location; inherited from mfhd location>

On migration to Alma, a new holding record (with a .1 extension) is made for the items with mainper as described in the MFHD Versus Permanent Location section above. Issues and items are attached to the original holding record. For example:

Holding record (id 123): location = main

Issues converted to items are attached to this holding record. (Items do not have their own location in Alma; they only have the locations of the MFHD to which they are attached).

New holding record (id 123.1): location = mainper

Items that had a permanent location of mainper are attached to this new holding record on migration to Alma.

Duplicate Locations in Voyager

Voyager allows customers to have location codes that differ from each other only by a space at the end of the code, for example, "main" and "main ". In Alma, these two locations are seen as identical. On migration, the location migrated to Alma is the location with the highest MFHD count (LOCATION.MFHD_COUNT).

The other location is mapped using the ALMAME_VALUE_NOT_FOUND line in the Location Mapping tab of the Voyager Migration Form.

Item Notes

The following is a list of item notes in Alma and their source from Voyager:

Alma Note	Voyager Note
Public Note	Mfhd_item.caption
Fulfillment Note	Item note type 2 (charge) Item note type 3 (discharge) When item_pieces > 1, then note “Item consists of x pieces”
Internal Note 1	Item note type 1 (regular) If serial issue is suppressed from opac but was still migrated, then "CONV: Suppressed" E-item internal note
Internal Note 2	Extra item barcodes Issue note
Internal Note 3	mfhd_item.freetext ON_RESERVE RESERVE_CHARGES PRICE SPINE_LABEL RECALLS_PLACED HOLDS_PLACED HISTORICAL_BOOKINGS SHORT_LOAN_CHARGES Last return date Last in-house use Item status and item status date according to chart in “Item statuses” section
Statistics Note 1	First item statistic note
Statistics Note 2	Second item statistics note
Statistics Note 3	Third and subsequent statistics notes

Areas/Fields Not In Scope

The following are not migrated:

Client location when an item is created

Fulfillment

Patron records are required if loans, requests, or fines are migrated. Patron records can be updated post-migration with the patron update routines.

Customer Input

Questionnaire Tab

Which identification number should be used by patrons as the primary identifier?

Code: PATRON_PRIMARYID

Default: Institution Id

Options: Institution ID or Most Recent Active Barcode. Mandatory.

Further Information: Select the identifier to be used as the primary identifier for all patrons. For more information, see Further Explanation – Fulfillment. The primary identifier must be unique and is usually the number used to uniquely identify a patron. It may or may not be used as the authentication identifier. Note that Primary Identifier is not case-sensitive, as opposed to all other identifiers, which are case-sensitive.

If you want to use a different field, contact your Ex Libris project team to discuss your request.

Augment users' identification number?

Code: AUGMENT_PRIMARYID

Default: blank

Options: Prefix, Suffix, None. Mandatory.

Further Information: Indicate if you want to add a prefix or suffix to the identification number for your users. Post-migration, customers load patron records into Alma from their local bursar’s system. In order to ensure a proper patron match, customers must be certain that an identification number in Voyager will migrate to Alma as a matchable identification number in Alma – typically, the identification number in Alma must match an identification number available to LDAP, Shibboleth or some other external authentication system. The LDAP or Shibboleth identification number is often different than the regular institution ID, and the difference is almost always indicated by a prefix or suffix. For more information, see Further Explanation – Fulfillment..

If Prefix or Suffix to the above question, list value here

Code: AUGMENT_ VALUE

Default: blank

Options: Mandatory, if answered other than None in the above question.

Further Information: List prefix or suffix here, if answered other than None in the above question.

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

Code: PATRON_LANG

Default: en

Options: optional.

Further Information: 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 code is also used as the default conversational language for vendors. Additionally, the language code zh-tw (Taiwanese Mandarin) is acceptable.

Patron Group code(s) which will migrate as Internal in Alma

Code: PATRON_INTERNAL

Default: blank

Options: optional. The internal patron groups must be separated by comma: for example, STAFF, WALKIN. The groups are case sensitive – codes are checked exactly as is in the DB.

Further Information: 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 are minority cases where community borrowers or alumni use library services. Identify the patron groups that are internally managed and provide the list of groups, comma separated. If the group is capitalized in the DB, be sure to capitalize it here – for example, Bindery does not match bindery.

Internal users manage their passwords using the Ex Libris Identity Service .
External users are fully external (except patron notes), including all user identifiers, authentication, and address information.

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: COURSE_PREFIX, PO_INV_PREFIX, and FUND_PREFIX

Migrate Course Reserves?

Code: COURSE_RESERVES

Default: Yes

Further Information: This question gives you options for course reserve migration.

Yes = migrate all course reserves
Active = migrate only active course reserves (Active = course end date is blank or within the date range)
No = do not migrate any course reserves from Voyager

Bib tag and text which will contain a Course indication

Code: TAG_FOR_COURSE_RES

Default: N/A

Options: optional

Further Information Specify a bibliographic tag and subfield and text that indicates if bibliographic record is attached to the course (ex: '960 $a ON RESERVE'). This is simply an indication that the record belongs (is linked to) a course. This may be useful to the customer to search for the bibliographic record in Alma to make a set, or to indicate to Primo later that the record is part of a course reserve set.

Course Start and End Date (if not present)

Code: COURSE_START_DATE and COURSE_END_DATE

Default: Start: Migration date; End: Migration Date + 1 year

Options: optional, if left empty default is used

Further Information : Alma requires a start and end date for courses. The migration program does attempt to fill in a start and end date (See 'Active Courses, Course Begin and End Dates' section below). If no date(s) can be found, we must use a default date.

Migrate the identifier that is present in the PATRON.SSAN field?

Code: MIGRATE_SSN

Default: No

Options: Yes/No

Further Information: Customers sometimes use the SSAN field in Voyager for an institutional identifier that is NOT the US Social Security Number (SSN). It is illegal to use the SSN for identification purposes, so if you answer ‘Yes’ to this question, you are agreeing that this field does not contain an SSN.

Use the most recent email address as an identifier?

Code: EMAIL_TO_ID

Default: No

Options: Yes/No

Further Information: If you wish, you may move the most recently updated patron email address to the EMAIL identifier type in Alma. If there is more than one email address for the patron, we will select the one that is active based on effective date.

Further Explanation – Fulfillment

Alma Patron Structure

The diagram below illustrates the Alma structure for patron data.

Patron Mapping Rules and Assumptions

Generally, patron information maps from Voyager to Alma directly. The following areas are migrated for patron.

Patron Group

In Voyager, a patron may have multiple patron groups, each associated with a different barcode. In Alma, a patron may have only one user group.

If there is more than one active patron barcode for a certain patron, then the Alma user group is assigned the patron group associated with the barcode which has the most recent barcode status date.

Alma patron group codes must not contain special characters. Allowed: - and _ (hyphen and underscore). Not allowed: !@#$%^&*()+=/?><.,\|]}[{`~ or the space character. Update these codes prior to migration. If you do not, the migration programs attempt to correct the codes.

Identification Numbers and the Primary Identifier

Ex Libris is providing three choices for selection of the primary identifier:

Institution ID
Most Recent Active Barcode: Take the active barcode. If there is more than one active barcode take the one with the most recent status date. If there is no active barcode, take the inactive barcode with the most recent status date. Additional barcodes will be placed in the user identifier section.
Other: Identifier in PATRON.SSAN field (see MIGRATE_SSN question on Questionnaire)

For each of the above, if the selected identifier is not present, then the original Voyager patron ID is used for the primary identifier, with a prefix of “ID”. Additionally, if the identifier is a duplicate in Voyager and it is chosen as the user name, it is disambiguated since the user name must be unique. In this case, the first identifier is migrated to the user name field as is, and subsequent duplicates are migrated with a suffix to make the identifier unique. If the identifier is modified to be placed in the user name, the original identifier is kept and placed in the user identifier section of the user record. Duplicate identifiers are not allowed in Alma, even within a single patron record.

Prefix or Suffix on Identification Numbers

Post-migration, customers load patron records into Alma from their local bursar’s system. In order to ensure a proper patron match, customers must be certain that an identification number in Voyager will migrate to Alma as a matchable identification number in Alma – typically, the identification number in Alma must match an identification number available to LDAP or Shibboleth or some other external authentication system. The LDAP or Shibboleth identification number is often different than the regular institution ID, and the difference is almost always indicated by a prefix or suffix.

For example, a source institution ID of 12345 might be stored in LDAP or Shibboleth as a12345 or 12345@institution.edu.

Patron and Barcode Statuses

All patrons are migrated with a status of Active. Customers can update patrons later via API, the patron loader, or in bulk.

Barcode statuses are mapped to Active or Inactive. Barcodes with the status of Active are mapped to Active, and Barcodes with the status of Lost, Expired, Stolen and Other are mapped to Inactive.

Statistical Categories, Department and Major

Department and Major, new fields added in Voyager 8.2.0, are moved to the User Stat Categories with prefixes of D: and M: respectively. So, if the department in Voyager was Biology, then in Alma it will be D: Biology. This allows customers to distinguish between the same word in different fields, especially since Voyager patron statistic codes are also migrated to the Alma User Statistical Categories and may also overlap with the department and major.

Notes

Patron notes are migrated, but they are migrated to a limited number of notes. The mapping is:

General = Library
Barcode = Barcode
Address = Address
Phone = Address
Pop-up = Library
All others = Other

Blocks

Voyager allows for a patron to be suspended with a suspension end date. This migrates to Alma as a block, with the suspension end date in the Alma block expiration date. If no end date is present in Voyager, the end date is set to the migration date + 1 year.

Patron Addresses

No attempt is made to determine a home/work/school address on migration to Alma. Every postal and e-mail address is assigned all of the address types on migration to Alma. After migration, you can clear any of the address types you do not want to be used for the patron or you can update the patron address types via the patron loader.

Loans

Active loan transactions are migrated from Voyager to Alma. If the loan was initiated by a proxy patron, the proxy patron information is stored in the loan note. Completed (checked-in) loan transactions are not included in the migration to Alma; however, an Excel report will be provided at the time of the final load migration to Alma with this information.

Historical circulation activity in the form of counts (e.g. historical charges, historical in-house use,and last loan date) is migrated to item record counts used by analytics and available in the item’s More Info details. Other historical activity, such as recalls are stored as notes.

Loans with indefinite loan periods are migrated as due on 31 Dec 2382.

Loan process statuses from Voyager include: Lost, Recall, Renew, and Claimed Return. Loan process statuses are updated during fulfillment cutover.

Proxy Patrons

Proxy patron information is not migrated to the patron record in Alma. Proxy patron information is stored in a loan note for active loan transactions that were initiated by a proxy.

Requests

Active requests (holds and callslips) are migrated from Voyager to Alma. Active requests are those that have been trapped and placed on the hold shelf for the patron to pick up. Requests that are merely requested – not placed on the shelf for pickup or in transit there – are listed in the rejected request error report as such.

Fines and Fees

Active/outstanding patron fines and fees are migrated to Alma. The structure in Voyager is very similar to the structure in Alma: a fine header record and numerous fine transaction records linked to it. Because of limitations in the Voyager fine/fee and loan structure, it is not possible to link a fine/fee to a loan on migration to Alma. Fine/fees are migrated as a standalone transaction, not linked to any loan.

Voyager provides an option to use demerits (points) instead of cash for transgressions. Outstanding demerits are migrated to Alma as a lump sum in the patron record.

Fine Fee Type – The fine fee types in Voyager will be mapped to the following in Alma:
Overdue, Media Booking Late Charge = OverdueFine

Lost Item Processing, Lost Equipment Processing = LostItemProcessFee

Lost Item Replacement, Equipment Replacement = LostItemReplacementFee

Media Booking Usage Fee = ServiceFee

Any fineFeeType which is editable by the customer (type code > 10) is mapped to Other
Transaction Type - Transaction types will be migrated from Voyager to Alma with the following map:
Forgive, Error, Batch Forgive = Waive

Refund, Bursar Refund = Refund

Bursar Transfer, Bursar Refund-Transferred = Exported and Paid

Payment, E-Kiosk, Other (manually added type) = Payment

Course Information Migration Rules and Assumptions

Active Courses, Course Begin and End Dates

In order to determine the begin and end dates for a course, and subsequently the active/inactive status, first we look at the associated reserve lists. For each course, we find the reserve list which expires furthest in the future, and use the begin and end dates from that reserve list for the begin and end dates of the actual course. If there are no associated reserve lists, we use the Begin and End dates specified in the Voyager Course. If those are not specified, we use dates specified in the questionnaire questions, COURSE_START_DATE and COURSE_END_DATE.

Then, in order to determine if the course is active or not, we check if the migration date is between those begin and end dates.

The 'migration date' uses the 'today' function when the data is exported from Voyager.

Reading Lists Linked to Multiple Courses

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

Reading Lists Linked to No Course

In Alma, a reading (reserve) list may be assigned to one and only one course. In Voyager, a reading (reserve) list may exist without an attached course. In Alma, these reading lists are still migrated, but are attached to a generated course called No Course.

Duplicate course codes + section

Course codes + sections (together) must be unique in Alma; if a course code + section is duplicated in Voyager, the subsequent course code is suffixed by the COURSE_ID on migration to Alma. Course name is not included in this disambiguation.

For example, if you have two courses with HIS 400 as the code, the first will migrate as HIS 400, and the second will migrate as HIS 400-345, where 345 is the internal Voyager record ID for the second course (used only to ensure uniqueness on migration). If you have two courses with HIS 400 as the code but they have different sections, the course code is not disambiguated.

Customers may wish to prepare for migration by checking to see if any list titles, courses, or departments are duplicates. If you can either delete the duplicates or make them unique.

Reading List Items -> Bibs

Elements of the reading list are stored in Voyager are stored at the item level; that is, the individual item record is attached to the reading list. In Alma, the reading list stores information at the bibliographic record level. 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.

E-Items

Courses may have regular items or e-items on their reserve list. In Voyager, if an e-item is attached to a suppressed bibliographic record, the bibliographic record is still searchable by course as a normal workflow in Voyager. This is not the case in Alma – if a bibliographic record is suppressed, it is not searchable. For migration, all suppressed bibliographic records are migrated as suppressed, even bibliographic records attached to e-items.

Instructor

The Instructor field in Voyager is a free text field to specify the instructor for the course. In Alma, the field is linked to the user file – that is, the instructor for the course is linked to the instructor’s Alma user record. Since there is no way to parse the free text in the Instructor field, the professor/instructor text is mapped to the reading list note on migration to Alma.

Fulfillment Areas/Fields Not In Scope

The following are not migrated:

Patron registration date
Patron historical counters
Modify location ID
Address status
Universal borrowing stub records that have no active transactions
Accrued (potential) Fines or Demerits
Patron address protect field (protect from overwriting from SIF)
Fine Fee Notice Date
Fine Fee Transaction method (how a person paid, such as credit or cash)

Acquisitions

Customer Input

Questionnaire Tab

Has your library contracted with Ex Libris to migrate Acquisitions data?

Code: ACQ_MODE

Default: Full

Options: Mandatory. Full (Full Acquisitions), None (No Acquisitions), Partial (Vendors, Funds, Purchase Orders (no Invoices)

Further Information: Select Full/ None /Partial depending on the mode that you have contracted with Ex Libris for the Acquisitions data migration.

The migration extract menu is set up to ask if you are migrating Acquisitions prior to the generation of the Voyager Migration Form. If you are not migrating Acquisitions, many of the Acquisitions questions and tabs on the migration form do not appear. For more information on the Voyager auto-extract, see Voyager to Alma AutoExtract Migration.

If you select None (No Acquisitions), you must still answer the questions on the migration form about the fiscal period (FISCAL_PERIOD, FISCAL_PERIOD_NAME, and CURRENT_FISCAL_PERIOD). Alma requires at least one fiscal period defined, even if no orders or vendors are migrated.

Close purchase orders that are NEW and older than x years

Code: PO_NEW_HISTORY

Default: 0 (do not move any to closed)

Options: Mandatory. Options: 0 (do not move any to closed), 1 year, 2 years, 3 years, 4 years, 5 years

Further Information: Inactive POs are migrated to CLOSED. Inactive is defined when status is new/pending (never sent to the vendor), the status date is more than a certain number of years old, and the order is linked to an active fund in the current fiscal year (it has been rolled over repeatedly). Closed orders have ENCUMBRANCE and DISENCUMBRANCE transactions, so they are still linked to the fund. New purchase orders that are still linked to inactive funds are subject to the rules described in the section “Fund Transactions That are Open but in a Previous Fiscal Year”, below.

Close purchase orders that are SENT and older than x years

Code: PO_SENT_HISTORY

Default: 0 (do not move any to closed)

Options: Mandatory. Options: 0 (do not move any to closed), 1 year, 2 years, 3 years, 4 years, 5 years

Further Information: Inactive POs are migrated to CLOSED. Inactive is defined when status is sent to vendor, but nothing has been received and the status date is more than a certain number years old, and the order is linked to an active fund in the current fiscal year (has been rolled over repeatedly). Closed orders have ENCUMBRANCE and DISENCUMBRANCE transactions, so they are still linked to the fund. SENT purchase orders which are still linked to inactive funds are subject to rules described in the section “Fund Transactions That are Open but in a Previous Fiscal Year”, below.

Close purchase order that are single part (0), have been invoiced, and are older than x years

Code: PO_INV_HISTORY

Default: 0 (do not move any to closed)

Options: Mandatory. Options: 0 (do not move any to closed), 1 year, 2 years, 3 years, 4 years, 5 years

Further Information: Inactive POs are migrated to CLOSED. Inactive is defined as invoiced, single part, and are older than x years. Closed orders have ENCUMBRANCE and DISENCUMBRANCE transactions, so they are still linked to the fund. Purchase orders in this category which are still linked to inactive funds are subject to rules described in the section “Fund Transactions That are Open but in a Previous Fiscal Year”, below.

Central Order Library

Code: CENTRAL_ORDER_LIB

Default: blank

Default Order Library

Code: DEFAULT_ORDER_LIB

Default: First library code found on the Alma Library list

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

Additionally, if CENTRAL_ORDER_LIB is set, funds and vendors use the central order library and no attempt is made to determine an ordering library list from the Voyager funds and ledgers.

Renewal date

Code: RENEWAL_DATE

Default: blank

Options: optional

Further Information: Provide your estimated subscription renewal date. The migration programs first attempt to find a subscription renewal date from the Voyager SUBSCRIPTION.RENEWAL_DATE or based on the last invoice date. If the renewal date is earlier than the migration date, or if the last invoice date is more than a year earlier than the migration date, the migration program uses a set renewal date, which is specified here. The subscription interval date is determined from the line item claim interval if it exists. If it does not, it is set to 30 days.

Legal Deposit Order

Code: ACQ_METHOD_ID

Default: blank

Options: List the PO Type that indicates a Legal Deposit order. If your institution has orders that are considered Legal Deposit, and you have created a PO Type specifically for them, list that PO Type name here. They were migrated to Alma as LEGAL_DEPOSIT.

Prediction Patterns

Code: PREDICTION_PATTERNS

Default: None

Options: None, Current, Current+Historical

- When Current, an 853/4/5 tag is added to the Alma holding record for each current classic prediction pattern, and an item is created for each pattern for the next expected issue of the pattern.

- When Current+Historical, the same information is added for closed patterns as well.

Further information: If you are using Voyager Acquisitions for serials checkin, Ex Libris recommends that you select 'Current' here. If you select "None" your checked in serial issues will still migrate and you will still be able to set up prediction in Alma, or receive issues manually. For more information on serial issues migration, see the section Item creation from Serial Issues, and also the questions related to serial issues.

Only regular (classic) prediction patterns are migrated ¬ complex patterns are not migrated to Alma.

Alma allows for a single prediction pattern per holding record, so if there are multiple patterns on a single holding in Alma, duplicate holdings are created. An example of this is a title with multiple parts.

Prediction patterns can be migrated to Alma even if no Acq is migrated.

Merge Vendors with Same Code

Code: MERGE_VENDORS_WITH_SAME_CODE

Default: No

Options: mandatory

Further Information: It is possible to merge vendors that have the same vendor code in Voyager into a single vendor in Alma. If vendors are merged, vendor account information from all merged vendors are retained, but everything else is kept from the first vendor found in the export file. If you want to merge vendors, answer Yes here. Default is No.

This is only for vendors with the same code within a single Voyager db - the fix is done during the export from the db. This question does not apply for multiple voyager databases which are merging into a single IZ in Alma.

Provide Prefix for POs and Invoices (if merging databases)

Code: PO_INV_PREFIX

Default: blank

Options: optional; use only if you are merging multiple databases into a single Alma institution

Further Information: If you are migrating from multiple databases with possible duplicate PO and invoice numbers and you want to prefix these numbers to avoid duplicate POs and invoices to be rejected, enter a fixed prefix code here. Provide a code that will be used to prefix all PO numbers, PO line numbers, and invoice numbers in the database. A hyphen is NOT provided. If your PO number is BN12345 and you put UWS- here, the final fund code is UWS-BN12345. Leave this question blank to leave the PO numbers and invoice numbers code as is.

Fiscal Period Cycle Pattern (DD-MM-C)

Code: FISCAL_PERIOD

Default: 01-07-1

Options: mandatory

Further Information: For example, a one year fiscal period starting on January 1 is: 01-01-1. A one year fiscal period starting on July 1 is 01-07-1.

Alma currently supports one-year fiscal period cycles. Answer this question even if you answered None to the ACQ_MODE question.

Which year do you use to name the fiscal year?

Code: FISCAL_PERIOD_NAME

Default: second/last year

Options: second/last year or first year. Mandatory.

Further Information: Many fiscal periods begin and end at the beginning of a calendar year. For example, a fiscal period may run from July 1, 2015 – June 30, 2016. Different institutions and/or countries have different naming conventions for these fiscal periods.

If the period July 1, 2015 – June 30, 2016 is called “2016”, then select “second/last year” (default).

If the period July 1, 2015 – June 30, 2016 is called “2015”, then select “first year”.

Answer this question even if you answered None to the ACQ_MODE question.

Which fiscal year is your current fiscal year?

Code: CURRENT_FISCAL_PERIOD

Default: by date of conversion

Options: 2014, 2015, by date of conversion

Further Information: This question is important around the fiscal period close. Some customers may prefer to run the fiscal period close in the legacy ILS prior to migrating to Alma, and some may choose to run the fiscal period close Alma after migration. This question allows you to make that choice regardless of when the conversion is run.

Example 1: Your fiscal period runs from July 1, 2014 - June 30, 2015 and July 1, 2015 – June 30, 2016.

Migration date: June 15, 2015.

You want to run the fiscal period close BEFORE you migrate to Alma, so all of your orders are moved to the next fiscal period. Therefore, you want your orders to be migrated into the July 1, 2015 – June 30, 2016 period even though the migration date is technically in the previous fiscal period.

Example 2: Your fiscal period runs from July 1, 2014 - June 30, 2015 and July 1, 2015 – June 30, 2016.

Migration date: July 15, 2015.

You want to run the fiscal period close AFTER you migrate to Alma, so even though the next fiscal period started already, all of your orders are still in the July 1, 2014 - June 30, 2015 fiscal period. Therefore, you want your orders to be migrated into the July 1, 2014 – June 30, 2015 period even though the migration date is technically in the next fiscal period.

Be aware that the year you choose here is dependent on the way you answered the FISCAL_PERIOD_NAME question, above.

If you do not know how to answer this, use determine by date of conversion. In this case, Alma makes the active fiscal period the one that contains the date of conversion.

Answer this question even if you answered None to the ACQ_MODE question.

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 active fiscal year will be 2017. The options are the following:

No – do not make an additional fiscal year.
Yes - make an additional fiscal year.

The only way to have two active fiscal years is to select Yes above. Otherwise, Alma has only one active fiscal year.

If you choose Yes, you have a choice to map the orders from an existing Voyager fiscal year into the Accrual fiscal year in the Fiscal year mapping tab. You can also choose to not map any Voyager orders into the new Accrual fiscal year by simply not mapping into the new year in the mapping tab. The decision to map or not map existing funds or orders is made on the Fiscal Periods tab. For more information, see the Fiscal Periods Tab.

How do you want to migrate your Reporting Funds?

Code: REPORTING_CODE

Default: MAP

Options: MAP, ALLOC, DONOTTRANSFER

Further Information: Instead of using reporting funds, Alma uses instead a reporting code. The reporting code is stored on the transaction record (encumbrance or expenditure) and in the purchase order and can be reported on for statistical purposes. Customers migrating from Voyager may decide to convert reporting funds to reporting codes, they may decide that the reporting funds be converted into actual allocated funds in Alma, or they may choose to not migrate reporting funds at all and have all of the fund transactions be assigned to the reporting fund’s allocated fund parent.

MAP: If this is selected, then use the map in the Reporting Codes tab. Reporting funds' transactions are assigned to the nearest parent allocated fund. Reporting fund names in Voyager are sent through the reporting code tab's map and then placed into the reporting code field in Alma.

If you select DONOTTRANSFER or ALLOC, then do not include any information on the Reporting Codes tab at all. Only use the Reporting Codes tab if you select MAP here.

DONOTTRANSFER: do not use reporting codes in Alma at all. Reporting funds' transactions are assigned to the nearest parent allocated fund. The reporting code field in Alma are left blank, and all other information about reporting codes in funds from Voyager do not migrate.

ALLOC: change the reporting funds to allocated funds. The reporting fund in Voyager are changed into an Allocated fund in Alma, and all transactions are assigned to that reporting-turned-allocated fund. Consequently, no reporting codes are created in Alma.

Fund Prefix (if merging databases on migration)

Code: FUND_PREFIX

Default: blank

Options: string (alphanumeric)

Further Information: If you are migrating from multiple databases with duplicate fund codes to a single Alma institution and want to prefix your fund codes to avoid duplicate funds from being rejected, enter a fixed fund prefix here. Provide a string that will be used to prefix all fund codes in the database. A hyphen is NOT provided. If your fund code is SCIENCE-MONO, and you put UWS- here, the final fund code will be UWS-SCIENCE-MONO. Leave this question blank to leave the fund code as is.

Reporting Codes Tab

To be filled in only if the “How do you want to migrate reporting funds?” question (REPORTING_CODE) was answered “MAP”. If you answered ALLOC or DONOTTRANSFER, then do not put any information in this tab.

Voyager Reporting Fund Code: The migration program automatically populates the tab with your current Voyager Reporting Codes. The FUND_CODE is used if present. If it is not present, then the FUND_NAME is used.

Alma Reporting Code: The desired code value for the reporting code in Alma. The reporting code in Alma may contain spaces, and the reporting code in Alma may be different than it was in Voyager.

Alma Reporting Code Name: 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.

You can collapse values when mapping. For example, map the reporting funds “French Serials”, “Spanish Serials”, and “German Serials” to the same reporting code “Serials” in Alma. The fact that the transaction is mapped in Alma to the parent allocated fund of “French” or “Spanish” indicates that the transaction is for French or Spanish.

If you are collapsing values, the Alma Reporting Code and Alma Reporting Code Name columns must be aligned.

In the following chart, the collapsing of the Biology funds into a single bio reporting code is correct. The collapsing of the two health funds into a single health reporting code is incorrect. In the health case, the name Health Monographs will never be used. The first combination (health + Health Serials) will be loaded into the Alma code table. The healthMono fund will map to health and then use the code table translation for health to Health Serials.

Voyager Reporting Fund	Alma Reporting Code	Alma Reporting Code Name
bioSer	bio	Biology
bioMono	bio	Biology
healthSer	health	Health Serials
healthMono	health	*Health Monographs*

If there are multiple levels of reporting funds, for example, an allocated fund has a child reporting fund and a grandchild reporting fund, the middle level (child) code is lost – only the grandchild reporting fund becomes the reporting code in Alma.

An ALMAME_VAL_NOT_FOUND line is not required here. If you do not want to use a reporting code in Alma for a specific reporting fund, simply remove the Voyager reporting fund from the list and the reporting code remains empty in Alma.

If the reporting code is present on the tab, the fund transaction is placed on the parent Allocated fund and a mapped code is placed within the transaction. If the reporting code is NOT present on the tab, then the fund transaction is placed on the parent Allocated fund but there will be no code in the transaction.

PO Line Types Tab

The PO Line Types tab is not mandatory; if no changes are made to the recommended defaults, then those defaults are used on migration. A primary reason to make changes to the mapping is that there may be some differences in PO usage based on the type of material that was ordered (detected via the reporting code).

Voyager PO Line Types: the code of the Voyager PO Line Type

Voyager PO Line Types Description: a description of the PO Line Type for informational purposes

Voyager Mapped Reporting code (optional): if you chose to convert reporting funds to reporting codes in Alma, then you may use the reporting code here to distinguish purchase orders. Additionally, if you chose to map the reporting codes, the mapped value is what is used here.

Alma PO Line Type: the PO Line Type in Alma

See the PO Line Type Status section in the Further Explanation: Acquisition section below for more information and examples.

Fiscal Periods Tab

Mandatory if Acquisitions are being migrated.

Voyager Fiscal Period: the migration program automatically populates the tab with your current fiscal periods.

Fiscal Period Start Date and Fiscal Period End Date: the Voyager start and end dates of the fiscal periods, provided for ease of decision making.

Alma Fiscal Period: the Alma Fiscal Period must be a year long, with no overlaps across fiscal periods (though you may define generous grace periods). Mandatory.

Active/Not Active: select if the fiscal period in Alma should be Not Active, Active, or Active (Accrual). Multiple fiscal years can be Not Active, but only one may be Active, and only one may be Active (Accrual).

The migration programs create the Alma Fiscal Period column as best as possible based on the fiscal period definition and the end dates of the fiscal periods. Customers should review the initial mapping and make adjustments to the Alma Fiscal Period column as necessary.

Do not add more fiscal periods to this tab. If you use Accrual Accounting, answer the Accrual Accounting question on the Questionnaire tab, which will add an additional fiscal year.

Customers who have a single fiscal period per year will have a straightforward mapping, fiscal period to fiscal period. However, if you have multiple overlapping fiscal periods in Voyager, you may have two or more Voyager fiscal periods being mapped to a single fiscal period in Alma.

For example, if you have the following Voyager Fiscal Periods:

1- July 00 – May 01

2 - Jan 01 – Dec 03

3 - July 01 – June 02

4 - July 02 – June 03

5 - July 03 – August 04

These have to collapse down to four fiscal periods in Alma. The following is one possible map:

Fiscal period 01, July 00 – June 01 (containing #1)

Fiscal period 02, July 01 – June 02 (containing #3)

Fiscal period 03, July 02 – June 03 (containing #2 and #4)

Fiscal period 04, July 03 – June 04 (containing 5)

In the above example, the funds and ledgers in fiscal periods 2 and 4 are mapped into fiscal period 03 in Alma. If there are any ledger or fund codes that have the same code in the two fiscal periods, they are disambiguated. For example, if FP2 and FP4 both contain a ledger called General Ledger or a fund called Monographs, we disambiguate the ledger or the fund so that the ledgers and funds can remain separate in Alma.

Accrual Accounting and Fiscal Periods

If you selected “Yes” to the ACCRUAL_ACC_FY question on the Questionnaire tab, then you may use the “Active (Accrual)” option in the “Active/Not Active” column of this tab.

To map an existing FY into an Accrual FY:

Designate a single Alma fiscal year as Active. Do not select more than one as Active.
Designate a single Alma fiscal year as Active (Accrual). Do not select more than one as Active (Accrual). Existing orders which were in an Accrual fiscal period in Voyager will map to the Accrual fiscal period in Alma.

To leave the Accrual FY empty in Alma:

Designate a single Alma fiscal year as Active. Do not select more than one as Active.
Do not designate an Active (Accrual) fiscal year on this tab. If you selected ‘Yes’ to the ACCRUAL_ACC_FY question but do not designate a fiscal period here, then the fiscal period will still be created in Alma but nothing will be migrated into it.

Fiscal Periods in Shared Databases

If the library has contracted to limit the Voyager extract to certain locations using the OWNING_LIBRARY_OR_LOCATIONS question, there may be fiscal periods on this tab that are not actually being migrated. In order to fill this out correctly, first map your own fiscal periods, for example, if you are library abc:

abc2013-2014 -> 2014

abc2014-2015 -> 2015

abc2015-2016 -> 2016

Any fiscal period that is not yours should simply map to one of the other fiscal periods that you have already mapped (in this case, 2014, 2015, 2016). So, library abc should map fiscal periods for def as follows:

def2012-2013 -> 2014

def2013-2014 -> 2014

def2014-2015 -> 2015

def2015-2016 -> 2016

The final result is that three fiscal periods are created: 2014, 2015, and 2016. Since no orders or invoices are created for the fiscal period def2012-2013, nothing is migrated for it and this is essentially an empty mapping.

Further Explanation – Acquisitions

Vendor Information Rules

Vendor Codes

In Alma, the vendor code must be unique, which is not necessary in Voyager. In order to ensure a unique vendor code on migration, the migration will check if the Voyager VENDOR_CODE is unique. If not, the VENDOR_ID will be attached to the code, for example if there are multiple Vendors with code BT, the second and subsequent codes found will be similar to the following: BT-46.

While migration will disambiguate the vendor, cleaning up in your legacy system allows you to determine if it make sense to consolidate separate vendor records into one or if the two vendors are unique and need unique vendor codes instead.

Vendors/Users

Alma vendors are also Alma users. Users are the general entity for something that has an identity, addresses, and contacts. Each Alma vendor has one user record and a separate vendor record to hold vendor-specific information.

Vendor contacts are also users. Each vendor record may have separate users who are contacts. These are independent from the vendor's user record.

There is no question for the conversational language specifically for vendors. The migration uses the patron conversational language in the migrated vendor record.

Currency

All of the vendors that Ex Libris creates during the migration are set to use all of the currencies defined as valid for the entire institution in Alma – based on all of the currencies used by the institution.

Vendor Accounts

The Alma vendor structure has fuller vendor accounts than in Voyager. Vendor accounts can have any of the information that a vendor record can have. In general, Alma vendor accounts are always used in orders and invoices compared to Voyager where the vendor account is optional.

Each Voyager vendor has one entry in the vendor table, but a Voyager vendor is not required to have any accounts. However, in Alma, each vendor must have at least one account. For vendors that do not have any accounts in Voyager, Ex Libris generates a single account in Alma with minimal information based on the vendor record. For vendors that have one or more accounts in Voyager, the accounts migrate one-for-one to Alma.

Vendor Account Locations

In Voyager, vendor accounts may or may not exist, but if a vendor account exists, it must be assigned an allowable ordering location(s).

Migration does not transfer allowable ordering locations to Alma, because Alma has a strict requirement that the related orders and invoices, plus the funds related to orders and invoices, all have the same location restriction. Meaning, for example, if an invoice is linked to a vendor, then the invoice and the vendor must have the same location restriction.

The amount of checking required to verify the relationship of vendors, orders, invoices, and funds is prohibitive, so all vendor accounts (and invocies, orders, and funds) are migrated at the institution level.

Vendor Account Status

The Voyager vendor account status is mapped to Alma as:

0 (active) = Active
1 (closed) = Inactive
2 (frozen) = Inactive

Vendor EDI information

Vendor EDI information and codes are migrated as they are. If multiple EDI connection profiles exist for the same vendor, the most recently updated profile is migrated. Some additional EDI vendor configuration will be required to enable the EDI functionality with vendors in Alma.

Also, Voyager allows duplicate EDI Connection Profiles where Alma does not. Customers may want to identify duplicate EDI connection profiles prior to migration and modify them so they are not duplicated.

Vendor Addresses and Contacts

In Alma, a vendor has a set of addresses and contacts. Vendor accounts may choose which of these addresses and contacts the account uses. Each vendor address is assigned all address types (order, claim, payment, etc.) on migration to Alma.

All email addresses are also assigned all email address types on migration (orderMail, claimMail, etc.). When an address is categorized as an email address, the email address must be in the ADDRESS_LINE1 of the address (first line of the address).

All the vendor addresses for the Voyager vendor record are added to the vendor and to all the accounts. There is no way to select specific addresses for specific accounts. Each Voyager vendor address may expand into one or more postal addresses or e-mail addresses in Alma and may also generate one or more telephone numbers.

Alma attaches all the addresses and phone numbers to the vendor record and to all vendor account records. You can unlink the addresses and phone numbers from accounts that do not use them after the migration is completed. Voyager does not link addresses and phone numbers to accounts, unlike Alma. All phone numbers are assigned all phone types (orderPhone, claimPhone, etc.).

Vendors at Cutover

As a general rule, customers migrating to Alma are told to update vendors in both Alma and the legacy system, because vendors are retained at cutover. Voyager customers should still do this, because it provides an opportunity to manage vendor data so it is cutover-ready in Alma. In case customers forget, or there is some other mis-communication or error, the migration programs do attempt to load gap vendors during the cutover load, primarily so that no orders are rejected because of a lack of vendor. If the vendor is already in place in Alma, then the gap vendor is simply rejected.

Areas/Fields Not In Scope

The following are not migrated:

All vendor history
Default vendor currency
Vendor claim count
Vendor cancel interval
Vendor ship via
Vendor create date
Vendor type
Vendor default PO
Vendor deposit
Vendor types
Vendor address number that needs to be reviewed
Some of the status and creation/modification information
Vendor bank information

Fund Information Rules

The purpose of this section is to describe the retrieval of Voyager funds information relative to the Alma structure. Voyager funds come in three types:

Summary funds
Allocated funds
Reporting funds

In Voyager, reporting funds can have other reporting funds or allocated funds as parents. Allocated funds can have other allocated funds or summary funds as parents. Allocated funds track independent balances. They reflect the real budgets of the library. Summary funds total the balances of their subordinate allocated funds. Every reporting fund transaction is actually a transaction on the parent allocated fund but is also recorded on the reporting fund. Reporting funds effectively split up an allocated fund into subfunds.

A fund hierarchy belongs to a ledger. Ledgers belong to acquisitions policy groups and fiscal periods. Ledgers also have overcommit and overexpend policies that apply to all subordinate funds that don't have their own overcommit and overexpend policies.

In Alma, funds come in two types:

Summary
Allocated

The ledger, summary, and allocated funds are similar to the equivalent entities in Voyager.

The functional equivalent of reporting funds in Alma are reporting codes which are independent of the fund structure. Reporting Funds/Codes section below for more information on how reporting funds migrate to Alma.

As stated above, allocated funds in Voyager may have another allocated fund as a parent. However, in Alma, allocated funds are all direct descendants of the ledger. Therefore, any allocated fund that is a child of another allocated fund is moved to be the child of the next highest summary fund or ledger. In essence, child allocated funds become siblings to their former parent allocated fund. See the allocated funds under Summary Fund B above for an example of this.

Summary funds in Voyager may also have another summary fund as a parent. In fact, there may be multiple summary funds in a hierarchy. Summary fund hierarchies are migrated as is to Alma.

Fiscal Periods

Alma currently supports one-year, non-overlapping fiscal periods. Since fiscal periods cannot overlap, Alma allows transactions to be applied past the fiscal period end dates using grace periods. It is therefore highly recommended to cleanly define your fiscal year end dates in the actual year that the fiscal year ends and not extend the end dates into the next calendar year’s fiscal period as is sometimes done to achieve long grace periods for past fiscal years.

During migration, fiscal periods are created that last one year, following the cycle defined in Voyager Migration Form. The fiscal period that encompasses the conversion date is marked as active, and previous fiscal periods are inactive.

Ledgers

The migration moves entire ledgers, with their fund structures, all at once. Each Voyager ledger becomes an Alma ledger.

All ledgers, including ledgers from previous fiscal periods, are migrated.

Voyager limits fund usage by the shelf locations assigned to a ledger. In Alma, the ledger also controls fund usage, but at the library level. In order to determine the ledger locations, the Voyager to Alma migration will use the same location to library mapping supplied for the Inventory migration, in the Voyager Migration Form.

However, if CENTRAL_ORDER_LIB is set, funds and vendors use the central order library and no attempt is made to determine an ordering library list from the Voyager funds, ledgers, and vendors.

Ledger and fund ownership

All ledgers and funds are owned by the institution in Alma. Ledger locations, as described in the above section, allow for limiting who can use ledgers and the funds under them.

Fund Names and Fund Codes

Fund codes for both Allocated and Summary Funds are not required in Voyager, nor are they required to be unique – the only thing that is required to be unique in Voyager is the FUND_ID. Since the exact Fund Code is used in Alma to match migrated funds to migrated fund transactions, the fund code that is migrated from Voyager to Alma must be unique. Additionally, ledger codes are stored similarly in Alma, so the deduplication below includes ledger codes.

If the FUND_CODE in Voyager is unique within a Fiscal Period, then the FUND_CODE will be migrated as is.

If the FUND_CODE exists but is not unique, then the existing FUND_CODE will be migrated with the LEDGER_ID and FUND_ID as a suffix, for example Literature-123-45.

If there is no FUND_CODE in Voyager, then the FUND_NAME will be copied to the Fund Code for migration purposes. If the newly generated Fund Code still is not unique, then the LEDGER_ID and FUND_ID will be added as a suffix.

Deleting unused funds prior to migration

If you have unused funds in your ledger, removing them will ensure your ledger in Alma reflects your actively used funds.

If a fund is not in use on any line items, it can be deleted. Even if a fund was used on previous ledgers and no commitments rolled into the current ledger, it can be deleted. If you delete a fund in this fiscal period and then roll, the new ledger will not have the deleted fund.

Funds with diacritics

Customers must change fund codes, including summary fund codes and ledger codes, so that there are no diacritics in the codes. This means characters like å, ø, ü, and others like them must be changed to the non-diacritic character (a or o or u). Customers can of course change these back to the diacritic characters after they are in Alma.

Reporting Funds/Codes

Voyager allows customers to track money spent outside of the allocated fund in subfunds called reporting funds. In the following sample diagram, French is the allocated fund and is the only fund that actually has any money in it. The reporting funds underneath it are merely methods to report on how money was spent within that allocated fund.

Alma does not have a similar reporting fund. Alma instead has reporting codes, a list of codes that exist outside of the fund structure. Therefore, the standard migration changes reporting funds to reporting codes in Alma. Reporting codes in Alma are independent codes that can be assigned to any PO line or invoice transaction. The transactions that were assigned to reporting funds in Voyager are assigned to the reporting fund’s nearest allocated fund parent in Alma.

Keep in mind that in Alma, you can also assign multiple summary funds above the allocated fund levels, which may provide the same type of reporting mechanism for which reporting funds were used in Voyager.

You may want to consider creating a standard list of reporting codes/funds to replace current non-standard codes for use with both current and historical ledgers as Alma displays full ledger and fund names for POs and invoices. ILS names for lower-level reporting funds can be reduced to show only the standard reporting code developed on both current and historical ledgers.

Converting Reporting Funds to Allocated Funds

While it is not recommended, customers may decide that they want the transactions that are linked to reporting funds in Voyager to be linked to actual allocated funds in Alma. This involves converting the reporting funds in Voyager to allocated funds in Alma on migration. In this case, the transactions that are at the reporting fund level in Voyager are linked to the corresponding (newly created) allocated fund in Alma.

When changing the reporting fund in Voyager to an allocated fund in Alma, the reporting fund is migrated as a sibling to its original parent allocated fund. This is necessary because allocated funds in Alma must be children of either a ledger or a summary fund – an allocated fund cannot have another allocated fund as a parent. See the diagram below for a visual representation of this process.

As indicated above, it is not recommended to convert reporting funds to allocated funds on migration. However, if your fund structures are such that it is absolutely necessary, then indicate such on the Questionnaire tab of the Voyager Migration Form.

Areas/Fields Not In Scope

The following are not migrated:

Fund types
Fund/ledger creation and modification history
Fund commit pending
Fund expenditures pending

Fund Transaction Information Rules

The purpose of this section is to describe the retrieval of Voyager funds information relative to the Alma structure. See the diagram below for an illustration of the Alma structure for funds data.

Voyager stores all official fund transaction information in the FUND_TRANSACTION table. However, the transactions are stored at the entire purchase order (PO) or entire invoice level – not at the PO line or Invoice line level. The FUND_TRANSACTION table may list a single encumbrance of $100 where the PO had three line items of $50, $30, and $20. This is not how Alma stores transactions, so migration for Voyager fund transactions for POs and invoices will be taken directly from the PO line item and invoice line item tables for line items, and from the price adjustment table for invoice header charges (charges that are not assigned to any specific invoice line item).

Allocations

In Voyager there is a distinction between initial allocations, fund increases, and fund decreases. In Alma there is no such distinction. All three of the above are migrated as simple allocations. Fund decreases are migrated as a negative allocation.

Purchase Orders Entry Point

Transactions from active purchase orders (POs)are migrated.

For migration, PO statuses and corresponding encumbrance transactions are created according to the following chart.

* = when the PO is closed according to the rules in the “Close purchase orders older than …” questions, change to ENC/DISENC instead.

Line Item Status	Invoice Item Status	Alma Order Status (Entry Point)	Encumbrance or Disencumbrance
0 – Pending or null	n/a	New	ENC
1 – Received Complete *OT	0 = Pending or null	Waiting for Invoice	ENC *
1 – Received Complete SO or CO	0 = Pending or null	Sent	ENC *
1 – Received Complete *OT	5 = Invoice Pending	Waiting for Invoice	ENC *
1 – Received Complete SO or CO	5 = Invoice Pending	Sent	ENC *
1 – Received Complete *OT	6 = Invoiced	Closed	ENC/DISENC
1 – Received Complete SO or CO	6 = Invoiced	Sent	ENC/DISENC
2 – Backordered	n/a	New	ENC *
3 – Returned	0 = Pending or null	Closed	ENC/DISENC
3 – Returned	5 = Invoice Pending	Closed	ENC/DISENC
3 – Returned	6 = Invoiced	Closed	ENC/DISENC
4 – Claimed	0 = Pending or null	Sent	ENC *
4 – Claimed	5 = Invoice Pending	Waiting for Invoice	ENC/DISENC
4 – Claimed	6 = Invoiced	Sent	ENC/DISENC
7 – Cancelled	0 = Pending or null	Cancelled	ENC/DISENC
7 – Cancelled	5 = Invoice Pending	Cancelled	ENC/DISENC
7 – Cancelled	6 = Invoiced	Cancelled	ENC/DISENC
8 – Approved	0 = Pending or null	Sent	ENC *
8 – Approved	5 = Invoice Pending	Waiting for Invoice	ENC *
8 – Approved	6 = Invoiced	Sent	ENC/DISENC
9 – Received Partial	0 = Pending or null	Sent	ENC *
9 – Received Partial	5 = Invoice Pending	Sent	ENC *
9 – Received Partial	6 = Invoiced	Sent	ENC/DISENC
10 – Rolled Over	0 = Pending or null	Sent	ENC *
10 – Rolled Over	5 = Invoice Pending	Waiting for invoice	ENC *
10 – Rolled Over	6 = Invoiced	Closed	ENC/DISENC

Fund transactions are not created for purchase order header transactions. Only those transactions associated with a purchase order line item are transferred. Since these are encumbrances, only potential balances are affected. Therefore, potential balances may be slightly different on migration.

When there are multiple fund transactions for the same fund on the same line item (multiple copies), then the transactions are combined into a single fund transaction.

Fund transactions for the invoice header transactions are migrated – the header transactions are placed in a newly-created line item 0 on the invoice. The cash/actual balance (from invoices) will be accurate on migration.

Fund Transactions That are Open but in a Previous Fiscal Year

Voyager allows orders to have open encumbrance transactions linked to a fund in a closed fiscal year. Alma does not allow this: if an order in Alma is open, it must be linked to a fund in the current active fiscal year.

The migration programs attempt to rectify the situation by closing some orders or moving some orders to the same fund but in the current fiscal year.

If an order is monographic, is Sent according to the PO Entry Point table above, and is linked to a fund in a closed fiscal year, then the order is Closed in Alma.
If an order is continuous, is Sent according to the PO Entry Point table above, and is linked to a fund in a closed fiscal year, then:
1. The migration program checks the response to the Close purchase orders that are SENT and are older than 'x' years', in the Questionnaire tab. If the order is older than x years, the order is Closed in Alma.
2. If the order is more recent than the response to a), the migration program looks for the same fund code but in the current fiscal year and attaches the order to that fund code. In essence, the order/transaction is moved to the current fiscal year.
3. If there is no identical fund code in the current fiscal year, then the order is set to status NEW and there is no link to any fund. These orders have to be reviewed on a case-by-case basis and be either closed or assigned to a new fund.

In all cases above, a note is written to the log file stating the order number, fund code, and action taken.

In 2a) above, be aware that the Encumbrance/Commitment amount for current funds will increase, depending on how many open continuous orders were present in the Voyager database. Customers are advised to scrutinize the provided log information for such orders.

Continuous Purchase Orders That Were Invoiced in the Current Fiscal Year

This situation is seen primarily at the end of a fiscal year, just prior to fiscal year rollover. When there is a continuous purchase order in the current fiscal year that has been received and invoiced, there is a potential for there to be double posting of funding amounts.

since the order is considered open/SENT, there will be an encumbrance created for this order
since there is a completed invoice for this order, there will be an expenditure created for this invoice

The encumbrance and the expenditure are on the same fund in the same fiscal year. In Voyager, the invoice and the order are linked and the encumbrance is suppressed from the active amounts.

Be aware that this may make the encumbrance amount for certain funds appear higher in Alma than they are in Voyager. This issue is resolved after the encumbrances roll over to the next fiscal year. Until then, customers may want to increase the allowed over-encumbrance percentage for affected funds.

This situation will happen throughout the fiscal year, but is more pronounced at the end of the year after many continuous orders have been received and invoiced. At the beginning of the fiscal year, this situation is not as pronounced, because not very many continuous orders will have been invoiced.

If you are migrating around the end/beginning of a fiscal year, you may want to consider rolling over in Voyager prior to migration in order to lessen the effects of this situation.

Invoices - Expenditures

Invoices in Voyager can have the following statuses:

0 – Pending

1 – Approved

4 – Complete

5 – Canceled

Alma expenditure transactions are created for all Voyager invoice statuses. Therefore, expenditure discrepancies can be expected in the final balance in Alma. Specifically, in Voyager, there may be funded invoices that were received prior to migration in Voyager, but not yet paid before the migration process to Alma began. These are listed as pending invoices in Voyager and as full expenditures in Alma. An invoice in Voyager can be canceled only if it has already been approved. Also, if an invoice in Voyager is canceled (type 5), Voyager does not dis-expend the funds. In order to retrieve those funds, an invoice with a credit should have been made in Voyager.

Transactions of Amount 0.00

Encumbrance transactions (purchase orders): Voyager allows for transactions to be of value 0.00 for all purchase orders (encumbrances). In Alma, encumbrances for open orders of amount 0.00 are changed to 1.00. Encumbrances/disencubmrances for closed orders of amount 0.00 are not transferred.

The following types of orders (Acq method) can be open with amount 0 on the order, but with with no transaction/encumbrance/link to fund: GIFT, DEPOSITORY, EXCHANGE, TECHNICAL.

Expenditure transactions (Invoices): All expenditures of amount 0.00 are discarded during migration, along with the associated invoice line. These discarded invoice lines are written to an error log.

Transactions on Reporting Funds

Since reporting funds in Voyager are normally migrated to reporting codes in Alma (as described in the Funds section above), fund transactions in Voyager that are listed at the reporting code level must be migrated in a special manner. If a fund transaction in Voyager has a reporting fund as the fund, then the transaction is migrated to Alma with the parent allocated fund as the actual fund. The original reporting fund for the transaction (or the mapped code) is placed in the transaction’s reporting code field in Alma. For information on mapping the reporting fund to a different reporting code in Alma, see Reporting Fund/Codes.

Voyager allows for multiple levels of reporting funds. In the above diagram, if a fund transaction is migrated that has Non-Fiction as the fund in Voyager, the fund transaction is migrated with the parent allocated fund of French as the fund, and Non-Fiction is placed in Alma’s reporting code field. The intermediate reporting fund of Books is not migrated for this fund transaction.

If you choose to change reporting funds in Voyager to allocated funds in Alma, transactions on the reporting fund continue to be migrated to the new allocated fund. In this case, all of the funds above (French, Books, Serials, Non-Fiction, and Fiction) become siblings to each other, and transactions are only migrated to the original fund. If, for example, an invoice line is linked to the Non-Fiction reporting fund in Voyager, you can see the transactions for Non-Fiction from the French fund. In Alma, the French fund is not linked to the Non-Fiction fund and all transactions are only viewable from the Non-Fiction fund.

Areas/Fields Not In Scope

The following are not migrated:

Transactions associated with the purchase order header – only those transactions associated with a purchase order line item are transferred. Since these are encumbrances, no actual balance is affected, only potential balances.
Intermediate reporting fund levels, as described in Reporting Funds/Codes above.

Purchase Order (PO) and PO Line Migration

This section describes the following for the ILS purchase order (PO) and PO Line component of migration.

The Alma structure
Mapping rules and assumptions
Areas/Fields Not In Scope

The Voyager structure for POs and PO lines is similar to the Alma structure. There is a PO header, which includes one or more PO lines attached to it. The PO lines represent the item(s) ordered.

As such, migration from Voyager to Alma will generally be a one-to-one migration.

One major difference between Voyager and Alma is that Voyager has an option to provide a fund transaction at the PO header level. As described in the Fund Transaction section above, Alma provides only fund transactions at the PO line level. As a result, PO header fund transactions will not be migrated. These are encumbrances, so do not have a real effect on fund balances.

Scope of PO migration

POs that were opened by mistake are not migrated to Alma. If someone opens a PO in Voyager and then immediately closes it, without saving, the vendor ID field will remain blank in the database (actually, ‘0’), and these POs are discarded during migration. Additionally, purchase orders with an empty purchase order number will not be migrated.

If the purchase order number is the same as the PO_ID, meaning it was constructed from an internal db key, then the migration programs place the yyydb code on the purchase order number (e.g. 12345-yyydb). if the purchase order number is NOT the same as the PO_ID, meaning the customer manually entered a purchase order number, then the purchase order number is left as is.

Duplicate Purchase Order Numbers

If there are duplicate purchase order numbers in Voyager, the migration program will disambiguate the numbers by putting the internal record key after the number for each duplicate. For example: UMC2345-22145 and UMC2345-14378.

Purchase Order Status

The following map is used to migrate the PO header status from Voyager to Alma:

Pending = NEW

Approved/Sent, Received Partial = SENT

Received Complete = SENT

Complete = CLOSED

Canceled = CANCELLED

Inactive POs are migrated to CLOSED. Inactive is defined as:

status is new/pending (never sent to the vendor) and the status date is more than a certain number of years old
status is sent to vendor, but nothing has been received and the status date is more than a certain number years old

To specify the number of years that defines an inactive purchase order, answer the following questions in the Voyager Migration Form:

Close POs that are NEW and older than x years
Close POs that are SENT and older than x years

Line Item Status

If the overall PO status is CLOSED or CANCELLED, then the PO lines associated with the PO are migrated as CLOSED or CANCELLED accordingly.

Otherwise, the line item status is mapped, according to the following table. The table contains the Rollover Status in Voyager column, so that customers may be aware of some differences in rollover behavior between Voyager and Alma.

Yes* = order open and eligible for rollover
Yes = order open but not eligible for rollover
No + = In Voyager, it is possible for a continuing order to be Received Complete and Invoiced, but still be acted upon (for example, received and/or invoiced again). The order is technically considered closed and is not eligible for rollover, but since Voyager is forgiving, some customers may think the order is open when it actually is not.

Line Item Status	Invoice Item Status	Alma Order Status (Entry Point)	Rollover Status in Voyager (FYI)
0 – Pending or null	n/a	New	Yes*
1 – Received Complete *OT	0 = Pending or null	Waiting for Invoice	Yes*
1 – Received Complete SO or CO	0 = Pending or null	Sent	Yes*
1 – Received Complete *OT	5 = Invoice Pending	Waiting for Invoice	Yes
1 – Received Complete SO or CO	5 = Invoice Pending	Sent	Yes
1 – Received Complete *OT	6 = Invoiced	Closed	No
1 – Received Complete SO or CO	6 = Invoiced	Sent	No +
2 – Backordered	n/a	New	not present
3 – Returned	0 = Pending or null	Closed	No
3 – Returned	5 = Invoice Pending	Closed	No
3 – Returned	6 = Invoiced	Closed	No
4 – Claimed	0 = Pending or null	Sent	Yes*
4 – Claimed	5 = Invoice Pending	Waiting for Invoice	Yes
4 – Claimed	6 = Invoiced	Sent	Yes*
7 – Cancelled	0 = Pending or null	Cancelled	No
7 – Cancelled	5 = Invoice Pending	Cancelled	No
7 – Cancelled	6 = Invoiced	Cancelled	No
8 – Approved	0 = Pending or null	Sent	Yes*
8 – Approved	5 = Invoice Pending	Waiting for Invoice	Yes
8 – Approved	6 = Invoiced	Sent	Yes*
9 – Received Partial	0 = Pending or null	Sent	Yes*
9 – Received Partial	5 = Invoice Pending	Sent	Yes
9 – Received Partial	6 = Invoiced	Sent	Yes*
10 – Rolled Over	0 = Pending or null	Sent
10 – Rolled Over	5 = Invoice Pending	Waiting for invoice
10 – Rolled Over	6 = Invoiced	Closed

PO Type (Acq Method)

The PO type for purchase orders are migrated to the Alma Acq Method as follows:

0 Approval = APPROVAL
1 Firm Order = PURCHASE
2 Gift = GIFT
3 Exchange = EXCHANGE
4 Depository = DEPOSITORY
5 Continuation = VENDOR_SYSTEM
else = VENDOR_SYSTEM

PO Line Type

PO Line Types are migrated according to the PO Line Type tab in the Voyager Migration Form. The following default mappings are used to migrate the PO line type status from Voyager to Alma:

0 Single-part > PRINTED_BOOK_OT

1 Subscription > PRINTED_JOURNAL_CO

2 Membership > PRINTED_JOURNAL_CO

3 Standing > PRINTED_BOOK_SO

4 Blanket Order > PRINTED_BOOK_OT

5 Multi-part Order > PRINTED_JOURNAL_CO

6 Approval > PRINTED_BOOK_OT

The above map is generally sufficient for most customers, and it is recommended to leave the mapping as above. However, you may decide to make changes to the standard mapping based on local workflows, or you may want to include mapped reporting codes in the mapping determination.

The possible values for Alma Line Types are the following:

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. For example, 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 PO Line Types for Electronic Orders.
OTHER_SERVICES_CO: Other Services Subscription -This should only be applied to orders without inventory. For electronic resources, see PO Line Types for Electronic Orders.

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

If a direct mapping from Voyager line type is not specific enough to determine Alma line types, you can use the reporting code (which is mapped from a Voyager Reporting Fund) to distinguish different PO Line Types. On the PO Line Types map, only fill in reporting code information for the lines where the reporting code is necessary to differentiate a line type in Alma. If the Voyager Mapped Reporting Code is not filled in, Alma ignores the reporting code when mapping.

In the example PO Line Type mapping table below:

A line type of Subscription and a reporting code of STO will have an Alma PO line type of PRINT_CO, as caught by the Subscription/STO line.
A line type of Subscription and a reporting code of OTHER have an Alma PO line type of PRINT_CO, as caught by the Subscription/ line.
A line type of Subscription and no reporting code will also have an Alma PO line type of PRINT_CO, as caught by the Subscription/ line.

The table is read from the top down, and the first line that matches is used. Therefore, a line type of Subscription and a reporting code of JRNL, as listed in the below table, is caught by the Subscription/ line, and the Subscription/JRNL line is essentially useless.

Voyager PO Line Types	Voyager PO Line Type Description (for info)	Voyager Mapped Reporting Code	Alma PO Line Type
ALMAME_VAL_NOT_FOUND			PRINT_OT
0	Single-part		PRINTED_BOOK_OT
1	Subscription	STO	PRINT_SO_NONMON
1	Subscription	PRINT	PRINTED_JOURNAL_CO
1	Subscription		PRINT_CO
1	Subscription	JRNL	this line will not be read by the migration!!!
2	Membership		PRINTED_JOURNAL_CO
3	Standing Order	JRNL	PRINT_SO
3	Standing Order	PRINT	PRINTED_BOOK_SO
3	Standing Order		PRINT_SO
4	Blanket Order		PRINTED_BOOK_OT
5	Multi-part		PRINTED_JOURNAL_CO
6	Approval		PRINTED_BOOK_OT

PO Line Types for Electronic Orders

The above line types are all descriptions based on a print order. All orders are stored in Voyager 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 transform 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.

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

Inventory Related to Orders

In Alma, some orders can have item records associated with them, and other orders can have holding records associated with them. Generally speaking, non-monographic orders are linked to a holding record, and monographic (one time) orders are linked to an item record. The specific chart for Items vs Holdings is below:

PO Line Type	Holding Record	Item Record
PRINTED_JOURNAL_CO PRINT_CO PRINT_SO_NONMON	Y	N
PRINTED_BOOK_OT PRINT_OT PRINTED_BOOK_SO PRINT_SO	N	Y
OTHER_SERVICES_OT* OTHER_SERVICES_CO*	N	N

PO Line Type

Holding Record

Item Record

PRINTED_JOURNAL_CO

PRINT_CO

PRINT_SO_NONMON

PRINTED_BOOK_OT

PRINT_OT

PRINTED_BOOK_SO

PRINT_SO

OTHER_SERVICES_OT*

OTHER_SERVICES_CO*

* Other Services orders are intended to be used for services not related to inventory and are therefore used very rarely.

Orders Linked to an Appropriate Item or Holding Record

When an item record is linked to a monographic order in Voyager, the migration program attempts to link the order record to the linked item record.

Similarly, when a holding record is linked to a non-monographic order in Voyager, the migration program attempts to link the order record to the linked holding record.

In both cases, if multiple orders are linked to a single inventory (item or holding), the first order found will be linked to the inventory. Alma cannot link inventory directly to multiple orders.

The second and subsequent orders are loaded as not linked to inventory, but have the intended inventory location in the receiving note.

Orders Linked to a Non-Appropriate Item or Holding Record or Not Linked

There may be cases where an order in Voyager has a linked item or holding record, but it is not the correct type, for example if a holding record is linked to a monographic order, the migration programs does not link any inventory to the order. Similarly, there may be orders in Voyager that are not linked to an item or holding at all and are only linked at the bibliographic record level.

In these cases, the migration program attempts to link orders to existing inventory based on location match, but again only one inventory can be linked to a single order. When no location match is found, the inventory location is placed in the receiving note.

Billing and Shipping Locations

Billing and shipping locations in Voyager will not map directly to Alma. Instead, the Voyager billing and shipping locations will be placed in the PO note.

PO and PO Line Notes

The PO header note field in Alma contains information from the Shipping Location, Billing Location, and PO header notes from Voyager.

The PO line note field in Alma contains information from the attached subscription and PO Line notes from Voyager.

The PO Line Receiving note in Alma contains the component notes from Voyager.

The regular PO Header and PO Line notes from Voyager are moved to the same place in Alma.

The instructions in vendor notes from Voyager are moved to the regular notes field in Alma, since it is unlikely that customers will make an order in Voyager and then send it to the vendor after migrating to Alma.

Vendor Reference Numbers

The Voyager Vendor Reference number migrates to the Alma Vendor Reference number. Unless otherwise specified, the reference number type is defined as 'IA'.

The Vendor Title Number migrates to the POL Note.

Subscription UPC number

The subscription UPC number is placed in the Alma order’s Additional Order Number field.

Expected Receiving Interval/Date

If the PO Line is classified as NEW, the following occurs:

If it does not, the value 365 days is used.

If the claim interval for that line item in Voyager exists, the expected_receiving_interval in Alma is created from it.
The expected_receiving_date is left empty.

If the PO Line is not classified as NEW, the following occurs:

The expected_receiving_interval in Alma is left empty.
The expected_receiving_date is obtained, as follows:
- from the serial_issue.expected_date for issues
- from the PO approve date and claim interval for monographs and standing orders
- if either of those are empty, Alma migration processing finds the most recent invoice date and add one year
- if invoices cannot be found, one year is added to the migration date

PO Lines in an Unsupported Currency

Currencies in Alma must be current, but there may be some older purchase order lines that are still listed in a currency that is no longer used. For example, the French Franc (FRF) may still be listed as a foreign amount on a PO in Voyager, but FRF is not a valid currency in Alma.

For PO Line migration, invalid currencies are migrated with their replacement currency, but the amount remains the same. So, for example, the original PO may have been listed as 4000.00 Italian Lira, which really is about 2 Euro, but the migration program keeps the original amount, so the PO line amount will be listed as 4000.00 Euro. A note is placed in the PO Line Note field indicating that the currency was replaced on migration, listing the old and new currencies.

Note that the transaction – the link to the fund –continues to be in the local currency. For example, if the local currency is GBP, in the above example, the fund transaction is listed correctly as 1.50 GBP, and the PO Line is shown as 4000.00 EUR.

Check-in Information

Voyager customers can use the serials module to record receipt of both standing orders and serials. The check-in records in the serials module are considered issues for migration purposes and are migrated as Alma items. For more information, see Migrate Suppressed Serial Issues?.

Areas/Fields Not In Scope

The following areas are not migrated to Alma:

POs opened in error, where the VENDOR_ID = ‘0’, are not migrated
POs where the PO_NUMBER is null (not supposed to happen in Voyager)
POs where there are no valid PO lines (only a PO header)
PO header encumbrance transactions are not migrated
Historical claim information

Invoice Migration

This section describes the following for the ILS invoice component of migration:

The Alma structure
Mapping rules and assumptions
Areas/Fields Not In Scope

Voyager and Alma Structure

The Voyager structure for invoices and invoice line items is similar to the Alma structure. There is an invoice header, which includes one or more invoice lines attached to it. The invoice lines represent the items received.

Therefore, migration from Voyager to Alma will generally be a one-to-one migration.

Scope of Invoice Migration

All invoices are migrated from Voyager to Alma, with the exception of those that were opened in error and closed immediately. The invoices opened in error can be identified by a blank (null) invoice number and a vendor ID of 0. Additionally, invoices that have a total invoice amount of 0 PLUS a line item amount of 0 are not migrated. Invoices of amount zero which have varying line item amounts (like a positive and a negative) are still migrated.

Additionally, if the invoice has a non-zero amount, all line items are migrated including line items of amount zero. However, the line items of amount zero are not linked to any fund since there is no expenditure.

Invoice Entry Point

The following map is used to migrate the invoice header status from Voyager to the Alma Invoice Entry Point:

First, check if there is a check number defined – if so, the invoice migrates as CLOSED. Otherwise, the invoice migrates according to the following:

Pending = NEW
Approved = CLOSED
Complete = CLOSED
Canceled = CLOSED

Invoice Payment Status

If the invoice status is closed as above, then the invoice payment status is PAID; otherwise, it is NOT_PAID.

Invoice Status in Alma

The migration programs set the following in invoices:

Entry Point

Approval status

Payment Status

After an invoice is loaded, Alma will assign an Invoice Status based on these and other factors. Statuses that may appar are 'Ready to be Paid' or 'Waiting Payment'. The assignment of these values is based on Alma configuration. As a starting point, see a description of the invoicing workflow: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/030Invoicing/010Invoicing_Workflow

Invoice Number

The invoice number must be unique per vendor in Alma. Since uniqueness is not required in Voyager, if duplicate invoice numbers per vendor are encountered, then the invoice number is migrated as <invoice_number>-<invoice_id>.

Invoice Adjustments

Invoice adjustment amounts that are for the entire invoice (invoice header) are migrated to Alma to a newly created invoice line item, with an index value of 0. The note regarding the header charge is placed in both the invoice line item note and in the note on the fund transaction.

When the invoice adjustment amount is for an individual invoice line item, there is no need to make an additional line. The final amount of the invoice line, after adjustments, is the amount that is migrated to Alma. However, the information about the adjustments is kept in the fund transaction note.

Check Number and Voucher number

The check number in Voyager is migrated to the payment voucher number in Alma.

The voucher number in Voyager is migrated to the invoice reference number in Alma.

Invoice Notes

Invoice header notes and invoice line notes are moved to the Alma invoice header and line notes respectively.

Physical to Electronic (P2E) Processing

This section describes the process of correctly categorizing resources as electronic in Alma. In Voyager, 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 in Alma.

Many types of e-resources can be in a customer’s Voyager database: e-journals, e-Books, e-Gov docs, e-packages, and others. In order to identify the e-resources, the institution should provide a list of bibliographic keys that identify records that are electronic, in the following format, where yyydb is your voyager database code. For example: 12344-schooldb.

123475-yyydb,portfolio

12346-yyydb,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.

The P2E file must be submitted as a csv file.

Associated holding and/or item records (if any)

For records that are listed in the p2e file, the p2e process will generate at least one electronic resource (portfolio or db), for each bib listed.

If there are multiple holdings or items in a location designated as electronic (see below), then an e-resource will be made for each electronic holding or item found. Typically, these records are identified during migration by a holding location that is easily identifiable (i.e., named ‘Electronic’, ‘Online’, etc.). If you’re using locations in this way, make sure that they’are only used for this type of resource, so no other records migrate as electronic resources.

If the bib listed has no holdings or items at all, or has only holdings or items in a non-electronic location, the p2e process will still make a single electronic resource based on information in the bib.

Duplicate electronic resources

The migration process ingests records from both Voyager and Link Resolver, which can create a lot of duplicate records in Alma. In addition, there are many electronic collections and databases which would be easier to simply activate from Alma’s Community Zone, rather than importing local records. Evaluate what duplication there would be between Voyager and your Link Resolver.

To not migrate the ILS version of the electronic resource, such as a record imported to Voyager with MARCit when the reocrd is also in SFX, use the SFX_PREFIX question. You may use this question even if you use a link resolver other than SFX. These records would nothen not be included in P2E.

Valid/invalid URLs

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. If the URL is not present or does not match what is specified in P2E_LINK, the resulting e-resource will have an empty link.

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.

Related Orders

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

Item material types and order types

Items and orders should initially be migrated with physical material and order types. The p2e process changes these types to the corresponding electronic type as the resource is changed to electronic. The mapping of physical to electronic types for items and orders can be found in the guide: https://knowledge.exlibrisgroup.com/Alma/Implementation_and_Migration/Migration_Guides/Electronic_System_Migrations/Electronic_Resource_Handling_in_Alma_Migration.

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 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 3 digit Marc field code + subfield: 856u. Only one subfield is allowed.

Default: 856 u

Which Holding or Bib field stores electronic link public note

Code: P2E_NOTE

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

Default: 856 z

Which Holding or Bib field stores electronic provider name information

Code: P2E_PROVIDER

Options: Provide a 3 digit Marc field code + subfield: 856m. Only one subfield is allowed.

Default: 856 m

Do you want the P2E process to include suppressed bib records from Voyager?

Code: P2E_SUPP_BIB

Options: Yes or No

Default: No

Explanation: During the P2E process, the migration programs look for the bibliographic record that is listed in the p2e file and any holdings or items record that is in a location marked as electronic is changed to electronic. The P2E migration can ignore (not make any electronic resource for) any bibliographic records that are suppressed, if a bibliographic record was added to the P2E file by mistake.

Yes = include suppressed bibliographic records in the p2e process. An electronic resource is created, and the bibliographic record continues to be suppressed in Alma.

No = P2E process does not consider suppressed bibliographic records, and passes over any bibliographic record ID in the p2e file that is marked as suppressed.

Do you want the P2E process to include suppressed holding records from Voyager?

Code: P2E_SUPP_HOL

Options: Yes or No

Default: No

Explanation: During the P2E process, the migration programs look for the bibliographic record that is listed in the p2e file, and any holdings or item record that is in a location marked as electronic is changed to electronic. The P2E migration can ignore (not change) any holdings record that is suppressed, or it can consider the suppressed holdings record as active for the p2e process only. Note that if we make a resource from a suppressed holdings record, the resulting electronic resource is not suppressed in Alma.

Yes = include suppressed holdings records in the p2e process. The generated e-resource is not suppressed.

No = P2E process does not consider suppressed holdings records when looking for holdings records to convert to electronic, and makes an e-resource from other electronic entities on the bibliographic record or from the bibliographic record itself.

Location Mapping 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 by answering Yes or No in the Electronic Location? column of the Alma Location tab.

Further Information

The conversion process identifies the lowest inventory level resource that indicates an electronic resource: item records, unsuppressed holding records, or unsuppressed bibliographic records. Suppressed bibliographic and holding records are considered in the p2e process depending on the responses to the questions P2E_SUPP_BIB and P2E_SUPP_HOL. In addition, any associated order records associated with the item, holding, or bibliographic record is included.

If the bibliographic record will not be migrated because it is duplicated elsewhere, it is removed from the P2E process. For example, SFX bibliographic records duplicated in Voyager are not migrated, because the SFX records will also be loaded into Alma from SFX itself. However, if the duplicate SFX record in Voyager has order information associated with it, it is kept in the P2E process to preserve the migration of the order record. Tools will be provided on the Alma side to optionally move the order record from the Voyager-sourced bibliographic record to the SFX-sourced bibliographic record, post-conversion.

Once the lowest level of inventory resource and associated order record have been identified, the records in Alma are structurally modified to reflect the fact that they are a portfolio or database.

If the bibliographic record is included in the file more than once and with a different e-resource type, the second record is rejected and written to the report file.

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 (the codes) from Voyager are mapped into the indexed internal note 3 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, the 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 instance), 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: Limiting By Location

This section describes the process of limiting a database by location information. Use this option (and associated questionnaire questions) if you have agreed with your project manager that Ex Libris will limit a Voyager database based on location information.

There are three questionnaire questions about limiting by location: OWNING_LIBRARY_OR_LOCATIONS, CIRC_CLUSTER, and COURSE_L IMIT.

Owning Library or Location

The Owning Library or Location limiting factor is used to limit inventory, fulfillment, and acquisition information. It can be used alone or in conjunction with the CIRC_CLUSTER limiting factor.

With this option, you have three choices:

No (default)–migrate all of the data in the listed database
Yes – migrate data only from the list of locations on the Location tab
List value(s) from LIBRARY.LIBRARY_NAME table in Voyager, for example OWN:lib1 OWN: lib2, where lib1 and lib2 are valid LIBRARY_NAME values.

For the last two options (locations on the Location tab or owning library) the Voyager migration programs have a list of location codes to check various data elements. Specifically, in the owning library option, the list of locations is derived from checking the locations associated with the owning library in Voyager location table in the Oracle database.

Inventory

Bibliographic records:

If an owning library is provided, the bibliographic records with the listed owning libraries are included.

If the Location tab is used, a bibliographic record is included if an item/mfhd/purchase order with the included location is attached to a bib. Included locations are those where the location is listed in the location tab and the column "Use in Location Limit?" is set to yes.

The "Use in Location Limit?" question is included because of customers who need to limit locations work as part of a larger location group such when multiple members of a consortia use a shared database. In this case, it is possible that an item in the included limit has a temporary location which is not part of the list of locations used for limiting. For example, the item is permanently housed in library MAIN, but it is stored temporarily in the storage area (STORAGE). You want to include the item, so indicate that MAIN = Yes in this column. You don't want all of the STORAGE items, so you don't want STORAGE to be set to Yes. However, if you don't include STORAGE in the list at all, that temporary location of STORAGE will be caught by the ALMAME_VAL_NOT_FOUND line, which usually indicates an error. In order to display the STORAGE temporary location correctly, include the STORAGE location in this table, but set it to No.

Additionally, if the bibliographic record is in the p2e fil, regardless of location, the record is kept. If the bibliographic record is a standalone bibliographic record, but not in the p2e file, it is not included.

When limiting by location, an extra identifier of the format (yyydb)nnnnn-yyydb is added in an 035 $a field in order to facilitate direct matching of shared bibliographic records during the NZ linking process in Alma.

MFHD/Holdings records:

For all bibliographic records included, there may be cases where a single bibliographic record contains MFHDs from both the included and the excluded location groups. In this case, only the MFHDs from the included locations are exported.

Items:

Items are limited by checking if the item's perm_location is in the list of locations. This means that there can be some cases where the MFHD location is in the limiting list, but the item perm_location is not in the limiting list.

The following situation can happen:

Holding: mfhd loc A

Item 1: perm loc A

Item 2: perm loc B

If A is in one migration for the location limit group, and B is in a different migration form for the location limit group, the result is the following:

Location limit group A: inventory exported

Holding: mfhd loc A

Item 1: perm loc A

Location limit group B: inventory exported

Holding (new): mfhd loc B

Item 2: perm loc B

This logic follows the logic that is described in MFHD Versus Permanent Location.

Issues and E-Items:

Issues and e-items inherit their locations solely from the MFHD; therefore, issues and e-items are migrated only if you are migrating the MFHD to which they are attached.

Alma Location Mapping Tab: ALMAME_VAL_NOT_FOUND

The function of the Alma Location mapping tab is a little bit different for institutions that are using limit by location vs those that are standalone.

For standalone customers, all inventory from Voyager is migrated, regardless of whether or not the location is listed in the Alma Location mapping tab. If the location is not listed, the ALMAME_VAL_NOT_FOUND line is used.

For Limit by Location customers, inventory is only migrated if the location is explicitly listed in this tab, and therefore the ALMAME_VAL_NOT_FOUND line is not used. In this case, there may be inventory which was forgotten because of a missed location and not migrated to Alma.

The ALMAME_VAL_NOT_FOUND line cannot be removed from the location tab, but if you answered LIMIT_BY_LOCATION question in the questionnaire tab using 'Yes', meaning use the location list in the location tab, it will not be used.

Fulfillment

Use the PATRON_LIMIT question on the migration form questionnaire tab to limit patrons by circulation cluster, patron group, or owning library.

If you list circulation cluster codes, patrons are limited by checking if the patron group is associated with circulation cluster.

If you list patron group codes, patrons are limited to the groups listed.

If you leave the PATRON_LIMIT question blank, the migration program still tries to limit patrons by using the patron HOME_LOCATION. Patrons whose HOME_LOCATION is in the list of locations are included in the patron extract. Additionally, if the HOME_LOCATION is equal to 0 (empty), the patron is also included. The HOME_LOCATION = 0 patrons may therefore be included in multiple exports, but this is safer than not including.

Loans, fines, and hold requests:

Loans, fines, and hold requests are migrated based the location information of the associated item record. That is, if an item is on loan and the item is included, then we must include the loan.

External patrons for loans within the limit

If the item is in the included inventory, but the patron is not, the patron is migrated anyway (to preserve the loan), but with a patron group of conv, and their original patron group will be placed in a note on the patron record.

Acquisitions

Purchase orders are migrated based on the CREATE_LOCATION_ID of the order. Invoices are migrated based on the CREATE_LOCATION_ID of the invoice. In both cases, if the CREATE_LOCATION_ID = ‘0’, the order is included. As with patrons, orders and invoices may potentially be included in multiple limited exports, but from a migration standpoint, this is better than not including.

Ledgers, funds, and their associated fund transactions are included if the high-level Ledger location is included in the list of locations. Note that if a ledger does not have a location assigned, the ledger and its associated funds and fund transactions are not exported, so customers should ensure that the ledgers are all assigned a location for a limiting group.

Vendors are included if the vendor was used in the included order or invoice as described above.

Leave all fiscal years on the migration form for validation purposes. If the fiscal year isn't included in the locaiton limit group, we just won't use it during migration.

Course Reserves

Most information can be limited by the library or location codes in the question OWNING_LIBRARY_OR_LOCATIONS, but courses do not have a library or location associated with them. Therefore, we limit by department code in the reading list. List the department codes, separated by a comma, for example SCI, BIO, MUS. Alternately, if all departments have the same prefix, you can enter a single string with an asterisk, for example UI*. It is not mandatory that courses have associated departments, but courses with empty departments are not included when the exporting by location option is used. Additionally, if there is no reading list (that contains the department), the courses is also not included. If you leave this field empty, all courses in the database are migrated to Alma.

Appendix C: Secondary Item File

You may want to provide item descriptive information in a secondary file. For example, you have a description in the format Vol. 12 No. 2 (2015 January), but Alma recommends that enumeration and chronology information are without labels and are in separate fields, for sorting purposes. When enumeration and chronology are in separate fields, you can (for example) limit the view to see all issues for volume 12, based on '12' in the EnumA field.

Voyager has enumeration and chronology fields in the database that are used for prediction purposes in serials, but these fields are not viewable or editable by the customer. For example, perhaps the serial prediction pattern predicted issues as Vol 12 No. 1 (January 2015), Vol 12 No. 2 (February 2015), and Vol. 12 no. 3 (March 2015). If they decided to combine issues 2 and 3, the library staff member may delete issue 2 and then change the item description for 2 to Vol 12 No. 2-3, February-March 2015. The description has changed, but the background Enum and Chron fields have not. We migrate the original enumA=12, enumB=2, chronI=2015, chronJ=2. Since library staff cannot edit the enum/chron fields in the background, we provide customers the opportunity to correct these on migration with a secondary item file, if desired.

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 xls or xlsx format, called secondary_item.xls, and provide it to your Ex Libris representative. This file should be attached to the SalesForce case for the test load or cutover load.

The Excel file should contain 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. If using barcode but not item key, keep this field here in the file but leave it blank.
barcode	Provide either item_key or barcode, but not both. If both are provided, item_key is preferred. If using item key but not barcode, keep this field here in the file but leave it blank.
description	Provide in a format such as: Vol. 12, No. 6 (February 2015).
enumA	Enum and Chron fields should be numerical with no additional text. For example, 12, not Vol. 12.
enumB	For example, 6.
enumC
enumD
enumE
enumF
enumG
enumH
chronI	For example, 2015.
chronJ	For example, 2.
chronK
chronL
chronM

Appendix D: Pre-migration cleanup

The following suggestions may help customers prepare for migration from Voyager to Alma. These are not mandatory; all of the situations will be handled by the migration programs in case you cannot perform this cleanup. However, some customers may want to identify problem spots and address them before rather than after migration.

1. MFHD location and Item location mismatch. See MFHD, perm, and temp location corrections.

2. Remove/correct duplicate item barcodes. See Item Barcodes.

3. Identify duplication of e-resources in Voyager with those from an external e-resource system such as SFX or 360. See Duplicate Electronic Resources.

4. Identify and correct duplicate fund codes or funds without a name. See Fund names and fund codes.

5. Remove funds where are not in use. See Deleting unused funds prior to migration.

6. Check for duplicate codes in vendor records. See Vendor codes.

7. Identify and correct duplicate EDI connection profiles. See Vendor EDI information.

8. Review serial check-ins and consider collapsing. See Serial Issues migration preparation.

9. Check for duplicate course codes in course reserves and consider disambiguating prior to migration. See Duplicate Course Codes.

Appendix E: Universal Borrowing

The purpose of this appendix is to explain the process of migration for Voyager Universal Borrowing (UB) databases.

Ex Libris migrates your Universal Borrowing data only if this service is purchased by your institution and is stipulated in your contract with Ex Libris.

Voyager’s Universal Borrowing provides a structure for reciprocal borrowing between Voyager libraries. In order to facilitate a transaction between a patron in one library, an item in a second library, and a pickup location in a third, Voyager generates a linked copy of the patron record called a stub record in any database where it is needed.

In Voyager, databases are referred to as follows:

Home library – the library/institution to which the patron belongs
Holding library – the library/institution to which the item belongs
Pickup library – the library/institution where the requested item is being picked up
Visited library – the library/institution from which either the remote request is placed OR an item is returned

In the Voyager to Alma UB migration, these are referred to as:

Patron DB – the library/institution to which the patron belongs
Item DB – the library/institution to which the item belongs
Pickup DB – the library/institution where the requested item is being picked up

The migration programs are not concerned with the visited library.

Preparation for Migration from a UB Database

Prior to migrating the UB Voyager databases, customers should run the following jobs:

Pcircjob 6 – Hold recall cancelled notices
Pcircjob 43 – Synchronize Patron Counters for Universal Borrowing. In addition to re-calculating the UB transactions for the home patron, Pcircjob 43 removes legacy UB_HOLD entries.

Customer Input

Questionnaire Tab

Do you have Universal Borrowing in your Institution?

Options:

No – database does not have Universal Borrowing
Yes – migrate all UB
Yes – migrate patron loans and fines only
Yes – Convert stub patrons to regular patrons
Yes – Combine into one institution in Alma

Default: No

Options: Only answer Yes – migrate all or Yes – migrate all except requests if you have purchased UB Migration and it is stipulated in your contract with Ex Libris.

Explanations:

No – if your institution does not have UB in Voyager, then answer No to this question.
Yes – migrate all UB: All Universal Borrowing information is migrated, including cross-institution requests. For more information about this option, see UB Requests During Fulfillment Cutover.
Yes – migrate patron loans and fines only: Migrate UB information but do not include cross-institution requests. This means that stub patrons continue to be linked as a sub-patron to the main patron in a different institution, and patron loans and fines are migrated attached either to the stub patron or the main patron. For more information about this option, see UB Requests During Fulfillment Cutover.
Yes - Convert stub patrons as regular patrons – Select this option if your institution is part of a consortium and uses UB to interact with other members of the consortium, but you are now withdrawing from the consortium. In this case, the UB patrons, loans, and fines, and requests are migrated. However, they are converted to local patrons, loans, fines, and requests, so that you can track them after they are migrated to Alma. There will be no links to other institutions in any of the former UB data elements.
Yes – Combine into one institution in Alma – Select this option if all of the universal borrowing institutions in Voyager will be combined into a single institution in Alma. This option merges patrons based on the stub patron relationship, so that there is a single patron in Alma with all associated loans, fines, and requests. For more information, see Patrons Merging into a Single Institution.

Further Explanation

Outstanding Fine on Item

When there is an outstanding fine or demerit associated with an item in Voyager, the fine is assessed on the stub patron record.

Upon migration to Alma, the item, stub patron, and fine/fee record are all migrated in place.

Additionally, a note is added to the Fine/Fee record indicating that the fine is for a UB (stub) patron.

Item Out on Loan

When an item is out on consortial loan in Voyager, the loan is generated and tracked in the item’s database.

Upon migration to Alma, the loan continues to be kept in the item’s database. A note is added to the loan record indicating that this is a UB loan.

This is not necessarily how Alma manages resource sharing among institutions. This is done upon migration only.

Circulation desk staff should be aware that if the loan is returned anywhere other than the item’s library, there is no way to discharge the item. The item needs to be sent in transit back to the item’s library in order to be discharged.

Items in Transit from a UB Loan

When an item has been discharged at a remote location and is in transit, the migration program sets a technical processing status of Not on Shelf, plus a fulfillment note that says the following:

In Transit Discharged from (sent location), to (receiving location), sent in transit on (shipped date).

Note that the receiving location may not always be the item’s library. The title may be very popular and the item may have been sent in transit to another pickup location.

Request Placed on Item

Only active hold/recall records are migrated to Alma. An active hold/recall record is one that has been trapped and placed on the shelf for pickup or has already been sent in transit to the pickup library. Consequently, call slips are not migrated to Alma. A call slip becomes a hold/recall record after the item is either sent in transit or placed on the shelf for pickup.

When an active request is placed on an item in Voyager, there is a direct link from the hold/recall record in the pickup DB to the item record in the item DB. Also, there is a link from the hold/recall record to the patron stub record, both in the pickup DB.

Upon migration to Alma, a copy of the bib/item is created in the pickup DB and linked to the migrated hold/recall record in the pickup DB. There is a link from the hold/recall record to the patron stub record, both in the pickup DB.

The original item record (in the Item DB) has the following modifications:

<temporaryLibrary>: RES_SHARE
<temporaryPhysicalLocation>: IN_RS_REQ
<temporaryPhysicalLocationInUse>: Y
<fulfilmentNote>: Temporary Item created in <yyydb> for UB Request pickup. Where yyydb is the database name of the destination database.
<baseStatus> to ‘0’ = not on shelf
<processStatus> to TECHNICAL

If the original item had a temporary location, then the original temporary location is placed in a note: Temporary library and location prior to setting to RES_SHARE: MAIN NEWBOOKS.

The owning library needs to reset the temporary library and location when the item is returned from the resource sharing loan.

The newly generated bib, holdings, and item (in the Pickup DB) have the following properties, where yyydb is the database code for the item’s database.

Bib – copy the bibliographic record as is, and
- Add 935 $a (no indicators): <BIB_ID>-<yyydb>
Holding – copy the holding as is, and
- Add 935 $a (no indicators): <HOL_ID>-<yyydb>
- Change 852 $b : RES_SHARE
- Change 852 $c: OUT_RS_REQ
Item – copy the item as is, and
- Change item library to RES_SHARE
- Add <fulfilmentNote>: “Temporary Item created from item_id <ITEM_ID> in <yyydb>.”

The temporary stub items are not contributed to the NZ.

Once the entire UB transaction has been fulfilled, library staff can identify the temporary stub items and withdraw them.

If there are two or more items on the same bibliographic record that need to move to the same remote/pickup database, the bibliographic record and holding records are copied once for each item that needs to be copied.

If an item is in transit to the pickup library but not yet on the shelf, the hold request is created in the pickup library upon migration. After the item is received at the pickup library, the circulation desk staff should wand the item in, and Alma will automatically send a notification to the patron that the item is available.

UB Requests During Fulfillment Cutover

The Alma migration cutover process consists of two extracts/deliveries:

full delivery (inventory, fulfillment, acquisitions)
circulation-only delivery (fulfillment only)

Since the UB requests require temporary bibliographic and item records to be created in foreign institutions, there may be a mismatch between inventory and requests as a result of the time gap between the full delivery and the fulfillment delivery. There are two types of mismatches – requests that have been fulfilled in the interim and requests that have been created in the interim.

Requests that have been fulfilled in the interim
During the full delivery, there can be a cross-institution request:

The Copy of Bib/Item is inventory that is copied and loaded into a foreign institution.

If in the interim, the Hold/Recall request is fulfilled by the patron picking up the item, the situation is the following:

The Hold Record is not migrated because it does not exist at the fulfillment cutover, but the original temporary bibliographic and item records still remain in the pickup location. We cannot remove any temporary bibliographic records in this situation at fulfillment cutover. Temporary bibliographic records created for UB requests need to be cleaned up anyway, so these can be retrieved and deleted post-migration as part of that process.
Requests that have been created in the interim
If a new UB request has been made in the time between the full extract and the fulfillment extract, the new request is not loaded to Alma, since there is no temporary bibliographic record present, so nothing to which the hold record can attach. We do not add more inventory during the fulfillment load. Requests in this situation that are rejected are provided in the normal migration report.

Migration options

You have two options regarding UB requests – migrate UB and include requests or migrate UB, but do not migrate requests. If you choose to migrate the requests, library circulation staff needs to be aware of the above gaps.

If you choose to not migrate the requests, no UB requests are migrated. However, local requests are still migrated, as are UB patrons, loans, and fines.

Patron Records

The original patron records (Home patron records) in Voyager are all retained on migration. Stub records are maintained when they are currently in use for active transactions. Stub records that are no longer in use are not migrated to Alma.

When a stub record is migrated to Alma, the following changes are made:

The middle name has the string (STUB) added to the name, so that the name reads like this: Smith, John B. (STUB).
A note is added to the stub patron record: Stub record copied from: yyydb. Original ID: NNNN where yyydb is the patron’s home database, and NNNN is the patron identification number in the patron’s home database.

Additionally, the master/home patron record and the stub record(s) are linked to each other using the Alma patron linking capability, which is part of Alma’s resource sharing functionality.

Patrons Merging into a Single Institution

When the option – “Yes – Combine into a single institution in Alma” is selected, patrons are merged only using the master-stub relationship. If there are patrons that have the same identifiers, such as barcodes in different institutions this may result in duplicate identifiers in Alma. Alma does not allow duplicate identifiers and these will have to be cleaned up post-migration.

During the merge, the main patron fields the first patron loaded are used in Alma – even if the first patron loaded was a stub patron. This means that only a single user group is migrated. All patrons that have a master-stub relationship have the original user group put into a note on the patron’s record so this information can be referred to post-migration.

All secondary information is kept from each merged patron: addresses, notes, identifiers, fines, loans, and requests. This option includes ALL stub records – in other UB patron migrations, stub records that have no transactions are not migrated. In the merge option, all stub patron information is included in the final merged patron.

UB Databases - Link Patrons

When “UB Databases Tab - Link Patrons" option is set to 'Yes' in the Voyager export, then the tab UB databases is created in the migration form. This tab must be filled out in order to provide linking information between migrated stub and master patrons in Alma. Linking patrons is not required - you may still migrate UB with one of the below three options, and the master and stub patrons will be migrated, but they won't be linked together in Alma.

"UB Databases - Link Patrons" may be used with the following three UB migration options:

· Yes migrate all UB

· Yes migrate patron, loans, and fines only

· Yes combine into one institution in Alma

The UB databases tab appears in the Voyager Migration Form if the Use “Merge Patron” option for UB Customers option is selected in the Voyager AutoExtract menu. See the Voyager to Alma AutoExtract Migration Guide for more information.

In order for Voyager to send and retrieve information between databases, you configure database connections in the SysAdmin module. (SysAdmin > Search > Database Definitions). Since the database definitions are completely local, the names used may not correspond to the actual database code (yyydb) of the remote database. Therefore, migration must have a map that maps the local database definition to the actual database code.

Columns

DB_ID: Database ID of Voyager databases which are related to your own database, pre-filled based on information in your Voyager Database Definitions section.

DB_CODE: Database code of Voyager databases which are related to your own database, also pre-filled.

yyydb: The corresponding ‘yyydb’ code of the remote database, for example ‘myunivdb’. The migration program provides all remote databases that have been defined, and you only have to provide the yyydb code for universal borrowing databases.

Alma four-digit institution code: The four digit institution code assigned to you by Ex Libris. Consult your Ex Libris project manager if you don't know what these codes are.

Appendix F: Error messages

Some error messages are too short to be helpful, so here are some further explantions. This list is not exhaustive.

Inventory

'There were unreadable content/foreign characters in the bib record': Either remove the unreadable character, or replace entire bib record.
MISS_BIB_MASTER_SKIPPED 'Skipped: The input bibid: 473712 is not in bib_master entity': The bib ID was in P2E input file but is either not in the Voyager database, or is suppressed.
852_NOT_MATCH_HOLDING_SKIPPED. 'Skipping because not match of 852 holding': No attached holding record was found in an electronic location. Creating e-resource at bib level.
SFX_BIB_SKIPPED 'Electronic resources management system record discarded': the electronic bib record was discarded because text from the 035a matched text from the migration form, SFX_PREFIX question.

Fulfillment

30868_53885 No items found for request: For request ID 30868, and patron ID 53885, no items were found on hold shelf or in transit for this request.'
883761_417025: No library found in the location tab for request': For request ID 883761, patron ID 417025, hold request pickup location is for a library that is not in this db, or not in the specified location limit. The request was not migrated.'

Acquisitions

'Null PO Number': PO was opened/initiated but not saved. No action needed.
'For invoice id: 46 vendor id equal 0 and have no invoice lines': the invoice was opened/initiated but no lines were added and the invoice was not saved. Invoice not migrated
'Invoice line item price was zero': the invoice line price is 0 or null, and invoice price is also 0 or null. the invoice line was rejected along with with invoice
Fund tx, AMOUNT_0_SKIPPED. We do not migrate fund transacations of amount zero. When the order does not require an amount (e.g. GIFT, DEPOSITORY, EXCHANGE, or TECHNICAL), then we do not need the transaction.
Fund tx, INVOICE_LINE_ITEM_REJECTED. The fund transaction was rejected because the connected invoice line item id was rejected.
Fund tx, BAD_INVOICE_LINE_DUPLICATE. The invoice line has incorrect duplicate fund transaction postings, so the second fund transaction is not posted. This is a result of an internal/invisible bug in Voyager, where there were duplicate entries in the database but only one entry showed in the client. Rejecting this duplicate entry 'fixes' this internal bug.