FEATURE
STRATEGIES FOR SUCCESS: Voyager to Alma Migration With a Team of Three
by Alyssa Koclanes, Nancy Schuler, and Heather Bush
| [T]here will be weekly deliverables, training, testing, and customizations to review. |
This article will explore the phases of migration and discuss best practices and strategies for implementing an integrated ILS with a small team. Eckerd College is a private undergraduate liberal arts school located in St. Petersburg, Fla., with a full-time equivalent of 1,811. Our leadership team for this project consisted of three librarians, with assistance from two additional librarians and a staff of nine library employees. The pre-migration process began in fall 2019 with a 4-month implementation phase prior to the launch planned for July 2020. During implementation, campus closures due to the COVID-19 pandemic resulted in an immediate need to transition all library work online.
As we began the planning phase, we did not realize how flexible the team would need to be, in case of contingencies. Four months prior to the Alma launch, our campus was shut down and our staff size was reduced by furloughs. Moving to a cloud-based system definitely aided our ability to quickly pivot. At the same time, we had to implement new virtual procedures for daily library work in addition to creating pandemic planning documents and ensuring staffers were safe—emotionally, mentally, and physically. Clear, concise communication and documentation are a key component for a successful ILS migration. But managing communication in an environment preoccupied with a pandemic was overwhelming
The Phases of ILS Migration
ILS migrations likely look a little different for every library, as all libraries have their own structures and workflows in place that make sense for them. The path we took included the steps outlined in the image below and discussed below.
 Platform Selection
The initial evaluation process started in fall 2018 when we scheduled on-campus demonstrations for four next-generation ILSs. Between October and December 2018, we reviewed and evaluated Ex Libris Alma/Ex Libris’ Primo, OCLC’s WorldShare, Innovative’s Sierra, and FOLIO. After the on-site demonstrations, we narrowed it down to two options: Alma/Primo and WorldShare, since we wanted one integrated discovery and ILS from the same vendor. Our final platform selection and evaluation process included site visits to two nearby institutions to better understand how similar libraries used the systems we were considering. This process was very helpful in making the final decision.
Pre-Migration Planning
Following the selection of Alma/Primo in April 2019, we began the pre-migration planning process with a staff kickoff meeting, more than a year before our intended go-live date in July 2020. At this meeting, the migration timeline was shared with library staffers, and we introduced the newly formed ILS migration leadership team. The team was led by the technical services librarian and included the e-resources librarian and the access services librarian. Ex Libris started the official onboarding process in October 2019, about 4 months before the official migration started in February 2020.
During the pre-migration planning phase, we determined which data cleanup projects to work on in advance and which projects would be easier to perform in the new system after migration. Data cleanup projects included circulation and catalog data, but we soon learned it would be easier and faster to perform the majority of the data cleanup in the new ILS. We also determined which collections to migrate and which collections would be easier to start fresh. For example, we decided to migrate our acquisitions data, but not our course reserves. Since we are a small library team, it was very beneficial to have a longer pre-migration planning phase in advance of the official implementation and migration.
Vendor Relationships
Having regular communications with your vendor is essential to staying on schedule, keeping track of tasks, addressing issues, and making sure your team has the training it needs. Ideally, your vendor will establish a structure for your communications. You should expect to have weekly or semi-weekly meetings during migration and implementation to discuss steps in the migration and address any issues or concerns, with training sessions on specific modules throughout. This is your opportunity to ask questions and discuss issues, but also to build a rapport with your vendor to make sure your needs are understood.
Vendors often make use of project management systems, such as Basecamp, to track questions, resolutions, specific contacts, milestones, and even conversations that are specific to a particular issue. There should also be a process in place for escalating issues that cannot be resolved by your migration specialist, as well as a separate system, such as Salesforce, for tracking progress and completion. Additionally, we had the opportunity to undergo migration with a cohort of two similar libraries. This enabled us to see if the other libraries had experienced certain issues and to work together to troubleshoot problems, while also learning from some of the challenges each of us faced. While this may not be a feature of all ILS migrations, we found it valuable to undergo the process in the company of similar libraries.
Finally, what may be an obvious step in the process to you may not be for your vendor. What data fields will be migrated? Will changes made in your test environment be carried over to your live environment? Don’t make any assumptions, and clarify things upfront to save time and avoid frustration later. In our case, we learned (a little late) that any changes made in our test environment would not transfer to production, resulting in the need to duplicate tasks that we thought would be carried over.
Implementation and Customization
The implementation and customization of a new ILS is a long process that requires all hands on deck. Once the migration countdown clock begins, there will be weekly deliverables, training, testing, and customizations to review. Most likely, your ILS vendor will provide your team with a test platform to begin learning the new system. For Alma, we were provided with 1) a sandbox site containing sample data for viewing and testing out features and 2) a test site specific to our library that included initial data migrated from our previous ILS. Our final production site was delivered after the final data migration.
Implementation begins with sharing specifications for fulfillment, cataloging, user records, acquisitions, resource management, system integrations, and discovery customizations. There will likely be lengthy documents that help you interpret migration forms and the expectations for each field. Once customizations are in place, test migration of catalog, acquisitions, and patron data occurs. This is followed by a period of testing to assess any data inconsistencies and other issues. Decisions about what data to migrate were made during the migration process. We moved all of our catalog and acquisitions data, but (as noted earlier) we decided not to migrate our course reserves data.
To provide seamless access to existing electronic collections and services, you may also be migrating to a new discovery system. If you are using an ILS and discovery platform from the same vendor, this is a straightforward process since the systems are built to work with each other. Ex Libris Primo VE employs a central discovery index, which we use to enable our collections and provide access via proxy authentication. We also set up integration with our interlibrary loan (ILL) provider, OCLC’s Tipasa, so that non-owned materials viewed in discovery can be requested via ILL. Some vendors provide alternative ways to incorporate their collections into other discovery systems to increase visibility to those collections. This is something that should be considered during the ILS selection process, particularly if your library has key resources that you would like to highlight through your discovery platform.
Updating our discovery platform also provided an opportunity to design it using logos and color schemes that complement our library website. This creates consistency across our many web platforms so that when users search our discovery platform (via the OneSearch box on our homepage), it takes them to a page with a similar look and feel. From there, they can authenticate with the campus security assertion markup language (SAML) system (Google Suite for our campus)—similar to how our users authenticate to other campus platforms such as the internal website and learning management system (Moodle)—providing seamless access through single sign-on (SSO) functionality.
We began working with our campus IT department early on to discuss
potential integrations with campus systems. IT manages the student information system (Banner) that provides patron data and SAML authentication, which we use for authentication to the ILS as well as our proxy server and Tipasa ILL system (both hosted by OCLC). We scheduled a kickoff meeting to share the new platform, discuss needs, and establish timelines so that everyone knew what to expect and when.
Staff Training and Development
Determining staff training needs for the new ILS should be a priority, and any pre-migration training the vendor makes available should be included. Each team member should make a list of tasks performed within his or her department to ensure all elements get tested. You may find that routines need to change, such as determining a new label printing process or how to manage course reserves.
The staff training and development plan started with a libguide, which organized the required training for each library department based on Ex Libris’ Knowledge Center. This self-directed training included videos, recorded webinars, and documentation to begin learning the system prior to implementation. After going live, there was a cross-departmental training session in which staffers and faculty members demonstrated how to perform functions related to their department. With a small team, cross-training is vital.
Final Testing and Launch
At the final testing phase, clarify who is responsible for testing migrated data: the library or the vendor. This was not always clear in our experience. Make a list of important tasks to test after all data has been migrated. We were provided a file with sample searches and reports to run. This is how we determined data was missing, which was caused by a power surge during final migration. Other issues included library ID cards not scanning properly—compounded by vendor issues and our campus security system—resulting in manual updates to patron ID records until the issue was resolved.
The launch of our new system was scheduled for summer 2020 to minimize disruptions to the campus community. The July 7 launch date allowed our team time to familiarize themselves with the new system and troubleshoot any issues prior to the start of Eckerd’s fall term. The launch also had a communication plan for campus outreach. Our plan consisted of frequent emails starting 1 month out until the day of implementation. These emails provided links to training, video tutorials, and a how-to page with an FAQ section. A newly launched proactive chat feature also helped to address and quickly resolve any post-implementation support issues.
Conclusion and Lessons Learned
We learned many lessons during the migration process. Testing the data is very important to ensure all data migrates over to the new system. Having a backup or way to access your old ILS data is very helpful. Anticipate that some workarounds might be needed for integration with other vendor’s systems (such as ILL). And, finally, don’t expect to know all aspects of the new system right away; there is time to learn more about it later, once you’re working in it. Scheduling weekly check-ins with the library staffers is very important to keep everyone on track. The elements that make an ILS migration with a small team successful include pre-migration planning, forming strong vendor relationships, staff training, and detailed final testing.
|
