- 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
Institution B patron groups
Bib record match and merge
Bib record merge is supported during institution merge. Bibliographic records are merged based on identifier matching, using the same match routines as are used by the “Link NZ records” process. The current matching options are:
- Unique OCLC Identifier match method
- Extended Fuzzy Serial Match method
- Active 035 (other system identifier) match method
- Title statement Extended Fuzzy serial match method
- 001 to MMS_ID match method
- ISSN match method (exact subfield match)
- ISSN/024/035 match method
- ISSN (exact subfield match)/024/035 match method
- 035 (other system identifier) match method
- 024/035 match method
- ISSN match method
- LCCN Serial Match Method
- Fuzzy Serial Match Method
NZ: If the institutions being merged are all linked to the same NZ, then the above options do not apply, and the only way bib records are matched is if they are both linked to the same NZ record. Effectively, the match routine is the match routine used for NZ matching.
After equivalent records are identified, they are then merged. In the following description, we use the term 'master' record: the master bibliographic record is either the record in the primary institution if one was present, or from the first bib record moved into the primary institution in case there is no matched record in the primary institution.
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, and the $9 LOCAL subfield is removed
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, 760, 762, 765, 767, 770, 772, 773, 774, 775, 776, 777, 780, 785, 786, 787, 856, 950-999. If these tags have $9 LOCAL in them, then they will be added to the master bib record and the $9 LOCAL removed.
Unimarc local tags: 09X, 59X, 69X, 950-999.
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.
Item barcodes must be unique across institutions.
Item process types are migrated as follows:
ACQ -> not transferred
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
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.
Patrons are matched using the primary identifier only. Patrons with the same primary identifier are considered equivalent.
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 main section of the master patron record is retained. From the incoming patron record, active fines/fees, blocks, notes, identifiers, statistics, demerits, and optionally contact information are moved to the master patron. Customers have the option to either retain all contact information, or only retain the contact information of the master patron. Contact information includes address, phone, and email.
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 correct 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 are NOT scrubbed, which 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. Therefore, customers in test mode should be careful during testing to not practice sending e-letters.
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.
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.
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 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 a match is found, then the incoming vendor code is prefixed when moved to the primary institution. Incoming vendor codes which do not find a match are not prefixed.
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.
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.
All incoming license codes are given a prefix. There is no option to merge licenses.
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.
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.
The following reports are available
|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.|