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:


  • 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.


  • 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.