Skip to main content
  • Subscribe by RSS
  • ExLibris Dev

    Alma Migration Considerations for Consortia


    This document describes the process for providing and processing records into a shared consortial environment in Alma from various legacy ILS systems.
    There are two zones within Alma:
    • Network Zone (NZ) – combined database of shared bibliographic records
    • Institution Zone (IZ) – local institutions that contribute records to the NZ and share records previously contributed by other members
    Typically, the Institution Zone institutions have a political / organizational connection to each other, such as statewide universities under a shared economic umbrella.
    Catalog records are bibliographic in nature and are often shared across members in the network zone. In some cases, there may be a need for localized only records that are not shared across members, but are maintained privately at the institutional zone level.

    Catalog Records

    There are two main types of central network zone catalog migration processes:
    • New Shared Catalog: The site did not work with a central catalog before implementing Alma. The site may have contributed records to a shared discovery tool, but the actual cataloging maintenance was done separately. In this case, individual IZs are loaded to the IZ first, and then the Alma IZ-NZ linking process is run to populate the NZ.
      The services involved for this process can vary from site to site and should be discussed with your Ex Libris representative.
      In this scenario, the site ensures that there is a single standard shared identifier (such as OCLC ID or other standard ID) across the records in order to allow the Network Zone to be populated and de-duplicated based on this defined identifier. Typically, the largest members’ relevant records are contributed to the Network Zone first, and smaller sites either link to already contributed records or contribute their unique records. Only records with relevant matching criteria are considered for contribution and linking.
    • Previous Shared Catalog: The site worked with a central shared cataloging environment before implementing Alma. Here, the shared catalog is provided at the beginning of the migration process, and it is loaded to the NZ first. The IZ cataloging records + administrative data (inventory, fulfillment, and acquisitions) are loaded and linked subsequently. The IZ-NZ link is generated without using the Alma IZ-NZ process as described above: the linking is done outside of Alma. While this linking closely resembles the Alma IZ-NZ linking process, it is not exactly the same. Instead of using 035 fields, the migration programs instead rely on a single shared identifier, usually in the incoming 001 field.


    Inventory consists of holdings and item records from your source ILS as well as electronic resources from your electronic link and resource management systems, such as SFX and Verde.
    Print inventory is managed at the institutional level. Initially, all records (bibliographic, holdings, items, patrons, orders, etc.) are loaded into the individual IZ.
    The methods used for the New Shared Catalog and the Previous Shared Catalog types are explained in different sections, since they are not exactly the same.

    New Shared Catalog

    This section describes the print inventory process for sites using the IZ-NZ linking job in Alma, where the sites previously had separate cataloging environments.
    After an IZ is loaded by migration, an Alma process runs that compares the IZ bibliographic record with records in the NZ based on the defined shared identifier. The process checks each IZ bibliographic record against what exists in the NZ:
    • If an identifier exists and a matched record is not found in the NZ, the IZ record is contributed to the NZ and becomes the master NZ record.
    • If a match is found in the NZ, the IZ record is linked to the master NZ record.
    In this way, the NZ is populated with de-duplicated records contributed from its members.
    The IZ maintains the Alma bibliographic record identifier (MMS ID) of the original IZ record in order to provide a base to which all other administrative data linkages (holdings, items, orders, loans) can attach.
    Once a bibliographic record from the IZ is linked to an NZ master catalog record, changes to the master are automatically reflected in all linked bibliographic records and all members linking to it. Localization of each linked IZ record is optionally supported via a defined set of supported local extension fields.

    Local Extensions (MARC)

    Consortia members who share bibliographic records may still want to maintain some local information in their IZ record. This can be accomplished through the use of local tags.
    Tags in the MARC 09x, 59x, 69x, and 950-999 ranges that are marked with subfield 9 LOCAL are saved in the IZ as local extensions to the master bibliographic record. Tags that are not in these ranges, as well as tags in these ranges that are not marked with subfield 9 LOCAL are not saved in the IZ. Sites can identify any tags in 09x, 59x, 69x, and 950-999 ranges that they want to keep locally, make sure they are in the specified ranges, and then mark them with a subfield 9 with only the word LOCAL (no spaces, punctuation, or any other characters) when providing the institutional IZ level records.
    For local fields in NZ or IZ: if local fields are used, Ex Libris recommends that the NZ use fields 900-949 and the IZ uses 950-999. This way the local NZ fields (900-949) are those that are local to the entire consortium where every institutional member uses them, and the local IZ fields (950-999) are those that are local only to the single institution. This is recommended because it is important to be able to retrieve groups of records based on data in specific local fields, and having the same local field used for two different data elements may cause problems in retrieval. During migration, if a 900-949 tag has $9 LOCAL subfield, it is removed and the tag is kept in the NZ.

    Local Extensions (Unimarc)

    For bibliographic records using Unimarc, the local extensions operate the same way as MARC local extensions, except that the ranges are defined as XX9, X9X, and 9XX.

    Contents of the NZ Record

    During the migration process, the contents of the NZ record are the contents of the first record of the group. When a record is added to the NZ and no match is found, the record (without local extensions) is added to the NZ and the local extensions are added to the linked IZ record.
    When a subsequent record is matched to the NZ record, the subsequent record’s local extensions are saved to the linked IZ record, and all other tags from the subsequent record are discarded in favor of the first-in NZ record.


    The NZ linking programs use values in the MARC/UNIMARC/KORMARC 035 $a and 035 $z fields to determine a match. Note that control field 001 in Alma is reserved for the Alma internal Bib ID (MMSid), so migration processes ensure moving any previously existing 001 content to 035 $a or 035 $z.

    Numbers in 035: Non-OCoLC

    As a rule, the exact string in the 035 $a or 035 $z fields are used for matching. For example:
    • (NhCcYBP)40015704661
    • (CaOOAMICUS)000026217529
    • (Gale)ESTCN6838
    Exact string matching is done for the above numbers, but not for OCLC numbers which have unique and special prefix handling.

    Numbers in 035: OCoLC

    The OCLC numbers are often inconsistent.
    If an OCLC number has the prefix (OCoLC), remove the prefix ocn, ocm, or on from the number portion of the OCLC number, and use only the value in parentheses to compare. This means that the following are considered equivalent:
    • (OCoLC)12341234 is the same as (OCoLC)ocm12341234
    • (OCoLC)567856789 is the same as (OCoLC)ocn567856789
    • (OCoLC)23456789 is the same as (OCoLC)on23456789
    This is accomplished by a normalization routine as described below.

    Normalization Flow

    035a and 035z = 'OCLC Identifier' Normalization Flow:
    for each
    MARC "035"|"a" AND MARC "035"|"z" value as '(Prefix)'||'ID'
    normalize lower_case '(Prefix)'||'ID'
    normalize OCLC prefix ('Prefix') for (ocolc)' OR '(oclc)' AS '(ocolc)'
    remove initial zero padding ('ID')
    remove OCLC padding ('ID') for 'ocm' OR 'ocn' OR 'on'
    For example:
    • 035 |a (OCoLC)41319586 is normalized to: (ocolc)41319586
    • 035 |z (OCoLC)ocn41319586 is normalized to: (ocolc)41319586
    • 035 |a (OCoLC)ocm00041319586 is normalized to: (ocolc)41319586
    • 035 |a ocm00041319586 is normalized to: (ocolc)41319586
    • 035 |a (NotOCLC)00099556677 is normalized to: (notoclc)99556677

    Multiple Matches

    Matches and linking is only executed when there is a single match in the NZ. If there are multiple bibliographic records found in the NZ that match the record attempting to link based on the chosen single shared identifier, the record is not considered a match. The case here is if a single 035 in a single incoming IZ record matches multiple records in the NZ.
    The results of this matching is that the record IZ is reported as a multi-match and is not linked to the NZ. Using Alma tools, this type of outlier duplication in NZ central catalog generation can be rectified and re-linked in smaller batch sets post-migration.

    Multiple Incoming Identifiers

    If the incoming IZ record has multiple chosen identifiers, the linking program looks for matches from all identifiers. If only one match is found in the NZ from all of the possible identifiers, the record is a match. However, if multiple identifiers from the incoming records each find a match in the NZ, the record is not considered a match.

    Matches Within the Same Institution

    There may be multiple matches of records within the source file of a single institution when duplicate records with different source bibliographic IDs exist in the previous system (relevant usually for sites that did not work centrally before moving to Alma). This type of duplication within a single institution is not handled by migration, and in such cases, the duplicate (second and subsequent) matches will not show in the local IZ holdings list - only the first matched record will show up.
    In other words, all of the duplicated records in the IZ are linked to the NZ record, but only one of the duplicate records show holdings in the NZ.
    IZ -> NZ: all of the duplicate records in IZ link up to the NZ appropriately – that is, you can search for a record in the IZ and click up to the correct NZ record.
    NZ -> IZ: if you search in the NZ for this title, the holdings from the first duplicate IZ record shows only as being held by that institution. The only way that all of the holdings for the institution to be shown from the NZ is if all IZ holdings are on a single bibliographic record.

    Records not Contributed to the NZ (for New Central Catalogs)

    Some records do not contain the type of ID key relevant for contribution to the NZ during migration of new central catalogs. These records are usually:
    • Migration-generated boundwiths (where the linkages are built based on IZ specific inventory)
    • Other local institutional records that have no relevant ID

    Suppressed Records

    When building the NZ, it is typically recommended that all shared catalog records are not suppressed so that each IZ can decide on its own to suppress behavior. That is, each IZ linked to a central catalog record can decide to suppress it for its own purposes. Suppression in Alma can also be done at the holdings administrative level as well, when needed. In this case, when records are exported to Primo, the bibliographic record is exported, but no services (holdings) are listed as being available. Only when a shared catalog record is definitely to be suppressed for all members equally should Bib-level suppression be used in the central catalog.

    Links Between Records

    There are three methods for providing links between two records in a consortial environment in Alma.
    • Relationships are built based on the standard MARC/UNIMARC/KORMARC linking fields between bibliographic records. One direction of linking is sufficient to create the bi-directional linkage, meaning that only one of the bibliographic records needs a tag.
      In order to see More Info related records in Alma, the bibliographic record and its target linked bibliographic record must exist in the active institution in which you are working in Alma. That is, if both bibliographic records linked together are in the NZ, a "More Info" link is displayed. If only one of the two bibliographic records is in the institution in which you are working, the More Info link is not displayed in Alma.
    • Alma's end-user services menu (GetIt and ViewIt) do bring in relationships across the consortium, however. That is, if the Alma resolver does not find a related record match in the Institution Zone, it searches for matches in the NZ as well. If it finds a match in the NZ and that match has related records, the Alma resolver searches the IZ for the record that links to the related record found in the NZ.
      The services menu approach is intended to be used via Primo only where all services are offered.
    • It is possible to enrich the standard Bib-level link with an additional pointer on the Bib linkage to the level of an item in the target record by putting issue information into the $g subfield with the following prefixes:
      • No – provide the specific chronology A OR barcode of the linked item
      • yr – provide the YYYY year of the linked issue
      • iss – provide the issue # of the linked issue
      • p – provide the specific page of the linked issue
    For example:
    • Linking to journal issue to specific item via barcode:
      773 18 $$tJournal of Neuroradiology.$$w(MaFC)003379300 $$gno:34990398830
    • Linking to journal issue to specific item chronology in specific year and issue on specific page. This requires the appropriate fields (like CHRON_I) in the item record to be filled in:
      773 18 $$tJournal of physics.$$w(MaFC)002274900 $$gyr: 1975 $$gno:22 $$giss:3 $$gp:35-49

    Previously Shared Catalog

    This section describes the print inventory process for sites loading the NZ first, where the sites previously had a single shared cataloging environment.
    The migration team loads the entire shared deduplicated set of bibliographic records to the NZ before any other IZs are migrated. The bibliographic records in the IZ are matched against the NZ bibliographic records, using the single shared bibliographic identifier of the previous system, usually in the 001.
    • If a match is found in the NZ, the migration programs create a local IZ record with just the local extensions and load that to the NZ.
    • If no match is found in the NZ, the migration programs load the entire record to the local IZ. This is unlikely but possible depending on the functionality of the previous system.
    There should not be any multiple matches in this case. Local extensions are defined here the same way they are defined in the Load IZ first section above.

    Links Between Records

    With the Previous Shared Catalog method of creating the NZ by loading the NZ first, links between records continue to work the same as described above in the New Shared Catalog section. However, keep in mind that when loading the NZ first, there is a possibility for bibliographic records without inventory to NOT be represented in a local IZ.
    When using the New Shared Catalog method where the IZs are loaded first, if there is a bibliographic record without inventory in the local IZ, it gets merged to the NZ. The local IZ maintains the representation of that bibliographic record in the IZ.
    When using the Previously Shared Catalog method where the NZ is loaded first, if there is a bibliographic record without inventory that was provided in the local IZ file, a representation of the bibliographic record will NOT be made in the local IZ if there is no inventory or no local extensions.
    Therefore, if there are bibliographic records without inventory that need to link to other bibliographic records in the local IZ, the bibliographic records should either have inventory or have a local extension tag. This local extension might be very small and insignificant such as the institution code in a single subfield.

    Local Authorities

    Alma stores the Library of Congress name and subject authority records as well as the Medical Subject Headings (MeSH) in the Community Zone among additional authority types that are consistently being added and enriched as part of Alma’s commitment to data services.
    Local authority record conversion is not part of the migration scope of Alma. If you have locally created or modified authority records to load into your local institution, use the standard Alma loader tools post-migration. In a consortial setup, they likely reside in the Network Zone for sharing across members. Contact your local Ex Libris project team for consultation if this is relevant for your institution.

    Electronic Inventory

    In some cases, consortial sites share electronic inventory in their source systems. When this is the case, migration allows customers to provide the specific e-activation data relevant for the shared network and can define the relevant “available for” institutional availability for these shared resources. In other words, the migration team loads electronic inventory into the NZ and then the customer sets the permissions for each local IZ that should have access to the resource.
    When the above is not yet relevant or cannot be determined prior to implementation, the default migration path is for each institution to provide its specific activations to the local IZ to ensure that all institutionally available electronic resources stay available to its users immediately. In such cases, adopting a shared electronic availability workflow can be setup after moving to Alma by activating these shared resources in the NZ, indicating the relevant IZs with which to share it and de-activating the previously local activations in the relevant IZs.


    The goal of the fulfillment migration process is to allow new Alma customers to keep track of items immediately post-migration. The migration programs do not attempt to migrate fulfillment data into the Alma Resource Sharing workflow.
    After migration, as customers begin to work in Alma, new transactions are created using the Alma Resource Sharing workflow and old transactions are closed out as items with previous workflows are returned.


    It is very common for patrons to have duplicate patron records at various institutions in a consortium. If the legacy ILS has linking information that allows for the migration processes to create a link between records, the migration program attempts to link the records when loading into Alma. There are two kinds of patron records:
    • Master patron – the patron record of the patron at their home institution
    • Stub patron – a copy of the patron record for use at visited institutions
    Alma expects to have linked patron information when the same patron is represented in multiple institutions. There are three types of relationships between master patron and stub patron records: those with a clear link, those without a clear link but with a common identifier, and those with no link or common identifiers. The type of relationship that the master patron and stub patron records have determines how the records are migrated.

    Clear Link

    If there is a clearly defined link between the master patron and stub patrons, Ex Libris recommends:
    • Migrate all master patrons
    • Migrate only those stub patrons that are necessary for maintaining a link to active loans, requests, and fines/fees. The extracts delivered should provide only the stub patrons that are in use.
    Post-migration, Alma customers are able to generate new stub patrons in visited intuitions when the workflow requires it. The migrated stub patron records can continue to be used in Alma, depending on customer desires.

    Common Identifiers

    If there is not a clearly defined link between the master patron and stub patrons, but there is a common identifier that is used by patrons across institutions, the migration process attempts to link the patrons using a common identifier. In this case, it is likely that all stub patrons are migrated. Post-migration, Alma customers can identify linked patrons that are not in use and purge them using Alma patron management tools.

    No Link or Common Identifiers

    If there is no link or common identifier for multiple patron records, the only option is to load records individually into Alma. The new flow can be adopted for new shared patron transactions after moving to Alma.

    Loans, Requests, and Fines Linked to Patrons

    Active Loans

    For migration, active loans are loaded into the same institution as the item. Post-migration, if an item is returned at a different institution, circulation desk staff needs to direct the item back to the item’s home institution in order to discharge the loan.

    Requests/Holds on the Hold Shelf

    For all migrations, only those requests that are on the hold shelf waiting for pickup are migrated.
    There are two options for migrating requests on the hold shelf:
    • Make a copy of the bib/item in the pickup DB. In this case, the copy of the bib/item needs to be cleaned up in Alma after the transaction is complete.
    • Migrate the request record to the item’s DB. In this case, if the pickup DB is different than the item’s DB, when the customer comes into the library to pick up the item, the hold/recall record may not be accessible to staff members in the pickup DB (depending on permissions).

    Active Fines and Fees

    For migration, active fines and fees are loaded into the same institution as the item, which is where the loan transaction took place.


    There is no consortial aspect to courses. They are all loaded into the individual institutions (IZ).


    Although there are some joint acquisition workflows involving central negotiated licenses on behalf of consortial members and their related electronic ordering of negotiated licensed material, since joint acquisitions in source ILS systems are extremely rare, migration focuses on best allowing customers to make use of Alma’s shared ACQ workflows after moving to Alma and does not build shared license/ordering workflows during migration. This involves suggesting sites use common vendor codes across the consortium, where necessary, so that migration can leverage Alma’s ability to share global vendor information.
    All purchase orders, invoices, and funds/transactions are brought into individual institutions in Alma. Purchase orders are linked to local inventory records and not directly to records in the Network Zone, although the vendors and inventory-related bibliographic records may be shared.


    Vendor record information can be shared across institutions in Alma, or they can be maintained locally.
    There are two options for loading vendor records into Alma:
    • Provide a global vendor file and corresponding local vendor files. Alma does the following:
      • loads the global vendor file in the NZ
      • loads the local vendor files into the IZ. In the process, Alma attempts to connect a local vendor to the global vendor by using a matching vendor code
        • If a global vendor is found, the local vendor inherits all of the global vendor properties.
        • If a global vendor is not found, the local vendor stands alone in the IZ.
    • Provide vendor files for each institution, with no link to other vendors. Vendors are loaded into each institution individually, as illustrated in the Non-shared vendors section in the diagram above.
    • Was this article helpful?
    // feedback widged