iven the recent spate of library system vendor ac-quisitions and consolidations, integrated library

system (ILS) migrations have become a hot topic again.OAlthough ILS migrations happen all the time, they tend

to be cyclical in nature. For example, in the late 1980s,a large number of libraries migrated from homegrownsystems to vendor-provided solutions. About 10 yearslater, in the latter part of the 1990s, a large number ofmigrations occurred again as the underlying technologymoved from being mainframe-based to the distributed,Web-based systems we have today

Although the individual circumstances that spur amigration vary from one library to another, a great de-gree of this renewed interest is being driven by dis-content with current-generation systems and the ven-dor practices that have arisen in this era of vendorconsolidation. Most of us can identify with the irrita-tion a person might feel when a viable system isyanked from the market as the result of a merger be-tween vendors. Perhaps even more frustrating is whenthe suggested replacement system is nothing morethan old technology repackaged with minimal im-provements that still doesn't adequately address theneeds of your library anyway.

It's not surprising then that many of the customerswho feel they have not been dealt with fairly are re-considering their options and checking out the wholefield of replacement-system candidates. Today, peopleare thinking broadly about what options might beavailable to them. These include changing vendors,using systems not traditionally associated with a par-

ticular library segment, or joining an open source ILScommunity. In the current marketplace, nothing is be-yond consideration.

These migrations, however, are distinguished fromthe efforts that many libraries are undertaking to im-plement new systems for gaining additional function-ality, such as next-generation catalogs. 1 While thesenext-gen implementations are closely related to theunderlying problems and general dissatisfaction withtraditional systems, they are distinct from the currentILS migration trend. The primary reason for this isthat next-gen system implementations do not, in mostcases, replace the library management back-end sys-tem, but instead graft new front-end, patron-facingcomponents to the in-place ILS.

Issues You Should Consider

Not surprisingly, this new round of system migra-tions raises a unique set of problems for libraries. Formany of us, it's difficult to recall the issues related tomigrating from one system to another because theprocess is but a distant memory, one we'd often like toforget. Our forgetfulness may be driven, to a great de-gree, by the fact that converting from one system toanother is a time-consuming and generally thanklesstask. Further muddying the water is that in the cur-rent environment, most migrations will not reallyleave us in a much better place (from a functional per-spective) than we are today. Primarily, this is becausethere's little true functional difference between ILSs,

Ip

UTERS IN LIBRARIES

LS migration in the 21st century

except for differences in functionalitywithin broad categories of systemtypes (i.e., systems designed primar-ily for public libraries as opposed toacademic libraries).

SMigrating from a current-generationsystem may provide minor improve-ments, but it's not likely to significantlyenhance the ability to better meet pa-tron needs. Even with significant newfunctionality, a migration raises thereal possibility of creating distress inthe patron community 2 that may re-flect poorly on the library.

The reality is that the major factordriving migrations today is the pro-mise of a new system that will be sup-ported by the vendor for the long-term.Given the state of the marketplace,most promises to this effect are ques-tionable, at best. In such an uncertainenvironment, we need to think care-fully about whether we stay with ourcurrent vendor or choose another beforeivesting the time and trouble to mi-grate to a completely new system. In,ome cases, the most reasonableway to proceed may be to fol-ow the migration path of ourarrent vendor. The following are someIctors to consider with the two options:

SIs your current vendor a viable com-rercial entity? If it doesn't have neces-Sfinancial backing and market share

Scontinue to enhance its products, it'sme to look for a new vendor. Investi-

Yate sources such as Marshall Breed-ig's annual "Automation Marketplace"sport3 to gather information on theinancial stability of your vendor.

i Is your current vendor investing inaew technology? If it's cutting back on,ew system development and puttingnore effort into small incremental im-rovements in an existing system, this:,uld be a danger sign. Most current-oneration ILSs will need major func-Jonal overhauls to make them work4fectively with emerging standards,kuch as FRBR,4 SRU, 5 and MXG. 6 Ad-

ditionally, they will need to have re-designed patron interfaces that willprovide seamless integration with thelarger world of information resources.If your vendor is not focusing on theseissues, consider finding a new one.

* Is your vendor independently owned?While it's no guarantee of stability, fi-nancially steady, independently ownedILS vendors stand a better chance of notbeing buffeted by the changing whimsof a corporate entity that's interestedonly in return on investment.

• Most likely though, yourvendor is not an in-dependent company.In that case, is itsparent companytruly investedin providing

systemsand services for

libraries and information agencies?Does the corporate integration strategymake sense? There's nothing inher-ently wrong with a vendor being partof a larger entity. However, those thatare can be influenced by many factorsoutside of the library marketplace. Oneimportant factor in evaluating a ven-dor in this situation is how well the li-brary services integrate with the over-all strategy of the larger corporation.If there does not seem to be any logi-cal connection, there probably is not.And the danger is that when profitabil-ity dips, the library unit will be a primecandidate for a sell-off.

Use a Fresh Perspective

If, after weighing the pros and cons,your library decides to move forwardwith a migration, it would be well worth

looking at the system requirements pro-cess with a different perspective.

In the past, library systems havebeen evaluated along very standardizedlines, such as developing requirementsfor circulation, acquisitions, serials, andOPAC components. This approach, how-ever, does not take into account eitherthe continuously evolving way our li-braries work or the rapidly increasingservice expectations of our patrons.

In 2003, people at the National Li-brary of Australia 7 used a different ap-proach when considering a large-scalesystem replacement project. Their workis a model for a new perspective on howlibraries provide and deliver services.In the original requirements, the focuswas more on outcomes than functions,and there were four subsystems. In to-day's environment, this focus on out-comes still stands, but the four sub-systems would be described slightlydifferently, with expanded functionality.However, the core purposes remain es-

sentially the same.The following are the

four updated descriptions:

1. Bibliographic subsystem-This pro-vides many of the functions one wouldexpect in a traditional cataloging mod-ule, with serials integrated into theworkflow as simply another materialtype. The subsystem supports the in-take, creation, and editing of biblio-graphic, authority, and holdings data.In this model, the focus is not on MARCformat data, but on any type of de-scriptive metadata.

2. Search subsystem-This subsystemfunctions in many ways and providessimilar services to the traditional OPAC.But in addition to discovering local ma-terial, it would also have functionalitysimilar to federated searching in orderto provide an integrated view of the re-sources that are available to the patron.

3. Customer management subsystem-This is similar in function to traditional

continued on page 60 »

GjUST2007Th ý,i,,iý't.dy.

i COMPUTERS IN LIBRARIESfeature: ILS migration in the 21st century

<< continued from page 8

administration and access-control sys-tems. The difference is that rather thanset up an individual silo of data, it'sfully integrated with other institutional

systems. This allows library staff mem-bers to leverage knowledge they al-ready have with similar tools (such asreporting) that are used across orga-

Tyia Tak in a Syte MirtonEfr

SYTE SELECTIO

Function s an fetrs wokru

Tetn workgroup.

Dat covrso workgroup S - S

Docum entto an training S

Drf vrrhn gol fo n0 w syStem

Sc ed l sit visitsSe

Pefr evlato demo on vedrts ytm

Cotrc Neotato

IMPLEMNTATIO

Syte -configuration

De-velop an imlmn data covrinseiiain

Deeo dat tetn procedures

Ore an istl ne hadwr

Insal test veso of ne system

Develo tes scit fo crtia fucinlt points

Develo scit fo tetn typic0 fucioa sitution

Deeo scrpt fo6. tn bom lfucinlstain

Insal tes database -

Peror tetn for tyia an abnrma Sitain

Pefr syte pefrac (sres testing

Conduc trinn fo prdcto staff S

Vedo prvie triigfri-ouetann tf

Tri library -staff

Crat loa ou ettinfnee

SYTE CUOVER0 5

Intl production databas

Test~ syte usn Sorma a abora siutocit

Enbl geea tfSn ulcacs osse

nizational systems (such as financialmanagement systems, student infor-mation systems, etc.).

4. Document delivery subsystem-Ata very basic level, this subsystem pro-vides a seamless interface for bothstaffers and patrons to request anduse materials held at other libraries.In the academic environment, coursereserve materials would be integratedinto this unified electronic documentdelivery system.

Steps Involved in Migration

With this general framework inmind, we can consider the steps in-volved in migrating to a new system. Ingeneral, there are three major phases:

1. System selections-In this phase,the library establishes the major work-ing groups for the migration effort, de-termines the functional requirements,and evaluates the suitability of severalsystems (given the requirements).

2. Implementation-This is where thelibrary performs the majority of themigration work. In this phase, staffersconfigure the system, convert datafrom the old system, test the new sys-tem, and receive training.

3. Production stabilization-This isperhaps the most often overlooked partof the migration. Staffers throughoutthe library work through the remain-ing issues of the migration effort.

The sidebar (left) outlines some ofthe major tasks that are typically per-formed in a migration. It's beyond thescope of this article to comment oneach step in detail, but the followingare some things to keep in mind as youplan your conversion:

1. Establishing functional workinggroups early on in the project is a crit-ical factor in overall project success.

COMPUTERS IN LIBRARIES

feature: ILS migration in the 21st century

r 2. Rather than

have very smallroups that focus

on specific functionalareas, try to use larger,

cross-functional teams

P..

W that focus on all aspectsof higher-level functional is-

sues. For instance, appoint a team to

handle general data conversion insteadof having one team specifically for theconversion of MARC data and anotherfor circulation data. Furthermore, don'tbe afraid to invite some "nonexperts"to the team. They may just be the cat-

alyst to get people thinking in new anddifferent ways.

3. Optimize your use of Web conferenc-ing technology for demos. It's often eas-ier to schedule shorter demonstrationsof specific functionalities at differenttimes than to get everyone together onthe same day for a massive demonstra-tion of every single feature in the sys-tem. This also facilitates focusing onspecific issues of importance ratherthan trying to address everything (andprobably not well) all at once.

4. Make sure there's plenty of oppor-tunity for staff and patron input. Thisincludes providing multiple methodsfor gathering this feedback. Don't justrely on a questionnaire or survey. Holda few focus groups or all-staff meetingsto discuss issues.

5. Expect that the contract-negotia-tion process will take longer than youanticipate.

6. Develop testing scripts that includesituations which are outside of normalworkflow patterns. Testing the odd casesis typically more informative than test-ing the routine.

7. Stress-test the system before goinginto production. Consider using auto-mated tools to simulate transactions. Seebelow for a list of some of these tools.

8. Don't neglect training. For a goodoverview of the issues to think about inthis area, I suggest consulting Ralston,Rioux, and Ellis' article "With FeetPlanted Firmly in Mid-Air: Staff Train-ing for Automation System Migration."1

9. Brace for a long day when the finalproduction cutover occurs.

-1I I ~ .

10. Warn staff that the weeks after themigration will be fraught with minorproblems and inconveniences as thesmall details are worked out. Regard-less of how well your migration goes,there are going to be issues afterward.

Timing Is Up in the Air

The astute reader will note that Ihave not provided any time estimatesfor the tasks in the sidebar. This is be-cause devising a one-size-fits-all time-line is difficult. Without understand-ing the context of the implementation,it's impossible to give reasonable timeestimates for planning purposes. Inmy experience, new system implemen-tations at smaller libraries were oftenperformed in as little as 7 months,but one implementation at a verylarge institution ran more than 2 years.Further complicating matters, as notwo libraries are alike, each of thesephases will take a different amount oftime to complete depending on the in-dividual institution.

However, based on an analysis of sev-eral installation plans, I calculate thata library can expect to spend approxi-mately 32 percent of its project time inthe selection phase, 48 percent in theimplementation phase, and about 20percent in the production stabilizationphase. So at a medium-sized academiclibrary, where the entire installationwould take a year, the timeline wouldwork out to almost 4 months for systemselection, 6 months for implementation,and a little less than 2 months to sta-bilize the system once it's in production.

Given the cyclical nature of thesetypes of conversions, it's not surprisingthat we're seeing a resurgence in sys-tem migrations. Significant changes inthe library system vendor landscapeare leading many institutions to re-consider what the future really holdsfor their ILS. But migrations like theseare not to be entered into lightly. AsI've explained, the process is complex,time-consuming, and expensive. One

owwiwfotoday.com << JULY/AUGUST 2007 61

i COMPUTERS IN LIBRARIES

feature: ILS migration in the 21st century

Is;7rone l

62 1JULY/AUGUST 2007 w. invc.infotoday.

- important consideration that shouldbe factored into any decision is whetherthe new system will have substantiallynew functionality that will better servepatrons. If there's no benefit to be hadin this area, then the wisest decisionmight be to wait awhile until a system

AARKETINGLibrary Marketing Library Services comes along that will provideP.%°oM`'•'•h • The "How-To" Marketing Tool new functionality.

Written Exclusively for Librarians

The Marketing Library Servicesnewsletter is the premier source of Frank Cervone is the assistant uni-ideas and news for savvy library versity librarian for information tech-

marketers. Whether you work in a nology at Northwestern University in

corporate, special, academic, school, Evanston, Ill. For several years, he wasa chief systems engineer at NOTIS Sys-or public library, MIS will help you tems, where he was intimately involved

call attention to your library, your ser- in many system migration projects. Hevices, and your value to the has an M.S.Ed. in online teaching andcommunity you serve, learning from the California State Uni-

versity-East Bay, an M.A. in informa-MLS will provide you with valuable tion technology management from De-how-to information on developing Paul University in Chicago, and a Ph.D.

Umarketing strategies, creating in management from Northcentral Uni-marketing materials, organizing versity. His email address is f-cervone@

Straffic-generating programs, acquiring northwestern. edu.

library funding, and so much more.

Endnotes1. Antelman, K., Lynema, E., and Pace, A.K. (2006). "Toward

a Twenty-First Century Library Catalog," Information

Technology& Libraries, 25(3), pp. 128-139.2. Probst, L. and Pelikan, M. (2006). "Listening to Our Users:

System Migration and the Evaluation of Web-Based Library

Services," The Reference Librarian, 95/96 (2006), pp. 37-51.3. Breeding, M. (2007). "An Industry Redefined: Automation

a • Marketplace 2007," Librarylournal, 132(6), pp. 36-48.* 4. Tilleft, B. (2004). What is FRBR?A Conceptual Model for

the Bibliographic Universe. Washington, D.C.: Library ofCongress. Retrieved May 24, 2007, from www.loc.gov/cds/

downloads/FRBR.PDF.5. SRU: Search/Retrieve via URL. Retrieved May 24, 2007,

from www.Ioc.gov/standards/sru.6. National Information Standards Organization. (2005).

Metasearch XML Gateway Implementor's Guide, Version1.0. Bethesda, Md.: NISO. Retrieved May 24, 2007, fromwww.niso.orglstandards/resources/MI-MXG_v1 O.pdf.

7 National Library of Australia. (n.d.). Redevelopment of theLibraries Australia System. Retrieved May 24, 2007, fromwvw.nla.gov.au/librariesaustralia/redevannounce.html.

8. Ralston, R., Rioux, M.A., and Ellis, K.D. (1999). -With FeetPlanted Firmly in Mid-Air: Staff Training for AutomationSystem Migration," The Serials Librarian 36(3/4), pp. 407-413.

COPYRIGHT INFORMATION

TITLE: In the 21st Century: Some New Things to Think AboutThis Time Around

SOURCE: Comput Libr 27 no7 Jl/Ag 2007

The magazine publisher is the copyright holder of this article and itis reproduced with permission. Further reproduction of this article inviolation of the copyright is prohibited. To contact he publisher:http://www.infotoday.com/