Alma Digital Migration

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

Alma Digital Migration Data Delivery Guidelines

Migration Overview

If you have contracted with Ex Libris for an Alma Digital implementation project that includes migration, then use this document as a guide for how to export your data in the expected format.

The procedure for migrating from a previous DAM system to Alma consists of the following steps:

Extracting the relevant data elements from the existing system into files (customer).
Preparing the data elements for loading into Alma (Ex Libris).
Loading and processing the transformed data into Alma (Ex Libris).

Migration Questions

Preferred metadata schema for Alma-D Collections: DC, MARC21.
Preferred metadata schema for Alma-D BIBs: DC, MODS, MARC21.
Metadata validation during migration:

• MARC: data must be MARC21 compatible.

• MODS: data must be compatible with MODS v3.7.

• DC: local fields should be defined in Alma before load using DC application profiles
In what Alma library will your digital inventory be stored?

• Controls staff roles scoping.

Incoming Systems

DigiTool

Migration Flow:

Ex Libris migration tool extracts digital collections and digital entities (including files) from your DigiTool system. The tool is installed locally on the DigiTool server (SSH access from Ex Libris IP to your DigiTool server is required). The migration tool will extract the entire digital repository, as one extract that contains metadata records and their associated files. The extracted files will be uploaded to your intuitional AWS storage (as part of your Alma digital service), please refer to AWS client installation for more information on accessing AWS directly.

Ex Libris project team will need your input regarding the following information:

Metadata formats used in DigiTool (DC/MARC/MODS) and the preferred metadata format to be used in Alma. If cross-walk is required, you will need to provide the XSLT file for this transformation.
Were collection metadata digital entities (entity type="COLLECTION") maintained in DigiTool? If yes, please inform your Ex Libris representative.
If you are using a remote storage in your DigiTool server, please inform your Ex Libris representative.

CONTENTdm

Migration Flow:

Ex Libris migration tool will harvest CONTENTdm file streams using APIs. It is required that all migrating collections will be publicly available before the migration process starts.

Customer Input:

The migration tool does not extract the metadata information. Therefore it is required to provide the metadata XML files, one XML file per collection.

The file name should be the collection ID in CONTENTdm and the format should be "CONTENTdm standard XML".

Information about expected export and format of the file can be found here:

https://help.oclc.org/Metadata_Services/CONTENTdm/CONTENTdm_Administration/Collection_administration/090Export_metadata?sl=en#CONTENTdm_Standard_XML

The expected output of CONTENTdm standard XML is Dublin Core. Non standard fields (not part of Dublin Core schema) can be mapped to proper Dublin Core fields.

(In case a different metadata scheme is required, XSLT for the cross-walk should be provided by the customer).

Islandora

Migration Flow

Ex Libris expects the Islandora data to be provided in the FOXML file format (objectStore directoy) and the file streams (datastreamStore directoy) from your Fedora installation. Data can be archived into tar.gz files for convenience of uploading to Ex Libris cloud. The data should be loaded to the Alma institutional AWS storage see further details in Appendix A.

Ex Libris migration team will process the provided metadata and files and prepare ingest folders to be loaded to Alma (See ingest). Collections entities are provided as digital entities within the export. Ex Libris migration tool can create an EAD file that represents the collection hierarchy. All migrated collections will reside under one top-level collection, this can be changed post migration.

Customer input

Expected data should include the following elements:

datastreamStore/* - compressed archives of all the files (bitstreams) stored in your fedora datastream store.
objectStore/* - compressed archives of your FOXML files from your fedora object store.
nnnn_MODS.tar.gz - a compressed archive of all of your MODS XML metadata files, organized in a folder structure representing your collection hierarchy (this is for convenience and redundant to the copies of the MODS files in the datastreamStore archives).
nnnn.sql.gz - a postgres sql dump of the drupal and fedora databases (Ex Libris migration team does not use this file, thus it can be omitted).

Note:

Alma supports standard MARC, MODS and DC. The metadata format that is provided will be used for loading to Alma, if cross-walk is required, you will need to provide the XSLT file for this transformation. Non-standard fields should be mapped to local fields (For DC: DC application profiles can be used).

Islandora Content Models

Islandora Content models Ex Libris has previously migrated to Alma-D:

islandora:collectionCModel
islandora:sp_basic_image
islandora:sp_large_image
islandora:sp_pdf
islandora:sp_audioCModel
islandora:sp_videoCModel
islandora:bookCModel
islandora:pageCModel
islandora:compoundCModel

If your Islandora data contained any additional Islandora content Models (or customized ones) that are not in this list, please inform your Ex Libris representative.

Simple Objects

Islandora simple objects such as sp_basic_image, sp_large_image, sp_pdf etc, may include more than 1 file. During migration grouping of files into Alma representations is done based on the file extension. For example, if a simple object such as islandora:sp_large_image contained a Tiff file and a Jpeg file, in Alma, there will be 2 representations created, one for for the Tiff file and the other for the Jpeg.

Note that the migration tool does not migrate the medium size derivative of sp_basic_image object that had an OBJ Jpeg file. Also, the proxy MP3 derivative is not migrated for an sp_audioCModel that had an OBJ MP3 file.

Complex Objects

For Islandora complex objects such as compoundCModel and bookCModel the metadata record is taken from the parent record only. Any metadata related to the children of the complex object is discarded. If you think you had specific metadata that was managed only at the children level please inform your Ex Libris representative.

The RELS-EXT data stream (AKA Fedora Object to Object Relationship Metadata) is used for determining the parent-children relationship. Specifically the tags fedora:isConstituentOf and islandora:isSequenceNumberOfxyz_nnnnnn are used for determining the children of compound object and the tags islandora:isPageOf and islandora:isSequenceNumber are used for determining the children of a bookCModel.

Same as for simple objects, during migration grouping of files into Alma representations, is done based on the file extension. For example, all book pages with a specific file extension, e.g., tiff will reside in one representation. There may be additional representations according to the number of different file extensions.

Note: Ex Libris migrates all derivatives from Islandora, part to the two mentioned ones (medium_size and proxy_mp3). If there is a desire not to migrate a specific derivative, e.g., JP2 files, please inform your Ex Libris representative.

Appendix A – AWS Client Installation

In each AWS region, all customers have a “bucket” (S3 storage location) refer to Amazon S3 Regions and Buckets for specific information on your region.

To directly access files in S3, an access key and secret are needed. Access keys are managed in Alma from Resource Management > Resource Configuration > Digital Storage.

The S3 storage location can also be used for delivering the migration data. The following two third-party tools can be used to directly interact with the Amazon S3 storage:

AWS command line interface
S3 Browser or MSP360™ Explorer, 3rd-party FTP-like interfaces