Verde to Alma Migration Guide

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

The purpose of this document is to explain the following:

The input or information that you need to supply Ex Libris in order to migrate your Verde system to Alma
The rules and assumptions that are applied to the Verde data upon migration to Alma

Prerequisites:

Basic knowledge of Alma and Verde key concepts and architecture and the requirements described in Getting Ready for Alma and Discovery Implementation.
Familiarity with the concepts of the electronic migration approach described in the Electronic Resource Handling in Alma Migration.
Verde to Alma migration is supported from Verde 2 in conjunction with SFX 4.12 and later.

This document is intended to be used together with the Verde Migration Form in which you indicate your mapping preferences for the migration process.

Ex Libris migrates your course and acquisitions data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.

Verde Migration Scope

The full Verde scope is separated into three main areas:

Licenses
Interfaces (Vendor-level administrative and access information)
E-inventory fields and linking. (This involves identifying which electronic inventory record (and in some cases which order record) to enrich with Verde data.)

Relevant e-products for which license, interface, and field information migrates:

Package in Verde = Package in Alma
Standalone in Verde =
- Portfolio (with no package) in Alma OR
- Database in Alma
Constituents = Portfolios (part of a package) in Alma
Other e-product types such as print oriented e-prints are not migrated to Alma.

The enrichment process includes the following:
- Linking the license to the relevant e-inventory: package, standalone (portfolio or database), or constituent (portfolio)
- Linking the vendor interface to the relevant e-inventory: package or standalone (portfolio or database)
- Enriching the relevant e-inventory with Verde e-product fields and local fields: package, standalone (portfolio or database), or constituent (portfolio)
- Enriching ILS-originated orders with Verde Acquisition record fields (or e-inventory record fields if the order is not ILS-originated). Verde systems using acquisition fields for orders not managed in their ILS also migrate, but enrich the e-inventory record rather than an order.
- There may be some local attributes or fields configured in your Verde e-product and acquisition fields (for example, non-CKB/global attributes). These local fields are migrated to Alma e-product or purchase order line note fields in Alma.

The electronic inventory which Verde describes (packages, standalones, constitutents) must be represented either in SFX and/or in your current ILS system.

Data from SFX represented in Verde must be active for it to be migrated. Ex Libris does not attempt to link Verde data to any other non-SFX link resolver such as 360Link.

Any non-SFX or non-active SFX originating e-product of types: standalone, package, or constituent must be represented by a bibliographic record in the ILS system and referenced in the Verde e-product with a bibliographic identifier.

Trials, breaches and incidents, costs, and workflows are not currently in the Verde migration scope.

Input Required for Verde Migration

The Verde migration involves the following distinct phases:

Activities done by the migrating institution:
- Downloading the Verde migration package
- Running the Verde migration package menu to:
  - Define your instance code
  - Create an initial Verde input migration form dynamically with your interface and external organization/vendor
  - Extracting raw Verde data using the Ex Libris provided tools
- Sending the output files via FTP
- Completing the Verde Input Migration Form, which includes various required and optional preferences and mappings
Migration activities done by Ex Libris
- Downloading the raw Verde data files and converting them to an Alma-supported format code based on the Verde input migration form
- Loading Verde data to Alma

Downloading the Verde Migration Package

The first step in Verde migration is downloading the Verde migration package.

To install the Verde migration package:

As the root user, download the Verde migration package (VerdeMigrationPackage.zip) from the Ex Libris FTP server to a directory of your choice on your Verde server.
Contact your Alma project manager for access credentials to download this package.
Run (as root):
> unzip VerdeMigrationPackage.zip

Running the Verde Migration Package Menu

The next step in Verde migration is to run the Verde migration package menu.

To run the Verde migration package menu:

Select VerdeMigrationMenu.sh. The following options are displayed:

1. Install Package (must be run as the root user)

2. Define your instance code (must be run as the verde user)

3. Create Initial Verde Migration Excel Form (must be run as the verde user)

4. Extract Verde Data (must be run as the verde user)
As the root user, select option 1 to install the Verde extract package.
As the verde user, select option 2 and enter the Verde instance code that you are migrating. This is a prerequisite to running any other step (as the verde user).
Select option 3, to extract Verde data to an Excel named Verde Migration Form.xlsx with the relevant questions and mappings that must be provided. The form is pre-populated with your vendor and interface codes. For more information on filling in this form, see Verde Migration Form.
Select option 4 to extract the Verde data to flat files which are sent to Ex Libris. This step exports data from the Verde database to the VerdeExtractedData_InstanceCode.zip file, located in the same directory as the Verde migration menu.

Sending the Output File to Ex Libris Via FTP

After producing the output file, send it to Ex Libris via the Ex Libris FTP drop-point as designated by your Ex Libris project manager.

Verde Migration Form

An initial Verde Migration Form specific to your institution is created dynamically on your Verde interface and vendor data and is the starting point for filling in the Verde Migration Form. An empty Verde Migration Form can be found on the Ex Libris Documentation Center for reference.

Migration

The form includes the following questions:

List the instance codes you are migrating from Verde:
For example: abc01
If you use Verde's Acquisition records, are those orders represented in your ILS system? Yes or No
- If you answered yes, are you referencing the POL # or PO#?
  Aleph: Z68 Order number, answer: POL#
  
  Voyager: Order line Number, answer: POL#
  
  Voyager: PO number, answer: PO#
- If you answered no, leave blank.
Which E-Product field value do you use in order to store the Bibliographic identifier source name to be used in case the e-product is not active in SFX?
e-product interoperability field ID source (g_other_source) should store the indication of the Bib identifier system for Verde e-product records not in SFX.

In column D, provide the value of g_other_source which will indicate that the value in the ID source field (g_other_id) is the ILS Bibliographic identifier.

The following is an example of an Aleph bibliographic identifier in Verde.
Which E-Product field do you store the bibliographic identifier to be used in case the e-product is not active in SFX?
e-product interoperability field ID number (g_other_id) contains the bibliographic identifier in combination with an ID source (g_other_source) value denoted in the previous question. No input is required here.
What is your ILS system database name? This is relevant for cases when the e-product is not active in SFX, but is needed in Alma.
For example:
- For Voyager – your Voyager DB name, for example, schoolnamedb
- For Aleph – your bibliographic library code, for example, ABC01
- For other ILS systems, provide the institution code, for example, 01abc_inst

Note: If the e-product is not active in SFX, then the previous three questions regarding bibliographic identifier are of the utmost importance. In order to have purchase orders and licenses link to each other in Alma, they must be linked to some inventory. When SFX is not the inventory, then an ILS bib must be the inventory. Additionally, the ILS bib must be included in the p2e (physical to electronic) migration file.

Verde Interface

This tab contains the Verde interface to vendor code mapping. It determines the relevant Verde vendor code for each localized interface – that is, an interface, package, or standalone that has managed admin or access information. In Verde, a vendor is also referred to as an external organization.

The sheet includes the interfaces that are imported into Alma. The Interface code and name are noted in columns A and B, respectively, as well as related information that might be helpful to find the relevant vendor in Verde (see columns D-I).

The only input needed in this tab is the Verde vendor codes in column C for each noted interface. In some cases, this column might already include the expected Vendor code. In these specific cases, simply confirm that this is indeed the correct vendor to which the interface is related. When it is blank, fill in the appropriate Verde vendor code - the vendor code in column C must be an existing vendor in Verde. Interfaces that are not mapped to any vendor are not migrated - if you want the interface to be migrated, add a vendor code to column C. An interface may appear only once in the list. Vendors that are not related to any interface are still migrated.

The starting point for this mapping is dynamically created from tables in Verde. The Verde Vendor code is listed in column C, and the associated Verde vendor name is in D. Columns E - I contain further information about these vendors/interfaces. When there is an Admin record associated with the interface, you see a code which starts with LAD*. When there is an Access record, you see a code which starts with ACC*. And when there is a Work code, you see CWE*. This may help you decide which interfaces to keep and which to discard.

Verde ILS Vendor Codes

This input is only relevant if you manage the same vendors in both Verde and in your ILS system, but the vendor codes that identify the vendor are different in each system. Indicate in this tab the ILS vendor code to apply for each Verde vendor code in order to avoid duplication of vendor information in the unified Alma system.

If an ILS has different vendors that have the same vendor code and the Verde vendor code is mapped to these non-unique codes, these duplicated vendor codes (starting from the second vendor code) are made unique by adding a unique suffix to them. Verde AutoExtract then matches the Verde vendor code with the single ILS vendor left with the original vendor code. (There is no option to decide which one of the duplicated ILS vendors is left with the original ILS vendor code). The other ILS vendors that originally had this vendor code, but now have a suffixed vendor code, are not linked to any Verde vendor.

Verde to Alma Migration Rules

Licenses

All licenses in Verde are migrated to Alma.

Licenses are implemented in Alma using the DLF-ERMI standard.

License details contain the following main sections:

Core license attributes such as license code, start / end dates, and vendor codes
License codes are the link between e-inventory and the license it references.
Terms (the DLF-ERMI terms that represent the license terms)
License attachments (related file attachments for the license)
Notes

Each vendor referenced by a license migrated to Alma is automatically flagged as a licensor, making it available as a licensor for other licenses in Alma.

All license statuses in Verde map to 'Active' in Alma, with the following exceptions: Retired -> Retired and Rejected -> Deleted

Vendors/Interfaces (Access/Admin/Statistics Data)

Interfaces are implemented in Alma as a vendor sub-attribute and may be referenced by standalone products/portfolios, packages, or databases. In Verde, interfaces are the top level of the e-product inventory hierarchy, while admin and access information may be referenced by the interface or by any other e-product level (package, constituent or standalone).

Therefore, it is essential that Verde interface e-products are mapped to Verde vendors (external organizations). Since this connection is not required in Verde, the connection is made in a mapping file with the columns Interface Name and Vendor Organization Code. This file is completed as part of the Verde migration form as noted above.

All interface or standalone-level admin, access, or statistical information migrated to Alma will reside in the vendor’s interface in Alma. For global e-packages/e-collections in Ex Libris’ CZ/KB, the interface name may not be changed in Alma; however, the information specific to the interfaces from your Verde system are managed and accessible in the Alma vendor interface record and are linked from those e-packages/e-collections in Alma. Each vendor that attains an interface is flagged as an access provider, making it available for use by packages or standalone portfolios.

Admin, access, and statistical information for packages or constituents level e-inventory are not managed in the Alma vendor interface. Therefore, this level of granular information is passed to the e-inventory record itself as referenceable inventory notes.

A special note for handling miscellaneous ejournals: Since in SFX miscellaneous eJournals are managed as a package/target, but in Verde are managed as standalones, it is recommended that a dummy vendor be created for each such standalone which corresponds to a SFX miscellaneous eJournal (and which includes Admin/Access/Stat information localized and needed in Alma). This vendor then needs to be mapped to the standalone's interface in the Verde migration form.

Note that vendor records (organization of type vendor) in Verde that are not associated with interfaces and do not have identical codes from the ILS system are migrated to Alma in their own right as Alma vendors.

The vendor/interface contains the following information:

Vendor/Vendor account details (core vendor/vendor account attributes such as codes and names)
The vendor code is mandatory. It is used to match the vendor code loaded from your ILS. If the vendor codes match, the details from the vendor are ignored, and ONLY the interface section is added to Alma. If the vendor code does not match any ILS vendor code, the vendor information is loaded. In this case, the vendor account is also mandatory - if one is not present in Verde, then one will be created from information in the Verde vendor record. If the Verde vendor code does not match any ILS vendor code, the vendor information is loaded as a new vendor along with the interface.
Contact information/Contact persons
Contact persons are migrated from Verde when the Verde organization contains them. When the vendor organization code exists in the ILS as well (for example, the interface became attached to the ILS vendor and the Verde-stored vendor details were ignored) primary contact information will have already been migrated from the ILS system.
Interface list (one or more interfaces)
The interface name is the match key to match e- inventory to your vendor interface records.
- Admin fields –managed as part of the interface record
- Access fields –managed as part of the interface record
- Statistics fields –managed as part of the interface record
Notes (repeatable)

Since many interfaces are managed in the global knowledge base and reside in Verde to represent e-product relationships, but are not actually managed in Verde, it is important to filter these interfaces from the migration, since they are automatically represented by the Alma community zone, which also contains this information. Therefore, only interface information that has been locally altered/managed in some way in Verde is migrated.

The locally managed interface includes:

Interfaces that have an updated access and/or admin record
Packages that have their own unique access and/or admin record
Constituents that have their own unique access and/or admin record
Standalones that have their own unique access and/or admin record

Since Alma does not support package or constituents that have their own unique access and/or admin record, this information populates an e-inventory note and is not managed as its own Vendor interface in Alma.

A sub-set of interfaces is determined which then populates your migration form, based on filtering all interfaces with the above criteria. Both e-product interfaces must meet the above criteria as well as generate interface records based on package or standalone access/admin occurrences.

Additionally, any interface to organization/vendor relationship that already exists in Verde is exported to the migration form. You must add any interface to vendor relationship that does not exist in Verde already and ensure that the relationships are correct.

The following is the field mapping logic:

All Vendor interfaces are set to active in Alma. They are all part of a vendor, which is either created new in Alma (since it does not have a matching vendor code already migrated from the ILS) or is added to an existing ILS vendor.
Administrative fields go to Alma’s vendor interface admin fields.
Access fields go to Alma’s vendor interface access fields.
Statistics fields go to Alma’s vendor interface statistics fields.
Any local admin/access/statistic field are mapped to the vendor interface note.
When multiple occurrences are allowed in Verde, but not in Alma, the additional occurrences of a field are mapped to the Vendor interface notes section.

For a list of interface linking examples, see Interface Linking Examples.

E-inventory Fields and Linking

Relevant linking of licenses, interfaces, and various inventory and acquisition fields to the appropriate e-inventory is coverted by the E-inventory field and linking process.

E-inventory Identification

The main step in this process is identifying the relevant e-inventory in Alma to which to enrich and link. There are several ways to identify the relevant e-inventory:

An e-inventory record managed and active in SFX. In this case, an SFX ID is present that allows identifying it in Alma (upon SFX migration to Alma).
An e-inventory record not managed or active in SFX. In this case, there are two possible ways to identify an e-inventory record when not managed or active in SFX:
- Based on a Verde ACQ record that is referenced in the ILS via a PO or PO line ID
  This can only be done if the library identified the bibliographic record related to that order as electronic during their ILS electronic identification.
- Based on a bibliographic ID that migrates from your ILS.
  This can only be done in case the library identified this Bib as electronic during their ILS electronic identification.

If no active SFX record exists and the library did not correctly identify its bibliographic records containing electronic inventory in its ILS migration (so they are still physical) or no identification is provided at all, the information in Verde related to these e-products are not migrated to Alma.

License Linking

The following apply to license linking:

Information is managed in the KB/CZ and is already reflected by the SFX migration.
Constituent information inherits information linked to its package, but does not link to that information directly.

Not that all e-inventory managed in Verde has information that is relevant for Alma. This includes the following potential reasons and examples:

A license related to a package whose constituents inherit this license reference in Verde is not considered unique information for the portfolio constituent and is not a sufficient reason to migrate the constituent’s Verde-managed information based on this inheritance to Alma. The license is linked only to the package in Alma.
A license related to an interface in Verde automatically shifts down to that interface’s “child” e-products (packages or standalones) and applies to each as if they had been directly associated with the license in Verde once brought into Alma.
If a license is related specifically to a constituent in Verde, the relationship remains after the license is transferred to Alma at the Alma portfolio level.

If there are multiple licenses linked to an e-product, the best license is selected based on the status code, listed in preferred order:

FINAL_VERSION
APPROVED
SIGNATURE_BY_LICENSOR
APP_LOC
LOCAL_RESPONSE
AWAIT_LOC
NEW

If more than one license has the same preferred status, then the license with the latest Execution Date or End Date is selected.

Interface Linking Examples

The following are interface linking examples:

Description	Result
Interface with three packages. Interface has its own admin/access information. Package inherits the admin/access information from the interface level.	One interface in Alma is related to the vendor of that interface. Each of the three packages link to this vendor interface in Alma.
Interface with three packages. Interface has no admin/access information. Each package has its own admin/access information.	No Interface is created. Each package’s admin/access information in Alma relates to its particular e-package inventory notes.
Interface with three packages. Interface has its own admin/access information. Two of the packages also have their own admin/access information.	One vendor interface based on the Verde interface admin/access information. Each of the two packages’ admin/access information in Alma relates to its particular e-package inventory notes.
Interface with three packages. Interface does not have its own admin/access information. None of the packages have admin/access information.	No vendor interfaces are migrated. If the packages are globally managed in the knowledge base, they indicate the relevant interface information based on the Alma global community zone.

Acquisition Linking Examples

If ACQ records are being used in Verde, the handling depends on whether these ACQ records have an order referenced in the ILS or not.

If they do, the following linking and enrichments can occur:

Allowing the identification of an electronic inventory record if the Verde e-product is not active in SFX. This can only be done if the library identified the bibliographic record related to that order as electronic during their ILS electronic identification.
Allowing enrichment of an order record with various Verde-stored ACQ fields such as subscription and renewal dates or other local ACQ fields.
Linking multiple orders to be related to one another.

If they do not, the following linking and enrichments occur:

All ACQ-fields enrich the identified e-product record’s notes in Alma.

So, essentially there are two primary scenarios:

The Verde acquisition record is linked to a relevant order number in your ILS (for example, the ILS order number is populated in Verde for the ACQ record, the migration form questionnaire indicates you manage ACQ in Verde and the order has an electronic indication via P2E). All Verde ACQ fields are migrated to the POL in Alma in such a case. Certain fields are migrated to analogous POL fields such as Verde Subscription Open Date as the Alma Subscription from date and Verde renewal date as the POL renewal date. The other ACQ fields (including local ACQ fields) are migrated as POL notes prefixed with the field's name.
The Verde acquisition record is not linked to a relevant order number in the ILS (for example, the ILS order number is not populated in Verde for the ACQ record or is linked to an order that is not electronic or the migration form questionnaire indicates you do not manage ACQ in Verde). All Verde ACQ fields (including local ACQ fields) are migrated as POL notes prefixed with the field's name.

E-product Field Linking

There are potentially localized e-product fields that are migrated to Alma. Fields that are globally managed (from the SFX KB) are already migrated and referenced by the SFX migration and CZ relationships. The localized e-product fields are added as package, DB, or portfolio notes in Alma.

For a description of the overall structure of the Verde linking fields, see the ERM Linking Data Definition Excel.