Tell us your name, title and your place of work?
I am Knut Anton Bøckman, and I work as “Special Advisor” in the Royal Danish Library in Copenhagen. My title is deliberately not very descriptive, as I am put to a range of different tasks – project management, external consultancy, workflow analysis, committees, etc. – always on library systems and data. But my rock bottom is Primo administration – this I’ve been doing for most of the almost 10 years I’ve been with the library.
What Ex Libris products are used by your institution?
We use Alma and Primo VE, and are currently implementing Leganto. Until very recently we used Aleph, SFX, and Primo (all on local installations) – and we continue to host approximately 30 other institutions on combinations of these products.
Your institution recently went through a long-planned migration and adopted Alma, can you talk a bit about your experiences on this?
The Alma (and Primo VE) adoption was one part of a three-pronged process – the other two being institution mergers and change of cataloging format, which all happened simultaneously. I’d like to start with a short description of the institution. The Royal Danish Library is the National Library of Denmark – with many special collections and archives. In addition, it also serves as University Library for four different universities: University of Copenhagen, Aarhus University, Roskilde University, and the IT University. On top of that, we are an internal library to the Central Government Administration of Denmark. This is obviously quite a complex organisation, and quite uncommon. It is crucial to understand that the University Libraries are (mostly) not part of the respective Universities, but instead part of the Royal Danish Library – which is a separate institution and has tasks beyond the University Libraries.
Prior to our Alma migration, we already knew some of this complexity in Copenhagen, where for years we’ve had the National Library in the same Aleph/SFX/Primo installation as the University Libraries for Copenhagen, Roskilde, and the IT University. In Denmark’s second-largest city, Aarhus, the State Library also had extensive National Library tasks, and was simultaneously University Library for Aarhus University. These services relied on data from a separate Aarhus Aleph installation and a great arsenal of self-developed tools, including a Discovery system.
The institutions were merged in 2017 and with our move to Alma, we would be united in one Alma institution, with common workflows, rules, and a library service that would span most of the country. The Royal Danish Library now has approximately 800 employees, in case you were wondering.
Our second challenge was the change of cataloging format. Denmark has its own version of MARC (called denMARC, obviously) that we’ve all been using for years. The format was supported by a regional extension of Aleph, but with the move to Alma, our 14 million records needed to be converted to MARC21. ExLibris performed the conversions based on official mapping documentation and extensive input from our side to account for local and variable cataloging practices. Testing of the converted records through several iterations and test loads of data required us to move the go-live date from up by a month. Even so, just the re-education of our librarians to adopt a new format and develop new cataloging practices is an ongoing effort.
And to finally return to your question: The Alma implementation served as the framework within which all this would happen, while also not being a trivial task in itself. We began in January 2019 and even though we went live in November 2019, we are still doing extensive data clean-ups and training. Nonetheless, I have no doubt that without tying all this to an externally set time limit and an implementation project managed by ExLibris, we would not have got as far as we have at this point with the institutional merge and the format conversion. In hindsight, the technical migration to Alma itself can tend to look like a breeze, as most of our issues stemmed from format conversions and merger issues, but of course this is not exactly true. For any institution, migrating to Alma will require a lot of analysis, testing, and decision-making, and as in our case, a particularly complicated landscape. While the denMARC to MARC21 conversion is completed (and now a crosswalk function in the Alma product), we still struggle with side effects of the merger process.
Do you have any tips for those who may be considering a migration?
It is tempting to say: don’t be so complex, but that obviously won’t help anyone. Of course, there are the general project advice: be clear about your priorities and your red lines, etc. – everyone should know this. From our experience, I’d like to highlight three things:
- You cannot start testing and training too early. Yes, your data may not be migrated yet, so some level of abstraction is required to follow through on this. But the sooner you start to build experience with the system, the better informed you will be about making configuration choices during implementation. In some cases, we could have saved a lot of time and effort if we had found out about a useful function earlier in the process.
- If your library has software developers creating auxiliary systems that should integrate with Alma, connect them closely to the departments that will use their product. Make sure they understand the ultimate goal and follow the required workflow. At several points, we found that the auxiliary system was not needed, as Alma supported the process already; at others, the integration just went so much smoother.
- Make full use of ExLibris’ implementation team. Our Alma implementation was staffed by a very professional services team, and unfortunately, we did not always take advantage of this at first. While they helped us tremendously, we often tried to solve many of the tasks ourselves instead of reaching out to them for a solution. Of course, there is a learning aspect to this, and a way for us to understand the system, but it also led to unnecessary delays in implementation decisions, testing, and training. We did get better at this over time, but I believe we could have gotten further if we had put our DIY culture on hold from the beginning.
Can you talk about a time where contributions from IGeLU members helped your work, or the work of your institution?
We rely heavily on the community for understanding how things can be done. The listservs for both Alma and Primo are great for finding answers and asking questions. Through my work in the Primo Working Group, I know many institutions that have migrated from Primo and Primo VE, and this has been a great benefit for us. To mention just a few, Amin Hussain (University of Manchester) was very helpful when we were setting up the load of external data sources to our Primo VE, and we’ve also had very helpful conversations on Primo VE with François Renaville (University of Liège) and Lukas Koster (University of Amsterdam). On the Alma side, we’ve received invaluable advice from Oslo University Library, both on project organisation, transitioning of catalog format, and not least, our Alma training planning, to which Christine Rostgaard has repeatedly and substantially contributed. While the Royal Danish Library has been active in the Primo community for quite some time, I expect us to become more visible also in other product areas going forward. There is so much to be learned from this community, and we also want to contribute in kind.