This post starts a series that will continue intermittently until (probably) late this summer, when the Bartlett Library of the Museum of International Folk Art goes live (we hope) on our new library system. We’re a special research library, but a lot of what we’re going through is relevant for any kind of library, so we are sharing our decision-making and migration processes in the hopes it may help someone else. You’ll find that these articles are all written from the perspective of a small library with a single staff member. If your team is larger, if you have extra resources, your experience will be a bit different, and you’ll want to think about who should be on your migration team and when each member of the team should become involved.
In the course of my library career I’ve worked with 8 different library software systems, and survived several migrations. Most of my time has been spent in public libraries (I’ve only been “special” for the last year, and I was academic for my first year as a librarian). Often, I’ve been the techiest person on the staff – well, for that matter, I’ve usually been the only librarian on the staff, and sometimes the only person – so discovering I needed to handle a library migration for the Bartlett was not the shock it might otherwise have been.
Step 1 of any migration is realizing that it is time, that the system you have in place no longer works for you. Step 1 ½ is overcoming horror and resistance to the idea.
Why horror? It’s not just that change is hard. In every migration there is potential for crucial catalog, patron, or transaction data to be lost or mangled, requiring large amounts of time to fix. There is the absolute certainty that your already more than full-time job is about to require even more work in the short term. There is the need to re-train staff, volunteers, and – most difficult of all – patrons to use a new system with a new catalog and staff interface. It is expensive. It is a big deal, and there is never enough time or money to do it as perfectly as we would wish.
The Bartlett Library automated late, and has only ever had one system: InMagic’s DBTextworks, which does not use MARC format records because it isn’t really a library system. Oh, joy.
Migration means not only converting all our catalog data, but somehow moving it from non-MARC into MARC. This realization is almost enough to stop the migration before it begins – but we know that we have to switch systems. With InMagic we can’t even do a basic keyword search. We need a system with better search capabilities, and one with a web interface. (There was more to the decision, but this is a short article. Feel free to contact me at firstname.lastname@example.org for more gory details).
Step 2, well, step 2 depends upon preference. Some people choose this time to figure out what money they will have available for a system change, both for the move itself and for the annual fees involved. It is certainly essential to have a ballpark cost in mind, but I’d advise against getting definite numbers from your funders at first. Why? If you do a little more research first (always keeping your ballpark figure in mind), then your initial funding discussions can include descriptions of the wonderful services you could offer with potential new system X if only you had amount $Y available… rather than settling for Z which is a few dollars less but won’t allow you to offer the snazzy new service. When asking for increased funds (which we almost always are), it helps to be able to tie the request to a concrete new service to be offered.
My step 2 is to go out into the world and begin to look over the options, and that will be the topic for our second post.