Getting Started

The Beginning

Getting started with Open Source Integrated Library Systems involves a number of steps. Before settling on an OSS rather than a proprietary ILS, you should consider any time and budget commitments and limitations. While OSS may cost less in terms of vendor fees, it can require a great deal of time from library staff.

Functionality

Once you decide on OSS, it is important to create a list of functionalities that your library wants or needs from its ILS. Then use the resources on this website to compare the features and modules of different OSS ILSs. For instance, a larger consortium would probably favor Evergreen, whereas a smaller library might choose Koha.

Technical Support

Your library should also consider whether it has the technical expertise in-house to install an OSS ILS independently or whether you will need the support of an outside vendor on customization, migration, implementation, updates, and maintenance. Another option is entering into a partnership with additional libraries that have the expertise to implement an OSS ILS. Informational websites are available, as well as online discussion forums, listservs, wikis, and contact information for other libraries using these and other OSS ILS.

Testing

Your library might also choose to run tests of various OSS ILS before deciding on one in particular. Even if you have chosen a specific OSS ILS, running tests is vital to ensure that data is migrated properly and not lost.

Training

As you enter the process of migrating and "going live," you will also want to train your staff and market to your patrons about the new OSS ILS.

What Is OSS ILS?

  • The ILS is key to the operation of most library systems
  • Proprietary systems are controlled by vendors and closed to libraries

The Integrated Library System represents one of the largest commitments for any library and has largely been the domain of proprietary vendors who charge yearly fees to maintain the system. With the advent of Open Source Software Integrated Library Systems (OSS ILS) such as Koha and Evergreen, librarians now have the option to gain greater control over their data than ever before.

  • Source code is freely available for use, modification, and re-distribution
  • Software is free to download, install, and use

OSS ILS refers to Open Source Software Integrated Library Systems. The open source software movement is based on the belief that users should have access to the source code of the software they use. Users are generally free to use, modify, and redistribute the software back to the community.

  • Fully featured software that provides the same functionality as proprietary software
  • Libraries can customize and build new functionality as needed
  • User-created code is donated back to the community

OSS ILS have all the functionality of proprietary ILS – including modules for the acquisitions, cataloging, and circulation of materials and serials, as well as online public access catalogs (OPACs) for users – with the source code for the software being available to the libraries themselves. The availability of the code enables libraries to change and improve their own ILS without having to go through a vendor with a commercial product.  Most libraries using OSS ILS name these features as the biggest benefits: the flexibility to control one’s ILS and data and the ability to turn to a robust community for support and information sharing.

Evergreen and Koha

The most prominent OSS ILS in the United States are Evergreen and Koha. Evergreen was created by the Georgia Public Library System in 2006 and is now used in all types of libraries requiring significant scalability, such as large public library consortia. Koha was created in 1999 by Katipo Communications in New Zealand and is more common in smaller libraries, especially in schools.

Other OSS ILS include NewGenLib (NGL), the Kuali Open Library Environment (OLE) Project for research libraries, and Collective Access for archives. Many libraries also make use of OSS CMS or content management systems such as Drupal, Joomla, WordPress, and Library a la Carte. Scriblio combines CMS and OPAC functionality.

There are a number of other OSS resources available specifically for libraries. Kete is an OSS for community digital libraries. Pre-Book is a PC booking and reservation computer software platform. SubjectPlus enables libraries to manage their websites and subject guides. The Social Opac (SOPAC) offers a discovery platform for library bibliographic data.

Other ILS

OSS ILS other than the popular Evergreen and Koha include three main options: NewGenLib (NGL), the Kuali Open Library Environment (OLE) Project, and Collective Access.  If you are in a non-traditional library, then you may need an OSS ILS that is more specialized. For example, museums, archives and ditigal collections are going to want to use Collective Access instead of Koha or Evergreen. Listed below are some of the other OSS ILS.


NewGenLib logo NewGenLib (NGL) is an OSS ILS created by Verus Solutions. It includes modules for technical processing or cataloging, circulation, acquisitions, serials management, administration, reports, and a web OPAC. NGL recommends first becoming familiar with these modules and their features and then downloading the software from its website, migrating existing data into NGL, and getting trained on NGL. NGL offers expert support for migration, implementation, and maintenance free of charge.


Kuali FoundationThe Kuali Open Library Environment (OLE) Project calls itself "the first system designed by and for academic and research libraries for managing and delivering intellectual information." It supports a wide range of resources and federation across consortia, interoperates with other enterprise systems, and provides workflow design and information management capabilities. It is currently under development and is funded by a grant from the Andrew W. Mellon Foundation and contributions from various research libraries.


Collective AccessCollective Access is a highly configurable cataloging tool and web-based application for museums, archives, and digital collections. It is available free of charge and requires little to no customization for support for various metadata standards, external data sources and repositories, popular media formats, and multiple languages. Current users include museums and archives from a range of disciplines, including art, anthropology, film, local history, architecture, conservation, libraries, and corporate archives. It was developed by Whirl-i-Gig.


An article from the Public Library Association describes a number of lesser known OSS ILS options:

Avanti MicroLCS was created in 1998 by Peter Schlumpf for small libraries. Development did not pick up until 2004, however; the cataloging and patron access modules were released in 2008. MARC is supported, and the system will run on Windows or Linux. It is limited to 128,000 titles and 256,000 items.

Emilda was created in 2000 by CompanyCube in Finland with the assistance of various school libraries. Today's version conforms to MARC and Z39.50 standards and can run on any operating system. Circulation and patron access catalog modules were released in 2005.

GNUTeca was developed in Brazil for academic and special libraries; several school libraries also use it. Cataloging, circulation, and patron access catalog modules were released in 2008. Its programming languages are Perl and PHP, making it not very scalable. It operates under Windows and Linux operating systems and supports MARC. Documentation is available in Portuguese, Spanish, and English.

Learning Access ILS was created by the Seattle-based non-profit Learning Access Institute for small public libraries. It was based on a Katipo product and offers modules for cataloging, serials, circulation, and the patron access catalog. It supports MARC, Z39.50, and Unicode standards. Perl and PHP are its programming languages. It can run on Windows, but Linux is preferred.

OpenBiblio was developed mainly in 2006-2007 and includes cataloging, circulation, and patron access catalog modules. The programming languages are PHP and LAMP, which do not have reliable scalability. The operating system is Linux, and UNIMARC is supported.

PhpMyLibrary was created in 2001 in the Philippines for small academic and special libraries. There is little documentation, and the owner has most of the control over the source code. Cataloging, circulation, and patron access catalogs are available. Linux and Windows operating systems are supported, as is SUSMARC. The system has limited scalability.

PMB (PhpMyBibli) was developed in 2002 by a public library in France with available modules for acquisitions, cataloging, circulation, the patron access catalog, and the selective dissemination of information. Documentation is available in English and French, and UNIMARC and Z39.50 are supported. The programming language is PHP, and the system has limited scalability.

PYTHEAS was created in 1995 by a librarian at the University of Arizona and then picked up by a librarian at the University of Windsor. Circulation and patron access modules are available, and the programming languages are Java and XML. There is limited documentation, but the system is highly scalable.

WEBLIS was created in 2008 by the Institute for Computer and Information Engineering of Poland with assistance from UNESCO. Cataloging, circulation, and patron access catalog modules are available. Documentation is available in English.

SLIMSSenayan Library Management System, or Slims, was created in 2006 by the Library of the Ministry of National Education in Indonesia. Built on a GNU/Linux base, it was released to the public in 2007 and is currently on version 5. The development team believes that the ILS is in use in at least 218 libraries and other institutions, and it has been downloaded over 250,000 times.

FAQs

What is an ILS?
It stands for Integrated Library System, the software that librarians use to manage acquisitions, build catalogs, check out materials, and keep track of library users.
 

Why choose an Open Source Software (OSS) ILS?
OSS refers to concept of "free" software developed by a community of interested users who share that software with each other. ILS have traditionally been expensive, complicated systems owned by proprietary companies that charge a fee to libraries for use and maintenance.
 

What OSS ILS options are available?
Although there are many OSS ILS that have been developed in many countries and for many types of libraries, the most common choices in the U.S. are Evergreen and Koha. Evergreen is usually chosen for larger consortia, whereas Koha is used in smaller school and special libraries.
 

Are OSS ILS really mature enough systems?
Some OSS ILS have been being developed for over a decade, and most of them offer the ILS modules vital for library service (circulation, cataloging, acquisitions, etc.). Many librarians using OSS ILS characterize them as ready for "primetime" or "going live."
 

How much technical expertise do I need to implement an OSS ILS?
Technical expertise is definitely helpful when migrating to and maintaining an OSS ILS. While there is a community and documentation to support you in solving technical problems, there is no proprietary vendor present to "fix" bugs for you. However, if you work at a small library without a technical staff, you can consider hiring a vendor to provide support for your OSS ILS. Equinox, LibLime, and ByWater Solutions are some of the most frequently used support vendors in the U.S.
 

What are the system requirements for OSS ILS?
The system requirements for OSS ILS vary by individual system. The main requirements for Evergreen are available on its documentation page. This Slideshare presentation provides information about the hardware and software requirements for Koha.
 

Who develops OSS ILS?
OSS ILS are developed by a community of the most technically skilled programmers and developers who create new modules and fix reported bugs.
 

How does open source fit with the mission of libraries?
Libraries have always been very engaged in issues like free access to information. In today's digital world, the issue of access has evolved to include such topics as the digital divide, open access journals, and open source software. Many librarians using OSS ILS say they believe in the vision and community open source creates and sustains.
 

Which OSS ILS is best for my library?
Generally if you are a small library go with Koha, if you are in a consortium go with Evergreen.  For more on this decision look at the following pages:  ILS Evaluation, Evergreen Evaluation, and Evaluation
 

What are the requirements for setting up a demo site?
Demo installations of Evergreen or Koha can be set up on a moderately powered PC running Linux. It's possible to get working installations up and running in a few hours.

Terminology

Acquisitions: An ILS module dedicated to ordering, receiving, and invoicing materials.
 
Apache HTTP Server: Open source server software required by Evergreen and Koha.
 
Cataloging: An ILS module dedicated to classifying and indexing materials.
 
Circulation: An ILS module dedicated to lending materials to patrons and receiving them back.
 
Collective Access: OSS ILS developed for museums, archives, and digital collections.
 
Documentation: Online resources, usually in the form of a downloadable manual, than OSS communities make freely available to guide users in how to implement, use, and customize recent releases of a system.
 
Evergreen: Popular OSS ILS in the U.S. Especially common in library consortia because of its scalability.
 
ILS (Integrated Library System): A resource-based planning system for a library used to track items owned, orders made, bills paid, and patrons who have borrowed. Modules generally include acquisitions, cataloging, circulation, serials, and the OPAC (Online Public Access Catalog).
 
Kete: OSS for community digital libraries.
 
Koha: Popular OSS ILS in the U.S. Commonly used in smaller school and special libraries.
 
Kuali Open Library Environment (OLE) Project: OSS ILS developed specifically for academic and research libraries.
 
Linux: An open source operating system that is required for the installation of Evergreen and Koha. It comes in many varieties called distributions. These include Debian, Fedora, Red Hat, and Ubuntu.
 
NewGenLib (NGL): Another OSS ILS more popular outside the U.S.
 
OPAC (Online Public Access Catalog): An ILS module dedicated to creating a public interface for users.
 
OSS (Open Source Software): Computer software that is available in source code form, allowing users to study, change, improve, and distribute the software. It is usually developed collaboratively.
 
Scriblio: Combines OPAC functionality with a CMS (content management system).
 
SQL: A query language designed to manage data in a database management system. ILS systems use open source relational database management systems (RDBMS) to maintain and manipulate data. Evergreen uses PostgreSQL, while Koha uses MySQL for its database.
 
Serials: An ILS module dedicated to tracking magazine and newspaper holdings.

ILS Research

The Process

The process of migrating to an OSS ILS includes numerous steps. First, libraries must evaluate the OSS ILS to see whether it fits the needs of their institution, how it will need to be customized, and how much time and money will be required for that customization. The next step is a test installation and test migration, which allow staff members to get accustomed to the new system, test functionality, and determine what kind and how much data preparation is needed. If this preparatory step is thorough, the actual process of installation, data preparation, and migration will be much smoother. Throughout the migration process, it is also important to train staff members on the new system and allow users to test the system before it goes live. Once the software installation and migration are complete and the staff  members and users have become acquainted with the new system, the library will be ready to "go live" with its OSS ILS.

Researching OSS ILS options before choosing and implementing is a vital step in the process. There are various resources available on this website to aid in this research process. In addition, contact information for libraries currently using OSS ILS is available; making connections with these libraries can help answer questions about OSS ILS functionalities and also develop potential partnerships and consortia.

One of the most common comments we have received in our research on OSS ILS is that librarians choosing to move to an Open Source platform should be aware of the technical skills and talents that their staff possesses. While there are several vendors who can manage the entire process, having knowledgeable staff who understand the terminology and play a part in maintaining the system can go a long way toward making the process smoother. Training is essential for each of the various elements of the ILS.

After researching and choosing an ILS and analyzing your library's technical expertise, it is important to create an implementation plan to spell out the various steps in the implementation process and who should be responsible for them. Tasks to complete include the following:

  • Evaluation
  • Demonstration site and data preparation
  • ILS installation
  • Data migration and testing
  • Staff training and user testing
  • Going live

Planning for each of these steps involves deciding upon expectations for the expected time range, action items by individual role, deliverables, and best practices. Some steps like data preparation and migration can take months, whereas training materials can be developed in weeks and taught in days.

ILS Evaluation

Evaluation is one of the main steps of migrating to an OSS ILS. Libraries must decide if an OSS ILS meets needs that will vary depending on the type and size of the library system. Libraries should also consider the technical skills needed by staff members to implement an OSS ILS; if technical skills are lacking, you may need the help of an outside vendor or a partner library. In addition, libraries must evaluate the amount of time needed to perform migration as well as regular maintenance. It is important to consider time commitments because they are almost always connected to budget commitments. Although OSS is generally a more cost-effective option, library staff must be prepared to spend additional time running their system. Finally, although online resources are generally useful, contacting libraries that are migrating to or have already implemented an OSS ILS can be of great help in the evaluation process.

According to an article from the Public Library Association, the following criteria in particular should be considered when evaluating an OSS ILS:

  • There is current development activity with at least two substantial releases a year.
  • At least the cataloging, circulation, and patron access catalog modules are currently available; acquisitions and serials control are in development. If a library requires broader functionality, there are similar libraries that may share development priorities.
  • MARC is supported.
  • Current source code and technical documentation are available for downloading under the GNU General Public License.
  • The product is currently in use in a significant number of libraries.
  • Scalability is not an issue—there is no risk of database size or activity levels exceeding the capacity of the software. 

Of course, the main OSS ILS in the U.S., Evergreen and Koha, meet all of these criteria. Libraries that have already decided to choose one of these systems will need to consider other factors. The Massachusetts Library Network Cooperative has released a useful list of points comparing these systems:

consortium choice

Evergreen Pros:

  • Originally developed with consortia needs in mind.
  • Majority of current customers are consortia-based, so these needs continue to push the development.
  • System architecture designed with scalability in mind.
  • Nelinet planning to offer training and support on this platform.
  • Evergreen FullfiLLment project (a potential alternative to URSA) recently funded by State Library of Ohio.
  • King County Library System funding considerable development for software requirements "suitable for many large, urban, multiple-branch, centralized library systems."

Koha Pros:

  • Client functions run entirely within a browser (and, therefore, the system doesn't require any client updates).
  • System's browser-based architecture more in line with overall software industry development (and, therefore, an easier platform for outside developers to understand and work on).
  • Growing community of developers and support vendors.
  • Software and, perhaps, community slightly more mature (project started earlier than Evergreen).
  • Community very international resulting in quick translations of the software.
  • Evidence of a growing base of consortia "customers."
  • Heavy adoption in India, a country with extensive IT resources.
software

Evergreen Cons:

Koha Cons:

  • Consortia needs have not been a focus during early and recent development.
  • Many current features cannot be implemented well (if at all) in a consortium environment.
  • Upcoming development (such as new acquisitions module) still lacks certain consortia-friendly features.
  • Majority of current "library customers" are small and/or independent rather than large and/or consortia-based.
  • History of platform forking so that development is not always getting plowed back into the core.
  • Strong potential for Indian development to fork since they have had little contact with original developers and do not need IT support.
  • International aspects of Koha community can potentially divert development from U.S. library needs and/or make new releases less relevant for U.S. libraries than they otherwise would be.

Cost

Cost is an additional factor in evaluating an OSS ILS. For any ILS, costs accrue through software development ($100,000-$250,000), hardware ($300-$2,500 per patron), file migration (15 cents per record at most), configuration and installation ($25,000 at minimum), documentation ($6,500 on average), training ($1,500-$2,800 per day for on-site versus $125-$150 per day online), and ongoing support ($9,000-$15,000 per year versus $150 per hour of bug fixing). All OSS ILS will save money by lacking the software license fees of proprietary equivalents, which range from $30,000 to $500,000.


Best Practices for Evaluation

Who makes the decision?

  • If in a single library, one or two people, usually the library director and whoever is serving as the tech person.
  • If in a consortium, a committee, often either the library directors or technical people.
  • However, 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 possible in the decision to move to open source.

Which ILS?

  • Make a list of requirements and don't migrate until they are all there.  This checklist is so you don't lose any key functionality because of migration.  This is a step where you can involve more than just the systems staff.  Asking the different departments what they're needs are ensure that the final decision includes everyone and hopefully will help build internal support for the migration.
  • Know your staff's abilities before committing.  Migrations are difficult in general.  Knowing what your staff's abilities are will show what kind of external help you will need for the migration.  This step is also about developing skills internally.  If you have time you can always start your staff on developing the skills needed before migration begins.  Lastly, knowing the staff will determine who is going to be on your migration team.
  • Talk to other libraries. They are a great resource for seeing how the system actually works, asking questions about the migration process, and providing information about possible problems.  If possible talk to a library that migrated from your current ILS.  Some systems are easier to migrate fom than others so this would be an opportunity to find out about any specific problems.  This connections can also come in handy later in the process.
  • Running any open source software requires technical skills, so develop skills internally even if you use a vendor for migration.  The goal should be to try to lessen the library’s dependence on vendors.
  • Have a development system: pre-migration can be used to test and train, post-migration can be used to help find solutions to problems.  This will also help develop skills internally.Make sure everyone understands the open source culture – there is no vendor to complain to, so if there is something you want changed, you have to do it yourselves (which is often considered both the best and worst thing about having an open source ILS).
  • Communication is key:
    • If working with a vendor, have a designated liaison with the vendor so all questions go through one person.  If in a consortium, this is even more important because you do not want every library asking the vendor the same questions.
    • If in multiple branches or a consortium, develop some kind of system so that everyone stays informed throughout the process.  One way to do this is to have one person at each library be a liaison between their library and the committee working on the migration.  That way there is a designated channel for any questions or problems to go through.
  • Be prepared to commit a significant amount of staff time for testing, development, and so forth.  This process can take a long time depending on how long you spend in each step. This process can take anywhere from six months to several years.  If your library is doing it all internally without a vendor, then staff time is going to increase.

Installation Requirements

Evergreen Installation Requirements:

The Official Evergreen Documentation lists the following requirements for Evergreen 2.2:

Server Minimum Requirements

The following are the base requirements setting Evergreen up on a test server:

  • An available desktop, server or virtual image
  • 1GB RAM, or more if your server also runs a graphical desktop
  • Linux Operating System
  • Ports 80 and 443 should be opened in your firewall for TCP connections to allow OPAC and staff client connections to the Evergreen server.

Staff Client Requirements

Staff terminals connect to the central database using the Evergreen staff client, available for download from The Evergreen download page. The staff client must be installed on each staff workstation and requires at minimum:

  • Windows (XP, Vista, or 7), Mac OS X, or Linux operating system
  • a reliable high speed Internet connection
  • 512Mb of RAM
  • The staff client uses the TCP protocal on ports 80 and 443 to communicate with the Evergreen server.

Barcode Scanners

Evergreen will work with virtually any barcode scanner – if it worked with your legacy system it should work on Evergreen.

Printers

Evergreen can use any printer configured for your terminal to print receipts, check-out slips, holds lists, etc. The single exception is spine label printing, which is still under development. Evergreen currently formats spine labels for output to a label roll printer. If you do not have a roll printer manual formatting may be required.


Koha Installation Requirements:

While it doesn't list specific hardware requirements such as processor speed or amount of RAM, the Koha Library Software Community does recommend the following for Koha 3.8:

To install Koha for immediate use we recommend

Resources

Help Resources

A huge variety of OSS ILS resources are available online. These include technical resources, community resources, and social media resources. Although general websites are important, some of the most useful resources are those that provide information about specific OSS ILS for comparison and those that allow libraries considering or using OSS ILS to connect with other libraries with similar needs.

Know your staff and their capabilities:

While being able to access external resources is a great help, having a technically skilled staff is a very important factor in any successful implementation. Knowing the extent of the skills available at your library can help you determine the extent to which you may need to depend on a vendor for support. Useful skills include:

  • Basic troubleshooting skills.
  • Comfort working with command line interfaces, especially in a Linux environment.
  • Database management, including familiarity with SQL.
  • The ability to discuss technical issues with experts in order to solve problems.
  • Familiarity with using wikis, IRC, forums, and listservs to seek information.
  • Willingness to learn new skills.

Technical Resources

Best Practices

Best Practices for Evaluation | Best Practices for Demonstration Site | Best Practices for Data Preparation | Best Practices for Staff Training and User Testing | Best Practices for Going Live and After

General Best Practices:

  • Partner with others, especially for development.
  • Be prepared to spend a significant amount of staff time on testing, development, etc.
  • Make sure you have enough experienced in-house staff and/or hire consulting experts to advocate for your needs, help you stay organized, and find or create ways to fill functionality gaps.
  • Develop skills internally.
  • Read contracts carefully and 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, so make sure you are on the same page.
  • Make sure 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 the problems in-house.
  • Remember that open source vendors are still ​vendors.
  • Have a development system: pre-migration to test and train, post-migration to help find solutions to problems.
  • Make sure everyone understands the open source culture; there is no vendor to complain to, so if there is something you want changed, you have to do it yourselves.
  • Involve stakeholders early and set up regular meetings for those involved in the migration project.
  • Designate a liaison between library staff and developers.
  • Provide specific examples when reporting problems.

Best Practices for Evaluation

Who makes the decision?

  • If in a single library, one or two people, usually the library director and whoever is serving as the tech person.
  • If in a consortium, a committee, often either the library directors or technical people.
  • However, 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 possible in the decision to move to open source.

Which ILS?

  • Make a list of requirements and don't migrate until they are all there.  This checklist is so you don't lose any key functionality because of migration.  This is a step where you can involve more than just the systems staff.  Asking the different departments what they're needs are ensure that the final decision includes everyone and hopefully will help build internal support for the migration.
  • Know your staff's abilities before committing.  Migrations are difficult in general.  Knowing what your staff's abilities are will show what kind of external help you will need for the migration.  This step is also about developing skills internally.  If you have time you can always start your staff on developing the skills needed before migration begins.  Lastly, knowing the staff will determine who is going to on your migration team.
  • Talk to other libraries. They are a great resource for seeing how the system actually works, asking questions about the migration process, and providing information about possible problems.  If possible talk to a library that migrated from your current ILS.  Some systems are easier to migrate fom than others so this would be an opportunity to find out about any specific problems.  This connections can also come in handy later in the process.
  • Running any open source software requires technical skills, so develop skills internally even if you use a vendor for migration.  The goal should be to try to lessen the library’s dependence on vendors.
  • Have a development system: pre-migration can be used to test and train, post-migration can be used to help find solutions to problems.  This will also help develop skills internally.
  • Make sure everyone understands the open source culture – there is no vendor to complain to, so if there is something you want changed, you have to do it yourselves (which is often considered both the best and worst thing about having an open source ILS).
  • Communication is key.
    • If working with a vendor, have a designated liaison with the vendor so all questions go through one person.  If in a consortium, this is even more important because you do not want every library asking the vendor the same questions.
    • If in multiple branches or a consortium, develop some kind of system so that everyone stays informed throughout the process.  One way to do this is to have one person at each library be a liaison between their library and the committee working on the migration.  That way there is a designated channel for any questions or problems to go through.
  • Be prepared to commit a significant amount of staff time for testing, development, and so forth.  This process can take a long time depending on how long you spend in each step. This process can take anywhere from six months to several years.  If your library is doing it all internally without a vendor, then staff time is going to increase.

Best Practices for Demonstration Site

  • Have a demo site.  This cannot be emphasized enough.  If you only do one of the things suggested here, this is the one.  It will have many uses.
    • It can be used in evaluation if your library is unsure which ILS to choose. One option is to test both and see which works better for your situation.
    • 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 will go when you move into the new system.  Another common term for data mapping is staging tables.
    • The demo site is a good way to do staff training.
    • It also provides a way to determine what the best setup (rules, policies, settings, etc.) are by testing them in advance.
    • It provides an opportunity to learn the processes of the different modules and how they differ from your library’s current practices.
    • Most importantly, it serves as a test run for migration, which should serve to make the actual migration go smoothly.

Best Practices for Data Preparation

  • If you can, do a fine amnesty when migrating to the 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.
  • Clean up 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 problems in the old system, now is the time to fix them.
    • Weeding – if you have records (either materials or patrons) that are out of date, now is the time to get rid of them.  The fewer records there are, the easier migration will be.  In addition, vendors often charge by the record, so why pay for records you don’t need?
  • Consistency is key.  If multiple people are working on the data, make sure they are working based on the same standard.

Best Practices for Staff Training and User Testing

Who does the training?  There are two main ways: vendor or internally.

  • If done by vendor, there are two options:
    • The vendor sends someone to the library to conduct training.
    • Train the trainer: the library sends someone to the vendor for training and then they come back and train the rest of the staff.
  • If done internally, there are a lot of training materials available.  There are several libraries that made training materials available online after creating them.  This is another time when having contacts with other libraries can help.
  • Documentation is important.  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.  
  • Usually a day or two of training is sufficient, but the staff may only need part of it because training usually covers circulation, cataloging, and administration.
  • If in a consortium that is spread out geographically, use webinars and wikis.
  • When doing training, have specific tasks to do.  This can be done in a few different ways:
    • Do the specific tasks at the training.
    • Demonstrate the tasks at the training and then give "homework" where the staff does the specific tasks independently.  To implement this option, give the staff access to a demo system.
    • Have the staff try the tests on their own and use the training session for any questions or problems they had.

Marketing for Patrons

  • Most libraries have not done anything elaborate.   Generally just announcements through posters, local paper, flyers, and on website are sufficient.
  • If the migration is greatly changing the situation for patrons, then do more marketing.   You can set up a demo computer for patrons to try or hold classes once the system is up.

Training for Patrons

  • Most libraries do not find this necessary.  Either the system is easy to use or it is set up to look like old system.
  • If you complete training, most use presentations and demos especially in corporate libraries or those with a limited number of patrons.
  • Another option is to create online tutorials.

Best Practices for Going 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.

Maintenance – Vendor

  • Often start with higher vendor support, which lessens as the staff learns and develops expertise.

Maintenance – Library Staff (assumes being done in-house with little to no vendor support)

  • The staff has to have the technical knowledge (Linux, SQL, and coding).
  • Often the money saved from moving to OSS is used to pay for additional staff.
  • Most time is not spent on maintenance, but on customization, updates, or problem solving.

Migration

Migrating from one system to another is a time-consuming process that poses the risk of losing essential data and functionality. While the specific steps involved will vary depending on the ILS you are coming from and the one you have chosen to move to, there are several things you can do to make the process go more smoothly.

Best Practices for Migration:

Process

  • Spot check data (testing, during and after migration).  Catching problems early means less work trying to fix problems later. 
  • Write workflows and policies/rules beforehand.  Writing these while working on the test site should provide step-by-step instructions on how to do the final migration.
  • If working with a vendor, regular communication is important.  Having regular meetings ensures that everyone stays on the same page and prevents miscommunication that will slow down the process.  Again, having one or two people working with the vendor and then having them communicate with the rest of the library ensures a clear chain of communication and will prevent repetition with the vendor.
  • When migrating multiple libraries, staging the migration in waves makes things easier.  This is generally a situation in which it’s a state-wide consortium.  Usually there is a pilot migration of 4-8 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.
  • If in a consortium that is coming from multiple ILS, having a vendor will make it easier.  This is not to say that it cannot 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.

Development/Customization

  • Before doing any customization, make sure that it has not been done already.  Make sure that you are not reinventing the wheel.  The great thing about open source is that any development done by any library comes back to the community, so if you want something done, usually someone else does too. 
  • Look for partnerships.  Often if you want a specific development, someone else does too.  There are many advantages.  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 another funding option.

Evergreen Migration Process | Koha Migration Process

Data Preparation

Data Preparation

One of the most important steps you can take to ensure a successful migration is to prepare your existing data. Data migration is one of the potential stumbling blocks in the ILS migration process since the fields or formats used in a previous system may not correspond directly to the new system. The data you will be moving includes the catalog records of items in your collection; patron records including patron addresses, currently checked out items, and fines and fees; and any other information you keep track of using your ILS, such as acquisitions.

  • Save time and Money
  • Avoid extensive post-migration data cleanup

Libraries migrating to OSS ILSs should do as much data preparation as they can. There are two main reason for doing data preparation.  First, it keeps you from spending the time and money migrating data that you don't need.  Second, the time you spend preparing you data beforehand prevents you from having to do massive cleanup after migration.  In both cases, data preparation helps make your migration a success.

Consider using a vendor for data migration

Data migration is one of the steps where vendor expertise can really help. Many support vendors have experience migrating data from a variety of different proprietary ILS so they can help guide you through the potential pitfalls you may face with your system. Ask vendors if they have worked with migrating data from your current system before you commit to a migration contract, and contact other libraries who have migrated from your system to get their input on potential problems.

Migrating to a new system is an opportunity to start fresh.  Any problems with your old records, any inconsistencies, any annoying quirks, now is the chance to fix them.  The added advantage is the more consistent your records are the more easily they can be migrated.  The key to migrating data is to know where each field in the old system is going to appear in the new one.  This is easier to track when the old records are standardized.  (For a general slideshow on the importance of data cleanup.)

Remove unnecessary data

More data means more potential problems and may also increase costs if you are using a vendor. You can reduce amount of data that you have to migrate by doing things like weeding your collection, removing user records that are no longer active, and considering other events like fine amnesty. Collection weeding was one of the most frequently mentioned suggestions in our survey of ILS migrators and helps by reducing the number of records and removing older items that may not have up-to-date records. Fewer records also means less time must be spent checking for errors. Purging old user accounts reduces data overhead, while holding a fine amnesty day for patrons or just wiping out fines and fees entirely can also make your process easier.

Another important element of data prep is getting rid of unneeded records.  Weeding, both collection and patron records, is useful.  ALA has some great resources on weeding library collections.  Although this is not a necessary part of data prep it is highly recommended.  This is also a good time to think about doing an inventory.  Knowing what materials you have ensures that the records that you migrate reflect the current state of your library.  The major motivator is cost.  If you are using a vendor to migrate your data, you should know that they charge by the record.  So why pay for records that you don't need?  If you're doing the migration internally, why would you want to clutter your brand new system with unneeded records. 

Fines are an element that deserves some discussion.  Often fines, or at least the fine details, are difficult to migrate from one system to the other.  If at all possible, consider a fine amnesty.  It will give you one less thing to worry about.  If you can't do an amnesty then consider other options.  Some libraries put their fines in an Excel spreadsheet, print it out and keep it at the circulation desk.  Then they put a note in the system.  As people pay their fines they are cross off the printout.  This method allows them to keep the details of the fines without fighting to move them into the new system.  It may take some creativity but sometimes the answer isn't to migrate the data into the new system.

Check data fields for consistency

Library catalogs often suffer from inconsistency in the fields used to enter information, causing confusion about item information and creating problems in migrating the data fields. Any migration planning process should emphasize the need to enter information consistently to avoid migration errors later.

Do a test migration first

This is a good idea for several reasons, but when it comes to your data, doing a test migration will let you see what happens to your information in the new system and make changes before you commit to going live.

 

 

Technical Resources

Many technical resources for specific OSS ILS like Evergreen and Koha are available online through the OSS communities themselves, proprietary vendors, and independent groups. These resources can help libraries with troubleshooting, customizing OSS ILS interfaces, managing databases, contacting experts for help with questions, and contacting community members through wikis, forums, and listservs. Although the official documentation pages for Evergreen, the Evergreen Wiki, Koha, and LibLime Koha are the most detailed and up-to-date resources available, many independent websites provide useful tips and tutorials about big fixes, workarounds, and customizations. It is important for libraries to realize that answering a question about an OSS ILS requires independently consulting multiple sources rather than simply contacting a single vendor.

Staff Training

The Role of Staff Training: Why and How?

Libraries migrating to OSS ILSs should train their staff members on the new system. Doing so will make the migration process much smoother and better enable staff members to perform their jobs and train and market the new system to patrons.

According to the general Migration and Training PowerPoint presentation at the 2010 Growing Evergreen International Conference, the first step of staff training is for each individual library to assess its training needs.

Who needs to be trained about what tasks?

  • Consortium and local administrators
  • IT staff
  • Frontline staff

When and where should they be trained?

  • On site
  • Online
  • A combination of both?
  • Training close to a “Go Live” date also tends to be the most effective

How should training be done?

  • A vendor could come in to train all staff members
  • One staff member could learn the system and then train others
  • Some libraries choose not to use a vendor at all and instead creating staff training materials from community documentation freely available online

Finally, why should staff be trained on OSS ILSs?

  • To reduce staff anxiety
  • Create staff enthusiasm
  •  Increase patron confidence
  •  Reduce future support tickets to a vendor

To train effectively, library administrators must talk with their staff about OSS ILSs, give them the opportunity to practice working with a demo site hands-on, available documentation from the community, and how to get help. Administrators must also talk with any vendors used for training about their libraries’ unique workflows, staff skills, current system requirements, and future goals.

Overall, the type of staff training done is not as important as doing staff training in general. Think about your unique needs as a library when deciding exactly how and when to train staff members. All types of staff training should involve task-related “homework” that individual librarians must work through to learn the new system.

There are a few examples of training materials available online for Evergreen and Koha. Unfortunately, there is not a lot available about training specifically, so libraries in the migration process are often forced to rely on vendors or work through the community documentation themselves. Having more libraries using Evergreen and Koha contribute and share their resources on the web would greatly help other libraries. If you are a library using Evergreen or Koha and want to share your resources on this website, please contact us on our Forums page.

Working with Vendors

Although switching to an OSS ILS is often a challenging process requiring significant time and technical experience, there are many resources available to help libraries with the evaluation and migration process. Vendors like LibLime (with its own separate source code) and ByWater Solutions for Koha and Equinox for Koha and Evergreen provide support to libraries without technical staff. There are also many resources and sources of documentation for individual OSS ILS available online.

Best Practices for 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.)
  • Make sure 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 the problems in-house.
  • Remember, open source vendors are still vendors.  
  • Provide specific examples when reporting problems.  Specific example will help the developers determine what the problem is.  Especially if there are problems with the use of terms, having examples will help prevent 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 they can translate any problems or explanations from one group to the other.
  • Set up regular meetings for those involved in the migration project.  Regular meetings keep everyone focused and on task.  It also provides an opportunity for questions, concerns, and problems to be addressed quickly.