Migration Nation, Part 2: Six Months Before Launch

This is part 2 of a series of posts about planning migrations to a new ILS.

In the first post in this series, we asked some of the tough human-resource questions, focused primarily on whether you have the right people in place. In this post, we’ll look at where you need to be in terms of other decisions and resources six months out from your projected migration date.

Are you ready to migrate?

Note that “six months” is an educated guess from the collective voices of Equinox/Evergreen experience. It obviously won’t hurt you to have more time under your belt for these key decisions. Certainly, libraries have also migrated with shorter timeframes — but at least know what you’re in for.

The six-month milestone is an ideal time to…

Closely examine the terms of your current ILS contract. You may need to pay to extract your data from your old system, particularly if you don’t own your data. Some smaller libraries have walked away from vendors, electing instead to recatalog, but in most cases you will need to budget the cost of retrieving your own data.

Determine your server specifications. If you aren’t going to outsource your hosting, you (or your consortium) will need servers. Evergreen, like most modern software, is usually configured on an array of redundant, reasonably-priced “commodity” boxes, a robust configuration with failover capabilities. You don’t want to lowball your needs, particularly with library use on the rise.

Decide if you need to rebarcode your items. This is a particularly crucial question if you are joining a consortium, as your library items will need unique barcodes that don’t overlap with barcodes used by other libraries. Obviously, the larger your library the more challenging rebarcoding will be. If you are going to rebarcode and you’ve been considering RFID, this is a good time to take another look at this emerging technology, as you will need to touch each one of your books anyway.

Decide if you need to rebarcode your patrons. O.k., perhaps not your patrons, exactly, but definitely their cards. If you are joining a consortium, patron barcodes shouldn’t overlap. Are you going with a consortial card? Is this a time to consider keyring cards, or a new card design? Again, if you’re considering RFID, this would be a good time to go with a “chipped” card.

Do you need to dedupe? For libraries planning a modern consortial catalog (single bib records with multiple holdings), records need to be merged (deduped). Wide variations in cataloging practices can make deduping fairly challenging, requiring close communication and planning among developers, data specialists, and catalogers.

Survey your data. You probably are familiar with at least some of your bad data: the short records that never got updated, the patrons who never got marked inactive because your old system wouldn’t allow that, the records that were never deleted. Get familiar with the skeletons in your closet. We guarantee your funky records will try to resurface during migration!

Inventory and weed. One smart way to get rid of a lot of bad data is to begin with an inventory (especially for missing items), followed by a weeding project. The database maintenance that accompanies inventory and weeding will make data migration easier. If you do need to re-barcode items, obviously, weed first.

Decide what data you are migrating. Just bibliographic records, or data such as patron records (particularly addresses), copy-level information, checkouts, fines, holds, and so forth? Before you say “all of it,” note that some libraries elect not to move over non-bib data (which in-house we sometimes call “transactional data”). These data are nonstandard, vary widely from vendor to vendor, and present complex extraction issues that will add to your cost and your timeline. Libraries that don’t migrate transactional data often check books into both their legacy and new ILS for a period of time, and offer amnesty no-fine periods (which also helps you retrieve long overdues and missing items before you weed).

Decide who will extract your data so it can be migrated into the new system. Will you do this yourselves or contract out with a company? (As noted above, transactional data is complex to migrate.) If you’re outsourcing, make that relationship now — not simply because you need to pick your provider, but because their availability affects your timeline.

Get “local admin” training so you can better identify policies and workflows that Evergreen can simplify, streamline, and improve. In some cases this may mean convincing staff who’ve “always done it that way” that another way can be better.

Decide if you’re going to use Evergreen to redefine shelving locations — particularly if you’ve been using workarounds because your old system didn’t let you pick the locations you wanted.

Convene policy discussions to decide policies at the local and consortial levels. In identifying consortial and local policies, particularly for outward-facing features, weigh the trade-off of a common user experience against local control. Just a handful of common areas for discussion include loan durations, fine policies, and holds policies. Evergreen supports all kinds of fine-tuned local control, but that doesn’t mean local control is always the best choice.

Review resource-sharing services. If new libraries are  joining a resource-sharing consortium, it could be timely to reexamine courier routes, hold policies, and other configurations.

Plan your training. In many cases, you don’t want to begin training too early — otherwise staff can forget features and functions. But it’s not too early to begin determining who will do your training, who will write your local training documents, who you will be training, and when they will be trained.

Finalize any development customization requirements. This is deliberately placed at the end of this list, after policy discussions and local admin training, because in many cases once you learn how Evergreen works, you may not need or want to try to bend it to the workarounds you used with your old software.

The next post will focus on the three-month milestones. You’ll notice the lists get much shorter as we get closer to the migration date. That’s how it should be.  Trust us, you’ll be busy enough without making last-minute decisions about holds policies and whether you need to rebarcode!