Visit our Facebook PageVisit our Youtube channel

Text Resize

-A +A

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.