Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    360 and Intota to Alma Migration Guide

    Introduction

    Ex Libris, a ProQuest company, provides data migration services to Alma from the following 360/Intota suite of products:
    • Electronic database and title activations: 360 Core/Link
    • ERM: 360 Resource manager (360RM) and Intota
    • COUNTER: 360 Counter reports
    Ex Libris migrates your ERM data only if this service was purchased by your institution and is stipulated in your contract with Ex Libris.
    This includes automatic migration of major 360 / Intota elements:
    • Electronic activations (databases/e-collections and titles) – 360 Core/Link
    • Electronic licenses – Intota/360
    • Electronic Vendors, Vendor interfaces and contacts – Intota/360
    • Linking key ERM data elements to database/e-collection level e-resources
    • COUNTER: Reports described as supported in Managing COUNTER-Compliant Usage Data
    This document explains:
    • Extraction requirements from 360 / Intota
    • Input required by the customer
    • Rules and Assumptions about the migration to Alma
    • An explanation of the Link Resolver Activation Report

    Related Documentation

    • This document is intended to complement the Intota to Alma Migration Form, an Excel spreadsheet that is read by the migration programs.
    • Prerequisites: Basic knowledge of Alma and 360/Intota key concepts and architecture, and the requirements (including the migration-related approach) described in the Getting Ready for Alma and Discovery Implementation document, as well as the Electronic Resource Handling Approach in Alma Migration document.
    • For more information on COUNTER data, see 360 COUNTER and Intota Assessment Migration.

    Migration and Activation Overview

    Migration from 360 Core/Link is consists of the activation of Alma KB resources which most closely match the existing 360 KB resources.    Since the 360 KB and the Alma KB are created based on different principles, it is not possible to directly the migrate the 360 KB resources into the Alma KB.  Instead, the migration programs look at the list of 360 packages and create a list of the matched packages in Alma.  In many cases, there can be many 360 packages that match a single Alma package.  It is less common, but still possible, that a single 360 package maps to multiple packages in Alma.  
    After the Alma packages are identified, the Alma resource is marked as 'Activate All' or 'Selective' based on the 'We subscribe to only some resources in this db' flag from 360.  if the Alma resource is 'Activate All', then all titles that Alma lists for that package are activated.  No attempt is made by the migration program to compare lists of titles between the 360 KB and the Alma KB for a database/package.  If the package is listed as 'Selective', then the list of titles associated with the package in the 360KB are uploaded for activation in Alma.  If the list of titles between the 360 KB and the Alma KB do not match, the list of titles will not match.  When the title is not present in 360 but present in Alma, the Alma title will fail to be activated.  When the title is present in 360 but not present in Alma, the migration may load the title as a local activation (not linked to the CZ) if there is enough identifying information, or not activate the title at all. 
    Do not modify the default bibliographic record template until after go-live. If the default bib record template is modified prior to the E-Resource Activation Load, extraneous fields may appear in the bib for locally created portfolios.
    When 360 Link is migrated, then the package activation as described above is performed.  Vendors, Licenses, and linking is not included in 360 Link migration.
    360 RM/Intota data is migrated if included in the contract. 360RM/Intota migration requires the 360 link migration/activation as described above.  360Rm/Intota migration includes:
    • Licenses
    • Vendor interfaces
    • ERM enrichment (includes linking e-collections to licenses, and enriching matched e-collections and/or purchase orders with relevant ERM-managed fields)
    Intota ERM/360 RM links to electronic resources only if the electronic resources are migrated from 360 Link.  No attempt is made to link licenses or vendors in Intota ERM/360RM to resources from other link resolvers, such as SFX.

     

    Naming Conventions

    While there is much overlap between Alma and 360/Intota Electronic Resource management, there are some differences, especially in naming conventions.
    Alma - 360/Intota Comparison
    Alma Definition 360/Intota
    Electronic Resource An information source that the library provides access to in an electronic format and where the content is not managed by the library. Electronic Resource
    Community Zone (KB) The Alma Community Zone contains the electronic KB where globally shared descriptive resource metadata and electronic resources for use by all Alma clients. Knowledgebase
    Portfolio The specific coverage, services, and link information relevant for a particular electronic title within a database/electronic collection. Title
    Electronic collection A collection of electronic resources. Replaces “database” and “package.” Also called e-collection in Alma. Database
    Local electronic collection A collection of electronic resources that is managed by the Institution (not in the KB). Library Specific Holdings
    Electronic collection An electronic collection which happens to have no specific managed titles/portfolios. Zero-title Database
    No direct analog (Searchable note tagging on e-collection instead) A grouping of databases (electronic collections) Collection
    Vendor A person or organization that sells, gives, or licenses resources to libraries Provider
    Vendor Interface An Alma record associated with a vendor for tracking back-office information about a vendor’s site, including access information, usage statistics harvesting, contacts, notes, etc. Platform (details of which may be tracked at the Provider or Database levels)
    Contact A person or business unit associated with a vendor. Contact
    License (DLF-ERMI) Terms by which electronic resources may be used. License (DLF-ERMI)
     

    Exporting files from 360/Intota

    Customers should export files from 360 or Intota using their administrative interface. In both the 360 Client Center and the Intota main page, there is a link for "Management Reports". All of the reports mentioned can be run from the Management Reports page. 
    Once the report has completed, download the report to your PC, and transfer them to the Ex Libris secured SFTP (MFT) site along with your ILS migration file delivery.  There is only one available export format, which is *.csv, and that is the format expected by Ex LIbris. Do not open or edit the files in Excel prior to sending to Ex Libris.

    Link Resolver (360Link) Files

    Ex Libris migrates 360 Link Resolver tracked resources and databases automatically, based on the Tracked Resources and Database Details reports exported from 360/Intota. 
    The files involved in 360Link migration are:
    • Database Details Report
    • Tracked Resources Report OR Tracked eBooks + Tracked eJournals reports: In the Management Reports Dropdown box, if you see "Tracked Resources Report", use that report. If you do not see "Tracked Resources Report", then export both "Tracked eBooks" and "Tracked eJournals" reports.
    Provide these files at the same time that you provide your ILS migration export files.

    ERM (360RM or Intota) Files

    The files involved in migration from 360RM or Intota to Alma are:
    • Contacts
    • Cost Report - Details
    • Database Details Report 
    • License Information Report
    • License Data Uploader
    • Notes and Comments
    • Tracked Resources Report (only. Tracked eJournals and Tracked eBooks is not allowed here)
    • Resource Administrative Information
    • Resource Renewal Report
    360Link resources must be migrated along with License and Provider information from the ERM in order for all resources to link together in Alma.

    If desired, it is possible to migrate only licenses, which link to inventory, and not migrate the vendor interfaces or the ERM enrichment.   In this case, simply provide the two license files (License Information Report and License Data Uploader).  All of the other files may be provided or not provided as desired.

    360 Link Migration 

    This section is relevant both for customers migrating only 360 Link (Databases and Tracked Resources) and for customers migrating Intota/360RM.  Intota/360RM migration requires 360Link migration as part of the migration.
    As stated above in the migration overview, migration of 360 KB to Alma KB consists of activating resources in the Alma KB that are the closest match to the 360 KB resource. There is not a 1-to-1 relationship between resources in the two different KBs.
    Also as stated above, after the specific Alma e-resource is identified as the comparable e-resource, then the Alma e-resource is either marked as Activate All or Selective, depending on a few factors.  See also the 1-to-many description below, and the Activate All vs Selective description below.

    Loading Options 

    There are a few options that customers can consider when migrating from 360Link to Alma.  

    Combine activations (Yes/No) - When Combine Activations is set to Yes, if there are multiple E-Resource sources, then activations in the second input form will be combined with the existing activations in Alma.  This options works even when the previously loaded activations are from a different e-resource system, such as SFX.  For more information on this, see Multiple E-Resource Input, and also the "Multiple Institutions" section below.

    Deduplicate Portfolios (Yes/No) - when Combine Activations = Yes, then if both activations are Selective (BY_TITLE), then portfolios in the packages will be deduplicated.  Please note that if the multiple portfolios have different date ranges, only the date range from the first portfolio will be used.

    Match by Title (Yes/No) - When a package is Selective (BY_TITLE), and the titles listed do not have an identifier such as ISSN or ISBN, then the loader can attempt to find a match by comparing the exact title of a portfolio with the titles of the portfolios in the specified package.  The title is an exact match, including punctuation, so 'Biology.' does not match 'Biology'.   Match by title is not attempted when an identifier is present but fails to find a match.

    The match by title option can currently process 10,000 titles per hour, which may add a significant amount of processing time to your overall migration timeline.    If you have 400,000 titles without an identifier, this could add 40 hours to your timeline. 

    If you wish to use one of these options, inform your Ex Libris representative so that they can inform the migration analyst.

    Active Databases in 360

    Databases are considered active if at least one of the following fields is Y:
    • Display in 360 Core
    • Display in 360 Link
    • Display in Summon

    If ALL three of the above are N, then this database is considered not active and will not be activated in Alma.

    The migration programs do not use the incoming 'status' column in Tracked Resources.

    Notes

    Notes at the database or title level are not currently migrated in 360Link-only migrations.  Notes from both databases and titles are migrated to the associated Vendor record if the site is also migrating 360RM/Intota ERM.

    360Core KB vs Alma KB and 1-to-many

    Because of differences in each product history, the 360Core KB generally has more entries than the Alma KB.  For example, if a publisher/provider offers 10 different options for packages from basically the same superset of resources, the 360KB team, generally speaking, usually added each of those packages individually as separate databases.  The Alma KB team, on the other hand, had one e-collection (database) and then individual resource selections would be made by selective activation of the superset of resources available in the e-collection.  So for this set of 10 packages, there might be 10 entries in the 360KB which map to 1 entry in the Alma KB.  This is referred to in migration as 1-to-many (1 Alma KB - many 360 KB). 
    Using a fictional company called BioChem, here is an illustration of the above paragraph.  
    BioChem has a limited set of resources, journals in the BioChem area.  Over they years they have repackaged these resources to sell to different markets, giving each package a different name.
    The Alma KB team has a single resource called BioChem.  The subsets of resources (packages) would be added to the BioChem entry with selective activation for the reduced set of resources.  The Alma KB doesn't add new entries for subsets of resources.
    The 360 KB team has added a new resource for each iteration that BioChem provides. So, 360KB might have these resources:
    BioChemSm for small libraries
    BioChemBig for large libraries
    BioChemPub for publics
    BioChemCovid super sale from 2020 Covid 
    BioChemAcad for academic libraries
    BioChemAll all resources 
    The 360KB entries likely would be classified as 'We subscribe to some of these resources' = No (meaning, activate all), because the resources are package-specific.  However, when these resources are transferred to Alma, they transfer to the main BioChem entry and switched to Selective.  In the above fictional list, the BioChemAll would likely transfer as Activate All.
    Because the 1-to-many situation is very common, customers will almost always see fewer activations in Alma than they saw in 360/Intota, even if all databases map to Alma.   To see which Intota/360 database(s) were mapped to an Alma e-collection, look in the Alma interface at the electronic collection main page.  Check the 'Provider package code (DB id)' at the top of the Electronic Collection page. In the image below, three databases (88V, 89A, and C3E) mapped to a single collection in Alma.
    dbcodes_from_3602.png
    While it is not possible to search Intota/360 by the database code, these codes are easily seen in the Intota/360 administrative interface and can be helpful to know which Intota/360 databases migrated to which Alma E-collection.

    Activate All vs Selective Activation (title identifiers)

    360Link has a field which is called 'We subscribe to only some titles in this database', which is roughly equivalent to the Alma KB activation flag.
    'We subscribe to only some titles... ' = Y   translates to Selective Activation, or 'By Titles'.
    'We subscribe to only some titles...' = N    translates to Activate All.
    Sometimes, because of the common 1-to-many situation described in the previous section, something that was 'We subscribe to only some titles ...' = N (activate all) in 360 is actually implemented as Selective activation in Alma.    This can happen if the titles in the 360 database are actually a subset of available titles in the corresponding Alma collection of titles.
    When Activate All databases are activated in Alma, individual titles do not need to be loaded.  All titles associated with the e-resource in the Alma KB are activated.  No attempt is make to compare the list of titles defined in 360 KB with the list of titles defined in the Alma KB.
    When Selective databases are activated in Alma, individual titles must be loaded and activated individually.  The key that the migration programs use for activating an individual title against the Alma KB is an ISSN or ISBN.  When a title does not have an ISSN or ISBN, then it is not possible to perform a title activation.  Examples of titles which may not have an ISBN or ISSN are titles that were published very long ago, or titles which are not officially published.   Further, if the ISSN or ISBN in 360 is faulty for some reason, for example if the same ISSN is used for multiple titles, migration cannot guarantee proper activation in Alma, since the activation is dependent on proper identifiers.
    When the package is listed as 'Selective', then the list of titles associated with the package in the 360KB are uploaded for activation in Alma.  If the list of titles between the 360 KB and the Alma KB do not match, the list of titles will not match.  When the title is not present in 360 but present in Alma, the Alma title will fail to be activated.  When the title is present in 360 but not present in Alma, the migration may load the title as a local activation (not linked to the CZ) if there is enough identifying information, or not activate the title at all. 
    For a list of titles from Selective databases which cannot be activated due to missing identifiers, see the section below, "Titles for Matched Selective DB Without an Identifier".
    For an explain about titles from Selective databases which have an identifier from 360 but do not find a match in Alma, see the section below, "Titles which have an identifier in 360 but no match in Alma". 

    Dates, Embargo periods, and URLs

    Dates/Embargo periods and URLs are only transferred for portfolios which are loaded for a Selective Activation e-collection. When an e-collection is Activate All, titles are automatically activated in Alma with no input from 360 at the title level. Custom URLs are not transferred at the collection level at all. 
    For Selective Activation titles: 
    • When a title finds a match in the CZ:  Custom Dates and Custom Embargoes are added to the title in the 'Local Coverage' area.  Regular Date fields are not used in this case, since they presumably are the same as the Global Dates that are inherited from the CZ.
    • When a title does not find a match in the CZ, it is added as a local portfolio.  In this case, dates are added to the 'Local Coverage' area in the following manner: If Custom Dates or Custom Embargoes are present, use these.  Else, use Regular Date and Regular Embargo fields.  Local portfolios only use 'Local Coverage'. 
    An embargo is dates which are specified in terms of most recent years or months.

    Local Databases

    Ex Libris does not migrate Locally-created databases.  These must be re-created in Alma post-cutover.  Locally created databases can be identified by having PRVLSH - Library Specific Holdings as the provider.

    Hidden (Deprecated) Databases

    The 360Core KB team sometimes removes a database from the KB after it has ceased being provided by the vendor.  Customers who have these hidden databases may continue to track them and use them in 360Link, but people may no longer begin tracking them after they have been hidden.  See the KB article for more information: https://knowledge.exlibrisgroup.com/...dden_Databases
    Hidden databases are not migrated to Alma.  Either change the activation from a hidden database to an active database prior to migration, or activate the appropriate database in Alma post-go-live.

    Proxy

    If the 360 collection used a proxy, the Alma package is also set to use a proxy.  The proxy is set at the service level.

    Multiple institutions and "Available For" Groups

    If you are migrating from multiple institutions in 360 into a single Alma instance, you can make a request to have the migration analyst assign Available For groups to a single incoming instance.  All resources in the instance are assigned the same group code.

    Assigning Available For groups in the 360 migration is a special request and must be approved by the migration analyst.

    These groups are also known as Inventory Network Groups.  To set up a group code in Alma, see the page https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/080Configuring_Resource_Management/160Configuring_Distributed_Access_to_Electronic_Resources

    Since Available For groups are assigned at the service level, it is not currently possible to assign an Available For group for Databases during migration as there are no services for Databases.

    E-collections That Have Two Service Options

    In Alma, since the E-collections are supersets and can be used for various purchased packages from the provider, there can be different services available in the same E-collection. For example, you can subscribe to Factiva with getFullTxt or with getSelectedFullTxt. With almost all of the databases, migration can select the correct service. However, some databases have multiple services available and we are unable to select the correct service.
    Review this list of databases. If you subscribe to any of them, confirm in Alma that the correct service (getFullTxt or getSelectedFullTxt) is selected, post-migration.
    • Columbia International Affairs Online (CIAO)
    • DigiZeitschriften Open Access
    • EBSCOhost Newspaper Source Plus
    • EBSCOhost TOPICsearch
    • Factiva
    • Informit A+ Education
    • Informit AGIS Plus Text
    • Informit Australian Public Affairs Full Text
    • Informit Family and Society Plus
    • International Index to Music Periodicals (IIMP)
    • International Index to Performing Arts (IIPA)
    • LexisNexis Academic
    • LexisNexis Netherlands
    • Nexis UK
    • ProQuest Dissertations & Theses
    • PubMed Central
    • PubMed Central Open Access
    • Westlaw Law School
    • WestlawNext Campus Research Law
    • WestlawNext Campus Research Law + News

    E-collection special case:  automatic holding feature

    Migration programs do not transfer coverage for databases which have automatic holdings set up in 360. 
    For information on automatic holdings in 360, see: 
    Currently supported databases in 360 are:
    • Ebook Central

    • Taylor & Francis

    For information on setting up automatic holdings in Alma, see: 
    Currently supported automatic holdings in Alma are: 
    • SpringerLink Journals
    • SpringerLink Books
    • Elsevier ScienceDirect Books Complete
    • Elsevier ScienceDirect Journals Complete
    • ProQuest Ebook Central
    • Books@Ovid Subscription Complete
    • Books@Ovid Purchase Complete
    • Journals@Ovid Complete
    • Wiley Online Library Books
    • Wiley Online Library Journals
    • Taylor & Francis eBooks Complete

    E-collection special case: CCC Copyright Clearance Center

    Copyright Clearance Center packages are handled in Alma in a manner that is so different than how they are handled in 360, that they must be manually activated in Alma post migration. The customer would manually activate the publisher packages that are relevant to them.

    360 Link Activation Report

    Post migration, a report is provided which contain databases and/or resources which require your attention post-load.  The purpose of this section is to explain what the customer sees in the 360Link Resolver Activation Report, and to provide information on how the information can be used.  This report is generated based on the Database Details Report and the Tracked Resources Report from 360/Intota. Databases from 360 are matched to Alma e-collections using a match routine jointly developed by the 360 and Alma KB teams.
    Customers are welcome to provide feedback on the matching process as part of the normal test load feedback process.

    Statistics Tab

    The following statistics are provided on the first tab of the spreadsheet.

    Before trying to decipher this section, please re-read the ''360Core KB vs Alma KB and 1-to-many'' section above.  The map from 360 to Alma is not a one to one mapping.  Also, as mentioned in the 1-to-many section, there are usually more 360 databases which map to fewer Alma e-collections becaues of the 1-to-many situation.

    Therefore, we provide numbers from both perspectives -- counts of the 360 incoming databases (from the 360 perspective), and counts of the matched Alma e-collections (from the Alma perspective). 

    Broad overview: 

    1: Database counts from the 360 perspective

    1.1, 1.2: breakdowns of 1

    1.3: e-collection counts from the Alma perspective (this number will be smaller than 1 because of the 1-to-many situation)

    2: title counts from the 360 perspective

    2.1, 2.2: breakdowns of 2

    2.3: Title counts from the Alma perspective 

     

    Statistic Description
    1. Total databases from 360 The total number of databases from 360, from the Database Details report.  This is a statistical number from the 360 perspective.   
    1.1. Total CZ matched databases The number of databases from 360 which matched an e-Collection in Alma, according to the KB team mapping. This number does not include MISSING, HIDDEN, LOCAL, or NA databases.
    1.1.1 Inactive Databases or BY_TITLE and 0 titles

    The migration program has identified the 360 db as inactive, although a map was sometimes found.  These can be identified by checking the 'Activate?' column, and seeing 'N'.    Whether or not a db is Active or Inactive is checked according to the 'Active Databases in 360' section above. Further, if a title is specified as BY_TITLE but there are no titles, this is considered inactive.

    Titles which have NA in the 'Alma Target ID', for example HIDDEN and MISSMATCH titles, are not included in this number.  Those titles are counted in section 1.2.

    1.2. Total non-matched databases The number of databases from 360 which did not find a matched e-Collection in Alma.  To see the breakdown of these databases, see the section 1.4.x
    1.2.1. Missed Matches The migration attempted to activate a matched database, but some technical error occurred in the activation. There should have been a match according to the map, but some problem occurred when using the map information to activate in the CZ.  These should be reported to the KB (Data Services) team.  These are on the '360 db to Alma e-collection' tab listed as 'MISSMATCH'.
    1.2.2. Gap Databases The KB mapping team has not yet identified a matched Alma e-collection for this 360 DB.  These are listed on the '360 db to Alma e-collection' tab as 'NA'.
    1.2.3. Hidden Databases These databases are deprecated by the 360 KB team, and are not migrated to Alma. See https://knowledge.exlibrisgroup.com/360_KB/Knowledge_Articles/360KB_Hidden_Databases.  These are listed on the '360 db to Alma e-collection' tab as 'HIDDEN'.
    1.2.4. Local Databases These databases were created locally in 360 and cannot be transferred to Alma.  These must be re-created in Alma.  Either find a suitable database in the Alma KB and activate it, or re-create locally again.  These are listed on the '360 db to Alma e-collection' tab as LOCAL.
    1.3 Alma e-collections mapped (includes duplicates) Post-mapping, the total number of mapped e-collections.  This number includes duplicates because of the 1-many situation. This number does not include NA HIDDEN LOCAL MISSMATCH and BY_TITLE with 0 titles
    1.3.1 Unique Alma e-collections to be activated Same as 1.3, except deduplicated.  These collections should be activated in Alma.
     1.3.2 Alma e-collections from 1-1 match Further breakdown of 1.3: the collections in Alma which were mapped from a single 360 db
    1.3.3 Alma e-collections from 1-many match Further breakdown of 1.3: the collections in Alma which were mapped from multiple 360 dbs
    1.3.4 Unique Alma e-collections from 1-many match Same as 1.3.3 but deduplicated.  
    2. Total individual titles from 360 The total number of individual titles that were found in the Tracked Resources report from 360Link. This number is typically fewer than the number of titles exported in the Tracked Resources file.  First, titles from local, hidden, gap, missed, and inactive databases are not included.  Further, titles that have multiple to/from dates have two entries in the Tracked Resources file but only one entry for Alma purposes.
    2.1. Titles belonging to a non-matched DB Titles associated with a 360 selective database where a match was not found. This number contains titles from Selective databases only.
    2.1.1. Titles from non-matched selective DB without identifier To read a description of this group of titles, see the “Titles from non-matched selective DB without identifier” section.
    2.2. Titles belonging to a matched DB/e-collection All titles associated with a 360 DB where a matched Alma e-collection was found. All of these titles were activated in Alma except those in a Selective database where the title had no identifier (see "Titles for Matched Selective DB Without an Identifier" below).
    2.2.1. Titles belonging to a matched ActivateAll DB/e-collection All titles associated with an Activate All 360DB where a matched Alma e-collection was found. Some of these titles may not have identifiers, but it does not matter because the e-collection was activated in entirety and individual title identifiers are not necessary.
    2.2.2. Titles belonging to a matched Selective DB/e-collection All titles associated with a Selective 360DB where a matched Alma e-collection was found. Identifiers (ISSN/ISBN) are necessary for the migration programs to be able to activate the individual titles in a Selective e-collection.
    2.2.2.1. Titles from matched selective db, with identifier The migration programs are able to load this group of titles for matched selective databases, since the migration programs have an identifier to use for matching individual titles.
    2.2.2.2.Titles from matched selective db, without Identifier The migration programs are not able to load these titles to Alma due to the lack of identifier. See the “Titles for Matched Selective DB Without an Identifier” section below.
    2.3. Total Alma e-collection titles Titles to be loaded to Alma: some titles may be loaded to multiple Alma e-collections because of 1-many DB matches
    2.3.1 ActivateAll titles  Number of portfolios in Alma for ActivateAll collections.  These titles are the Alma counts for Activate All collections.  Activate All collections do not list titles on the TITLES tab - the titles are only activated in ALma because they have the ActivateAll flag set.
    2.3.2 Alma selective e-collection titles to be loaded to Alma Number of titles in the TITLES tab, for Selective e-collections. The TITLES tab only contains titles for selective e-collections. This number may contain duplicate because of 1-many DB matches
    2.3.2.1.Titles from matched selective e-collection, with identifier Mapped titles in Alma which have an identifier. Similar to 2.2.2.1, except some 360 titles map to multiple Alma titles because of 1-many
    2.3.2.2.Titles from matched selective e-collection, without Identifier


    See the “Titles for Matched Selective DB Without an Identifier” section below.  Similar to 2.2.2.2, except some 360 titles map to multiple Alma titles because of 1-to-many.

    2.3.3 Unique Alma e-collection titles Number of unique titles in the TITLES tab (deduplication of 2.3.2)

    360 DB to Alma E-Collection

    This tab contains the original 360 databases and their matched Alma e-collection, if a match was found.
    If a matched Alma e-collection was not found, then the Alma e-collection column contains:
    • Hidden databases - Ex Libris does not find matches for these since they are no longer supported by the 360 KB. https://knowledge.exlibrisgroup.com/360_KB/Knowledge_Articles/360KB_Hidden_Databases

    • Local databases - Ex Libris does not find matches for these since they are not linked to a 360 KB entry and therefore cannot be transferred to an Alma KB entry.
    • Missed Matches - These should be reported to Ex Libris. Mapping was attempted, but failed for some technical reason.
    • Inactive - these databases are no longer active in 360.  They should be recreated in Alma with an active e-collection.
    • Gap -  The mapping team has not yet identified a suitable match for these databases.
    Databases in the categories above should be activated manually in Alma. Customers may provide feedback to Ex Libris on which e-collection in Alma is the match for the gap databases.
    The Activate? column contains the selective or activate all status based on information coming from the 360 or Intota Database Details report. The options are:
    • Y = Activate all

    • BY_TITLE = Selective activation

    The two columns “Number of titles in the database” and “Number of titles without an identifier” are present for informational purposes. Titles from unmatched databases are listed in the tab Titles for unmatched collection. Titles from matched databases are not listed on this report.
    Titles in the Number of unmatchable titles without identifier column are listed only for matched databases, and can be found on the Selective titles without ID tab.
    The "One to Many" column indicates if multiple 360 databases were combined into a single Alma e-collection.

    Titles for Matched Selective DB Without an Identifier

    When the migration programs activate an Activate All e-collection, no title information is needed. However, when a Selective e-collection is activated, information on the individual selected titles is needed. In order to do this individual title activation, the migratoin programs use an exact identifier (ISSN or ISBN) to find the matched title. Some titles do not have identifiers by design. The most common reason is that they were published before identifiers were used, but another common reason is that the 360KB has inadvertantly not provided the identifier.  

    Ex Libris introduced an option to match titles by title string if there is no identifier provided, as mentioned in the "Loading Options" section above.  The matching option is "Match by title yes/no".  As mentioned in a note in the "Loading Options" section, there could be a significant time delay if there are very many titles without identifiers, so use this option with caution.

    If you choose to NOT use the "Match by Title" option, then the other options for handling these titles are:

    • Activate the entire e-collection in Alma, and then go through and clear the titles you do not own
    • Activate the titles in the e-collection manually

    Ex Libris recommends that all titles on this list be evaluated, since some multi-volume titles may overlap with titles that do have identifiers.

    Titles for Non-Matched Selective DB Without an Identifier

    Titles in this category are from selective 360 databases for which an Alma e-collection match was not found. Eventually the matching algorithm will be updated so that this database does find an Alma e-collection match. When the Alma e-collection is found, the migration programs will be able load the individual titles – except that they will still not be able to load the individual titles where there is no identifier. You may want to evaluate these titles in a similar way that you are evaluating the “Selective Titles without ID” group below, so that when a match is found you will have a better idea about how you will handle them in Alma. In order to find these titles, see the description in the “Titles for unmatched collection” tab, below, and filter for titles that do not have any identifier such as ISBN or ISSN.

    Titles for Unmatched Collection

    All of the titles listed in this tab are titles from 360 databases that did not find a matched Alma e-collection. The titles are from all unmatched databases/e-collections - both Selective and Activate All.
    This tab is provided for two reasons:

    Titles which have an identifier in 360 but no match in Alma (local portfolios)

    There may be titles in the Alma KB for certain e-collections which are not in the e-collection list in the 360KB, and vice versa.   When a title is in the 360KB, and should be loaded to Alma as a title for a selective database, there is a small chance that the title is not present in the Alma KB yet.  In this case, since there is an identifier, the migration programs load the title to the selective database but as a local title. 

    Neither these titles nor a count of these titles are currently provided in the 360LR Activation report.

    To find these titles in Alma,  

    • Search for Electronic Portfolio
    • Electronic Portfolio Is Local = Yes
    • Electronic Collection Is Local = No
    • If you also migrated from SFX, you may need to specify that TItle/Originating System contains keywords 'NON_SFX'

    The results of this search will show you the titles which had an identifier in 360, are attached to a Selective Activation e-collection, but for which there was no matching title in Alma so they were added as local. 

    These titles may be manually linked to the title in the CZ once the Alma KB team has added them to the CZ.

    When local portfolios are created, the default bibliographic record template is used.  If the default template is modified, some extraneous fields/punctuation may be present in locally-created portfolios.  We are working to correct this, but in the mean time as a workaround, wait to modify the default template until after go-live.

    Providing feedback on the mapping process

    The 360KB to Alma KB map is managed by the Data Content team, who also manages both KBs.  Since both KBs are updated constantly, the map is constantly updated as well. The following situations may be reported via Salesforce case and will be forwarded to the Data Content team.

    - Missing portfolios in the Alma KB for a Selective Activation or an Activate All e-collection.

    - Incorrect mapping: provide the incoming (360) database information, the mapped e-collection, and the e-collection you think it should map to

    - Missing mapping: provide the incoming (360) database information and the e-collection you think it should map to.  If there is no relevant e-collection in Alma yet, you can request that one be added.

    In some cases, the mapping may be corrected between test and production loads, but in many cases the added/corrected KB entries will be available after go-live.  Customers may localize the new CZ/KB entries when they appear.

    Report of Loader Events 

    A report of the events which took place during the E-Resource load for 360 is available upon request.  This report is usually very large, and many entries are purely informational.  However, it may be useful to review.  

    The important lines are for skipped resources.  Here are some examples: 

    Skiping 2 for package: National Council of Teachers of English. Reason: Package was not selected for activation by titles - Job ID: 380284740008584

    Package: Oxford Scholarship Online with service: getFullTxt does not exist in CZ, skipping - Job ID: 380284740008584

    Intota/360 ERM Migration 

    This section is relevant for customer migrating from 360RM or Intota ERM. 360Link Database Details and Tracked Resources information is migrated along with Intota/360Rm migration in order for resources to be linked to licenses/vendors. For information on migrating from 360Link, see 360Link Migration.

    Migration Form: Customer Input

    If you are migrating 360RM or Intota ERM, use the 360 and Intota Migration Form.

    Questionnaire Tab

    Complete the following in the Questionnaire tab:

    Institution Code, Customer Code, Institution Name, Customer Name

    Codes:INST_CODE, CUST_CODE – These are filled in by Ex Libris.
    INST_NAME, CUST_NAME – These are mandatory and must be filled in.
    Default: N/A
    Options: This question is mandatory.
    INST_NAME and CUST_NAME: Fill these fields in with your institution’s name and your customer name (this is only different from the institution name if you are part of a consortium).

    Intota/360 Three Letter Customer Code

    Code: INTOTA_360_CODE
    Default: None
    Options: Enter the three-letter code used in the Intota interface or the Serials solutions client center. If you do not know your three-letter code, you can determine it by looking at the files exported from your database. For example, in the file Database_Details_Report_ABC-2017-01-13-54251, the three-letter code is ABC.

    Cost Data

    Code: COST_DATA
    Default: ALL
    Options: Decide how much cost data from Intota/360RM you want to retain in Alma.
    ALL: Bring all cost data.
    NONE: Do not bring any cost data.
    ORDERS: Bring cost data only if the license is linked to an ILS order.
    Further information: There are a number of fields in Intota which allow customers to store notes about orders and payments.  These notes are placed in a linked order, if found, or if not found, in the related Vendor record.  These notes may be overwhelming in a single vendor record, and some customers wish to not migrate such notes at all.

    Negotiation Licenses

    Question: Make all incoming licenses of type NEGOTIATION in Alma
    Code: NZ_NEGOTIATION
    Default: No
    Options: Yes = make all licenses in the Network Zone have type 'Negotiation'. When Yes, customer must provide a list of institution codes in NEGOTIATION_INST_LIST.
    Question: Institution code list for Negotiation Licenses
    Code: NEGOTIATION_INST_LIST
    Default: No
    Options: If the answer to the question NZ_NEGOTIATION is yes, then provide a list of institution codes which will be covered by the negotiation license. Separate the institution codes using comma. E.g. 01CONS_A, 01CONS_B, 01CONS_C 

    Alma Library Code for newly-created vendors

    Code: 360_VEND_LIB
    Default: empty
    Options: Provide an Alma Library code for newly created vendors.  If not provided, the vendor will be at the institution level.  This question is only useful if multiple institutions are merging into the same institution in Alma.  If you are a single institution, leave this blank.

    Alma License Location Tab

    The Intota/360 License has a location that indicates the storage location of the license, for example, in the Library Director’s Office or the Electronic Services Filing Cabinet. Alma has a similar location field, but requires a code and a description of the location.
    Intota Physical Location: The list of physical locations in Intota/360 for indicating where a license is stored.
    Description: Detailed information about the location, if necessary.
    Alma License Location Code: A code that indicates the location of the license. This is separate from (not related to) the physical location in the inventory migration.  THis column is used as the code when making the LicenseStorageLocation code table in Alma.
    Alma License Location Description: The description of the license location in Alma. This may be the same as the Intota Physical Location.  This column is used as the description when making the LicenseStorageLocation code table in Alma.

    Alma License Status

    The Intota/360 license statuses must be mapped to one of the fixed list of Alma license statuses using this form.
    Intota License Status: The list of license statuses in your Intota/360 database.
    Description: Explanation of the statuses, if necessary.
    Alma License status: Select one of the Alma license statuses from the dropdown box (DRAFT, ACTIVE, DELETED, EXPIRED, RETIRED).

    Vendor Crosswalk

    There may be provider codes in Intota/360 that are related to vendor codes in your migrating ILS. For example, you can manage the electronic information in your ERM, but manage the payment with a purchase order in your local ILS.
    If there is a relationship between providers in Intota/360 and your legacy ILS, provide a map of the providers to vendors here. Use this map to unify the information from your ILS vendor to be linked to the e-products associated with this provider from Intota/360.  If you are not migrating providers from Intota, or from your ILS, then this map is not necessary.
    You can use this map even if you have only some providers that are related to legacy ILS vendors. Intota/360 providers that are not related to local ILS vendors are migrated to Alma as vendor interfaces of type Access Provider.
    The vendor crosswalk is performed only one time, at testload.  Vendors are not re-migrated at cutover, in any migration (ILS or 360).
    Intota Vendor Code: The vendor/provider code in Intota/360RM.
    Description: A description of the provider, if necessary.
    ILS Vendor Code: ILS vendor codes map directly to Alma with no change, so this is essentially the Alma vendor as well.

    License Term Values

    The Intota/360RM custom license term values for license terms (for example, instead of saying Permitted, you can make a value called Single chapters only) may be mapped to Alma’s standard DLF-ERMI license term values using this map.  Alma does not allow customized terms.
    Intota License Term Value: The list of license term values in your Intota/360 database, from 360/ProQuest Client Center > Menus > License Menus > License Terms Of Use Rights.
    Description: Explanation of the terms, if necessary.
    Alma License Term Value: Select one of the standard DLF-ERMI license term values from the dropdown box (YES, NO, UNKNOWN, PERMITTED, PROHIBITED, SILENT, UNINTERPRETED, NOTAPPLICABLE).  Use only the options in the dropdown, do not add new options.  Alma does not allow customers to define their own term values.
    The original Intota/360RM custom license term values are saved in a note in the license for future reference.

    License Terms and Types

    This tab lists the License Terms and Types mapping from Intota/360 to Alma. The only thing that can be changed on this tab is the Section column, which will place the license terms and types into a certain section on the License Terms tab in Alma.
    Intota License Term Value: The list of license terms in your Intota/360 database.
    Description: Explanation of the terms if necessary.
    Alma License Code: The standard DLF code for this license term.
    Type of license term: the standard DLF type for this license term.  Generally speaking, if there are multiple incoming values for a single license term, they are concatenated into the single license term.  In a special case, AUTHUSERDEF has two separate incoming fields, both of which may have incoming values.  All of the incoming values from both fields are concatenated into the single AUTHUSERDEF term.
    Section (editable): The section of the License Term page where this term will be listed in the Alma license. This information can be changed in the License Terms code table in Alma after migration.

    Further Explanation – ERM Migration Process

    Licenses

    Licenses in Alma and Intota/360 are both based on the DLF-ERMI standards and can be linked to e-collections/databases only.  Since both systems follow the DLF-ERMI standard, license terms generally map 1-1. You may change the order of the license terms using the migration form License Terms and Type tab prior to migration, or you can change them post-migration in the Alma License configuration.
    Intota/360RM license types (for example Negotiated or Click-through) are not supported in migration and are placed in the license note.
    Vendor level licenses from Intota are changed to link to directly to each collection level resource associated with the vendor.  
    A single license may cover (be linked to) multiple e-collections, but an e-collection can have only one license associated with it.  If there are multiple, we select the Prevailing license first, and otherwise try to choose the best based on the active dates of the licenses.
    Migration does not currently support linking at the title/portfolio level. For more information, see Migration to Alma from ProQuest Workflow Solutions.
    To see e-collection(s) associated with a license, click the Inventory tab of the license.  To see if any licenses are associated with an e-collection, from the search results list, click the More Info link. Licenses are listed under Licenses

    Vendors

    A vendor is generated from provider and contact information for databases which are currently active. We do not make a vendor in Alma if there is no active database associated with the provider.   A single contact in Intota/360 can be associated with multiple providers. In migration to Alma, any shared contact information between vendors is duplicated across all associated vendors. Contacts can be seen in the Contact tab of the migrated vendor in Alma.
    To see the administrative login and pw information for a vendor, look at the Contact Information tab of the main vendor.  Administrative data can also be found by clicking on the Vendor Interface record, which is accessible from the bottom of the Summary tab, and then looking in the 'Administrative Information' tab.
    Notes can either be placed on the Notes tab of the main vendor record, or on the Notes tab of the Vendor Interface record.
    Vendors created from the Intota/360RM migration are retained for cutover, just like vendors created from your ILS.    This means that vendors - and information migrated to them - are not updated for the cutover.  They are created at testload, and that is the last time migration updates them.  
    All vendors from Intota are set to Access Provider = Y, and are set to Licensor = Y if there is an attached license.  Intota vendors are set to Material Supplier = N, but if you use the vendor crosswalk to merge vendors with existing ILS vendors, the merged vendor is set to Material Supplier = Y.

    Order and Cost information

    Intota/360RM has a text field with an order number which does not link to an order in Intota/360RM but can be used in migration to link the resource to an order in Alma. The migration programs take the Order Number field as is from Intota/360 and attempt to find a match for the ILS-originated PO or PO Line in Alma for the associated electronic resource.  It is not necessary that the Vendor Interface (Provider) for the resource be the same as the vendor for the order - these can be two different vendors, and the resource can still be linked to the order.
    If found, the e-resource is linked to the ILS-originated order and cost information from Intota/360 is populated on the existing Alma order’s notes. Any e-resource formerly linked to that matched ILS order is unlinked.  If no order is found, the cost information for the resource is placed on the provider notes in Alma.
    It is not possible to generate an order (or an invoice) during the 360RM/Intota migration to Alma.
    You can decide how much cost data to migrate using the COST_DATA question on the questionnaire tab.

    Reviewers/Patrons

    Fields in the Alma license are linked to actual users defined in Alma user. The persons in the Intota/360 license are textual strings. No attempt is made to map these strings to actual users, so these licenses need to be linked to the appropriate Alma-managed user post-migration, if necessary. The field is not mandatory.

    Collections and Notes

    Alma does not have a collection concept to group electronic collections together. However, searchable note tagging can allow similar functionality. Multiple notes in Alma can also be managed on either the e-collection or e-portfolio levels. Collection names are placed on Alma Vendor interfaces and on the Alma License if the collection was related to the license in Intota. 
    Notes in Intota can be applied either on the electronic collection, electronic portfolio or vendor interface levels, depending on the type of information being managed. Notes from both databases and titles are migrated to the associated Vendor record, along with the vendor interface notes.
    Fields from Database Details go to Vendor Note: Collection, Long Database Description, Public Database Note, Public All Titles Note.  Fields from Cost Report and non-'open' notes from the Notes and Comments file are also placed in the Vendor Note.
    Fields from Resource Administrative Information are placed in the Interface section of the vendor, 'Access Information' and 'Notes' tab.

    Serials Solutions MARC Records

    Some customers may export 360 core resources in MARC format for loading into the local ILS. This is often necessary, since the ILS is a central means for discovery.
    If you have MARC records in your ILS that represent 360 Core resources, you have the following options:
    • Do not provide the MARC records when delivering records to the migration team for ILS migration.
    • Provide the MARC records, but also provide a string on the migration form (SFX_PREFIX) that allows the migration programs to detect these records. This string is usually 'WaSeSS'.  The migration program skips the records if there are no attached data elements and suppresses the records if there are attached data elements (such as items and orders).
    • Provide the MARC records, but do not provide a string on the migration form (SFX_PREFIX) question. This results in duplicate records for the resource – one from the ILS and one from the 360RM/Intota -> Alma migration. These records need to be handled (merged) manually post go-live.

    Managing Duplication in Alma

    Resources in 360/Intota may be duplicated in Alma, either through the import of MARC records from 360 (see Serials Solutions MARC Records) or through simple cataloging of electronic resources in the ILS. For more information on how to manage duplication of electronic resources in Alma, see Managing Duplication in Alma.
    • Was this article helpful?