Experiences of Migrating to an Open- Source Integrated Library System Vandana Singh INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 36 ABSTRACT Interest in migrating to open-source integrated library systems is continually growing in libraries. Along with the interest, lack of empirical research and evidence to compare the process of migration brings a lot of anxiety to the interested librarians. In this research, twenty librarians who have worked in libraries that migrated to open-source integrated library system (ILS) or are in the process of migrating were interviewed. The interviews focused on their experiences and the lessons learned in the process of migration. The results from the interviews are used to create guidelines/best practices for each stage of the adoption process of an open-source ILS. These guidelines will be helpful for librarians who want to research and adopt an open-source ILS. INTRODUCTION Open-source software (OSS) has become increasingly popular in libraries, and every year more libraries migrate to an open-source integrated library system.1 While there many discrete open- source applications used by libraries, this paper focuses on the integrated library system (ILS), which supports core operations at most libraries. The two most popular open-source ILSs in the United States are Koha and Evergreen, and they are being positioned as alternatives to proprietary ILSs. 2 As open-source software becomes more widely used, it is not enough just to identify which software is the most appropriate for libraries, but it is also important to identify best practices, common problems, and misconceptions with the adoption of these software packages. The literature on open-source ILSs is usually in the form of a case study from an individual library or a detailed account of one or two aspects of the process of selection, migration, and adoption. In our interactions with librarians from across the country, we found that there are no consolidated resources for researching different open-source ILSs and for sharing the experiences of the people using them. Librarians who are interested in open-source ILS cannot find one resource that can give them an overview of the necessary information related to open-source ILSs. In this research, we interviewed twenty librarians from different types and sizes of libraries and gathered their experiences to create generalized guidelines for the adoption of open-source ILSs. These guidelines are at a broader level than one single case study and cover all the different stages of the adoption lifecycle. The experiences of librarians are useful for people who are evaluating open- source ILSs as well as those who are in the process of adoption. Learning from their experiences will help librarians to not have to reinvent the wheel. This type of research helps the librarians by empowering them with the information they need; also, it helps us in understanding the current status of this popular software. Vandana Singh (vandana@utk.edu) is Assistant Professor, School of Information Sciences, University of Tennessee, Knoxville, Tennessee. mailto:vandana@utk.edu EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 37 LITERATURE REVIEW As mentioned earlier, most of the literature on open-source ILS is practitioner-based and provides case studies or single steps in the process of adoption. These research studies and resources are useful but do not address the broad information needs of the librarians who are researching the topic of open-source ILSs. Every library is different, so no two libraries are going to take the same path in the adoption process. The usefulness of these articles depends on whether the searcher can find one in a similar environment. Another issue is the amount of information given in these resources. Often these papers discuss only one aspect of moving to an open-source ILS, for example choosing the open-source ILS. If they do cover the whole process, there is usually not enough detail to know how they did it. For example, Morton-Owens, Hanson, and Walls organize their paper into five sections: motivation and requirements analysis, software selection, configuration, training, and maintenance. 3 However, each section includes more main points than description. Another relevant stream of literature includes those that compare different open- source ILSs. These range from little more than links to different open-source projects to in-depth comparisons.4 For example, Muller evaluated open-source communities for different ILSs on forty criteria and then compared the ILS on over eight hundred functions and features.5 These types of articles are very useful for those who are trying to become acquainted with the different open- source ILSs that are available and are in the evaluation phase of the process. Again, they are not helpful in understanding the entire process of adoption. Some best practices articles such as Tennant may be a little older, but his nine tips are still valid and very useful as a good foundation for anyone thinking about making the switch to open-source ILS.6 What Are the Factors for Moving to an Open-Source ILS? Another reason why an open-source ILS appeals to libraries is its underlying philosophy: “Open source and open access are philosophically linked to intellectual freedom, which is ultimately the mission of libraries.” 7 The other two common reasons are cost and functionality. The literature covering the decision to move to an open-source ILS makes it clear that there is a wide variety of ways that libraries come to this decision. In Espiau-Bechetoille, Bernon, Bruley, and Mousin, the consortium made the decision in four parts. 8 The article states that they initially determined that four open-source ILSs met their needs (Koha, Emilda, Gnuteca and Evergreen), although it is somewhat vague as to how they determined that Koha was the best for their situation. Indeed, most of the article is about how the three libraries involved had to work together, coordinating and dividing responsibilities. Bissels shares that money was the main reason that the Complementary and Alternative Medicine Library and Information Service (CAMLIS) decided to migrate to Koha.9 They explain the process of making that decision. CAMLIS was being developed from nothing, which makes their situation different than most libraries, and hence the process is different as well. Michigan is an area known for its number of Evergreen libraries. Much of that is due to Michigan Library Consortium. Dykhuis explains the long, involved process that led to a number of Evergreen installations. 10 MLC provides services to Michigan INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 38 libraries, such as training and support. When they started looking for an ILS system that all libraries could use, the main concerns were cost and functionality, which are the two key aspects that are mentioned in any discussion about choosing an ILS. Kohn and McCloy state that they decided to migrate to a new ILS due to frustration with their current ILS and that they involved all six of their librarians in the decision-making process.11 Dennison and Lewis show another reason why people migrate to open-source ILS.12 They say that the proprietary system they were using was much more complicated than they needed. In addition, because of staff turnover no one really understood the system. This lack of expertise combined with increasing annual costs led to the decision to move to an open-source ILS. An important lesson to take from this article is that they included all six of their librarians in the decision- making process. For a smaller library where everyone is an expert in their area of the library, it is important to get everyone involved in order to make sure that important functions or needed capabilities are not overlooked. Almost any library that chooses open-source ILS will name cost as one of their primary reasons. Functionality is usually what determines which ILS they choose. Riewe conducted a study where he asked why each library chose its current ILS. 13 Open source libraries responded most often with ability to customize, the freedom from vendor lock-in, portability, and cost. How does Migration Happen? There are two general ways to do a migration: all at once or in stages. Kohn and McCloy discuss a three-phase migration.14 The reason for this method was to spread the cost over several years. They did the public website and federated catalog as phase one and did the backend part during phases two and three. When multiple libraries are involved, phased migration is more like what is described in Dykhuis.15 In that case, first a pilot program was created where a few libraries migrated over to the new system. When that was successful, then more libraries migrated. In contrast to a phased migration, Walls discusses a migration completed in three months.16 This time includes installation, testing, and configuration. One interesting decision they made was to migrate at the end of the fiscal year in order to limit the amount of acquisitions data to be migrated. Dennison and Lewis completed their migration in two months. In this migration, most of the work was done by the company that was hosting their system. 17 This limited the amount of expertise that the library staff needed and made the migration much smoother from their perspective. Migration can also be an opportunity; for example, Morton-Owens, Hanson, and Walls mention that they used the migration to Koha to synchronize circulation rules between the branches. 18 It was also used to weed out inactive patrons (anyone who had not used the library in two years). Data migration can be a problem, though. In the old system, the location code had been used for where the item was within the branch library, what kind of item it was, and how it circulated, but EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 39 these are three separate fields in Koha. However, to some extent these issues are true of any migration between different systems. The migration experience is not always of a smooth transition. One of the advantages of open- source is the ability to customize and to develop functions that are specific to your library. In the case of New York Academy of Medicine Library (NYAM) working with its consortium WALDO (Westchester Academic Library Directors Organization), it was the decision to have developments completed before migration that caused the problems.19 Their migration schedule was delayed by a month, and even after the delay not all of the eleven key features were complete. In addition, their migration took place when LibLime (a proprietary vendor) with whom they were working announced their separation from the Koha open-source community, which caused additional confusion. There are a couple of lessons to take from this. First, if doing development, be sure that the time needed is built into the migration schedule. Also, when choosing an ILS, think about how many developments are going to be necessary to successfully run the ILS in your environment. Lastly, try to prioritize the developments to minimize the number needed before “going live.” What Does the Literature Say about Training? Very little is available about the training process for open-source ILS. In current studies, training can be done in two ways: either by buying training from a vendor, or doing it internally.20 Dennison and Lewis found that having staff work on the system together at first and then try it independently was the most successful. 21 They had a demonstration system to practice, which also helped. In addition to this self-training, they had onsite training done by module, which allowed staff to attend only the training that was relevant and needed for them. In all of the articles discussed in this section, only one talks about ongoing maintenance. 22 The two-paragraph section includes suggested methods and does not mention anything about the amount of time or expertise needed for ongoing maintenance. In summary, in this literature review we found that there is research about open-source ILS but that there is a need for much more work in this area. It was found that research articles and practitioner pieces are available and talk about different aspects of the adoption process. The main reasons for adoption are identified. There are also a few scattered individual articles about the process of migration, training, and maintenance. There is a gap in the studies of open-source ILS, and there is no comprehensive study that documents the process, explains the steps, and identifies best practices and challenges for librarians who are interested. DATA SOURCES The objective for data collection was to collect data from a variety of library types and sizes in order to collect a wide range of data. E-mail invitations for interviews were sent to Koha and Evergreen discussion list and to several other library-related discussion list. The e-mail requested volunteers for a telephone interview to share their experiences with open-source integrated library systems. Potential participants identified themselves as being willing to be interviewed for INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 40 the project via e-mail and were then contacted by researchers to set up times for phone interviews. The list of interview questions was e-mailed to the participants before the interviews so that they could review the questions and had enough time to reflect on their experiences. The interviews were conducted with librarians working in a variety of libraries, including nine libraries using Evergreen and one in the process of migrating to Evergreen. Seven libraries were using Koha, two were using other open-source ILSs, and one was using a proprietary ILS while evaluating open- source. Public libraries were the most numerous with eleven respondents, while there were also four special libraries, three academic libraries, and one school library. Researchers also requested information about the size of the library collection. Seven libraries owned collections of less than 100,000 items, seven had collections of 100,001–999,999 items, and four libraries owned collections of over 1,000,000 items. Geographically, the respondents ranged all over the United States and included one library located in Afghanistan (although the ILS was installed in the United States). Table 1 details the description of the data. DATA COLLECTION METHOD Interviews were chosen as the primary means of data collection in order to gather rich information that could be analyzed using qualitative methods. Researchers sought to interview professionals from a variety of library types and sizes in order to collect a variety of different experiences regarding the selection, implementation, and ongoing maintenance of open-source ILS. Interviewing was the chosen methodology for several reasons. First, the goal was to go past the practitioner articles to see what kinds of trends there are in the migration process. This requires getting experiences from multiple librarians. Interviews provide the in-depth “case-study description” that we were looking for.23 In addition, the most useful aspect of interviewing is the ability to follow up on an answer that the participant gives.24 This ensures that the same type of information is gathered from every interview. This is unlike surveys where sometimes participants do not respond in a way that answers what the researcher really wants to know. In our case, we used telephone interviews due to the geographic dispersion of the participants. It allowed us to talk to librarians from all over the country instead of just within our area. The interview questions are listed in appendix A. DATA ANALYSIS METHODOLOGY Interviews were transcribed, and identifying information was then removed from each of the transcribed documents. The transcripts were then uploaded into Dedoose (www.dedoose.com), a web-based analysis program supporting qualitative and mixed methods research. Dedoose provides online excerpt selection, coding, and analysis by multiple researchers for multiple documents. The research team used an iterative process of qualitatively analyzing the resulting documents. This method used multiple reviews of the data to initially code large excerpts which were then analyzed twice more to extract common themes and ideas. Researchers began by reviewing each document for quantitative information, including the library type, ILS in use, EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 41 number of IT staff, and size of the collection. This information was added as metadata descriptors to each document in Dedoose. Upon review of the transcriptions and in discussions about the interview process, researchers began a content analysis of the qualitative data. Codes were created based on this initial analysis to aid in categorizing the data from the interviews. Two coders coded the entire dataset, specifying categories and themes to the excerpts of the interview transcription. All of the excerpts from each coder were used to create two tests. Each coder then took the test of the other's codes by choosing their own codes for each excerpt. Researchers earned scores of .96 and .95 using Cohen’s kappa statistic, indicating very high reliability. Table 1. Description of Libraries Library Size (number of items in collection) Library Type ILS Used Under 100,000 Academic Koha 100,000–1,000,000 Public Evergreen Under 100,000 Special Proprietary—Considering open-source Under 100,000 Public Koha School Koha 100,000–1,000,000 Public Millennium—In process of migrating to Evergreen 100,000–1,000,000 Public Evergreen 100,000–1,000,000 Special Koha Under 100,000 Public Koha Public Evergreen 100,000–1,000,000 Academic Evergreen-Equinox Under 100,000 Special Koha Over 1,000,000 Academic Kuali OLE 100,000–1,000,000 Public Evergreen-Equinox Over 1,000,000 Public Evergreen 100,000–1,000,000 Public Evergreen Under 100,000 Public Koha-Bywater Over 1,000,000 Public Evergreen-Equinox Under 100,000 Public Evergreen Over 1,000,000 Special Collective Access INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 42 RESULTS Results from the interview questions were divided into eight categories identified as stages of migration, starting with evaluation of the ILS, creation of a demonstration site, data preparation, identification of customization and development needs, data migration, staff training and user testing, and going live and long-term maintenance plans. Best practices and challenges for each of the stages are presented below. This section begins with some general considerations gleaned from the responses. General Consideration When Migrating to an Open-Source ILS • Create awareness about open-source culture in your library—let them know what to expect. • Develop IT skills internally even if you use a vendor. • Assess your staff’s abilities before committing. Knowing what your staff can do will help determine whether you need to work with a vendor and to what degree or if you can do it alone. It is also a way to determine who is going to be on your migration team. • Have a demonstration system; pre-migration, it can be used to test and train, and after migration it can be used to help find solutions to problems. This will also help develop skills internally. • Communication is key. o If working with a vendor either as a single library or as a consortium, have a designated liaison with the vendor so all questions go through one person. In a consortium, ensure that everybody knows what is going on. • Be prepared to commit a significant amount of staff time for testing, development, and migration, especially if you are not hiring a proprietary vendor for support. Working with Vendors • Read contracts carefully. Do not be afraid to ask questions and request changes. Sometimes the other party has a completely different meaning for a word than you do. Make sure you are on the same page. • Ensure that there is an explicit timeline and procedure for the release of usable source code. • See that you are guaranteed and entitled to access the source code in case you need to switch developers, bring additional developers on board, or try to fix problems in-house. • Provide specific examples when reporting problems. Specific example will help the developers determine what the problem is and will help prevent any miscommunication. • Designate a liaison between library staff and developers. The liaison will have to be someone who understands or can learn enough about what the developers are doing so that he or she can translate any problems or complaints from one group to the other. EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 43 • Set up regular meetings for those involved in the migration project. Regular meetings keep everyone focused and on task. They also provide an opportunity for questions, concerns, and problems to be addressed quickly. Sample quote from interviews: One of the main things that came up is working with Equinox, it was amazing. To start with, they were very, very helpful. And I had made an assumption, and I think the rest of us had, too, that we were working with, that this was developed by librarians, and that the terminology used would be library jargon. But that was not the case. We had some stumbling points over, we would say, okay, we want this, or this is a transaction, or that’s a bill, but that’s not what they called it. They didn’t call it a transaction, or they didn’t call it a bill. And so when we wrote the contract, we wrote it so that none of the patrons’ current checkout record would migrate, which is a big issue. And we didn’t realize that we weren’t using the right terminology in order to put that in the contract so that those current checkouts would move over with the migration and not just the record. Stage 1—Evaluation When making the decision of whether to migrate to open-source and which open-source ILS is best for your library, the main things to start with are two questions: who makes the decision and on what basis. In practice, who makes the decision? • If a single library, one or two people make the decision, usually the library director and whoever is serving as the tech person. • If in a consortium, a committee makes the decision, often either the library directors or tech people. Best practice suggestion: Regardless of the size of the library system, even though these are the people making the decisions, you should always try to include as many groups as open-sourceible in the decision to move to open-source. Which ILS? • Make a list of requirements based on your current system and a wish list of requirements for the new system. This is one area where you can involve more than just the system staff. Asking the different departments (cataloging, acquisitions, and circulation) what their needs are ensures that the final decision includes everyone. • Talk to other libraries that have made the move to open-source. They are a great resource for seeing how the system actually works, asking questions about the migration process, and providing information about open-source problems. If available, talk to a library that migrated from your current proprietary system. Some systems are easier to migrate from than others, so this would be an opportunity to find out about any specific problems. INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 44 Stage 2—Set Up a Demonstration Site • This is the most important guideline in the entire paper. Create a demonstration site before making a final decision. o If there is still confusion in your team about which ILS to use, setting up a demo site and installing Koha and Evergreen will be the best way to decide which one works for your situation. o Doing at least one test migration will show what kind of data preparation needs to be done, usually by doing data mapping. Data mapping is where you determine where the fields in your current system go when you move into the new system. Another often-used term for data mapping is staging tables. o The demo site is also a good way to do staff training when needed. o The demo site also provides a way to determine what the best setup rules, policies, and settings are by testing them in advance. o It provides an opportunity to learn the processes of the different modules and how they differ from your library’s current practices. o Most importantly, it serves as a test run for migration, which will make the actual migration go smoothly. Sample quotes from interviews: Do you think that the tests with the data and doing that really helped? Oh yes, we were have had a disaster if we hadn’t done three tests and test loads. The PALS office has done conversions multiple times before so they have it done, and we have good tech people. So they knew that the three tests loads would be a good thing. We did discover some of the tools that should be used, like for example one of the things that’s recommended for Evergreen patron migration is to have a staging table, so you dump all your records into a database that you can then use to create the records in the Evergreen tables. And you know we found out why that was important by running into a couple, a few problems with not being able to line up the data in the multiple fields. But you know that’s the sort of thing we expect. That’s pretty, I classify it as pretty typical migration learning, is finding out what works one way, what doesn’t the other. But you know that was a good thing because all the documents were saying, “You should use a staging table.” And we had to figure out ourselves why that was such a good idea. You should use a staging table for migration, i.e. move records into a database that is then used to create records in Evergreen. It helps because some data doesn't line up in the same fields. It's a good idea to set up tables and rules far in advance in order to test before migration. It's very important to do data mapping very carefully because if you lose anything during migration it's difficult to get it back. Check it to make sure that all the fields will be EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 45 transported correctly, and run tests while the old system is still up to make sure everything is there. Stage 3—Data Preparation • Clean up the data in advance. The better the data is, the easier it will transfer. This is also an opportunity to start fresh in a new system, so if there were inconsistencies or irritations in the old system this is a good time to fix it. o Weeding—If you have records (either materials or patrons) that are out of date, get rid of them. The fewer the records, the easier migration will be. In addition, vendors often charge by record, so why pay for records you do not need? • Consistency in data is key. If multiple people are working on the data, make sure they are working based on the same standards. • Do a fine amnesty when migrating to a new system. Depending on the systems (current and new), it is sometimes impossible or very difficult to transfer fine data into the new ILS, so doing a fine amnesty will make the process simpler. • Spot check data (testing, during, and after migration). Catching problems early means there will be less work trying to fix problems later. Sample quotes from interviews: I would say that if you’re considering converting to an ILS software, that you’ve really got to do the data mapping very carefully with a fine-toothed comb because you don’t want to lose data. It’s too hard to get it back in. The data needs to be normalized so that the numbers of fields are uniform, names are in the correct order, and data is displayed correctly. The library has had to decide whether it is worthwhile to do things like getting rid of old abbreviations, etc. to make the data more easily understood. Problems occur with old data if information such as note fields has been entered inconsistently. It's important to have procedures and to make sure everyone is following them. Often things are put in different places, which causes a lot of trouble. They are doing a lot of cleanup of data, such as reducing the number of unique values in the case of some items that had a huge number of values in a drop down list. Would like to spend more time on data cleanup but need to go ahead and get data migrated. Stage 4—Development/Customization • One benefit of using an open-source ILS is that any development done by any library comes back to the community, so often if you want something done, someone else might have already created that functionality and you can use it. INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 46 • Develop partnerships. Often if you want a specific development, someone else does too. If your staff does not have the expertise, then you could provide more of the funding and the partner could provide the tech skills or vice versa. Partnerships mean the development will cost less than if you did it alone. • Grant money is also available for open-source development and may be another funding option. Sample quotes from interviews: The library does its own minor customizations and uses Equinox for major jobs. They will lay out and prepare everything then hire Equinox to write and implement new code. The library tries not to do things on its own but always looks for partnerships when doing any customizations. That way libraries that have similar needs can share resources. Stage 5—Migration Process • Write workflows and policies/rules beforehand. Writing these when working on the demo site should provide step-by-step instructions on how to do the final migration. • Having regular meetings during the migration process ensures that everyone stays on the same page and prevents miscommunications that will slow down the process. • If many libraries are involved, migration in waves will make things easier. This is generally a situation with a statewide consortium. Usually there is a pilot migration of four to eight libraries, then after that, each wave gets a little bigger as the system becomes more practiced. This can also be a useful model if the libraries involved in the consortium are accepting the migration at different rates. • For a consortium that is coming from multiple ILSs, having a vendor will make it easier. This is not to say that it could not be done without a vendor, but migrating from System A is going to be different than migrating from System B. This increases the complexity, which can make working with a vendor more cost effective. Stage 6—Staff Training and User Testing • Who does the training? There are two main ways: by a vendor or internally. o If trained by a vendor, there are two options:  The vendor sends someone to the library to conduct training.  The library sends someone to the vendor for training and then he or she comes back and trains the rest of the staff. o If trained internally, there are a lot of training materials available. There are several libraries that have created their own materials and then made them available online. This is another time where having contacts with other libraries can help in using common resources. EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 47 • Documentation is important for training. The best way is to find what documentation is already available and then customize it for your system. • Do training fairly close to the “Go Live” date. • Use a day or two for training. If a consortium is spread out geographically, use webinars and wikis. • When doing training, have specific tasks to do. This can be done a few ways. o Do the specific tasks at the training. o Demonstrate the tasks at training and then give “homework” where the staff does the specific tasks independently. To implement this option, staff has to have access to a demo system. o Have staff try the tests on their own and use the training session for questions or problems they had. Sample quotes from interviews: Well we had, we hired Equinox to come and do 2 days of training with us. So they’re here and did hands-on training with us. And then we also, they provided some packets of exercises that people could do on their own. And we had the system up and running in the background so that they could play with it about a week before we actually went live to the public so that they could get used to it, figure out how things worked, and work with it a little bit so they could answer questions before the public came and said, hey, how do I find my record, and I can’t get into this anymore. And the training was really good, but the hands-on was the best. And it’s not a difficult system to work, but you just need a little experience with it before it makes sense. Evergreen runs a test server that anybody can download the staff client for that and work in their test server and just examine all of the records and how the system works, to figure out our workflows. We looked up documentation online—Evergreen, Indiana, Pines, various places—copied the documentation they so graciously hosted online for everybody to use, went through it, found what worked for us. Those couple staff members worked with other staff. We printed out kind of our little how-to guides for other people, depending on which worked, and told them they’re going to sit down, we’ve got terminals set up here, sit down and learn it. The admin person, she went through some quite detailed training. She went to Atlanta and had training from Equinox on a lot of aspects of Evergreen. And then we also, she came back, and then she did training for all the libraries in the consortium, kind of an intensive day-long or half-day-long thing that she offered in several different central geographic locations so that all the libraries would have a chance to go and attend without having to drive too far. And we also did webinars, we got a couple webinars for the real outlying libraries. And we also have ongoing weekly webinars. And we have a wiki set up where we put all the information in the online manual and stuff like that. INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 48 All the training sessions were recorded, and so we had them on CD for new people coming on board. Marketing for Patrons • Most libraries have not done anything elaborate, generally just announcements through posters, local papers, flyers, and on websites. • If the migration is greatly changing the situation for patrons, then more marketing is needed. • Set up a demo computer for patrons to try or hold classes once the system is up. Training for Patrons • Most libraries did not find this necessary. Either the system is easy to use or it is set up to look like the old system. • If training patrons, create online tutorials. Stage 7—“Go Live” and After • If possible, have your old system running for a month or two until you are sure that all the data got migrated over properly. Sample quote from interviews: Check it to make sure that all the fields will be transported correctly, and run tests while the old system is still up to make sure everything is there. Maintenance—Library Staff (This assumes a migration being done in-house with little to no vendor support.) • Staff has to have the technical knowledge (Linux, SQL, and coding). • Often the money saved from moving to open-source is used to pay for additional staff. • Most time is not spent on maintenance but on customization, updates, or problem-solving. Maintenance—Vendor • Often start with higher vendor support, which lessens as the staff learns and develops expertise. DISCUSSION AND CONCLUSION Interviews with twenty librarians from different settings provided insight into the process of the adoption of open-source ILS and were used to develop the guidelines presented in this paper. These guidelines are not intended to serve as a complete guide to the process of adoption but are meant to give interested librarians an overview of the process. These guidelines can help libraries prepare themselves for the research and adoption far before they delve into the process. Since these guidelines are all based in the real-life adoption experiences of libraries, they provide insight EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 49 into the challenges as well as the opportunities in the process. These guidelines can be used to develop an adoption plan and requirements for the adoption process. In future research, we are working to create adoption blueprints and total cost of ownership assessments (with and without vendors) for libraries of different sizes and types. Also, as part of this research we have developed an information portal that contains resources that will help librarians in each phase of the process of open-source ILS adoption. The information portal along with these guidelines will fill a very important gap in the resources available for open-source ILS adoption. The URL for the portal is not being provided in this paper to ensure anonymous review. REFERENCES 1. Marshall Breeding, “Automation Marketplace 2012: Agents of Change,” Library Journal 137, no. 6 (April 1, 2012), http://lj.libraryjournal.com/2012/03/industry-news/automation- marketplace-2012-agents-of-change (accessed February 18, 2013). 2. Tristan Müller, “How to Choose a Free and Open-Source Integrated Library System,” OCLC Systems & Services: International Digital Library Perspectives 27, no. 1 (2011): 57–78, http://dx.doi.org/10.1108/10650751111106573 (accessed February 18, 2013). 3. Emily G. Morton-Owens, Karen L. Hanson, and Ian Walls, “Implementing Open-Source Software for Three Core Library Functions: A Stage-by-Stage Comparison,” Journal of Electronic Resources in Medical Libraries 8, no. 1 (2011), 1–14, http://dx.doi.org/10.1080/15424065.2011.551486 (accessed February 18, 2013). 4. Janet L. Balas, “How They Did It: ILS Migration Case Studies,” Computer in Libraries 31, no. 8 (2011): 37. 5. Müller, “How to Choose a Free and Open-Source Integrated Library System.” 6. Roy Tennant, “Technology Decision-Making: A Guide for the Perplexed,” Library Journal 125, no. 7 (2000): 30. 7. Xan Arch, “Ultimate Debate 2010: Open Source Software—Free Beer or Free puppy? A Report of the LITA Internet Resources & Services Interest Group Program, American Library Association Annual Conference, Washington, DC, June 2010,” Technical Services Quarterly 28, no. 2 (2011): 186–88, http://dx.doi.org/10.1080/07317131.2011.546268 (accessed February 18, 2013). 8. Camille Espiau-Bechetoille, Jean Bernon, Caroline Bruley, and Sandrine Mousin, “An Example of Inter-University Cooperation for Implementing Koha in Libraries: Collective Approach and Institutional Needs,” OCLC Systems & Services: International Digital Library Perspectives 27, no.1 (2011): 40–44, http://dx.doi.org/10.1108/10650751111106546 (accessed February 18, 2013). http://lj.libraryjournal.com/2012/03/industry-news/automation-marketplace-2012-agents-of-change/ http://lj.libraryjournal.com/2012/03/industry-news/automation-marketplace-2012-agents-of-change/ http://dx.doi.org/10.1108/10650751111106573 http://dx.doi.org/10.1080/15424065.2011.551486 http://dx.doi.org/10.1080/07317131.2011.546268 http://dx.doi.org/10.1108/10650751111106546 INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 50 9. Gerhard Bissels, “Implementation of an Open-Source Library Management System: Experiences with Koha 3.0 at the Royal London Homoeopathic Hospital,” Electronic Library and Information Systems 42, no. 3 (2008): 303–14, http://dx.doi.org/10.1108/00330330810892703 (accessed February 18, 2013). 10. Randy Dykhuis, “Michigan Evergreen: Implementing a Shared Open Source Integrated Library System,” Collaborative Librarianship 1, no. 2 (2009): 60–65, http://collaborativelibrarianship.org/index.php/jocl/article/view/7/8 (accessed February 18, 2013). 11. Karen Kohn and Eric McCloy, “Phased Migration to Koha: Our Library’s Experience,” Journal of Web Librarianship 4 no. 4 (2010): 427–34, http://dx.doi.org/10.1080/19322909.2010.485944 (accessed February 18, 2013). 12. L.H. Lyn Dennison and A.F. Lewis, “Small and Open-Source: Decisions and Implementation of an Open-Source Integrated Library System in a Small Private College,” Georgia Library Quarterly 48 no. 2 (2011): 6–8, http://digitalcommons.kennesaw.edu/glq/vol48/iss2/3 (accessed February 18, 2012). 13. Linda M. Riewe, “Survey of Open-Source Integrated Library Systems,” Master’s Theses, Paper 3481, http://scholarworks.sjsu.edu/etd_theses/3481 (accessed February 18, 2013). 14. Karen Kohn and Eric McCloy, “Phased Migration to Koha: Our Library’s Experience.” 15. Randy Dykhuis, “Michigan Evergreen: Implementing a Shared Open Source Integrated Library System.” 16. Ian Walls, “Migrating from Innovative Interfaces’ Millennium to Koha: The NYU Health Sciences Libraries’ Experiences,” OCLC Systems & Services: International Digital Library Perspectives 27, no. 1 (2011): 51–56, http://dx.doi.org/10.1108/10650751111106564 (accessed February 13, 2013). 17. L.H. Lyn Dennison and A.F. Lewis, “Small and Open-Source: Decisions and Implementation of an Open-Source Integrated Library System in a Small Private College.” 18. Emily G. Morton-Owens, Karen L. Hanson, and Ian Walls “Implementing Open-Source Software for Three Core Library Functions: A Stage-By-Stage Comparison.” 19. Lisa Genoese and Latrina Keith, “Jumping Ship: One Health Science Library’s Voyage from a Proprietary ILS to Open Source,” Journal of Electronic Resources in Medical Libraries 8, no. 2 (2011): 126–33, http://dx.doi.org/10.1080/15424065.2011.576605 (accessed February 18, 2013). 20. Ian Walls, “Migrating from Innovative Interfaces’ Millennium to Koha: The NYU Health Sciences Libraries’ Experiences”; Emily G. Morton-Owens, Karen L. Hanson, and Ian Walls, http://dx.doi.org/10.1108/00330330810892703 http://collaborativelibrarianship.org/index.php/jocl/article/view/7/8 http://dx.doi.org/10.1080/19322909.2010.485944 http://digitalcommons.kennesaw.edu/glq/vol48/iss2/3 http://scholarworks.sjsu.edu/etd_theses/3481 http://dx.doi.org/10.1108/10650751111106564 http://dx.doi.org/10.1080/15424065.2011.576605 EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 51 “Implementing Open-Source Software for Three Core Library Functions: A Stage-by-Stage Comparison.” 21. L. H. Lyn Dennison and A. F. Lewis, “Small and Open-Source: Decisions and Implementation of an Open-Source Integrated Library System in a Small Private College.” 22. Morton-Owens, Hanson, and Walls, “Implementing Open-Source Software for Three Core Library Functions.” 23. Laurel Jizba Mis, “An Essay on Our Interviews, and a Call for Participation,” Journal of Internet Cataloging 6 no. 2 (2003): 17–20, doi: 10.1300/J141v06n02_04 (accessed February 18, 2013). 24. Golnessa Galyani Moghaddan and Mostafa Moballeghi, “How Do We Measure the Use of Scientific Journals? A Note on Research Methodologies,” Scientometrics 76, no. 1 (2008): 125– 33, doi: 10.1007/s11192-007-1901-y (accessed February 18, 2013). doi:%2010.1300/J141v06n02_04 doi:%2010.1007/s11192-007-1901-y INFORMATION TECHNOLOGY AND LIBRARIES | MARCH 2013 52 Appendix A. Interview Questions Library Environment 1. What is your library type (school, academic, public, special, etc.)? 2. What is your library size (how many employees, population served, and number of materials)? Evaluation (We would like as much info as possible about why the system was chosen over others, including any existing system.) 3. What open-source ILS are you using and why did you choose it? 4. When choosing an open-source ILS, where did you go for information (vendor/ILS pages, community groups, personal contacts, etc)? 5. Who was involved in deciding which ILS to use? Adoption (We would like to document specific problems or issues that could be used by other libraries to ease their installation.) 6. Were there any problems during migration? 7. What do you know now that you wish you had known before migration? 8. How long did migration take? Were you on schedule? 9. If getting paid support, how did the vendors (previous and current) help with migration? Implementation (Again, specific examples of the things that worked well or didn't work. How can other libraries learn from this experience?) 10. What kind of (and how much) training did your library staff receive? 11. Did you do any kind of marketing to your patrons? 12. (If haven’t gotten to this part yet), what are your plans for implementation? 13. How much time did implementation take and were you on schedule? Maintenance (This information will be especially important when compared to the library type and size as a reference for other libraries. We would like to get answers that are as specific as possible). 14. How large is your systems staff? Is it sufficient to maintain the system? 15. How much time do you spend each week doing system maintenance? How does this compare to your old system? EXPERIENCES OF MIGRATING TO AN OPEN-SOURCE INTEGRATED LIBRARY SYSTEM | SINGH 53 16. What resources (or channels) do you use to solve your technical support issues? What roles do paid vendors play in maintenance of your system? Advice for other libraries (These open-ended questions are an opportunity to learn more information that we might not have thought of asking about. Responses could provide a valuable resource to other libraries as they plan their implementation). 17. What is the best thing and worst thing about having an open-source ILS? 18. Are there any lessons or advice that you would like to share with other librarians who are thinking about or migrating to an open-source ILS? ACKNOWLEDGMENT This research was funded by an Early Career IMLS grant. ABSTRACT Interest in migrating to open-source integrated library systems is continually growing in libraries. Along with the interest, lack of empirical research and evidence to compare the process of migration brings a lot of anxiety to the interested librari...