Running the Library, Technology

Tales of Migration, Part 8
In Which We Set Timelines and Draft Contracts

This is the eighth in a series covering the library system migration of the Bartlett Library at the Museum of International Folk Art.

The story so far: The library needs a new library system, and has selected Koha open source software hosted and maintained by ByWater Solutions as its preferred solution. We’ve found a partner in the Laboratory of Anthropology Library nearby and created a draft agreement between the two libraries. We have a firm quote from the vendor and all initial approvals and now we need a contract.

Actually, in our situation we needed two contracts since the two libraries have separate funding streams. In any case, not being (or having any desire to be) a lawyer, I’m not going to talk much about contracts per se. Our institutions had boiler-plate contract forms we could fill in; yours may have something similar. The vendor will have a contract form as well, but in my experience we’ve mostly used contracts drawn up on the library (or consortium) side and negotiated with the vendor rather than using the vendor’s contract.

The one piece of the contract over which we librarians labored hard was the timeline. In our case, it’s an “exhibit” attached to our contracts and mentioned within them as containing key terms. The timeline is your best tool for keeping your migration on track. It will let you know progress is being made at an appropriate rate, and that your go-live date is viable – or, in the worst case, it will let you know well ahead of time that you can’t go live on the date planned, and that you need more time to resolve issues with the migration. It specifies key deliverables that the vendor must provide, and tells the vendor when they must be provided.

This was our timeline design process:

  • We asked the vendor for a sample timeline showing how long they typically need to perform the migration work on their side.
  • We decided whether their sample timeline left us enough time to test whether the data was loaded into the system correctly and whether the system worked correctly. We increased our time in each area since we are solo librarians, and since we are happy taking a little longer with our migration to make sure it goes smoothly. If you’re in a hurry (for example, to get the migration done before you have to pay for another year on your old system) your priorities may vary.
  • Up to this point the timeline didn’t have real dates attached, just lengths of time like “two months after contracts are signed”. Now we sat down with a calendar and attached tasks to specific dates. For us this meant stretching our migration process a bit longer to allow for things like a previously scheduled vacation, and to make sure our go-live date didn’t crash up against a huge event like the International Folk Art Market. We couldn’t stretch too long, though, or we’d hit preparations for an essential Fall book sale… this is a lot like juggling. Be realistic about what you and your staff can manage.

Key events in the timeline:

  • Contracts signed
  • Initial meeting (in-person or via web/phone) of the migration team, including members from the vendor and the library, to discuss the timeline, technical details, ongoing meeting schedule, and everyone’s responsibilities
  • Library delivers data to vendor (Watch out here! How much data cleanup will you want to do before you deliver data? Leave time for this.)
  • Library delivers system rules and parameters (everything that describes your library’s rules for items, circulation, patrons, etc.) to the vendor
  • Vendor has time to convert data and load converted data and rules into a test system
  • Library gets access to test system with data
  • Vendor trains library staff (Get the training as close as possible to the time you get the test system. Things you learn in training will help you test the system effectively and discover quickly whether you need to make adjustments to the data or the parameters you have chosen. Don’t delay the training; the last thing you want is to get your training the week before you go live, when it’s too late to adjust your choices.)
  • Library tests system and makes sure data loaded correctly
  • Vendor customizes public catalog
  • Library tests public catalog (if you use third party products like Overdrive or ChiliFresh this is the time to install those as well)
  • Meeting to give go-ahead for final conversion
  • Library provides fresh data
  • Vendor converts data and loads it into a live system
  • Library goes live with new system
  • Library has time to review final conversion and make sure all is well before signing off on conversion and data
  • Regular ongoing support and maintenance begin

I’ll go through the steps in more detail when we get to actually doing them.

Your timeline may need more steps. For example, some vendors convert serials data separately from monographs. If you have a lot of complex magazine, journal, or other serials data you may need extra steps for the serials section of the conversion (which is notoriously tricky). Perhaps your library has a governing body, like a Board of Trustees, that wants to sign off on different sections along the way, or that requires reports from the vendor at certain points. Add what you need.

One more piece of advice on your timeline before we go: identify key dates when you make decisions about whether the process is working and the go-live date is still achievable: if step X is not done by date Y then go-live must be rescheduled. Make these check points clear to the vendor up-front. This will improve your control over the process and ensure you are not pushed to sign off on a product you don’t think is ready for use.

Next up: how to make decisions about when to do data cleanup.

Comments Closed

Comments are closed. You will not be able to post a comment in this post.