From Sierra to FOLIO
Cataloging perspectives on migration and post-implementation impact
The University of Missouri System (UM System) consists of the University of Missouri-Columbia (MU), University of Missouri-Kansas City (UMKC), University of Missouri-St. Louis (UMSL), and the Missouri University of Science & Technology (Missouri S&T). For over two decades, the libraries of the UM System, along with the State Historical Society of Missouri, used Innovative Interfaces products as a shared integrated library system. In the summer of 2021, the libraries decided to migrate to FOLIO, with a go-live date of June 2022. This essay will examine some aspects of the migration and implementation process from a cataloging perspective, while also providing a discussion of significant challenges and workflow changes that came about post-implementation.
FOLIO’s unique data structure presented challenges in the initial stages of migration since FOLIO is intended to be agnostic in terms of data encoding standards, and its bibliographic data store is rooted in the BIBFRAME conceptual model. Rather than relying solely on raw MARC data, FOLIO uses data in MARC records to generate instance records that library staff can search and review. To accommodate this, one of the first tasks undertaken by catalogers in the UM System libraries was to review the MARC-to-FOLIO instance mapping and ensure that MARC bibliographic data would translate to instance records in a way that would be useful to library staff. Some complications surrounding this are discussed below. FOLIO also does not allow item records to be directly associated with instance records; they must be clustered under holdings records that separate items by location. This closely corresponds to the Sierra check-in record, which staff primarily used to maintain serials holdings data. It was not unusual for staff at MU to use more general locations at the check-in level and specific locations for the item records. As an example, the library’s remote storage facility had a single location code (fci) under which specific codes for the originating branch library or depository were gathered (fcjii for the journalism library, fcmii for the math library, fceii for module 1 of the depository, and so on). Item records used the detailed code while the check-in was assigned the single location code. To create holdings records that correctly reflected data in Sierra, FOLIO required exact matches between location codes in Sierra records and the corresponding codes in FOLIO. Cataloging and serials staff worked to correct Sierra location codes as much as possible prior to implementation, but extraneous holdings records were still created. Identifying and resolving these is an ongoing task.
In addition to MARC mapping and other decisions dictated by FOLIO’s data structure, item data presented a range of issues. The most significant data points that cataloging staff addressed were locations, material types, and the various categories of notes that had accumulated over the years. In addition to removing locations with no associated items, the migration provided an impetus to consolidate some locations and dissolve those that were no longer necessary. Cataloging staff used Sierra’s Create Lists module to identify items in these locations and then worked with public services staff to determine whether to relocate or withdraw items. Even with this, there were location questions left unresolved prior to the migration; these item records were assigned an “error location” in FOLIO and are gradually being addressed by cataloging staff. Material types in Sierra were reviewed and edited to ensure consistency with the options available in FOLIO, and a mapping table was prepared to aid in ensuring that all material types had a corresponding type in FOLIO. The table also served to identify errors to be resolved after implementation. Item notes posed a particular challenge beyond simple reconciliation and mapping.
Due to staff turnover, there were several types of notes that current cataloging staff were unable to interpret, so the most comprehensible notes were identified and addressed first. Staff made efforts to locate items with notes that an item required cataloging attention so that issues could be resolved and the notes deleted. The cleanup process regarding notes has affected practice in FOLIO, where they are assigned less frequently than in the past. Notes with details about transfer to offsite storage were retained and remain in use, since depository staff use this information to ensure that materials are all accounted for. Notes needed for statistical purposes were also retained, as were notes about print retention commitments and significant donations. Item records were one of the first datasets to be loaded into FOLIO as part of what was meant to be an iterative process. Early item loads revealed barcode issues that required resolution; cataloging staff located physical items wherever possible, verified barcodes, and revised data in Sierra so that subsequent item loads in FOLIO would more accurately reflect reality.
Cataloging staff also had to make decisions regarding records that did not need to migrate to FOLIO. While staff were able to easily resolve things like on-the-fly records and brief bibliographic records, subscription electronic resources presented unique difficulties since there was a wide variety of practice across the UM System libraries. Prior to the migration, the libraries used a shared catalog that drew from data in Sierra, but practices regarding discovery layers and knowledge base use differed across the system. Of the libraries employing a discovery layer, UMSL and Missouri S&T used Ex Libris’ Summon, while MU and UMKC used EBSCO Discovery Service (EDS). With the migration, all libraries opted to stop using a traditional OPAC and start using EDS as the sole means of discovery, so decisions were made based on the capabilities and features of EDS and how it interacts with FOLIO. In Sierra, records for e-resource packages were initially received from Serials Solutions and loaded by a systems librarian every month, while MU and Missouri S&T also received records via OCLC Collection Manager, with those records being loaded weekly by the systems librarian.
Regardless of the source, there was a great deal of fluctuation in the catalog caused by holdings changes and record updates. Early in the migration process, the UM System libraries chose to treat FOLIO as an inventory system, with the mindset that it would provide access to perpetual access electronic resources but not subscription resources. Making these decisions prior to implementation resulted in the need to identify e-resource records that did not need to migrate; records were located using Create Lists and edited and marked with Global Update.
To maintain stability in FOLIO after implementation, the libraries developed two practices. The most straightforward uses EDS’ underlying knowledge base to provide access to selected packages. The second takes advantage of EDS’ capability to support multiple catalogs within a single environment. In this process, packages not available directly through the EDS knowledge base are selected by cataloging staff in OCLC Collection Manager, which provides MARC records for download. Staff then edit the records and upload them via FTP, triggering an update to the appropriate catalog in EDS. Even though this remains a weekly process as it was in Sierra, the savings in time and effort has been significant, and FOLIO has remained more stable than Sierra.
The post-migration experience has been one of constant experimentation and learning. The intention was for the migration process to be iterative, which would allow staff to review FOLIO data and suggest necessary changes in a gradual process prior to implementation, but the volume and complexity of the data coming from Sierra prevented this. As a result, cataloging staff are continuing to find things post-implementation that need to be corrected. Analytical added entries have not been treated in the most satisfactory way by MARC-to-FOLIO instance mapping, particularly regarding relationship designators, and correcting this has been an ongoing challenge for library staff. The libraries have not had success in revising the MARC mapping to include $i, which records the relationship between the resource described in the analytical added entry and the one described in the main record, so it is not clear from viewing an instance record how a part may relate to the whole, and the MARC source record must be consulted. Revisions were also required to cause subfields containing information such as medium of performance ($m), musical key ($r), and version ($s, which is especially useful for works such as classics or religious literature that often exist in multiple expressions) to display in the instance view. Additionally, FOLIO does not recognize MARC 035 data as an OCLC identifier without the prefix (OCoLC); several thousand records in Sierra did not have this prefix, and this feature of FOLIO was not clearly understood by staff during the migration process. As a result, these identifiers are categorized in FOLIO as generic system control numbers, and resolving these is an ongoing process that is complicated by present limitations in FOLIO’s batchloading capability.
Record loads have been a challenge in general and for a variety of reasons; prior to implementation, the systems librarian position that was responsible for creating record load profiles and performing loads was vacated. As a result, a key post-implementation task for cataloging staff was to develop load profiles in FOLIO that corresponded to processes in Sierra, then test them until the desired results were achieved. In addition to the learning process associated with developing these profiles, FOLIO also has significant difficulty loading large files of records, though future updates should resolve this issue as computing capacity improves. Similarly, FOLIO currently lacks a feature as powerful as Sierra’s Global Update tool. There is a bulk edit feature, but it currently only edits selected attributes of holdings and item records. Significant changes to sets of instance records require staff to export, edit, and reload the underlying MARC records. Holdings and item updates outside the parameters of bulk edit can be done via the FOLIO API, a tool with a significant learning curve.
Gathering annual statistics has also been a challenge since FOLIO currently does not have any internal functionality that corresponds closely to Sierra’s Create Lists module, and any existing external tools are outside the purview of cataloging staff. The FOLIO user interface has a CQL-based query search feature that can search a wide range of data points, but data in FOLIO is expressed in terms of the instance record, meaning that, for example, a search for items created within a particular date range will return a list of instances and leave the user to identify the items that match parameters of their query. The FOLIO API offers a reasonable alternative for many scenarios, but significant post-search manipulation is often necessary to make sense of the results, aside from the time required to learn how to use the tool. The solution to annual statistics this year was to use Sierra data since implementation was so close to the end of the last fiscal year, but it remains to be seen how this will be done in the future.
The libraries have also not had success in conclusively identifying materials that should have been migrated but were not. Circulation staff often find materials that did not make it into FOLIO, and they send these items to cataloging staff for resolution. This process has been complicated by the fact that in some cases nothing migrated from Sierra, while in other cases the bibliographic record was migrated and a holdings record generated, but the item record did not migrate successfully. Even after migration, there is also still a place for Sierra. The UM System libraries belong to a statewide consortium called MOBIUS, which still uses Sierra. Since there is no interoperability between FOLIO and Sierra, the UM System libraries have retained Sierra to aid in consortial lending. This requires the item updates associated with large-scale withdrawals and transfers to be performed in both systems, which can take considerable time.
FOLIO is very much an evolving system; it updates regularly, and each release adds new functionality. From a cataloging perspective, UM System libraries staff are looking forward to linking of authority and bibliographic records and automated authority processing, which will work in conjunction with improvements in batchloading capability to improve data integrity and accuracy in the catalog. MOBIUS is also moving to FOLIO with a projected go-live date sometime in 2024, so FOLIO will at that time become the sole integrated library system for the libraries, which will streamline things further.