Guide to Merging Alma Institutions
Overview
- Customer makes decisions on data
- Ex Libris performs test merge
- Customer evaluates merge, provides feedback
- Ex Libris performs cutover merge
- Customer approves merge
Customers are encouraged to read this entire document well before the merge process to help prepare their data for merging. Some data elements must be modified prior to merging, and some data elements are not retained.
Deciding on the Primary institution and Merge Order
One of the first decisions to make is which institution is the primary institution and which institution(s) will be secondary. The secondary institutions will merge into the primary institution. Therefore, certain data elements in the primary institution are preserved where the same elements in the secondary institutions are lost/not moved.
Examples of data which are not moved from secondary to primary:
- All record history, usually located on the 'History' tab of most data elements
- Records which are marked as deleted are not moved.
- Data elements specifically mentioned in this document as not included in merge are retained in the primary institution. Examples of this are Inactive patrons, or staff user roles
- All configuration, for example Fulfillment and TOU policies, Metadata search configuration, Reporting codes
Ex Libris generally recommends that the largest institution be designated the primary.
In this document, the Primary institution is sometimes referred to as institution A, and the secondary institutions B and C.
If there is more than one secondary institution, determine the order for loading. The order is important in cases where an entity is not present in the primary institution but may be present in more than one secondary institution. This is important in bibliographic, patron, and vendor records merge.
Configuration and codes
Customer codes and configuration are not disambiguated nor are they transferred from a secondary institution to the primary institution. This includes, but is not limited to:
- Library codes
- Location codes
- Item Type codes
- User Group codes
- Configuration elements
- Metadata configuration such as search indexes, barcode generation prefixes, import and export profiles
- Fulfillment and TOU policies, User block definitions, notifications such as overdue notices
- Fiscal periods, Acq Reporting codes, currencies
Therefore, customers must:
a) ensure that the codes and configuration do not overlap in the data itself. If they do overlap, it will not be possible to distinguish the different sets of data with the same code post-merge.
For example, if institutions A and B both have a user group code of UNDG, when patrons are merged together, all patrons will continue to have the user group code of UNDG. If customers later want to distinguish between UNDG patrons from A and UNDG patrons from B, they cannot rely on the user group code to distinguish.
If you want them to have the same shared code, you can leave the data as is. However, if you want to be able to distinguish the two groups post-merge, change the codes in at least one of the sets of data. Using the example above, change the UNDG code in institution B to BUNDG or something along these lines.
b) transfer all configurations to the primary institution. All codes and configuration must be manually created in the primary institution.
Institution A patron groups
STAFF
UNDG
FAC
Institution B patron groups
BSTAFF
BUNDG
BFAC
Therefore, patron groups BSTAFF, BUNDG, and BFAC must be added to the primary institution. Additionally, all Fulfillment policies and Terms of Use must be re-created in the primary institution for these groups.
Special currency correction
If there are more than one default currencies in the different institutions, after the merge the master institution has two default currencies. Customers or Professional Services staff should select the correct default currency and remove the other one(s).
Inventory
Bib record match and merge
Customer should select whether to match by NZ link id or by Solr Search match. Match by NZ link id can be done only if Primary and Secondary institutions are linked to the same NZ.
Match by NZ link id
• If Secondary record is linked to CZ, try to match Primary record by CZ link id (Primary and Secondary records should have the same CZ link id). If match is not found, copy Secondary Bib to Primary institution.
• If Secondary records is not linked to CZ and linked to NZ, try to match Primary record by NZ link id (Primary and Secondary records should have the same NZ link id). If match is not found, copy Secondary Bib to Primary institution.
Solr Search match
The Solr Search uses two parameters: serial and non-serial. For a list of Solr Search match types, see "Serial Match Methods" and "Non-Serial Match Methods" sections of Managing Import Profiles page.
• If Secondary record is linked to CZ, try to match Primary record by CZ link id (Primary and Secondary records should have the same CZ link id). If match is not found, copy Secondary Bib to Primary institution.
• If Secondary record is not linked to CZ, try to match Primary record by using selected Serial Match method/Non Serial Match method. If match is not found, copy Secondary Bib to Primary institution.
Merging
When the incoming merged record is added to the master record,
a) if an incoming tag has $9 LOCAL, the tag will be added to the master/merged record. The $9 LOCAL is retained.
b) all other tags are discarded in favor of the master record. In other words, if no tags have $9 LOCAL, then the record from the incoming institution is discarded completely after the match is performed
c) MARC Local tags are: 09X, 59X, 69X, 770-789, 009, 035, 9xx, and any field which ends in 9 (e.g. 119, 529, etc)
Associated inventory (item, holding records) is moved to the master bibliographic record.
Updated MMSID: The MMSID of any record in the primary institution is retained; the MMSID of records from the secondary institutions are replaced with a primary institution MMSID. For secondary institutions, the previous MMSID is saved in the originating system ID. Also, a map of old MMSID -> new MMSID is provided to customers post-merge, for use in API updates if relevant.
Further, information on new, matched, and deduplicated bibs can be requested.
Items
Item barcodes must be unique across institutions.
Item process types are migrated as follows:
TRANSIT, WORK_ORDER_DEPARTMENT, ILL, HOLDSHELF -> set to TECHNICAL
LOAN, LOST_LOAN, LOST_LOAN_AND_PAID -> re-created during merge based on the transferred loan records
ACQ -> re-created during merge based on transferred acquisitions information. If no acquisitions is merged, then this is not migrated.
Electronic Inventory
Electronic inventory refers to either a collection or a portfolio.
Electronic inventory which is not linked to the CZ, also called local, is uses the same match/merge process as described above for physical resources. The local electronic resources continue to be electronic in the primary institution.
Electronic inventory which is linked to the CZ moves in the following manner:
Match: any resource linked to the same CZ record. If a match is not found in the primary institution, the resource is activated in the primary institution.
Move: customers may choose one of two options:
a) combine collections: at the end of the merge, there is only one activation for these resources.
b) do not combine collections: at the end of the merge, there is an activation for each institution which had the resource.
Further, information on new, matched, and deduplicated collections and portfolios can be requested.
Fulfillment
Patrons
Customers may choose whether to match/merge patrons or not. If matching, then patrons are matched using the primary identifier only. Patrons with the same primary identifier are considered equivalent. If not matching, then if the primary identifier is already present in the master institution, then the incoming patron record is rejected.
If an incoming patron does not find a match in the primary institution, it is added completely. Similar to the concept of the 'master' record in the description of merging bibs, if a patron from a secondary institution is added to the primary institution because there was no matched patron, then that newly added record becomes the master patron record in terms of merging.
If an incoming patron finds a match in the primary institution, it is merged in the following manner:
The master patron record is retained. From the incoming patron record, active fines/fees, blocks, notes, identifiers, and statistics are moved to the master patron. Contact information is not moved from the incoming patron record.
If the master patron record exists but is marked as 'deleted', then the master patron is actually deleted and then incoming record is moved as new.
Patron identifiers must not be duplicated in the same patron. If a patron is matched and both the master and the incoming patron have the same identifier, the incoming identifier is not moved.
Patron identifiers also must not be duplicated in the same institution, on different users. The following case is not handled:
- Patron from Institution A
- Primary Identifier: 123
- Barcode: B999
- Patron from Institution B
- Primary Identifier: 345
- University ID: B999
The above two patrons are not matched/merged, because the match point is always Primary Identifier and 123 does not match 345. The secondary identifiers (Barcode and University ID) are not compared to other patrons, so the duplicate identifier of 'B999' is moved to Alma when the patron from B is added as a new patron. Alma does not allow duplicate identifiers anywhere, so the customer must correct the situation either before or after the merge. The situation may be corrected by:
- modifying one of the identifiers manually, either before or after the merge
- merging the two different patrons in Alma using Merge Patron job
Staff roles are not moved.
Patron emails may be scrubbed during test load only, if customer selects to do so. Scrubbming emails is a practice used during migration which deactivates patron emails so that any test e-letters which are emailed out are not actually sent to a real email address.
Further, information on matched and rejected records is available (See 'Statisitcs' below). There is no report on merged patrons; since the patrons are matched on primary ID, the primary ID continues to be the method of retrieval for merged patrons.
Non-Patron Fulfillment
Active and completed loans are moved from the secondary to the primary institution.
Fines and Fees are moved as part of the patron. Closed Fines and Fees (of amount 0) are not moved.
Regular requests and resource sharing requests are not moved.
Course Reserves information is not moved.
Acquisitions
The Acquisitions merge is available with the January 2023 release.
Provide a prefix for acquisitions information for each secondary institution, for example 'AB-'. This prefixes all of your fund codes so they are like 'AB-books' and 'AB-serials'. Additionally, the prefix is used if vendors are not merged and there is a duplicate incoming vendor code (see 'Vendors' section for more information). The prefix is used to disambiguate the POL_REFERENCE in purchase orders if necessary. Finally, the prefix is used to disambiguate license codes.
Funds and Ledgers
All institutions must have the same fiscal period. If the fiscal periods differ slightly, incoming fiscal periods are modified to fit the primary institution.
All incoming fund and ledger codes are given a prefix so that there is no overlap with the funds and ledgers of the primary institution. There is no option to merge funds and ledgers.
Vendors
Vendors can be merged based on the vendor code, or they can not be merged at all.
If you do not wish to merge vendors, provide a prefix for all secondary institutions: if not merging, then all incoming vendor codes are prefixed when moved to the primary institution.
If you wish to merge vendors based on vendor code:
Vendors are considered a match if the vendor code is the exact same
After matching vendors are merged in the following manner:
The main section of the master vendor record is retained. From the incoming vendor record, accounts, payment methods, served units, vendor and account contacts, and notes are added to the master record. Further, if there is an existing vendor interface with the same name on the master vendor, then the interface is not copied. Interfaces which do not already exist on the master record are copied.
Inactive vendors are not moved.
Purchase Orders and Invoices
Deleted purchase orders and invoices are not moved
Cancelled POs and Invoices are moved, but no attempt is made to place them in the proper Alma workflow.
Purchase requests are not moved.
The PO Access Model is not brought over, so customers can update electronic POs with 'Update PO Lines Information' job.
Purchase orders and invoices attached to inactive vendors are not moved.
Purchase order line numbers (POL_REFERENCE) are disambiguated using the Acquisitions prefix.
Invoice numbers do not need to be disambiguated since they are associated with a vendor.
Licenses
All incoming license codes are given a prefix. There is no option to merge licenses.
Other Considerations
Analytics
Because historical data regarding records is not transferred from secondary to primary, analytics in the post-merge environment contains only the history of the primary institution.
Network Zone/Consortia
When the institutions being merged are part of a consortia with a network zone (NZ), the migration team removes the secondary IZ(s) from the 'Held by' list in the NZ once the merge is complete.
The merge process retains the link to the NZ for inventory, so a re-linking of IZ-NZ should not be necessary. In other words, if a bib record in a secondary institution is moved to the primary institution as is because no match was found in the primary institution, the bib is copied over along with the link to the NZ record.
Statistics
The following reports are available
| Report | Info |
|---|---|
| New Bib Records | New bibliographic records in the primary institution. |
| Bib records matched by Search | When records in a secondary institution found a match in the primary institution using the specified match method (not CZ or NZ matching). Relevant for institutions previously NOT linked to the same NZ. |
| Bib records matched by CZ Link | When records in a secondary institution found a match in the primary institution because both were linked to the same CZ record |
| Bib records matched by NZ link | When records in a secondary institution found a match in the primary institution because both were linked to the same CZ record. Relevant for institutions previously linked to the same NZ only. |
| Bib records matched by MERGE_RECORD_ID | There are not usually very many of these. When a bib in the secondary institution was previously merged. |
| Electronic collections deduplicated by CZ link | When e-collections in a secondary institution found a match in the primary institution because both were linked to the same e-collection in the CZ. |
| Electronic portfolios deduplicated by CZ link | When portolios in a secondary institution found a match in the primary institution because both were linked to the same portfolio in the CZ. |
| Patrons deduplicated by Primary ID | The list of patrons in a secondary institution where a match was found in the primary institution. |
| Patrons rejected | Patrons which could not be moved to the primary institution because no primary ID is present. |