Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Alma Migration – Combining or Separating Source Databases

    Combining Multiple Source Databases into One Alma Institution

    As part of the move to Alma, it is not uncommon for libraries that currently maintain their own autonomous system/database to decide to consolidate organizationally and join with other libraries into a single shared administered Alma institution when purchasing Alma. There are various options and considerations for these types of data combinations during migration to Alma.
    Generally, the further separated the source institutions are data-wise the better, both in terms of data preparations on the library’s side and potential resulting duplication and/or loss of data. Specific data areas and their considerations are noted below.
    This document generally describes when two merging institutions go live with Alma at the same time.  However, the same principles apply for a new institution which is joining an already-live institution.  See also the separate section Appending to a Production Environment.
    Disambiguating internal identifiers
    If internal identifiers are not disambiguated, data elements will be linked to the wrong entity, for example loans may be linked to the wrong item. 
    When combining multiple source databases into a single Alma institution, it is important to utilize the tools provided by Alma migration to disambiguate identifiers, in all areas of migration: Inventory, Fulfillment, and Acquisitions.  When combining databases from the same same library system, it is possible that a unique internal identifier may overlap unexpectedly with an internal identifier from a different database.  For example, you may have a title with bib key b99878007 in one database and the same bib key for a completely different title in another database.  When the two datasets are combined into Alma, the prefix placed on each key will prevent items being attached to the incorrect bib.
    The bibliographic prefix is placed on the internal identifiers for bibs, holdings, and items. 
    The patron prefix is placed on the internal identifiers for patrons, loans, and requests.  Other identifiers, such as barcode or university ID, are untouched.
    The fund prefix is placed on the fund code and ledger code.
    The above prefixes can be specified in each ILS' migration form.
    In Voyager, there is no need for a prefix for bibs or patrons, since the voyagerdb is appended to the bib and patron identifiers, e.g. 1234-yyydb. 
    Configuration Forms

    It is possible to generate one configuration form from multiple migration forms.  See the Configuration Form Guide for more information.


    Configuration codes

    Libraries/Locations and other data-related configuration codes (library codes, user groups, etc.)  MUST be unique across the Alma institution. The first instance of the code will be loaded. All data referencing that code will be associated with that code.

    For example, if source DB ‘1’ has a library code = MAIN with name Main Library and DB ‘2’ has a library code = MAIN as Mainstream Library, DB ‘1’s library code and name will apply and all of DB ‘2’s data will be associated with this code.
    Bibliographic records/physical inventory 

    De-duplication is not part of the standard migration scope. If there are duplicate Bib records across the source databases, they will all be migrated and remain duplicated in Alma, including each Bib’s related data.

    Item barcodes, specifically, may be problematic if they are duplicated across source databases, as this type of duplication is not supported in Alma and will have adverse effects on fulfillment functions for those items. This is typically very rare, but must be considered in the institution’s preparation. Typical solutions for this scenario are to prefix duplicate barcodes with library-specific codes prior to migrating to Alma.
    Link Resolver E-resources

    E-resources may come from a variety of different places: SFX, 360Link, or manually with the E-Resource Activation form. It is possible to load e-resources from all three into the same IZ, even duplicates from the same place such as multiple SFX institutes.  All three e-resource inputs allow for combining activations, which is very similar to deduplication.

    Combining activations means that if an e-resource is activated in Alma prior to a load, and a new e-resource is about to be loaded, then the loaded resource will be combined with the existing resource.  This works if the two inputs both map to the same Alma KB resource. For example, the migration programs map a 360 KB resource to Business Index in Alma.  360 is loaded to Alma first, so Business Index is activated in Alma.  Next, the SFX migration programs map an SFX resource to Business Index in Alma.  When SFX is loaded second, and the 'Combine Activations' flag is on, then there is only one activation of Business Index after the SFX load.  When 'Combine Activations' is off, then there are two activations of Business Index in Alma.

    The 'Combine Activation' flag works with Available For groups.  For more information and examples, see Multiple E-Resource Input

    When combining activations, and the activations are Activate All, then the final activation is Activate All.  When the activations are Selective, there can be a possibility of duplicate portfolios.  You may choose to deduplicate portfolios or not.  When yes, the portfolios will be deduplicated based on identifier such as ISSN or ISBN. If there are differing local coverage dates, the coverage dates for the first title is used.  No attempt is made to handle different coverage dates.  When no, all portfolios will be activated with no attempt at deduplication.

    Since all P2E resources are by definition local activations, there is no possibility to combine the above e-resource activations with P2E resources.

    Since the P2E jobs are run in Alma after all data has been loaded, the p2e field/subfield parameters for link, note, and provider must be the same for all incoming institutions.  It is not possible to use 856 $z for note for one institution and 856 $y for note for another.  They must both use the same field/subfield.



    The method for deduplicating patrons from multiple systems is by doing a case-sensitive match on the username (also known as the Primary ID). The username in Alma must be a unique value across all other patron IDs. If any patron username exists in more than one of the source databases, the first patron instance will be migrated. Any subsequent duplicate record (based on the same username) will associate any active fines/fees, blocks, or notes with the first loaded patron with that username.  Unique (not already existing) identifiers are also added.  Any additional contact information from each subsequent duplicate user with that username will be rejected. This necessitates that the username mapping for each institution uses the same identifier type during migration to allow this de-duplication of users to occur.  The matching of patrons may also be based on the original ID of the patron, which is an internal identifier in a previous ILS system. Using the original ID as the patron match is only available for customers who do their own programmatic pre-deduplication of patrons.

    When deduplicating patrons, customers have the option to either retain all addresses, or only retain the addresses of the first patron.  Inform your Ex Libris project representative which of these you prefer.

    Matching and upper/lower case

    If you want to deduplicate patrons and the identifiers from different institutions have different cases, for example a1234 and A1234, then the customer should correct these prior to merge so that the cases are the same (i.e. a1234/a1234 or A1234/A1234).   If you have this case, contact your Ex Libris representative so that we can review the data prior to load to ensure a successful match/merge.

    Loans/Fulfilled on hold-shelf Requests

    All loans from all instances will be loaded. If there are loans for the same patron in the different databases, they will link to the single instance of the user record as noted in the patron bullet. This is also true for fulfilled on-hold shelf requests.



    When Acquisitions is in the contractual scope, the fund and ledger codes must be unique for all funds/ledgers across the source databases since the fund/ledger codes in a single Alma institution must be unique. If the codes are not unique, they must be disambiguated before migration and in tandem also make the same disambiguation in any provided related Acquisitions data (orders and invoices). It is recommended, in such cases, for each source database to prefix its fund codes with a unique library-specific identifier. Additionally, the fiscal period cycle must be the same in the source institution (for example, Jul 1 – Jun 30) and must all be migrating the same number of years of Acquisitions data.


    Vendor codes must be unique in each Alma institution. The merging of vendor records is not part of the migration scope. If different source DBs contain the same vendor code, only the first one loaded into Alma and its contents will remain.  The others will be rejected. Any Acquisitions record (order or invoice) referencing that vendor code will link to that instance of the vendor. For instance, if DB ‘1’ has vendor code = EBSCO and DB ‘2’ has vendor code = EBSCO – the details for the EBSCO vendor will be derived from DB ‘1’ only.

    As a special request, you can retain vendor account information for vendors with the same vendor code.   That is, vendors with the same code will always be deduplicated. If no request is made, only the first vendor and its account(s) are kept.  If a special request is made, the accounts for subsequent vendors will be added to the first vendor loaded.


    Purchase order and purchase order line numbers are unique in Alma per institution. If the source databases maintain the same order or order line number, they must be disambiguated prior to migration or only the first instance will be loaded to Alma and the others will be rejected.


    Not all ILS systems can provide full invoice data and this data often is migrated enriched to a related order record. However, when invoices are migrated for certain ILS systems, invoice numbers should be unique in Alma per institution per vendor. If source databases maintain different invoices, but with the same invoice number for the same vendor, they must be disambiguated prior to migration. This case is likely extremely rare.

    Appending to a production environment

    All of the above information applies to situations where a new institution is joining an institution already, depending on the scope outlined in the contract.  Exceptions and clarifications: 

    Acquisitions: Acquisitions is not supported when appending to a produciton environment.

    Link Resolver: Link resolver information cannot be loaded to a production environment, so electronic resources available via link resolver need to be manually activated in Alma.

    Testload and cutover:  The process for loading is a little bit different.  For the testload, the entire live Alma prod environment (configuration and data) is copied to impl, migrated data is appended, customer tests and confirms, and reports problems if there are any.  For cutover, the entire live Alma prod environment is also copied to impl, migrated data is appended, customer tests and confirms. Then, reformatted data of the appended library is loaded to live production environment. 

    Code and mapping tables: Because code tables and mapping tables are customized in a production environment, the migration programs do not load these tables into Alma during a merge.  If there are new codes, they must be manually added to the environment.  This includes: Library, Location, Item type, User Group, User identifier type (for example ADDL_ID_1), or any other code in the migration form maps.

    Separating Part of a Single Source Database into Separate Alma Institutions

    As part of the move to Alma, some libraries that currently share a single system/database with other libraries decide as part of their Alma purchase to separate themselves with full organizational autonomy into their own single administered Alma institution. There are various options and considerations for these types of data separations during migration to Alma.
    The method by which all data areas ultimately get separated is based on each library’s input of library / location codes to filter upon when separating all data areas.
    The details described below are intended only for cases of organizational separation for autonomy and are not intended or supported for data cleanup purposes.


    • Libraries/Locations and other data-related configuration codes (library codes, user groups, etc.) – As noted, each separating library will provide the list of libraries / locations codes with which to ‘cut’ the data. ONLY the data relating directly or indirectly to those codes will be migrated for that particular library to its new Alma institution.
      Setup codes such as user groups will migrate in full from the source institution and will not be filtered or ‘cut’.
    • Bibliographic records/Physical Inventory – Based on the holding and item library/location associations, only holdings and items matching one of the libraries /locations provided will be migrated, including all of their Bibliographic records.
      Any non-matching holding or item or bibliographic record without any holding or item record matching the list of libraries /locations will not be migrated for the specific separating library.
    • Link resolver E-resources – If the e-activations for a particular separating library exist as its own SFX institute or instance, the SFX data can be migrated to its new Alma institution as is automatically. Additionally, if the source link resolver system is a non-Ex Libris link resolver, the flow is essentially standard as in such cases the library must indicate all activations to be performed for the new Alma institution.
      Only if the SFX data is intertwined with another library’s activations in a single SFX institute is there no way to separate the activations. In such a case, there are two options:
      • Migrate the entire SFX institute anyway – and remove/de-activate all irrelevant activations in batch using Alma’s batch e-portfolio delete tools post-migration. This is only relevant if the amount of irrelevant e-activations are relatively small.
        Advantage: Least work intensive during implementation.
        Disadvantage: Results in temporarily offering end-users certain services the institution doesn’t actually license.
      • Migrate the activations via a non-Ex Libris link resolver Excel for the library’s e-activations (do not migrate from SFX).
        Advantage: No irrelevant activations from day 1.
        Disadvantage: More work intensive during implementation. Customer must indicate all activations and forego automatic SFX migration.


    • Patrons – Patrons are filtered based on their direct and/or indirect association with the libraries/locations list provided by the separating library. Depending on the source system, these are the methods supported for separation:
      • Patron’s home library or equivalent associated with the library/location list
      • Patron’s active loan association with items associated with the library/location list
      • Patron’s active on-hold shelf requests for items associated with the library/location list
      • Patron’s outstanding fine/fee balance directly with one of the library/location list
    • Loans/Fulfilled on hold-shelf Requests – Loans and on hold-shelf requests are filtered based on their indirect association with items in the library/location list.


    • Funds/Ledgers –When Acquisitions is in contractual scope, and depending on the source system, the funds / ledgers are filtered based on:
      • Fund/Ledger direct association with the library/location list
      • Fund/Ledger indirect association with an order in the library/location list
    • Vendors – Vendors are filtered, depending on the source system, based on one of two methods:
      • Vendor direct association with a specific library/location in the list
      • Vendor indirect association with a specific order which is associated with a specific library/location in the list
    • Orders – Purchase order and order line data is filtered based on its direct association with one of the library/location list.
    • Invoices – Not all ILS systems can provide full invoice data and this data often is migrated enriched to a related order record. However, when invoices are migrated for certain ILS systems, invoices are separated based on their association with vendors that were migrated and were associated with data relevant for the library/location list.


    • Was this article helpful?