Alma Migration – Combining or Separating Source Databases
Combining Multiple Source Databases into One Alma Institution
Disambiguating internal identifiers
Configuration Forms
It is possible to generate one configuration form from multiple migration forms. See the Configuration Form Guide for more information.
Inventory
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.
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.
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.
P2E
Fulfillment
Patrons
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.
Acquisitions
Funds/Ledgers
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.
Vendors
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.
Orders
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.
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, 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
Inventory
- 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.
- 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.
Fulfillment
- 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.
Acquisitions
- 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.