Electronic Resource Migration General
Alma is a unified resource management system, meaning that all types of records like physical, electronic, and digital are managed in the same system. Prior to migrating to Alma, institutions may have managed the different types of records in a variety of different places, and in some cases managed the same resource in multiple places.
This document describes various inputs for electronic resources.
- the different types of electronic resource records that are expected
- how those resources may be duplicated
- how to decide which version of a resource to migrate
- if necessary, how to manage duplication in Alma post-go live
Sources for Electronic Resource records
Generally, electronic resource records may come from any one of the following sources:
ILS: Resources from your ILS which appear to be physical, but actually represent electronic resources. During migration, all resources which come from an ILS are migrated as physical, but some of them, which you identify, can be re-categorized as electronic. In Alma Migration, this is called Physical to Electronic, or P2E for short.
SFX or 360Link: Resources from a link resolver system which is supported by migration, which currently include SFX and 360Link. Link resolver information from these two systems are exported, processed, and the relevant resource is activated in Alma.
Other link resolver: Resources from a link resolver system which is not currently supported by migration. In this case, customers may provide information in the E-Activation Worksheet (an Excel spreadsheet) which will then be loaded into Alma. Information in the spreadsheet will be used to activate packages, portfolios, or databases, along with title information for Selective packages.
Digital Resources: The library may own or manage digital resources, which may be managed/stored separate from the ILS, or they may be represented in the ILS. If resources are represented in the ILS for discovery purposes and also managed separately, this may lead to some duplication in Primo and possibly Alma, depending on migration decisions.
Electronic Resource Management (ERM) systems: ERM systems usually work in conjunction with a link resolver system, such as Verde and SFX, or 360RM/Intota and 360Link. The ERM system manages information associated with the electronic resource, such as licenses and vendor interfaces.
Provider Zone records: Ex Libris has partnered with content providers to enable them to maintain Bibliographic records directly. As part of this process there may appear duplicate bibliographic records for a single item; one supplied by the provider directly and the other managed by Ex Libris. Following community feedback we have released the Alma Direct Ingest Tool which enables direct ingest to the Alma Community Zone without creating duplicate records.
As we make progress with this new tool we will address the existing duplicate records. For more information, see Data Excellence (DX): Introducing Alma Community Zone Direct Ingest for Title Lists.
PQIS resource activations: After all electronic resources are loaded by the migration team, we run an activation process which checks that purchased ProQuest resources are activated in Alma.
EBook Central: Owned, DDA, and Subscription integration will be set during test load for EBook Central customers, starting with testloads beginning after September 2020.
PQIS Activations
When customers purchase resources on PQIS, the Migration team can use the customer's PQIS ID to activate these in Alma. The process activates resources which may have been missed in SFX, 360Link, or the E-Activation worksheet. After reviewing the process in testload, you may request to not activate these for cutover. The PQIS activation may be run by customers post-migration. For more information on the PQIS activation, see My Electronic Resources by Provider.
Automatic PQIS activations do not work with Available For groups, nor do they include proxy activation.
Prior to providing a PQIS ID to the migration team for use in migration, please verify that there are active subscriptions for the customer.
Ebook Central Activations (EBC)
For Ebook Central resources, after initial setup during migration, the process runs on a daily basis.
At the beginning of Alma implementation, the Ex Libris project team requests that the EBC resources are activated for Alma. In the EBC configuration page, Subscription, DDA, and Owned should all be checked for 'ALMA Auto-Holdings'.
After this is set up, the migration team activates the EBC integration profile in Alma, and activates the collection 'Ebook Central Perpetual Subscription & DDA titles', where all EBC resources are placed during the sychronization process. After go-live and the initial synchronization, the EBC synchronization job should be set to be run daily. See Upload Electronic Holdings from Ebook Central for more information.
By default, Ebook central activations are not migrated with SFX nor 360Link, and are not included in the E-Resource Activation Sheet. However, we do not make any attempt to remove local activations created through P2E, so if you have EBook Central collections in your ILS, use the SFX_PREFIX question on the Migration Form Questionnaire tab to remove them during migration.
Available For Groups and EBC: EBC works with multi-campus institutions, as described in Distributed Electronic Access on the EBC documentation page. Generally, create an integration profile for each siteid, and set the AF Group parameter in the integration profile.
ILS Electronic Records Duplicated in Link Resolver or Other System (SFX_PREFIX)
In many cases, institutions create a duplicate representation of their electronic resources in the ILS. Both SFX and 360Link provide a mechanism to load bibliographic records to the ILS. In SFX, this is called MARCIt, and in 360Link it is called 360MARC. Other link resolvers may have similar mechanisms. Additionally, there are other types of resources where the resource is available in an external system and is duplicated in the ILS, such as E-book collections. If you will activate your e-book collections in Alma directly from the source, and you also have ILS records for these e-books, then you will want to consider eliminating these ILS records during migration.
Usually the duplication of resources is for discovery purposes, when the ILS is used as the main discovery platform for the institution. However there may be other reasons, such as ordering and invoicing. In any case, if a customer migrates these resources from both the ILS and the link resolver system, there will be duplicate resources in Alma.
The default migration recommendation is to eliminate the duplication from the ILS migration, in favor of the activations from the source - SFX/360Link/LR/e-book vendor, etc. The primary reason this is the recommendation is that P2E creates local activations only. There is no way to link a P2E-derived electronic resource to the associated Community Zone/Knowledge Base entry. Using the resources that are migrated from SFX, 360Link, or E-Resource Activation sheet will ensure that the resources are linked to the CZ master record and will be updated by the KB team on a regular basis going forward.
Customers may be able to not export bibliographic records which represent duplication during the export process. That is, instead of exporting all bibliographic records from the ILS, you can export everything except these resources which represent duplications.
If a customer is unable to limit the export, they may use the SFX_PREFIX question on the migration form for their particular ILS. Every ILS has this question on the Questionnaire tab. Even though the question is called SFX_PREFIX, it is used to skip bibliographic records with certain strings in the 035. For example, when MARCIt records are imported to the ILS, they have an 035 $awith an internal SFX number, and it usually looks like: (SFX)1234567. Therefore, a typical response to the SFX_PREFIX question is '(SFX)', which means that any record where there is the string '(SFX)' in the 035 $a will be skipped. The text used in the 035 to distinguish 360MARC records is WaSeSS. Multiple strings can be used in the SFX_PREFIX question in the Voyager migration only.
There are two cases where even if the string is found in the bib record, the record is NOT skipped:
- Bibs that have inventory as well. In such cases, the record must be brought as is so as not to lose the inventory.
- MARCIt or equivalently marked records that have ILS orders linked to them.
In both cases, the bib record is transferred to Alma as a suppressed record so that the physical inventory or order information can be migrated also. In these cases, a duplicate SFX, 360Link, or other link resolver system record also migrates to Alma and results in duplication - once from the ILS and once from the Link Resolver. Typically what customers do is manually combine the information on the suppressed bib record with the CZ-activated record post-golive.
Discovery should not be affected by back-office duplication of this type, due to various safe-guards and Primo functionality. For more information, see Managing Duplication in Alma below.
Currently, in Voyager migration, there is an option to include or not include suppressed records in the p2e process with the question P2E_SUPP_BIB. if you answer the question 'Include suppressed bib records in the p2e processing' as No, then the suppressed bib record above will not be included in p2e processing, and therefore no e-resource will be generated for that bib, and the order will remain physical. If you answer the question 'Include suppressed bib records in the p2e processing' as yes, then an e-resource will be generated, the associated order will be transformed to electronic, and you will have duplicate e-resources to manage: one CZ-linked package from 360 or SFX, and one local database/package (non-CZ linked) from the p2e process. For assistance on managing duplications like this, see the "Managing Duplication in Alma" section below.
Examples for SFX_PREFIX
Example 1: Bib + item in Electronic Location
Result: Bib not migrated
Example 2: Bib (no item or holdings)
Result: Bib not migrated
Example 3: Bib + item in electronic location + order
Result: Bib is migrated because of the order, but the bib is suppressed. If the bib was included in the P2E list, then the item in the electronic location may be transformed to an e-resource.
Example 4: Bib + item in Physical Location + item in Electronic Location
Result: Bib is migrated because of the item in the physical location, but the bib is suppressed. If the bib was included in the P2E list, then the item in the electronic location may be transformed to an e-resource.
Package and Portfolio relationships
It is important to note that the package relationships to portfolios are generally not maintained in ILS systems. When an ILS records is sent through P2E, it does not have the parent-child package/portfolio relationship when initially transferred to Alma. Therefore, when deciding whether to keep an ILS record or a link resolver version of the record, the following is true, following migration:
- Package/portfolio relationship information is reflected in records that came from link resolver systems and not from the ILS e-records, which are created by the P2E process.
- ILS electronic record versions typically have order associations (if orders exist) and link resolver system versions do not have orders.
- Identified ILS packages become packages in Alma, but are unrelated to their portfolio constituents. (Packages are also referred to as “Electronic Collections” in Alma. These types of Electronic Collections are typically suppressed and not published to Primo.)
- ILS portfolios identified become standalone portfolios in Alma – at least initially – with no relationship to any package. In many cases, no link resolver system equivalent portfolio exists. In such cases, there should be no issue of duplication and the ILS standalone portfolio will remain as the back-office and delivery master.
- ILS databases identified become databases in Alma. Databases are a type of “Electronic Collection,” and are more likely to be published to Primo and have ViewIt/delivery linking information.
- Link Resolver electronic versions always contain package structure and linking information, and will be the master for structure and linking when analogous records for these resources arrive from the ILS.
- ILS electronic versions that have link resolver system equivalents are the back-office acquisitions master only.
- ILS electronic versions without link resolver system equivalents are the linking delivery master and back-office acquisitions master.
If the ILS has bibliographic records for individual portfolios that are part of a larger package, it is recommended to start managing these resources at the package level in Alma, rather than the portfolio level. Post-migration, you can associate the standalone portfolios that were created as a result of the p2e process with the package (local e-collection) in Alma. The advantages of managing resources at the package level are that any information about the package that changes will affect all resources, such as license and access information. You need only manage this information once at the package level instead of multiple times at the portfolio level. For more information about associating licenses with packages, see ERM Overlay below.
Multiple E-Resource Input
In some cases, either in a consortia environment or in a standalone institution, customers may have multiple inputs for e-resources. For example, a consortia may have multiple SFX inputs, or even inputs from SFX and 360Link and also the E-Resource Activation sheet. In these cases, customers may want to combine activations.
For example, you may have the following inputs, these could be from SFX, 360, or the E-Resource Activation sheet in a single institution, or from the same incoming system, like two 360s or two SFXes.
Institution A
- Business Journals - available for group A
- Science Search - no group (available for everyone)
- Historical Abstracts - available for group A
- Popular Press Index - available for group A
Institution B
- Business Journals - available for group B
- Historical Abstracts - no group (available for everyone)
- Science Search - available for group B
- Literature Studies - available for group B
Options for loading in SFX and 360:
Combine collections: when combine collections is yes, then when the second set of activations is loaded, if there is an existing activation then the new activation (and group) will be added to the existing activation. This is available in SFX, 360, and E-Resource Activation.
Using the above example, the result is:
- Business Journals - A, B
- Science Search - no group
- Historical Abstracts - no group
- Popular Press Index - A
- Literature Studies - B
When Combine collections is no, then there will be an activation for each iteration of the resource.
- Business Journals - A
- Business Journals - B
- Science Search - no group
- Science Search - B
- Historical Abstracts - A
- Historical Abstracts - no group
- Popular Press Index - A
- Literature Studies - B
Note about services using the 'Combine collections' flag: There may be cases where there are different services for the multiple activations. For example, you may have:
SFX: Business Journals, Full Text search - group A
360: Business Journals, Abstract search - group B
In this case, when combine collections is yes, then the following is the result:
Business Journals, a single activation with two services
- Full Text search - A
- Abstract search - B
Deduplicate Portfolios: when the incoming collections are selective activation, meaning all portfolios are listed individually, you may choose to deduplicate portfolios or not.
This is available in SFX., 360, and E-Resource Activation.
- When yes, the portfolios will be deduplicated. 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.
Managing Duplication in Alma
Using information provided in the section 'ILS Electronic Records Duplicated in Link Resolver or Other System' above, most MARCIt records and electronic record bib equivalents are not migrated from your ILS, so much of the SFX or other link resolver system-ILS duplication for serial records is eliminated. If there is order information or item information on these duplicate bib records, the bib record is kept so there can be some duplication to clean up with these records.
However, inevitably, when moving from a multi-system environment to a uniform and consolidated environment, some duplicates remain.
Ex Libris can deduplicate CZ-linked activations as described above in 'Multiple E-Resource Input', but this is only for CZ-linked resources from SFX, 360, and the E-Resource activation sheet. Ex Libris does not automatically de-duplicate electronic inventory identified from the ILS system (p2e) with SFX or other link resolver system counterparts. The main limitations of this de-duplication are due to the fact that:
- Typically source ILS systems do not have enough consistent information in the e-records to determine specific package associations for the e-titles.
- There are a variety of cases where enriched vendor BIB records have been purchased and may not be desirable to de-duplicate.
Instead, the following approach, which involves ViewIt delivery logic and tools in Alma to allow phase-out/management of the duplicates, has been adopted.
- Primo and Alma logic focuses on best ensuring the end-user discovery experience is not affected by any back-office duplication. This is achieved by preferring link resolver and community zone versions of resources for ViewIt linking over an ILS version of the same resource, and leveraging Primo’s robust de-duplication algorithm to further ensure a single result for resources being discovered via Primo.
- Ensure that there is no data loss by making sure that the relevant order/back-office information managed in the ILS remains. As noted, this results in the SFX or other link resolver system version as the master for linking/delivery/discovery and the ILS version as the back-office tracking and management master.
- Alma functions exist for ongoing purposes that allow optional Alma back-office cleanup. This currently includes the ability to:
- Identify the P2E records and build them into sets.
Common ways of identifying P2E-created inventory which may be candidates for suppression or removal:
- Gathering the e-journal portfolios which may not have been marked for exclusion from the ILS:
By Performing an Alma advanced search for:Electronic portfolio where All titles (Tag Suppressed equals "No" and Originating System contains keywords "ILS”) and Electronic Portfolio (Is Standalone equals "Yes" and Material Type equals "Journal").These are likely to be, but are not necessarily, duplicates with a better quality link-resolver system version of the e-resource and can be reviewed and potentially batch deleted or suppressed within Alma.
- Repeating the above for suppressed e-journal duplicate candidates (e.g. changing Tag Suppressed equals “Yes”) that may have been identified for exclusion, but due to other factors such as being linked to an order, are still migrated to Alma.
- Gathering e-collections with electronic type = Package which migrated via P2E which are more often than not simply a placeholder record to link to orders.
By Performing Alma advanced search for:Electronic Collections where All titles (Originating System contains keywords "ILS") and Electronic Collection (Electronic collection Type equals "Selective package").The above 3 cases are the most likely results that can be considered for clean-up consolidation post go-live. Some common actions that may be taken for them:Remove order or license linkages from the duplicate e-inventory record (usually the ILS electronic record would be considered duplicate if an SFX or other link resolver system equivalent also exists for the resource).
- Identify the P2E records and build them into sets.
- Re-link any information (orders, licenses, Bib) to the “master” link resolver/CZ inventory record and deleting/suppressing the duplicate version:
- Editing the e-resource via editor and find the appropriate e-order and/or license with which to associate the inventory record and populating the PO line ID field and/or license field (for e-collections/packages this is from the General tab and for portfolios from the Portfolio Information tab)
- Finding the PO line via the PO line search and using the “Change Bib Reference” function to associate the order with the e-inventory record’s BIB record.
- Delete the order/license relationship via the e-inventory editor of the extraneous duplicate inventory record.
- Delete the duplicate e-inventory resource.
At this point, only the master version remains as the full management, linking, and structural master of the resource in Alma.
Even if you do not want to delete the records you may still want to suppress the record from discovery. Via set building, the Suppress Bib records from discovery job can be run in order to batch suppress the relevant records.
ERM resources
In cases where ERM system data is included, dependent on the scope of work with Ex Libris, it needs to be added or overlaid such that the appropriate resources are identified. Links from a migrated ERM system require an identifier – such as OrderId, SFXid or other link resolver system ID, and/or ILSBibId – that can link to the relevant resource and update it with the ERM-stored electronic resource-specific information.
It is expected that all e-resources managed in the ERM are reflected already in some way in the ILS and/or link resolver systems (in some cases, perhaps only as a suppressed bibliographic record). In addition, it is expected that all e-orders managed in the ERM are reflected in the ILS system.
Ex Libris migrates your acquisitions data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.
Identify e-resources for ERM enrichment (when relevant, based on your scope agreement with Ex Libris). Depending on your ERM system, the main match point may be with the Alma CZ via SFXid/Alma KB id, and/or with information loaded from the ILS (OrderId or BibId). In either case, the incoming ERM information is loaded by matching to the ERM reference in Alma.
ERM information includes:
- Licenses and their associations
- Interface/vendors and their associations, including localized access/admin information
- Enriching e-resources with key, localized e-inventory information
- Enriching related ILS order information with key acquisition record field information, such as subscription dates, renewal dates, vendor reference number, and order relationships and repeatable notes.
ERM enrichment is recommended primarily for individual portfolios that are not part of any package, and for packages. It is not recommend for portfolios that are managed as part of an e-collection or package.
For more information on migrating ERM resources into Alma, see ERM to Alma Data Delivery Specification.
Digital Repository Records and P2E
In general, digital repository records that are owned and/or managed by the institution in a digital management system should NOT be included in the P2E process from the ILS.
For example, a library can create bibliographic records in their ILS for a locally-owned digital resource and include an 856 link to the repository object. This appears to be an electronic resource in the ILS because of the 856 link, but the digital object will most likely be included in a pipe to Primo. If the bibliographic record from the ILS is included in P2E, this will result in duplication in Primo.
If the digital resources that are on a bibliographic record contain item or holding records, they should be withheld from migration or deleted in Alma immediately after migration to avoid having them be false “P” or “E” in Alma.
Digital inventory can be integrated with Alma using standard Alma tools following go-live.
Usage statistics (SUSHI)
Ex Libris migrates usage statistics from two places: USTAT (Aleph) and COUNTER (360). Configuration of SUSHI is not included in migration; SUSHI is configured on the vendor record. Since vendors are loaded once at testload and then not loaded again for cutover, any SUSHI configuration made on the vendor is retained during cutover.