Archive for the ‘Migration Nation’ Category

Migration Nation, Part 2: Six Months Before Launch

Wednesday, March 11th, 2009

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.

Migrations

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!

Migration Nation, Part 1: Thinking Ahead to a Successful Migration

Tuesday, February 3rd, 2009

The Equinox team has a few legacy-ILS-to-Evergreen migrations under its belt; it’s something we do well –and we’re getting better at it all the time. To launch this new year on a good foot, we’re publishing a six-part series on planning successful data migrations.

Over the next three weeks we’ll address these topics: Thinking Ahead (this post); Six Months Out; Three Months Out; One Month Out; One Week Out; and Post-Migration. Please share your own ideas and experiences as well. This is the kind of stuff “they don’t larn you in library school,” so the more knowledge we can accrue, the better off we’ll all be.

By the way, you may think this post should leap into questions about data, rebarcoding,  servers, policies, and so forth. You’ll notice this post is farther down Maslow’s hierarchy and focuses on some very basic human resource issues that trump other questions.

Finally, many of the questions are the same whether you are hosting your own servers or using a hosted service, joining a consortium or migrating as a “standalone” library. But we’ll note the questions unique to those experiences.

Thinking Ahead to a Successful Migration

The first task is to identify the factors influencing your migration date. Pick a tentative date  for your migration as the endpoint of your timeline, then work backwards by answering these six questions:

1. Who needs to be available at different points of the timeline for training, database maintenance, policy decisions, public relations, and “boots on the ground” during the final weeks of the actual migration and the immediate aftermath? Will you need to create (or even hire) key positions such as project manager, training coordinator, or a primary IT person?

2. Will you will continue running your legacy system concurrently with your new system? This could reduce the data that needs to be migrated, but, depending on your timing and the expiration date on your legacy system’s contract, may create another contract renewal your library needs to fund. If you will continue running your old system, how long? A month? Three to six months? Longer?

3. Will you stay open during migration, or close the library? (Deciding to close for several days makes a long weekend or a slow period a good bet.)

4. Do you need a help desk? Depending on your environment, your library may need to create a help desk for fielding support questions. How will you staff the help desk? If you don’t have a help desk, how will you communicate with your support service?

5. What materials do you need on hand during the switch-over? Think down to the most basic levels. If you will be circulating by hand for several days, then make sure you have plenty of “circ sheets” (and pens!) or some other method for tracking your circulations and registrations.

6. What’s your contingency plan in case health, weather, or other emergencies take key people out of action during crucial periods? Remember… not having a contingency plan is the best way to invoke Murphy’s Law!

Stay tuned for next Tuesday’s post in this series, Migration Nation: Six Months Out.