Breaking Ground: Consortial Migration to a Next-Generation ILS and Its Impact on Acquisitions Workflows

Morag Stewart and Cheryl Aine Morrison

Morag Stewart (mkstew@uw.edu) is an Acquisitions Librarian, Acquisitions and Rapid Cataloging Services, University of Washingon Libraries. Cheryl Aine Morrison (erhodin@uw.edu) is a Library Specialist I, Acquisitions and Rapid Cataloging Services, University of Washingon Libraries.

Manuscript submitted February 9, 2016; returned to authors April 5, 2016 for revision; revision submitted June 1, 2016; paper accepted for publication July 1, 2016.

This paper is based in part on a presentation given during the 2015 American Library Association Annual Conference.

From June 2013 to January 2015 the Orbis Cascade Alliance (OCA), a consortium of thirty-seven public and private academic institutions, migrated to a new shared Integrated Library System (ILS), Ex Libris’ Alma, with Primo as the discovery component. The consortium wanted to cultivate an environment that would better support collaboration and sharing, particularly in the realms of collection development and technical services. This paper examines the immediate impact of the migration on acquisitions workflows, mainly of the largest consortium member, and the short-term and long-term goals following the completed migration. Lessons learned and suggestions for managing a consortial migration are offered, plus a discussion of what it is like to work in the cloud.

The Orbis Cascade Alliance (OCA), comprised of thirty-seven diverse academic libraries at the time of migration, moved from three different locally hosted Integrated Library Systems (ILSs) and four different discovery platforms, into a single cloud-based shared ILS (SILS).1 While there is discussion in the library literature regarding the reasons for the migration, plus the process of migrating data, there has thus far been limited examination of the effects of the transition on technical services workflows across the consortium. Understandably, it was difficult to fully grasp the immediate and longer-term implications on daily workflows and collaborative activities until all OCA members had migrated. With the migration complete in January 2015, and June 2015 marking the end of the first biennium of working in the new system, there has been sufficient time to enable one of the first libraries that migrated to reflect on the experience, with an emphasis on acquisitions workflows and the impact on staff.

As one of the first OCA libraries, and also the largest, to migrate, the University of Washington Libraries (UW Libraries) got an early start with the Alma transition. The size and complexity of the data and workflows involved necessitated considerable time to examine processes and determine how to proceed following implementation. Since the completion of the migration, the Acquisitions and Rapid Cataloging Services (ARCS) unit within the UW Libraries has moved beyond the initial shock of adapting to a new system to evaluating new workflows and considering what the future in the new system will look like.

Over a year after the completion of the migration, OCA members continue to learn how to function and adapt as the new system changes. It is now possible to begin to answer questions about what it is like to work in the cloud, what benefits have been gained through the migration, and what OCA is striving toward with regard to cooperative acquisitions and collective workflows and collection building with the new system.

Literature Review

For much of the 1990s and early 2000s, it seemed that the main focus of the professional literature was on the future of technical services (paralleling the millennial question of the survival of the library as an institution), followed in the late 2000s by an emphasis on the next generation ILS, and primarily library management systems (LMSs). The introduction of the cloud, the interest in consortium level work, the push for the new ILS to include improved handling of electronic resources (e-resources), and the search for more advanced discovery systems has fueled a rapid change in design and concept. While much has been predicted about both the future of the ILS and technical services in general, it may be prudent now to take a closer look at what opportunities and capabilities these new systems offer technical services units, and the adaptations and adjustments required of staff going forward.

Twenty years ago, Hamilton provided a lengthy discussion of what acquisitions librarians should consider when investigating and choosing a system vendor and what to expect during migration and following implementation.2 While much has changed about the technology in subsequent years, the overall points about making sure one’s contract is clear regarding both vendor and library responsibilities, the adjustment period for using a new system, and the importance of maintaining vendor relations are as important now as they were in years past.

The constantly changing work environment and trend toward reorganizing acquisitions structures noted more than two decades ago was greatly influenced by a change in library systems.3 A different system necessitates new workflows and procedures. However, as noted by Stamm and more recently Green, it can take a year or more to fully realize all of the changes that may be required both organizationally and within individual workflows.4 It is a careful balancing act to determine how much downtime may be needed during a migration, the time required to start working in the new system, and designating an appropriate amount of time to evaluate long-term process and structural changes prompted by the migration. New ILS structures call for greater integration of staff processes and promise greater capabilities, especially when working with electronic resources, but just what implications do these new capabilities have for designing workflows?

Consider what is meant by next-generation library systems. In 2007, Breeding stated the need to reconsider back-end library technology, not just the discovery services, as he foresaw the separation of discovery from the ILS proper.5 He lamented the lack of integration in the systems available during that time: having each component as a separate piece of software to be added and maintained creates extra work and greater likelihood of problems.6 Wang and Dawes provided a brief synopsis of ILS development of the preceding two decades and detailed several traits they anticipated in new library systems (format agnostic resource management, platforms based on Service-Oriented Architecture (SOA), flexibility to accommodate modern workflows, and new discovery systems).7 They focused on two particular examples of how the future may look, specifically the Kuali Open Library Environment (OLE) and Ex Libris’ Alma. In describing OCLC’s WorldShare Management Services (WMS), Gutierrez and Givens also recognized the need for more effective management of e-resources and highlighted the capabilities of a knowledge base built-in to facilitate discovery that “moves at the speed of Google and offers vetted content.”8 Bahr’s query about next generation systems reveals further suggestions, including the desire for application program interfaces (APIs) and the ability to communicate with other systems such as Human Resources and Accounts Payable.9 Yang outlined the many features of new systems and some downsides such as greater dependency on the Internet and the fact that how these systems will interact with other academic campus systems is a significant unknown.10 In fact, as development and implementation of next generation systems continues, Breeding has offered up the moniker “library services platform” to describe the new capabilities of these systems that consolidate functionality.11

Machovec explored positive and negative factors of a shared ILS (SILS). He noted that continued funding difficulties in higher education made possible cost savings and staff efficiencies attractive to institutions investigating the possibility of adopting new systems; nevertheless, there are concerns about security as cloud based ILSs will not be behind local firewalls, and a greater risk of event failure resulting from consolidating services with a single vendor.12 Bordeianu and Kohl mentioned this as well and stated “in this new system any problem becomes a shared problem—if the system goes down, every single WMS library goes down.”13 Another issue of concern is the time required to migrate. Holbert’s assessment of the absurdity of trying to migrate to a new ILS in four months is echoed by Zhu and Spidal, who discussed the decision to migrate the thirty-seven members of the Orbis Cascade Alliance in four cohorts, allowing four to six months per group.14 Much can be accomplished in a short span of time, though it is also worth asking what could be accomplished with more prep time.

What impact do new systems have on workflow development and staffing? Fu and Fitzgerald explored how they will impact staffing from a systems librarian perspective, but apart from their paper, there is little in recent literature that discusses how other technical services staff will be affected.15 A systematic study of technical services staffing would be welcome, but with a particular focus not just on the number of positions affected or complexity of work, but also whether changes in technology have really improved efficiency. The ILS, as with much else in the library world, is oriented to serve the library’s patrons; however, Alma and other next generation systems are the backend support, not the discovery tools that patrons actually see. It follows that the ILS should be developed with a different audience in mind—librarians and library staff, particularly those in technical services since it is in essence an inventory control system. Yet the limited discussion of acquisitions and other technical services personnel as a user group leads one to question for whom these systems are really being developed.

Another focus in the development of new systems has been on promoting greater collaboration. Collaboration has been an important aspect of the profession in American libraries since the late 1800s. Weber detailed how the early focus on cooperative and standardized cataloging, the creation of interlibrary loan (ILL), and the establishment of national and regional catalogs all helped to create a strong foundation of cooperation and collaboration in American librarianship.16 Kopp notes that the driving force behind library cooperation and collaboration has been the desire to effectively serve patrons. Furthermore, technological advances have an impact on the formation of consortia, and advances in library automation, along with fiscal and organizational factors, are creating an environment best suited for their existence.17

In their 2015 book on library consortia, Horton and Pronevitz discuss the current high interest in collaborative work and note that “the tool that librarians most often use to launch and manage collaborative projects is the library consortium.”18 This interest in progressively more collaborative work, along with the development of the cloud-based ILS, is fueling an exploration of shared ILSs among consortium members. Budget costs remain a large concern and, as Breeding notes, the continued pressures on budgets will make this the norm rather than the exception.19 The growing popularity of a shared ILS and a desire to make electronic formats accessible to patrons consortially has encouraged vendors to experiment. One result, beginning in 2013, was OCA’s migration to the Ex Libris LMS, Alma, with the goal of creating a shared electronic collection for all thirty-seven members and an eventual sharing of technical services to serve the entire alliance.20

As detailed by Breeding, OCA has had previous experience with collective technology ventures before Alma migration, beginning with the use of Innovative’s INN-Reach system to create a union catalog that would facilitate ILL.21 When it was time to consider migrating to a new system, as described by Cornish, Jost, and Arch and a shared working environment that a cloud system could provide, the chance to be truly innovative presented itself.22 Now with a new shared system in place, OCA strives to create greater collaboration in collection development and explore a collective technical services structure.23

Furthermore, it is enlightening to consider how different OCA institutions prepared for the migration, the issues they encountered, and the impact the migration had across the consortium. OCA’s Request for Proposal (RFP) and selection process leading to the selection of Ex Libris products is described by Jost et al.24 Zhu and Spidal detail the process of preparing for and accomplishing the data migration to Alma in 2013 at Washington State University (WSU), a member of the second migration cohort.25 Fu and Carmen have also written a case study of Central Washington’s migration to Alma (in the fourth and last OCA cohort), adding background information about their three-phase migration process and highlighting the importance of systems and e-resources librarians to that process.26 It is easy to get lost in migration matters as it was a two-year process, however, moving to the new ILS was just a first step in fulfilling OCA’s vision of a truly collaborative consortium. Even as the migration progressed, member institutions were considering next steps. Spring et al. describe the complications that arose from the need for policies to standardize how everyone across the consortium would work in the new ILS, even though not everybody had yet migrated.27 The impact on acquisitions and other technical services staff through the balancing of the consortium’s needs (and mandates) as a whole with local policies and practice is perhaps best illustrated by an example.

Leading the Pack: The University of Washington Libraries Migration Story

As the largest OCA member, with three campuses, sixteen branches, and more than eight million volumes, the UW Libraries was one of the first OCA institutions to migrate, transitioning from Innovative’s Millennium ILS and OCLC’s WorldCat Local to Alma and Primo in the first of four cohorts in June 2013. At the time of migration UW Libraries’ Acquisitions and Rapid Cataloging Services (ARCS) division had already undergone several significant changes. For example, in spring 2012, catalogers and acquisitions staff who performed rapid cataloging began training for Resource Description and Access (RDA) implementation. A few months later, in the summer of 2012, following reviews and efficiency recommendations related to licensing and acquisitions, some of the technical services units were realigned by function. Previously, ordering, receiving, and cataloging were divided by format into the Monographic and Serials Services divisions. ARCS was formed by merging the monographic and serials acquisitions portions of the two divisions, and Cataloging and Metadata Services (CAMS) was formed by combining the monographic and serials catalogers into a single unit. This reorganization required relocation of almost all the staff in the new units. By the time the physical relocation of staff was complete in December 2012, preparations for the system migration were in progress.

The situation was further complicated by the fact that ARCS was not the only acquisitions unit within the library system. The International Studies unit and the East Asia Library maintain their own acquisitions staff. In addition, UW Libraries and the University of Washington’s Law Library, while historically existing as separate entities, would now be considered a single library system in OCA’s Alma implementation. This required a merger of UW Libraries’ and Law’s bibliographic record files upon migration and increased standardization of record coding and other practices between the previously separate acquisitions operations.28 The migration presented challenges in terms of harmonizing vendor files, ordering practices, and tracking statistics, but it has also presented opportunities for increased communication between units and greater standardization of procedures.

Coinciding with these challenges were personnel changes at UW that impacted the transition to Alma and the goal of consortial harmonization. The head of the UW Libraries’ Information Technology Services (ITS) unit, who spearheaded much of the preparation before migration and wrote the script that enabled Financial Services to begin automated payment of electronic (Electronic Data Interchange (EDI)) invoices, planned to retire once the migration was complete and the system was running smoothly. He stayed until May 2014, at which point most regular operations were running and the ARCS receiving and cataloging backlog was declining. Additionally, the Electronic Resources Librarian retired in the summer of 2013 shortly after migration, though she returned on a part-time basis through May 2015 to help train transitional coverage of licensing responsibilities. These changes in leadership added an additional layer of uncertainty to the post-migration process with regard to system vendor communications and the development of policies and procedures for the licensing and management of e-resources.

System Migration

When OCA initiated the RFP process, there was no fully developed next generation ILS that could provide the functionality needed for OCA to reach its goals.29 This required the vendor to develop the system needed on a very tight timeline, which meant that some aspects of the new ILS, such as the Acquisitions functional area and the Network Zone (NZ) containing OCA’s shared catalog, were just completed or being finished as the first cohort migrated. Subsequently, there was no time to update training materials, or for a fully functioning sandbox with the NZ component, to be developed and deployed by the vendor before the first migration (see table 1). This was a major challenge for Cohort 1 staff who had a very short window to learn how Alma worked before the go-live date. When UW Libraries went live in 2013, staff had to learn how to navigate and create new workflows in the live shared catalog that functioned differently than the training environment. On the positive side, the entire migration was implemented in stages, over a period of two years. This allowed the early implementers to work with the vendor to correct problems and allowed for needed functionality development to occur without having all OCA members learn the system on the fly at the same time.30 Nevertheless, the dynamic nature of this situation made it difficult to provide adequate documentation and training to prepare everyone for an environment that was, and still is, changing.

Before discussing the complications that were experienced with the creation of acquisitions workflows in the new system, it is necessary to explain how OCA’s Alma implementation differs from a stand-alone institution’s version. One issue in creating OCA’s envisioned SILS was the need for a shared bibliographic database environment while allowing member institutions to retain some local control and to provide a place for local order and holdings records. To accomplish this, Ex Libris created a three-layer system consisting of a local, a consortial, and a community record repository space. The first layer, the Institution Zone (IZ), houses local holdings, inventory, and order records. Each OCA member institution has its own IZ. The key element is the middle layer, the Network Zone (NZ), which houses the bibliographic records of OCA’s member libraries, separate but linked to the local/institutional repository (IZ) for each OCA member. Complementing these two layers is the third, called the Community Zone (CZ), composed of e-resource records, the Alma Knowledge Base (KB), available to all Alma users, not just OCA members. Compared to the single layer of the traditional ILS catalog, it was an adjustment to learn to work across multiple zones, and to understand how they are linked.

Alma was originally designed with just the IZ and the CZ. To accommodate and further OCA’s needs, Ex Libris added the NZ to the system already in place. The intent was for the NZ to function like the IZ. However, patching in a new component does not always produce the expected results. Initially, parts of the system did not work as anticipated. For example, loading bibliographic records presented several issues, including the system timing out before full record sets could load and in some cases loading multiple copies of records into the NZ. Even after migration completion, several unanswered questions face OCA, such as how to handle bad data created in the first several months of migration and how to resolve record load and merger issues.

In addition, the nature of permissions, or “role” assignment in Alma terms, created some unique challenges when determining who could do what and when. For example, as bibliographic records are created and merged in OCLC, or as mismatches occur between vendor-supplied records and OCLC record exports in the ILS, it is often necessary to move orders from one bibliographic record to another. In the legacy catalog, overlaying bibliographic records was routine and had been performed by both acquisitions and cataloging staff. In the multi-layer Alma consortial environment, where multiple institutions have holdings on a bibliographic record, this is no longer an option. Instead, staff import the desired OCLC record, create a brief record, or find the desired record already in the NZ to which they want to move orders and/or holdings, then use Alma’s Relink process to transfer the order/inventory from one bibliographic record to another.

At UW, this is an Alma function that ARCS staff can perform but CAMS cataloging staff cannot. The broad permissions assigned to the Acquisitions operator role in Alma allow a person to see and alter most order records. The local decision was to assign such a role only to necessary (i.e., ARCS) staff. The legacy system was more flexible in how permissions could be assigned, permitting cataloging staff sufficient acquisitions permissions to complete a similar task, but which would not allow them to edit order records. Since this is not possible in Alma, a system has been established for CAMS staff to notify ARCS via a web form when they need to have an order moved to a new bibliographic record. This is an example of a local workflow that did not exist before migration, but its creation was necessitated as much by local decisions and policy as Alma’s structure. This workaround also requires quite a bit of interdepartmental communication, cooperation, and time.

OCA is not alone in this challenge regarding role assignment, as it seems to be a function of other next generation ILSs. Bordeianu shares that the University of New Mexico experienced similar issues in their migration to OCLC’s WMS. In their case, it was cataloging permissions that allowed non-catalogers to modify bibliographic and holdings records.31

Another challenge presented by the new SILS is the granularity of order records, or Purchase Order Lines (POLs). In the UW Libraries’ previous system, Millennium, there was a single type of order record that could be used for all purchases. Most fields could be edited and the system allowed the creation of macros to enhance efficiency and reduce errors in repetitive data input processes. Templates could be created for specific kinds of orders or material formats and could include note fields. Conversely, Alma has a great number of order types, and one must be chosen and cannot be changed once the order record is created. Templates can be saved, but data must be present in four required fields (material supplier, price, fund, and acquisition method), with the exception of orders using the acquisition methods of Gift or Technical (fund and price are not required then). Thus, if one wants to use a template for purchases from a particular fund but with variations in vendor, for example, one must manually delete the incorrect value and input the correct vendor information after using the template to create each order, partially defeating the point of using a template and increasing the potential for operator error. Alma templates also do not currently retain note field text, necessitating manual keying of information.

While the granularity of order types in Alma might seem quite desirable, it has not proven to be as beneficial as hoped. The POL type chosen at the beginning of the order creation process determines what fields are available in the order records and what kind of inventory is created. In the legacy ILS, inventory was neither automatically created at the point of order nor linked directly to order records. It took time for ordering staff to familiarize themselves with all of the POL types and to know when it was appropriate to use which one, resulting in many orders placed using the wrong order type shortly after migration. Since the order type cannot be changed, these mistakes necessitated canceling and/or deleting incorrect orders and creating new ones.

One example of the difficulties encountered in creating order workflows in Alma involves mixed media orders. As previously mentioned, order records in Millennium were flexible and allowed the creation of single order records for multipart or mixed media items. Alma’s more granular nature forces strict boundaries on the items being ordered. This is most obvious in the differences between physical and electronic orders. Items with a multimedia component, such as a DVD with a streaming file that requires a license, are becoming more prevalent. To order this in Alma, ARCS must create multiple orders, one for each media type. As long as one of the orders is for an electronic format, a license record may be linked to that order to track licensing information and provide a note that displays to public users regarding usage rights.

A similar concern occurs as more orders involve individual vendors that may require licensing agreements for physical items. In the previous system, any order or type of inventory could be linked to the electronic resource management (ERM) module, but in Alma, which does not at the time of this writing accommodate attaching or linking license records to nonelectronic order records or inventory, it has become a topic of discussion regarding how to create the best workflow for ordering and license documentation.

Lack of an ERM Module

For all of the emphasis on the necessary inclusion of ERM in new library systems, perhaps one of the more disorienting aspects of Alma has been the seeming absence of an ERM module.32 Behind the scenes, one can find many of the components of such a tool distributed across the Alma functional areas of Acquisitions and Resource Management (cataloging). Within the Acquisitions functional area, connections between the vendor file and the licensing section allow for documenting and tracking licenses. Despite an initial delay in UW Libraries’ use of Alma’s licensing features because of instability, by June 2014 improvements had been made, enabling the part-time Electronic Resources Librarian to develop procedures for recording license information and to train ARCS and other relevant staff. While this was significant, it did not change the fact that not all ERM data migrated. Millennium license records migrated but Millennium vendor contact and resource records did not. Effort has been made to input necessary data into the Alma vendor file; however, access to legacy resource records is only available via text files exported during migration and stored on a local server.

Alma’s licensing landscape is also complicated by the zone environment. Currently, locally licensed materials are tracked using license and vendor records in the IZ. However, OCA is also exploring how to manage e-resources and licenses for consortially owned or subscribed materials. This involves putting license records in the NZ. Considering the initial issues faced when determining how bibliographic records are linked between the NZ and IZ, it will be interesting to see how licenses and e-resources management continue to evolve.

Within ARCS, e-resources staff discussed best practices and procedures using Alma’s functionality for local e-resource management. There are advantages to the new system’s management of activation, which can be done at the point of order, but the placement of this functionality under Alma’s Resource Management (cataloging) functional area has led to questions as to who should perform what tasks. Local historic practice has led to a divided handling of e-journals and e-books complicated by the division of serials and monograph processing. Presently at UW Libraries, e-journals and e-book packages may be activated by ARCS staff finding a CZ record and activating its portfolio. In contrast individual e-books, though also ordered by ARCS, are cataloged using existing NZ records or OCLC records imported into the NZ, and are handled by CAMS staff in a workflow that generally follows the one used before migration.

Local Configuration

Unique to ARCS’ migration experience was the need to reconfigure not only ordering and cataloging workflows, but also a locally developed automated receiving system utilizing Microsoft Access. This homegrown system allows fewer staff to handle an increasing volume of physical items, especially during the second half of a biennium when an increased amount of ordering and receiving occurs. Historically, the Access process used with Millennium called for incoming groups of material to be received in batches. Multiple files of bibliographic, order and/or item data were exported (necessitated by the limit on the number of fields allowed per export file) from the system and joined into a single spreadsheet, which was then input into Access. Queries ran against the data to evaluate cataloging quality and results output in printed report slips. These slips categorized each item and routed them to ARCS student employees to process, to ARCS staff for additional checks or minor editing, or to CAMS catalogers for more extensive work or original cataloging in OCLC. In contrast, Alma’s infrastructure does not allow batch receipt, requiring a reconsideration of workflow to allow for item-by-item receipt. To limit the number of times individual items are handled, it was decided to combine receipt and student cataloging functions as much as possible. These and other changes required the complete reconfiguration of the Access system and the attendant workflows. It took about a month to complete the first modified Access process for approval books, as data extraction was sometimes problematic and unstable. It took an additional two months to complete the other Access workflows for firm orders and other materials before staff could begin to process those backlogs.

Adapting Workflows to a New System

As suggested by ARCS’ overall cataloging statistics by fiscal year (see figure 1), the first year in Alma saw a decline in cataloging production while the second year in the new system shows productivity close to the level of the year immediately preceding migration. Direct comparison of these numbers, however, is difficult. Before migration, ARCS staff were involved with various data cleanup projects that took time away from cataloging activities. As this was also the end of a biennial cycle, effort was placed on receiving and processing the invoices for as much material as possible to ease the transition to the new system rather than cataloging. Reconfiguration of the Access process after migration allowed for more efficient processing than in the weeks immediately following go-live, but Alma’s inability to batch receive means certain efficiencies of the old system have not been realized in the new.

An added difficulty, which will be ongoing, is that Alma is a constantly changing environment, receiving monthly updates. These changes prompted ARCS in the summer of 2015 to reexamine some of the Access workflows created shortly after migration and to reconfigure them again. This process will likely need to be repeated as the system continues to evolve.

The challenges of adapting workflows to the new system were heightened by terminology changes, which many have found to be confusing. In Millennium, an order was often referred to as a Purchase Order (PO). Alma accounting terminology differs slightly in that an Alma PO is composed of one or multiple Purchase Order Lines (POLs), or individual orders. Further adding to the confusion was the fact that when order data from Millennium migrated, it was split between the PO and the POL in Alma, necessitating one to look in both to find historical information. A particularly troublesome aspect of the new terminology, as pointed out by another OCA institution staff member, was that not knowing what functions were named made it extremely difficult to find answers in the online help manual.33 This continues to be an issue, but will hopefully get easier with time. Another terminology quirk is the inconsistent naming of navigation links. Some pages within a workflow have “Cancel” buttons to navigate back to a previous page, whereas others have a “Back” button. Staff have become accustomed to what buttons are displayed on which pages, but in a system that is seemingly always being updated, these kinds of bugs are still the cause of occasional consternation and amusement.

Learning to Work in the Cloud

Becoming used to terminology changes is not uncommon during migrations, especially when transferring to a new vendor. This is exacerbated by cloud-based systems, which are conceptually different from the ILS of the past. The significantly different structure and work environment brings with it much new terminology that requires staff to become conversant with the underlying concepts and learn to perceive their work in a new fashion. The University of New Mexico experienced such issues when migrating to WMS.34 This can be difficult, especially if the new concepts require the reconfiguration of a workflow and duty assignment. The University of Wolverhampton put it best by stating “more than a change of systems, this has been a change of working cultures.”35

The rolling migration in four cohorts was also of tremendous value. Although the first cohort had to pave the way and perform the initial troubleshooting, they were able to help smooth the transition for the cohorts that followed by providing feedback and problem solving with Ex Libris, helping to train cohorts three and four, and acting as a resource throughout the migration process. Other vendors, such as OCLC, have experimented with this cohort migration model and have found that often the most useful answers to questions that arose came from other members who migrated to the same system, or were in the same cohort.36 This sentiment was echoed by a staff member at an institution in the fourth and final OCA cohort. She reported that vendor training was intense but difficult to follow because of the unfamiliar nature of the new system and limited time to practice with the sandbox before training commenced. The shared nature of the system also created difficulties, and since it was so new, vendor training videos did not address the reasons why functions did not operate in the ways covered in training. She found communication with designated OCA members to be the most helpful.37

In addition to being a major factor involved in preparing for migration and training, time is also a primary concern when considering system usability. One point of contention for personnel across OCA is the amount of mousing, clicks, and steps required to perform any function within the new system.38 This is especially frustrating for repeated actions and fields that do not self-populate as one types. It essentially takes longer to complete many tasks. Added to this is the nature of a cloud-based system requiring each action or update to be transmitted to the cloud before the operator can proceed. While Internet connectivity has improved to amazing speeds, there is still a few seconds lag time that is not seen on local intranet systems. What used to take only a few seconds can now take as long as several minutes as each area of a record is completed and updated. If there is a network disruption or a slow-down in service, it becomes even more time-consuming.

In contrast, one of the advantages of a web-based interface is the ability to work remotely, allowing for flexibility in when and where one does one’s work. It is difficult, however, to create a system that looks and functions identically across a wide variety of web browsers, resulting in varying levels of functionality and stability across platforms. In acquisitions and cataloging work, it is often necessary to open multiple order and/or bibliographic records and compare them with one another side-by-side, something the legacy ILS supported. This is not the case in Alma’s web-based environment, which does not enable the operator to have multiple records open at the same time. To work around this, if one opens multiple sessions of Alma in the same browser window, or on multiple windows of the same browser, the system becomes unstable, unless one uses private browsing mode. Another option is to open Alma in different browser programs, one session in Firefox, another in Internet Explorer or Chrome, for example. However, depending on one’s comfort and familiarity with multiple browser programs, this is not an optimal solution.

Migrating to and working in a new SILS has been challenging, but OCA’s journey is just beginning and will require a lot of hard work and patience. One area where this has become apparent is working in the NZ. Sharing master bibliographic records consortially is definitely a challenge. For efficiency for both patrons and OCA members, duplication of OCLC records must be kept to a minimum, which requires members to agree on cataloging standards as well as (potentially) best practices for record loader configuration and performing record loads. For such a large nonhomogenous group, a lot of thought and participation by all members is vital. Unfortunately, since there are so many duplicate records in the system, attempting to correct and resolve the migrated data and consolidate previous holdings on a record-by-record basis is not a practical solution. A certain amount of record duplication is inevitable, and the goal is to minimize this as much as possible. This is proving difficult because of factors such as data, often electronic record sets, migrating only to the IZ, differences among OCA members as to whether to use CZ or NZ records for ordering and cataloging e-resources, OCLC merging records after the bibliographic records are already in the NZ, and problems with the loaders matching incoming records to less than ideal bibliographic records already in the system.

This was further complicated by the two-year migration plan, which called for all member institutions’ bibliographic records to be loaded into the NZ in June 2013 and holdings added as the institutions completed migration. For almost two years, there were many records in the NZ that lacked holdings. It was difficult to determine whether these were true duplications or ghost records created by the problematic loads. Now that migration is complete, OCA is exploring policies to handle records in the NZ that do not appear to have holdings. This will likely be a moving target, however, as OCA membership grows and the records of new members are added upon their migration to the system. Presently, one librarian from UW Libraries is the point person for deleting records from the NZ and OCA members contact her to delete excess records as they are found.

Although some of the migration problems have been resolved, the issue of OCA-wide policy and procedures, as evidenced by the NZ record cleanup question, looms large. An additional area that needs attention is ordering. There are several different methods for ordering books from large vendors such as YBP, but no preferred method or best practice has been implemented. This gives individual OCA members autonomy, but makes working together in the NZ more difficult. At the time of this writing, there is also no standard record loader set-up, increasing the likelihood of bad record matches. This has been seen in the past with an ISBN match that disregards a subfield z, allowing print materials to be placed on e-resource bibliographic records, and requiring cleanup later. While OCA has templates for the creation of brief bibliographic records and best practice mandates in place, there is much ground to cover in establishing policies to standardize or harmonize practices across the consortium.

Conclusion

When considering a consortial system migration project, many questions are asked, including where does one want to go and by what means and route does one get there. There are presently many different routes to take, not all with the same destination in mind. The journey has certainly been an adventure, but the OCA and the UW Libraries are fortunate to have many talented and dedicated staff who were able to aid in navigating the challenges presented. As stated in the literature on the future of the ILS and libraries, technology continues to evolve and many institutions will need to evolve with it. The next generation ILSs offer libraries the potential to serve their patrons in ways only dreamed about a few years ago. As these systems become more stable and as libraries and ILS developers work together to make them more accommodating to what is needed, the benefits will outweigh the challenges experienced in migration and afterward.

Nevertheless, given the capabilities of new library management systems, human intervention is still necessary to accomplish technical services work and will continue to be so into the future. Migrating into this developing environment and learning to design workflows in coordination with other consortium members in a constantly changing system can be an unsettling experience. This holds true for both electronic and print materials processing. What has changed are the skills needed, as was suggested in years past by Ruschoff and further specified by Fu.39 Revision of workflows following migration is standard practice, but the integrated work between consortium members now adds a new dimension to the puzzle.

Locally, several issues became apparent after migration as ARCS staff became accustomed to the new work environment. From initial processes such as ordering directly through Alma, setting import profiles for bibliographic records, overlaying records and relinking during cataloging, to loading and paying EDI invoices, nearly all functional areas presented some initial difficulty in transitioning to the new system. While some solutions required filing support cases with the system vendor, others came more directly from staff learning the “Alma way” of performing a process. Much work was accomplished collaboratively by colleagues sharing tips and tricks such as suggesting what web browser worked best to see specific record characteristics. In addition to collaboration overall, it is also worth noting that to accomplish certain tasks, a broad understanding across functional areas of the system and physical departments within one’s institution is helpful. However, such knowledge does not always eliminate the hurdles presented by departmental divisions, especially in larger institutions with more distinct divisions, when trying to design efficient workflows.

ARCS continues to adjust to the new system, having reevaluated the local Access receiving system in the past year, hoping to gain more efficiency now that the system is more stable than it was three years ago. The ripple effect on workflows from the “Alma way” of doing things highlights divisions between staff alignment and responsibilities and that of operations delineated by Alma roles and system architecture. This serves as a reminder that library organizational structure may need to change just as intra- and interdepartmental processes change to work more efficiently with the new system.

No system migration is easy; however, there are particular complications of which to be aware when migrating as part of a consortium into a shared system. The UW Libraries and the OCA take pride in being leaders in library technology. This has very real practical implications when migrating to a system so new that not all of the pieces of the system are in place when preparing to migrate. UW Libraries and the other members of the first migration cohort were not the first libraries to transition to Alma; however, there was much that was new for OCA with its Network Zone configuration, a component that non-consortial early adopters lacked. Given the size of the consortium and the variety of individual libraries needing to migrate, the two-year project cycle seems, in hindsight, exceptionally ambitious, particularly to allow the libraries in the first cohort time to familiarize themselves with the new system and prepare data for migration.

Working in the cloud has its own set of advantages and disadvantages. There is freedom from local servers, but requires dependence upon the Internet, which individual institutions do not control. As was observed during the first year of using Alma at UW, server issues still affect work, but it is now on a larger scale than one single institution.

Moving forward from the completion of migration in January 2015, the shift in focus from migration to integration, proceeding with the vision of shared consortial technical services, began in earnest at the summer 2015 Alliance Summit meeting. To address geographic barriers and begin more collaborative work, new working groups have begun to schedule regular conference calls to discuss various functions, such as discovery and delivery, technical services, etc. These calls are open to all OCA members, and allow for information exchange and will hopefully foster a sense of community.

There is no doubt that being a member of a consortium carries many benefits, but it is also true that there can be drawbacks and friction. Where once individual institutions could determine their own cataloging and acquisitions policies, there needs to be agreement between OCA members in many areas; time to reach these agreements and make other OCA decisions must be weighed against getting work done locally.40 In a heterogeneous consortium with a great variety in institutional size and funding capacity, it is important to recognize and address potential areas of friction, such as sharing of resources, cost allocations, and methods of contribution. One way to do this is to keep communication lines open. Encourage discussion and collaboration. Encourage staff to approach this new venture with a willingness to be flexible and open-minded.

Whether contemplating making a system change in the future, or looking back on the process after the fact, there are many variables to consider when evaluating such a change. No system is right for all institutions and even the needs and wants of individual members of a consortium will vary. New systems such as Alma have much to offer in the handling of multiple formats of material, but there are decided trade-offs in functionality as well. In the case of the OCA, continuing to use a multitude of ILSs and discovery systems was not an option and a change was necessary to reach the consortium’s goals. While there are many usability and other enhancements that one could suggest for Alma and other newer LMSs, the interim goal of bringing consortium members closer together and fostering a new working environment has been, at least on some levels, successful. Nevertheless, further work remains to achieve consortial goals regarding collaborative technical services, especially as new members join the consortium and as the system continues to change. Bearing these ideas in mind, the UW Libraries and OCA continue to move forward and break new collaborative ground.

References

1. “Shared ILS migration complete!,” Orbis Cascade Alliance website, accessed October 5, 2015, www.orbiscascade.org/sils-migration-complete.
2. Marsha J. Hamilton, “The Great Migration: Second Generation Acquisition and Library Management Systems,” Acquisitions Librarian 7, no. 13–14 (1995): 5–33.
3. Tamara Frost Trujillo, “Perspectives on Acquisitions Librarianship: today and tomorrow” in Technical Services in Libraries: Systems and Applications, edited by Thomas W. Leonhardt (Greenwich: JAI Press, 1992): 200, 203–4.
4. Andrea L. Stamm, “The End of an Era Builds New Team Spirit: Team Playing at Its Best,” Cataloging & Classification Quarterly 30, no. 2-3 (2000): 367–71, http://dx.doi.org/10.1300/J104v30n02_13; Peter Green, “Implementing a Next Generation Library System,” Proceedings of the IATUL Conferences Paper 1 (2014): 5–6, docs.lib.purdue.edu/iatul/2014/libservsys/1.
5. Marshall Breeding, “It’s Time to Break the Mold of the Original ILS,” Computers in Libraries 27, no. 10 (2007): 39–41.
6. Marshall Breeding, “Dispatches from the Field: Recasting Library Catalogs,” American Libraries 38, no. 9 (2007): 43.
7. Yongming Wang and Trevor A. Dawes, “The Next Generation Integrated Library System: A Promise Fulfilled?,” Information Technology & Libraries 31, no. 3 (2012): 76–81, http://ejournals.bc.edu/ojs/index.php/ital/article/view/1914/pdf.
8. Art Gutierrez and Earl Givens, “Libraries in Transition: 21st Century Library Systems,” Kansas Library Association College and University Libraries Section Proceedings 4, no. 2 (2014): 36–37, http://dx.doi.org/10.4148/2160-942X.1046.
9. Ellen Bahr, “Dreaming of a Better ILS,” Computers in Libraries 27, no. 9 (2007): 11–12.
10. Sharon Yang, “From Integrated Library Systems to Library Management Services: Time for Change?,” Library Hi Tech News 30, no. 2 (2013): 3–7.
11. Marshall Breeding. “Library Services Platforms: A Maturing Genre of Products.” Library Technology Reports 51, no. 4 (2015): 6-9, http://dx.doi.org/10.5860/ltr.51n4.
12. George Machovec, “Consortia and Next Generation Integrated Library Systems,” Journal of Library Administration 54, no. 5 (2014): 436–38.
13. Sever Bordeianu and Laura Kohl, “The Voyage Home: New Mexico Libraries Migrate to WMS, OCLC’s Cloud-Based ILS,” Technical Services Quarterly, 32, no. 3 (2015): 291, http://dx.doi.org/10.1080/07317131.2015.1030267.
14. Gentry Holbert, “OCLC’s WorldShare Management: Early Adopter Experience at a Small Liberal Arts Institution on the Web,” Information Standards Quarterly 24, no. 4 (2012): 21-26; Lihong Zhu and Debra F. Spidal, “Shared Integrated Library System Migration From a Technical Services Perspective,” Technical Services Quarterly 32, no. 3 (2015): 267, http://dx.doi.org/10/1080/07317131.2015.1029844.
15. Ping Fu and Moira Fitzgerald, “A Comparative Analysis of the Effect of the Integrated Library System on Staffing Models in Academic Libraries,” Information Technology & Libraries 32, no. 3 (2013): 47–58, http://ejournals.bc.edu/ojs/index.php/ital/article/view/3388/pdf.
16. David C. Weber, “A Century of Cooperative Programs Among Academic Libraries,” College & Research Libraries 37, no. 3 (1976): 205–21.
17. James J. Kopp, “Library Consortia and Information Technology: the Past, the Present, the Promise,” Information Technology & Libraries 17, no. 1 (1998): 7–12.
18. Valerie Horton and Greg Pronevitz, ed. Library Consortia: Models for Collaboration and Sustainability (Chicago: ALA Editions, 2015): 1.
19. Marshall Breeding, “The Trend Toward Outsourcing the ILS: Recognizing the Benefits of Shared Systems,” Computers in Libraries 24, no. 5 (2004): 36–38.
20. Horton and Pronevitz, Library Consortia, 65.
21. Marshall Breeding, “Case Study: The Orbis Cascade Alliance: Strategic Collaboration among Diverse Academic Institutions,” Library Technology Reports 49, no. 1 (2013): 30.
22. Al Cornish, Richard Jost, and Xan Arch, “Selecting a Shared 21st Century Management System,” Collaborative Librarianship 5, no. 1 (2013): 17–18, http://collaborativelibrarianship.org/index.php/jocl/article/view/232/180.
23. Horton and Pronevitz, Library Consortia, 38.
24. Cornish, Jost, and Arch, “Selecting a Shared 21st Century Management System,” 19–28.
25. Zhu and Spidal, “Shared Integrated Library System Migration,” 253–73.
26. Ping Fu and Julie Carmen, “Migration to Alma/Primo: A Case Study of Central Washington University,” Chinese Librarianship: an International Electronic Journal 40 (2015): 11–13, www.iclc.us/cliej/c140FC.pdf.
27. Kathleen Spring et al., “How Is That Going To Work?: Part II—Acquisitions Challenges and Opportunities in a Shared ILS,” in Charleston Conference Proceedings, edited by Beth R. Bernhardt, Leah H. Hinds, and Katina P. Strauch (West Lafayette, IN: Purdue University Press, 2014), http://digitalcommons.linfield.edu/librariesfac_pubs/13.
28. Richard Jost, email correspondence to authors, October 12, 2015.
29. Cornish, Jost, and Arch, “Selecting a Shared 21st Century Management System,” 21.
30. Machovec, “Consortia and Next Generation Integrated Library Systems,” 442.
31. Bordeianu and Kohl, “The Voyage Home,” 288.
32. Yang, “Time for Change?” 5.
33. June Waggoner, email correspondence to authors, September 17, 2015.
34. Bordeianu and Kohl, “The Voyage Home,” 290.
35. John Dowd and Frances Machell, “Cloud Atlas: University of Wolverhampton’s Journey into the Library Management System Cloud,” SCONUL Focus 58 (2013): 45, www.sconul.ac.uk/sites/default/files/documents/14_12.pdf.
36. Michael Dula et al., “Implementing a New Cloud Computing Library Management Service: A Symbiotic Approach,” Computers in Libraries 32, no. 1 (2012): 6–11.
37. Waggoner, email correspondence to the authors, September 17, 2015.
38. Catherine Chapman, email correspondence to the authors, September 17, 2015; Waggoner, email correspondence to the authors, September 30, 2015.
39. Carlen Ruschoff, “Competencies for 21st Century Technical Services,” Technicalities 27, no. 1 (2007): 15–16; Ping Fu, “Supporting the Next-Generation ILS: The Changing Roles of Systems Librarians,” Journal of Library Innovation 5, no.1 (2014): 39–40, www.libraryinnovation.org/article/view/326/545.
40. Jost, email correspondence to authors, October 12, 2015.