Vol. 20, No. 7 • July/August 2000

• FEATURE • Managing the Transition to a New Library Catalog: Tips for Smooth Sailing by William Doering

In this article, I’ll offer some strategies for pulling off a successful migration. My particular experience has been in a university library environment, though many of my tactics can be easily adapted to other settings.

Because each institution has unique political and organizational dynamics and professional experience and expertise, there is no one way to implement a new library catalog. But after installing three different systems at two different academic institutions in the last 10 years, I have learned some of the characteristics of a successful migration. I have the advantage of a cataloging background, which has proven to be invaluable during test loads and deciding which MARC fields to display in the OPAC. But even more important than the technical details of the project is being able to manage a project and lead staff in a team environment.
 

Getting Your Team on Board
Involving the library staff in the selection process is important for several reasons. First, if staff members were a part of the selection process, they will have geared up mentally for the task of migration, and hopefully, they will have allocated their work so as to set aside time for the process. They will also have a sense of ownership in the new system. They may not agree with the selection, but they will feel a part of the decision. And last, they will be more motivated to help with the implementation.

Your staff members are your greatest allies. If they feel they are a part of the process, they will want to help. Use this to your advantage. Let them know where they can help, what role they play in the process, what their deadlines are, and that they’re doing a good job. Any new system will not improve every aspect of your existing system, so some employees may end up with some frustrating tasks. But if they are involved in the process up front, hopefully they will see the big picture and will persevere.

It is important to divide up the projects (looking at policies, data migration, and filling out migration questionnaires) among the staff, but these need to be working groups of people. One person cannot and should not do everything. And most systems are too complex for one person to have all the expertise. Make sure each working group has broad representation from the entire library, and that good communication flows between groups.
 

Be a Seaworthy Captain
It is imperative that one person be ultimately responsible for the migration and that he or she be organized. This is a highly personal issue. Each of us has different organizational habits and tendencies, so it’s the bottom line that’s important. In my case, I found that I needed to be able to put my finger on a certain document quickly, to respond to questions in a timely manner, and to remember what the status of many things was at all times. And, I needed to constantly be aware of the timeline. How you organize yourself is up to you, but be organized. Consider using specialized software to help manage the timeline.

An efficient migration will involve multiple layers of structure for decision making. There are times when you need to call a meeting to decide on an issue. There are times when you just ask a couple of key players and go with a decision. And there are times when you just have to make your own decision so the whole migration isn’t stalled in politics or debate. It is so easy to get bogged down in the process because it can seem overwhelming, but remember that most of the decisions you make aren’t written in stone. They can be changed later if necessary.

Also, instead of having endless full-staff meetings where most of the people attending don’t know a thing about the topic or about its effect on the OPAC or other modules, ask those who do know in an informal way and go with their suggestion, or go with your own instinct. After the new system is operational, you can readdress some of these issues. Spend your time on the big issues that are difficult, impossible to change later, or that are required to get the project accomplished.

To make the migration process manageable, I highly recommend hiring additional staff, increasing staff appointments, or at least hiring additional students for the migration process. Besides the enormous task of the migration process, there are still day-to-day activities to accomplish. We can’t stop buying, cataloging, or servicing our collections, yet we have to add the huge load of moving data to a new library catalog.

Almost every library employee will be affected by the new catalog. In addition to the actual migration, there will be clean-up projects, rekeying data, catching up on backlog created during down time, verifying loads, training, creating new policies and procedures, and publicity and communication to the clientele. Getting approval for additional man-hours can help maintain existing work flows as well as the migration work. Additional hours will also be a huge relief to existing employees who are already fretting about all the work there is to do in the short time frame.
 

Communicate the Timeline
Overseeing an entire migration project can be overwhelming, so break down the migration into smaller projects and place them into a timeline with deadlines. Most project deadlines should only be viewed as a target, but be sure to include the anchor events, which are set and cannot easily be changed to different dates. Anchor events might include vendor training or cutting off the old system; other items in the timeline then revolve around these events. The anchor events provide leverage, both inside and outside the library, goals, successes, and stability throughout the entire migration. Knowing what has to be done when is essential, for you and the entire staff. Update the timeline frequently, and share it widely.

It is essential that all employees know the current status of the migration: what is happening today, tomorrow, next week, and next month. Holding frequent meetings is always an option, but I have found that an all-staff e-mail once a week is better. Highlight what’s important, what was accomplished, what the road blocks ahead are, and a detailed timeline. Though the timeline may change with each e-mail, it is important that one exists, and that it be communicated, updated, and followed. Communication between and within the working groups, as well as with administration, is also important.
 

Make Training Work
Most vendors will offer training on the new system’s operation at an additional cost. Buy as much vendor training as you can afford, but because it is typically expensive, chances are that you won’t be able to afford enough. As a result, the training naturally concentrates more on the big picture and less on the detailed specifics of the system and how it works. The other result of the high cost of vendor training is that you can’t afford to include as many staff as you’d like.

Because being a trainer can be stressful (always on the road, being expected to be an expert in all modules, always in front of a class, and trying to learn new releases while on the road), vendors typically see high personnel turnover rates among trainers. So, make sure you get a well-trained trainer. Send questions and expectations to the trainer ahead of time so he or she has time to prepare. I have also found it beneficial to struggle a little with the product before I attend the training. That way I can ask pointed questions regarding the problems I’ve encountered. Also, that way the session can take less time with step-by-step basic usage and can focus instead on what’s not intuitive. Last, be prepared to follow up any vendor training with in-house training.
 

Design Good Testing Data
I have found it extremely helpful to have data prepared for testing and a checklist of potential problem items to look at during the implementation process. There will be numerous times in the migration process that the vendor will want you to test a data load. If you don’t have any examples in place beforehand, you won’t have anything to compare it to. The load may look fine, but is all the data present? Is everything in the appropriate fields? Did the vendor follow all of the requested specifications?

It is essential to have specific examples that can be used to examine pre- and post-load data quickly and thoroughly. See the sidebar for specific things I have found useful. You could also create problem records, which can be tested to assure that the vendor is dealing with incorrect data correctly. It’s also a good idea to have a total number of records for each type of data you are migrating (bibliographic, authority, items, holdings, patron, vendor, open orders, fund, and outstanding circulation transactions) so you know if the expected number of records actually migrate.
 

Client Involvement
Should faculty and students (or your users in general) be involved? There are many schools of thought on this one, and the answer probably depends greatly on your local climate. Typically, the faculty and students won’t have a clue about the migration problems or solutions.

However, involving your constituents will help them understand how complex a migration really is. It will also get them on board, help spread the word, and may even help build library support. Involving faculty and students in the selection process would of course be the ideal. But, failing that, you should at least keep them informed, make sure they are trained, and involve them in the look and feel of the new OPAC. Your own student assistants will provide the most useful suggestions, so use them as a focus group.
 

The New System Going Live
No doubt, you will not be able to get everything done by the date you go live. In addition, there are some things (like what fields to index and display and adding graphics to the Web OPAC) that you can make more informed decisions about after you fully understand the implications of the decision. Perhaps the easiest things to hold off on are new services the system will provide. New services are probably why you bought the system that you did, but do they need to be activated right away? Could things like self check-out, patron placed services, EDI, and cataloging of images and sound clips be postponed slightly? It is important to set realistic priorities and communicate that other features will have to wait until you get to them in post-production.

When do you shut down the old system? This is a real balancing act. On one hand, you will be paying maintenance on two systems during any overlap period. This may be something you can’t afford. Yet, there is usually some information that can’t be migrated and needs to be retained long enough to see another process through or until it can be rekeyed. My belief is that it is cheaper to hire temporary staff to rekey data into the new system or to save data you know will not migrate in paper or electronic form than it is to keep the old system active until existing staff has time to deal with non-migrated data. Typically 1 to 2 months of overlap between systems seems reasonable. You might consider phasing out the old system by canceling aspects of the software, maintenance, or operating system while retaining only the aspects you still need.
 

What Can You Do Early?
Some things can be done ahead of time. If you need higher levels of computers or particular software, get them installed before the migration if you can. Prepare the equipment room with any required electrical, data, and HVAC needs. Start examining policies in circulation. A new system will not have all of the same functionality and options. Depending on what is available in the new system, policies, especially circulation policies, will most likely have to change. Additionally, this is a great time to change policies that will no longer make sense. Anything you can do ahead of time will make your life that much easier during the migration.
 
 

Things to Look for When Testing Data Bibliographic records for each location Periodical payment data, receipt notes, check-ins, and action dates Acquisition payment data, receipt notes, and action dates Long bibliographic records Long bibliographic fields such as 520 and 505 tags Bibliographic records with several copies in various locations Bibliographic records with many attached items Long authority records All MARC formats (videos, CDs, microfiche, music ...) Patron records (status, active, address, fines, active transactions) Call numbers with semicolons, or of atypical origin Order records Suppressed records should still be suppressed Provisional records Claim notes and action dates Open orders by type (continuation ...) and prices Diacritics in authority and bibliographic records 949 fields of bibliographic record Unlinked items or short MARC records Copy holding notes and 852, 866, 867, 868, and 899 fields Long and/or complex call numbers (government documents, Dewey, Cutter) Existing system control numbers

Vendor Communication
Keeping the vendor in line can be difficult. But vendors are your allies, so use them to your advantage. They know the new system better than anyone else. They are used to migrating data, and they probably have experience in migrating libraries from your current system. However, you must keep on top of them. If they are not getting back to you, give them a call. Don’t sit back and wait. If you need something and their only response is, “We can’t do that,” ask them why. Make sure you get your questions answered. Remember that the vendor is most likely working on multiple installations at the same time; they often won’t have time to pursue your questions fully, unless you ask the question several times. Be fair with the vendor; don’t expect the world, but be firm on what your needs are. After migration, re-read and verify that all vendor promises have been met by going through your request for proposal (RFP) and the binding contract. If you wait too long, these agreements may be null and void.

Try to resolve as many outstanding problems and transactions in the existing system before your data extraction. Although the vendor should be able to migrate open orders, checked-out items, holds, recalls, and bindery shipments, there are exceptions. My rule is the fewer the number of exceptions, the better. Consider ceasing the shipment of materials out on ILL, suspending a bindery shipment, forgiving low-dollar fines, not allowing renewals, or renewing items set to be due near the migration date. In addition, perform as many purges as possible to get rid of unwanted patron records and logically deleted but not purged bibliographic, holding, and item records. In every migration I have experienced strange phenomena with outstanding transactions. They’ve never been serious, but a little work up front can save you tenfold later.

You must know your data. Your new vendor will have migration questionnaire sheets for you to fill out, which ask detailed questions as to how you want certain data from your existing system handled. If you don’t know your current data and your local practices, you’re in trouble. You can usually ask your vendor to change blocks of records during the migration. This is also a great time to clean things up that your previous system couldn’t handle or change.
 

A Successful Voyage
We all understand the amount of technical work that will occur during a migration. However, we usually forget the equally important aspect of organizing the project so that the migration is accomplished in an effective and efficient manner. Too often we attempt to accomplish this by setting up committees to oversee the migration. Yet, this alone does not involve enough staff members with expertise. A successful project can only be achieved by bringing the entire library staff together so that the strengths of each employee are maximized in such a way that the migration process is not bogged down. Most important of all is communication—communication of what each person’s role is in the migration; what is going on; and when specific tasks, decisions, and training are to be accomplished. And, of course food and other diversions are good too!l
 
 

William Doering is the integrated systems librarian at the University of Wisconsin–La Crosse and has worked previously at DePauw University (cataloging) and Luther College (cataloging and systems). He received a master’s degree in library and information studies from the University of Wisconsin. His e-mail address is doering.will@uwlax.edu.
 

Resources
Carter, Nancy and Scott Seaman. “Circulation Policy Issues and System Migration: You Can’t Beat a Move for Cleaning House.” Colorado Libraries, Winter 1997, pp. 32–35.
Cleyle, Susan. “Avoiding the Implementation Blues.” Feliciter, Vol. 42, 1996, pp. 32–36.
Copland, Nora S., James F. Farmer, and Patricia A. Smith. “Data Migration: A Brief Primer.” Colorado Libraries, Winter 1997, pp. 22–24.
Culbertson, Michael. “The Training Aspects of System Migration.” Colorado Libraries, Winter 1997, pp. 28–30.
Garrison, William A. “Issues in System Implementation.” Colorado Libraries, Winter 1997, pp. 13–16.