Theology Cataloging Bulletin
Vol. 24, No 2• February 2016 3-3 Section 3

TESTIMONY

Thinking of Migrating?

I am the head of the cataloging department at Murray State University and am part of the four-person core implementation 
team for migrating to a new integrated library system (ILS). As of the writing of this, we have been “live” in our new system 
for two weeks. Going live was a culmination of over a year of focused data cleanup and a six month implementation process. 
Even though all the data (bibliographic, acquisitions, and patron) is in the new system and all of our workflows and processes 
are starting to happen there, we are still deep in the migration process and will be for the next several months, at least. While 
I am sure that there are new lessons to be learned ahead of me, I have come through this portion of the migration process 
with some insights that are fresh on my mind. If you are considering migrating to a new system, you might benefit from these 
thoughts. All of my comments will be vendor-neutral as they are not limited to a specific vendor or system.

Have a good reason for migrating. Migration from one ILS to another is a complex process that carries risks as well as 
unforeseen consequences. The motivation behind the migration as well as the system’s capabilities and features should align 
with the mission of the library as well as the institution and not be the result of a personal or political agenda. It is crucial 
that staff understand how the new system will meet the goals of the mission in a better way than the current system does. 
When (not if ) they are frustrated by the learning curve, overwhelmed by the workload, or simply exhausted by the changes, 
staff can be encouraged by knowing that the effort is worth the outcome because it supports their ability to serve students 
and faculty as well as the mission.

Do not migrate with other libraries. Unless your library is joining a consortium or migrating as a consortium, there 
is very little benefit to be gained and a lot to be lost by migrating with additional libraries. We were one of eight Kentucky 
university libraries using the same system; we had separate databases but used the same server. Four of those libraries 
negotiated with the vendor of the new system as a group and were then scheduled by that vendor to implement the system 
together (still with separate databases). Coordinating the schedules of key people in four different libraries located in two 
time zones for weekly phone calls with the vendor was challenging enough. The loss of personal attention specific to our 
institution’s needs contributed to dissatisfaction and frustration with the migration process.

Clear the agenda of any other projects. Migrating to a different ILS is a big deal. To do it well takes time and attention, 
time and attention that staff should not feel they have to share with other big projects. If at all possible, wait to migrate 
until other projects are finished and don’t begin any new projects once the contract has been signed until the migration is 
complete. Additionally, pay attention to non-system related events going on in your staffs’ lives to avoid migrating when a 
key staff member will be on maternity leave, putting a tenure portfolio together, or managing some other life altering or time 
consuming event. While these types of circumstances can’t be completely avoided or foreseen, be aware that staff involved in 
major life changes may have a difficult time focusing their attention on a system migration.

Assign an optimistic and confident project manager. In a system migration, it is more important for the project 
manager to be an excellent communicator with a variety of stakeholders both inside and outside the library and university, 
to prioritize tasks and direct people, and to be highly organized than it is for them to have a particular job title. Knowledge 
of ILSs and data structure is also important but a job title should not be the only criteria used to determine who the project 
manager will be. Additionally, optimism and confidence go a long way toward providing a positive environment and instilling 
a can-do attitude while validating and encouraging when there are set-backs and challenges along the way.

Include a cataloger on the implementation team. The familiarity that a cataloger has with the bibliographic data 
and how the current system is configured to use that data is an asset that will tremendously aid the configuration process. 
While MARC records are MARC records no matter which system is in use, how elements of the MARC record are 
utilized in the new system may not be the same way they were utilized in the legacy system. Also, since item records are 
not standardized, the features and uses of item records are likely to be different from one system to the next. The cataloger’s 
awareness of the use of the components of records will help ensure the necessary data is in the right place in the new system. 



Theology Cataloging Bulletin
Vol. 24, No 2• February 2016 3-4 Section 3

Additionally, being part of the implementation team will give the cataloger a better understanding of the system as a whole 
facilitating better training, easier troubleshooting, and quicker functionality implementation.

Start early with data cleanup. If the data is not good in your current system, it is not going to get better in the next 
system and may even be problematic when it comes to migrating the data. Whether or not data cleanup has been part of 
the normal workflows of the cataloging department, now is the time to prioritize it and the sooner the better. As much as 
possible, eliminate unnecessary data and standardize the rest. Utilize the reporting capability of your system to find problems 
that need to be resolved. You may be surprised at the type of problems you can find even in standardized reports. Vendors 
might suggest that data cleanup can wait until after migration as it might be easier to do in the new system; however, 
sometimes it is just more convenient to get work accomplished in a system with which you are familiar. It is difficult to know 
how long it will take you to learn how to run reports or make batch edits in the new system. While you still have access to 
the data in the legacy system, run reports that will help with ongoing data cleanup being mindful that data in the legacy 
system will be increasingly out of date and inaccurate. However, familiarity with running reports in the legacy system gives 
you confidence in the results of those reports that is lacking when running reports in a new and unfamiliar system. Finally, 
be aware that once implementation gets underway, configuration, testing, and training will begin to consume whatever time 
you had for data cleanup.

Have a supportive Dean or Library Director who will advocate for you. Last, but certainly not least, a Library 
Director who is willing to intervene with external constituents is your ace in the hole. If the training provided by the vendor 
is insufficient or the IT department is not responding to emails requesting IP addresses, a skilled Library Director may be 
able to make a phone call or schedule a meeting that will result in improved communication and response time or even an 
on-site trainer.

All in all, our migration went and continues to go fairly smoothly, to one degree or another. That is pretty ambiguous, isn’t 
it? We did not have any big problems with the bibliographic data but getting user data from our registration system into the 
ILS was problematic. Thank goodness I deal with bibliographic data! Now begins the process of becoming as familiar with 
the new system as I was with the old. I’m sure in a few years I’ll be able to give you a more straightforward answer about how 
the migration went and may even have some more insights to share.

Submitted by
Leslie Engelson
Metadata Librarian, Murray State University