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.