Von NEBIS zu SLSP

Wie die Datenmigration des grössten Schweizer Verbundes umgesetzt wurde

Barbara Wittwer, ETH-Bibliothek Zürich

Zusammenfassung

Am 7. Dezember 2020 begann mit der Suchplattform swisscovery für das Schweizer Bibliothekswesen eine neue Ära. Die sechs bestehenden Verbünde von wissenschaftlichen Bibliotheken fusionierten zu einer einzigen Plattform, der Swiss Library Service Platform (SLSP). Damit einhergehend wurde mit Ex Libris Alma auch ein neues Bibliothekssystem eingeführt und Aleph und SFX wurden abgelöst. Der NEBIS-Verbund, ehemals grösster Bibliotheksverbund in der Schweiz, initiierte mit „Change NEBIS“ ein Projekt, in welchem die Datenmigration organisiert und durchgeführt wurde sowie die NEBIS-Bibliotheken beim Wechsel zu SLSP begleitet wurden. Die NEBIS-Systemverantwortlichen organisierten und priorisierten die Datenbereinigungen und bereiteten die NEBIS-Daten für die Testläufe und finale Migration auf. Dank sorgfältiger Planung, Einbezug von Fach-Expert*innen, Datenbereinigungen sowie aufwändigen Testmigrationen konnten die komplexe Datenmigration des NEBIS-Verbundes termingerecht ausgeführt und die im NEBIS verwendeten Systeme anschliessend ausser Betrieb genommen werden.

Summary

On 7 December 2020, a new era for the Swiss scientific libraries began with swisscovery. The six large library networks merged into one single platform, the Swiss Library Service Platform (SLSP). This was accompanied by the introduction of a new library system, Ex Libris Alma, which replaced Aleph and SFX. The NEBIS network, formerly the largest library network in Switzerland, initiated a project called “Change NEBIS”, which organised and carried out the data migration and also supported the NEBIS libraries in their change to SLSP. The NEBIS system managers organised and prioritised the data clean-ups and prepared the NEBIS data for the test migrations and the final migration. Thanks to careful planning, the involvement of experts, data clean-ups and extensive test migrations, the complex data migration of the NEBIS network was completed on schedule and the systems used in NEBIS were subsequently deactivated.

Zitierfähiger Link (DOI): https://doi.org/10.5282/o-bib/5738

Autorenidentifikation: Wittwer, Barbara: ORCID: https://orcid.org/0000-0002-9870-7885

Schlagwörter: Datenmigration; Alma; Bibliotheksverbund; SLSP

Dieses Werk steht unter der Linzenz Creative Commons Namensnennung 4.0 International.

1. Einleitung

Der NEBIS-Verbund war mit ca. 140 angeschlossenen Bibliotheken von 1987 bis 2020 der grösste Bibliotheksverbund in der Schweiz1. Die NEBIS-Verbundzentrale und die Bibliotheks-IT waren an der ETH-Bibliothek Zürich angesiedelt. Der NEBIS-Verbund zeichnete sich durch seine heterogene Bibliothekslandschaft sowie die Multilingualität2 aus.

Im Jahr 2015 wurde das Projekt Swiss Library Service Platform3, kurz SLSP, an der ETH-Bibliothek initiiert. Ziele des Projekts SLSP waren, ein Bibliothekssystem der neuen Generation sowie ein Discoverytool zu beschaffen, ein Serviceangebot für wissenschaftliche Bibliotheken und eine nationale Plattform aufzubauen und damit die bestehenden Verbünde abzulösen. Im Mai 2017 wurde dazu die SLSP AG4 gegründet. Trägerinstitutionen der SLSP AG sind 15 Hochschulen. Nach der Gründung der SLSP AG wurde Personal5 angestellt und Expert*innen aus den Verbünden und einzelnen Bibliotheken für die Projektarbeiten beigezogen. Die Evaluation der neu zu beschaffenden Systeme kam im Jahr 2018 zum Abschluss. Die Wahl fiel auf das cloudbasierte Bibliothekssystem Alma6 und das Discoverytool Primo VE7, beides Produkte der Firma Ex Libris.

Im vierten Quartal 2020 erfolgten die Datenmigration und der Start von SLSP. Damit einher gingen der Go-Live von Alma und die neue Suchplattform swisscovery8, die auf dem Discoverytool Primo VE basiert. Mehr als 470 Bibliotheken9 aus sechs Verbünden10 von wissenschaftlichen Bibliotheken – darunter alle Bibliotheken des NEBIS-Verbundes – schlossen sich der SLSP an. Die Verbünde lösten sich anschliessend auf.

Um den Wechsel des NEBIS-Verbundes zu SLSP zu vollziehen, startete im Jahr 2017 an der ETH-Bibliothek das Changeprojekt „Change NEBIS“ unter der Leitung von Andreas Kirstein, stellvertretender Direktor der ETH-Bibliothek und Verbundleiter des NEBIS-Verbundes. Für den NEBIS-Verbund und dessen Mitarbeitende bedeutete dies, die NEBIS-Bibliotheken beim Wechsel zu SLSP zu unterstützen, die Datenmigration von rund acht Millionen Titelaufnahmen, 15 Millionen Exemplardatensätzen und 4.2 Millionen E-Ressourcen-Portfolios durchzuführen, die eingesetzten Systeme Aleph11, SFX12, ARC13, und Primo 14 abzulösen und für die Mitarbeitenden der NEBIS-Verbundzentrale geeignete Anschlusslösungen zu finden.

Für die Datenmigration und den Abbau der bestehenden Systeme des NEBIS-Verbundes wurde im Projekt „Change NEBIS“ das Teilprojekt „Applikationen und Daten“ eingerichtet, für dessen Leitung die Autorin dieses Artikels verantwortlich war. Nachfolgend wird auf die Arbeiten in diesem Teilprojekt eingegangen. Dabei werden sowohl die gemachten Erfahrungen und gewonnenen Erkenntnisse erläutert als auch Überlegungen, die bezüglich Projektmanagement gemacht wurden, aufgeführt.

Die Planung der Einführung der neuen Systeme Alma und Primo VE (d.h. Einarbeitung in die Systeme, Schulung, Planung des Go-Lives, etc.) war nicht Bestandteil des Projekts „Change NEBIS“, da der NEBIS-Verbund nach der Migration aufgelöst wurde und die Einführung der neuen Systeme in der Verantwortung von SLSP und den Bibliotheken war. In den jeweiligen Institutionen wurden dafür eigene Projekte15 durchgeführt.

2. Verantwortlichkeiten und Meilensteine

Für die Migration sämtlicher Daten aus den Vorgängersystemen der sechs Verbünde war SLSP verantwortlich. Zusammen mit der Firma Ex Libris plante und koordinierte SLSP die Migration sowie den Go-Live der neuen Systeme. Die Verbünde waren dafür verantwortlich, die Daten für die Migration vorzubereiten, die Datenextraktion für die Testmigrationen und die finale Migration auszuführen. Ebenso unterlag die Information der angeschlossenen Bibliotheken der Zuständigkeit der Verbünde. Für die Kommunikation und Unterstützung der NEBIS-Bibliotheken beim Wechsel zu SLSP wurde im Projekt „Change NEBIS“ ein weiteres Teilprojekt geschaffen, welches eng mit dem Team des Teilprojekts „Applikationen und Daten“ zusammenarbeitete.

Da Ex Libris für die Dedublierung der bibliografischen Daten, die aus den sechs Verbunddatenbanken zusammengeführt werden mussten, keine zufriedenstellende Methode anbieten konnte, wurde das Team von swissbib16 mit dieser Arbeit betraut.

Für die Planung der Migrationsarbeiten setzte SLSP eine Arbeitsgruppe ein, welcher die Migrationsverantwortlichen der einzelnen Verbünde und die für die Migration zuständigen Mitarbeitenden von SLSP angehörten. Unterstützt wurde das SLSP-Migrationsprojekt von Expert*innen aus zehn sogenannten Vanguard-Bibliotheken17. Bei den Vanguard-Bibliotheken handelte es sich um zehn ausgewählte Bibliotheken, welche unterschiedliche Institutionen vertraten (u.a. die ETH-Bibliothek Zürich, Universitätsbibliothek Basel, ZHAW Hochschulbibliothek Winterthur). Die Vanguard-Bibliotheken stellten personelle Ressourcen für die Tests der migrierten Daten und der Konfigurationen der Systeme zur Verfügung.

Das Migrationsprojekt begann offiziell im Februar 2019 mit einer Kick-Off Veranstaltung mit Ex Libris, SLSP, den Migrationsverantwortlichen der Verbünde und Vertreter*innen der Vanguard-Bibliotheken. SLSP vereinbarte mit Ex Libris drei Testmigrationen, welche in den Jahren 2019 und 2020 stattfanden. Die Migration begann Ende Oktober 2020 und dauerte etwas mehr als sechs Wochen. Am 7. Dezember 2020 konnte Alma mit den migrierten Daten durch das Bibliothekspersonal der SLSP-Bibliotheken in Betrieb genommen werden.

Zeitplan des Migrationsprojektes

3. Beginn des Projekts „Change NEBIS“

Noch bevor der Systementscheid fiel, startete das Projektteam von „Change NEBIS“ im November 2017 mit den Projektarbeiten. Das Team des Teilprojekts „Applikationen und Daten“ begann damit, alle betroffenen Systeme, Daten und Akteure18 sowie deren Beziehungen zueinander in einer Übersicht zu erfassen. Diese Zusammenstellung bildete die Basis für die Definition der Arbeitspakete.

Der frühe Start des Projektes (drei Jahre vor der Datenmigration) schuf genügend Zeit, um auf Projektebene die Ziele festzulegen, die Kommunikationswege zu bestimmen, Schnittstellen zwischen den Teilprojekten zu definieren und die Arbeiten zu planen. Als im Jahr 2018 der Entscheid für das künftige Bibliothekssystem, welches Aleph ablösen sollte, zugunsten Alma gefällt wurde, konnten die weiteren Arbeiten in Angriff genommen werden. Um eine realistische Erwartungshaltung zu entwickeln und Prioritäten festlegen zu können, orientierte sich das „Change NEBIS“-Projektteam an Erfahrungsberichten19 anderer Bibliotheken und Verbünde und tauschte sich mit Projektverantwortlichen aus Einrichtungen, die bereits Alma eingeführt hatten, aus. In jedem Vortrag, jedem Artikel und in Erfahrungsberichten wurde der grosse Aufwand bezüglich der Datenbereinigungen deutlich, wodurch dem Projektteam schon früh bewusst war, dass entsprechend viele Ressourcen dafür einzuplanen waren.

4. Von Aleph und SFX zu Alma: Unterschiede in der Topologie der Systeme

Im NEBIS-Verbund wurden die Daten in Aleph in einer bibliografischen Datenbank, einer Holdingdatenbank, mehreren lokalen Schlagwortdatenbanken sowie drei administrativen Datenbanken verwaltet. In einer administrativen Datenbank wurden die lokalen Daten der Bibliotheken verwaltet, z.B. Exemplardaten, Abodaten, Benutzerdaten, u.a. Dass die lokalen Daten in drei administrativen Datenbanken verwaltet wurden, ist der Integration von zwei grossen Institutionen in den NEBIS-Verbund geschuldet. Die lokalen Daten der Zentralbibliothek Zürich waren in einer administrativen Datenbank gespeichert, diejenigen der Universität Zürich in einer weiteren. In der dritten wurden schliesslich die lokalen Daten der ETH Zürich und weiterer Bibliotheken des NEBIS-Verbundes verwaltet.

Die E-Ressourcen-Zugänge wurden im NEBIS-Verbund in fünf SFX-Instanzen verwaltet. Dies war nötig, da es im NEBIS-Verbund Institutionen gab, die die Zugänge zu ihren E-Ressourcen selbst verwalten wollten und dafür eine eigene Instanz verwendeten.

Die Topologie von Alma sieht eine Community Zone (globale Zone, enthält v.a. Metadaten von E-Ressourcen und Normdateien) und eine Institution Zone, in welcher die Bestands- und administrativen Daten einer oder mehreren Bibliotheken verwaltet werden, vor. Die Metadaten der E-Ressourcen, welche v.a. von E-Ressourcen-Anbietern stammen, befinden sich in der Community Zone und können dort freigeschaltet werden. In der Institution Zone wird verwaltet, welche Ressourcen die Bibliothek lizenziert hat.

In Alma von SLSP gibt es zusätzlich noch eine Networkzone. Diese richtet Ex Libris für Netzwerke ein, die mit einer zentralen Katalogisierung arbeiten möchten. In der Networkzone befinden sich die bibliografischen Daten von SLSP sowie lokale Normdatenbanken. Speziell bei SLSP kommt dazu, dass sich auch die Benutzerdaten20 in der Networkzone befinden.

Die Alma-Instanz von SLSP besteht aus 29 Institution Zones21, welche jeweils die Bestandsdaten von mehreren Bibliotheken enthalten. Die Bibliotheken wurden vor allem aufgrund ihrer institutionellen Zugehörigkeit in einer Institution Zone zusammengefasst. So teilen sich beispielsweise alle Bibliotheken und Archive der ETH Zürich22 eine Institution Zone.

Die Alma-Topologie von SLSP

5. Migrationsprozess

Ex Libris bietet für die Datenmigration von Aleph bzw. SFX nach Alma ein standardisiertes Verfahren an. Für die Extraktion der Daten in Aleph und SFX wurde ein „Extraction Kit“ – ein Programm, mit welchem die Daten extrahiert werden – auf dem Aleph-, bzw. SFX-Server installiert. In einem umfangreichen Migrationsformular definierten die Migrationsverantwortlichen die Parameter, welche die Aufbereitung der Daten steuern. Damit war es möglich, die extrahierten Daten an die Datenstruktur von Alma anzupassen und fehlende Elemente in den Daten automatisiert zu ergänzen. Zudem ermöglichte das Migrationsformular Mappings vorzunehmen, z.B. jenes der Materialarten, die sich von Aleph zu Alma unterscheiden. Damit konnten die Exemplardaten mit den neu geltenden Materialarten ausgestattet werden.

Für einzelne Institutionen, die zu Alma migrieren, mag dieser Standardprozess gut funktionieren, für die komplexe Datenbankstruktur des NEBIS-Verbundes ergaben sich dadurch Einschränkungen: Die Definitionen im Migrationsformular galten für die Daten aller Bibliotheken, die in einer administrativen Datenbank in Aleph vorhanden waren. Folglich mussten die Parameter so gesetzt werden, dass diese für den Grossteil der zu extrahierenden Daten stimmten. Vor allem bei Signaturen musste in Kauf genommen werden, dass diese nicht alle richtig migriert wurden und daher in Alma manuell nachbearbeitet werden mussten. Zudem bot der Migrationsprozess keine automatisierte Lösung, die Ausleihstatus, welche die Ausleihbedingungen von Exemplaren steuerten, den neuen Ausleihbedingungen in Alma zuzuordnen. Die Status mussten folglich von den Migrationsverantwortlichen in Aleph mit einer Abfolge von Befehlen in der Datenbank an die in Alma verwendeten Ausleihstatus23 angepasst werden.

Dasselbe Problem zeigte sich auch für die Extraktion der E-Ressourcen-Daten aus SFX: für die grösste SFX-Instanz, welche Daten von mehreren Institutionen enthielt, konnte der Extraktionsprozess nicht durchgeführt werden, da die unzähligen Open-Access-Ressourcen für jede enthaltene Institution entladen werden mussten. Dies konnte nur umgangen werden, indem die Open-Access-Ressourcen in SFX deaktiviert und nicht extrahiert und migriert wurden. Sie mussten von SLSP und den jeweiligen Institutionen in Alma freigeschaltet werden.

Schematische Darstellung des Migrationspfades von Aleph und SFX nach Alma

Die Daten aus Aleph wurden in 16 verschiedene Institution Zones von Alma migriert und verteilt. Das „Extraction Kit“ steuerte, in welcher Institution Zone die Daten einer Bibliothek eingespielt werden sollten. Ex Libris übernahm die Einspielung der Daten in die Institution Zones, wo diese mit dem zugehörigen bibliografischen Satz in der Networkzone verknüpft wurden.

Die SFX-Portfolios von NEBIS wurden in 13 verschiedene Institution Zones von Alma migriert. Dort erfolgte mittels eines automatisierten Verfahrens von Ex Libris eine Verlinkung zu den bibliografischen Datensätzen und Portfolios in der Community Zone.

Die bibliografischen Daten der sechs Verbünde wurden von swissbib mittels eines komplexen Algorithmus dedubliert und in die Networkzone von Alma geladen.

6. Datenbereinigungen

Die Metadaten in Aleph wurden nach unterschiedlichen Regelwerken24 katalogisiert, was zu heterogenen Daten führte. Zudem entstanden durch die Integration von Metadaten von Bibliotheken, die im Laufe der Jahre neu zum NEBIS hinzukamen, Dubletten und Aufnahmen unterschiedlicher Qualität.

Da es nicht möglich war, alle „Altlasten“ zu bereinigen, empfahl sich folglich die Bereinigungsarbeiten zu priorisieren.

In einem Bereinigungskonzept wurden die zu erledigenden Bereinigungen aufgelistet und bewertet. Es erwies sich zunächst als schwierig, herauszufinden, ob es sich um wirklich wichtige Bereinigungen oder um kosmetische Korrekturen handelte. Eine von Ex Libris zur Verfügung gestellte Checkliste sowie Bereinigungsaufträge von SLSP und swissbib halfen, die notwendigen Bereinigungen festzulegen. Die erste Testmigration lieferte anschliessend erste Erkenntnisse über den weiteren Handlungsbedarf.

Innerhalb des Projekts „Change NEBIS“ wurden folgende Priorisierungsregeln festgelegt:

Priorität hatten Bereinigungen von Daten bzw. Datensätzen,

• die aufgrund der anderen Architektur von Alma ohne Bereinigung funktionale Beeinträchtigungen zur Folge haben würden (z.B. ein Exemplar ohne Standortangabe, welches in Alma nicht ausleihbar wäre)
• die ohne Bereinigung nicht migriert würden (z.B. im Erwerbungsmodul erfasste Lieferanten, die mit keiner Bibliothek verknüpft sind)
• die in Alma nicht mehr oder nur mit grossem Aufwand geändert werden können (z.B. Print-Abos, die an einer hybriden Aufnahme25 eines E-Journal hängen)
• mit fehlenden oder falschen Codierungen, um die korrekte Dedublierung mit anderen Datensätzen und die korrekte Anzeige im Discovery sicherzustellen.

Eine der wichtigsten automatisierten Bereinigungen in Aleph bestand darin, alle Exemplare mit einem Standort zu ergänzen. Der Standort in Exemplar- und Holdingsätzen stellte in Aleph kein Pflichtfeld dar, in Alma steuert er jedoch die Ausleihbedingungen und ist daher zwingend.

Weiter war es wichtig, dass die Exemplarstandorte mit jenen in den zugehörigen Holdings26 übereinstimmten. Leider gab es in der Aleph-Datenbank von NEBIS in den meisten Fällen keine Verknüpfung von Exemplar und Holding, weshalb mit einem eigens dafür entwickelten Skript die Daten abgeglichen und angepasst werden mussten. Dies war notwendig, da es in Alma keinen administrativen Satz (ADM-Satz27) mehr gibt, der das Exemplar mit dem bibliografischen Satz verbindet. Diese Aufgabe übernimmt in Alma der Holdingsatz.

Die Bereinigungen von E-Ressourcen-Aufnahmen und die Anpassungen von lokalen Schlagwörtern, bei welchen die Verknüpfung mit einer ebenfalls zu migrierenden lokalen Normdatenbank hergestellt werden musste, zählten bei den bibliografischen Daten zu den aufwändigsten Arbeiten.

Weiter wurden lokale Codierungen in den nutzerspezifischen MARC-Feldern (9XX) in lokale Erweiterungen28 umgewandelt. Diese Bereinigung betraf rund 4.3 Millionen Felder, welche aufgrund der langen Indexierungszeit sich nicht mehr im Tagesgeschäft umsetzen liess. Diese Felder wurden deshalb erst unmittelbar vor der Migration mittels Aleph Service - ohne Indexierung - angepasst.

Sämtliche erforderlichen Bereinigungen konnten rechtzeitig abgeschlossen werden. Entscheidend hierfür war, dass die Systembibliothekar*innen grosse fachliche Expertise in Datenbereinigungen mit Aleph aufweisen konnten und mit dem Netzwerk Metadatenmanagement29 der ETH-Bibliothek ein Team zur Verfügung stand, welches die Daten analysieren und die Bereinigungen ausführen und/oder koordinieren konnte.

7. E-Ressourcen-Aufnahmen in Aleph

Im NEBIS-Verbund war es lange Tradition, die Aufnahmen von E-Books automatisiert in Aleph einzuspielen. Bereits ab 2007 konnten dadurch grosse Mengen an E-Books in Aleph nachgewiesen werden. E-Journals und Datenbanken wurden ebenfalls in Aleph erfasst, allerdings manuell. In der bibliografischen Datenbank von Aleph existierten daher entsprechend viele E-Ressourcen-Aufnahmen von hoher Qualität.

Für den Nachweis der E-Ressourcen in Alma bzw. in swisscovery war die Migration der Aufnahmen nicht notwendig. Dieser wurde durch die Migration der Daten aus SFX sichergestellt. Allerdings hätte der Verzicht auf die Migration der Aleph-Aufnahmen auch bedeutet, dass damit verknüpfte Erwerbungsdaten (Bestellungen, Rechnungen, etc.) nicht migriert werden können. Folglich musste der Entscheid gefällt werden, ob die zahlreichen, qualitativ hochwertigen Aufnahmen in Aleph nach Alma migriert werden sollen oder nicht.

Nach der ersten Testmigration zeigte sich, dass die Migration der E-Journal-Aufnahmen aus Aleph nicht sinnvoll ist. Die Nachbearbeitung der migrierten Aufnahmen wäre sehr kompliziert gewesen, da die Titelgenerationen bei den Datensätzen in der Community Zone von Alma und jener in Aleph sehr häufig nicht übereinstimmten. Zudem ist es sinnvoll, Bestellungen von E-Journals in Alma auf Collection 30 -Ebene zu erfassen. Da es in Aleph von NEBIS keine Collections gab, wurden die Bestellungen auf Titelebene erfasst. Die Bestellungen hätten demnach alle umgehängt werden müssen, was einen grossen Bereinigungsaufwand bedeutet hätte. Die Daten von E-Journals, die in der Alma-Community-Zone vorhanden sind, erfüllten zudem die Qualitäts-Ansprüche.

Bei den E-Book-Aufnahmen sah dies etwas anders aus: Die Qualität der E-Book-Aufnahmen in der Community Zone in Alma war und ist sehr unterschiedlich.

Die Migration der Titelaufnahmen von E-Books aus Aleph nach Alma kann einen Mehrwert bedeuten, wenn die Titelaufnahmen qualitativ besser sind als jene in der Community Zone und über Sacherschliessungsdaten und Normdatei-Verknüpfungen verfügen. Die migrierten Aufnahmen lassen sich in Alma mit einem sogenannten Post-Migration-Clean-up-Prozess mit den Portfolios aus der Community Zone zusammenführen. Da dieser Prozess jedoch sehr aufwändig und komplex ist, wurde der Entscheid den NEBIS-Bibliotheken überlassen, ob sie ihre E-Book-Metadaten migrieren lassen möchten oder nicht. Drei Bibliotheken haben sich für die Migration von ausgewählten E-Book-Paketen entschieden. Alle anderen Aufnahmen von E-Books, E-Journals und Datenbanken wurden in Aleph vor der Datenextraktion gelöscht, um zu verhindern, dass sie migriert werden.

8. Drei Testmigrationen

Die Testmigrationen fanden im April 2019, im August 2019 und Februar 2020 statt. In den ersten beiden Testmigrationen wurden nur die lokalen Daten der zehn Vanguard-Bibliotheken sowie alle bibliografischen Aufnahmen migriert. Bei der dritten Testmigration wurde erstmals die Migration der Daten aller Bibliotheken, die zu SLSP wechselten, getestet. Vorgängig hatten die Katalogisierungs-Expert*innen mehr als 100 unterschiedliche Datensätze gesammelt, um für die Tests genügend Beispiele bereit zu haben. Da sich die Mitarbeitenden, die mit den Tests betraut waren, zunächst noch in Alma einarbeiten und mit der Datenstruktur vertraut machen mussten, konnten nach der ersten Testmigration noch nicht alle Probleme dieser Migration erkannt werden. Zudem lag der Fokus für die Tests der ersten Datenmigration darauf, die dedublierten bibliografischen Aufnahmen in der Networkzone zu testen. Damit der Produktivbetrieb von Aleph nicht gestört wurde und die Massenmutationen getestet werden konnten, wurden sämtliche Daten jeweils vom NEBIS-Produktionsserver in die NEBIS-Testumgebung kopiert. Die Daten wurden nach deren Anpassung aus dem Aleph-Testserver entladen.

Für jede Testmigration mussten die Daten neu aufbereitet und die Testsysteme neu aufgesetzt und konfiguriert werden. Deshalb blieb nach der zweiten Testmigration nur wenig Zeit, um die aufgrund der neuen Erkenntnisse notwendigen Datenbereinigungen vorzunehmen. Dies hatte zur Folge, dass die Wirkung einiger Datenbereinigungen nicht getestet werden konnte und erst die finale Migration zeigte, ob die Daten richtig migriert wurden. Einen grösseren Zeitabstand zwischen der zweiten und dritten Testmigration oder gar der Verzicht auf die zweite Testmigration wäre für den NEBIS-Verbund hilfreich gewesen.

Erschwerend kam hinzu, dass die Migration mit den Daten aller Bibliotheken nur einmal getestet werden konnte. Aufgrund der Komplexität und der Grösse des Projektes wäre es jedoch nicht möglich gewesen, mehr als eine Testmigration mit allen Daten durchzuführen.

9. Datenmigration

Die Datenextraktion der NEBIS-Daten dauerte elf Tage und fand vom 20. bis 30. Oktober 2020 statt. Der erste Schritt war ein Katalogisierungs- und Erwerbungsstopp in Aleph, d.h., es durften keine neuen Katalogisate, Holdings und Exemplare erfasst oder bestehende verändert werden. Dies wurde mit dem Entzug von Katalogisierungsrechten sichergestellt.

Bevor die Datenextraktion beginnen konnte, nahmen die Migrationsverantwortlichen letzte Korrekturen an den Daten vor. Anschliessend erfolgte das Entladen der Daten aus Aleph und SFX sowie deren Übermittlung an Ex Libris.

Sämtliche Datenextraktionen konnten termingerecht abgeschlossen werden. Ex Libris und swissbib übernahmen danach die Aufbereitung der Daten der sechs Bibliotheksverbünde und spielten diese in die Networkzone (bibliografische Daten) und die 29 Institution Zones (Bestandsdaten, administrative Daten) von Alma ein. Die gesamte Migrationsphase dauerte sechs Wochen. Nach einer erneuten kurzen Testphase gingen Alma und swisscovery pünktlich am 7. Dezember 2020 live.

10. Benutzerdaten und Parallelbetrieb

Aufgrund von datenschutzrechtlichen Einschränkungen war es nicht möglich, die Benutzerdaten aus den bestehenden Systemen nach Alma zu migrieren.

Folglich konnten bestehende Ausleihen nicht nach Alma migriert werden, weil die zugehörigen Benutzerdaten fehlten. Die Vorgängersysteme sollten daher nach dem Go-Live von Alma weiterhin genutzt werden, um die noch dort getätigten Ausleihen abzuschliessen. In Aleph ausgeliehene Medien wurden in Alma gekennzeichnet und für die Ausleihe gesperrt.

Dieser Parallelbetrieb der beiden Systeme Aleph und Alma dauerte knapp vier Monate.

Ein Vorteil des Parallelbetriebs war, dass die Abwicklung der offenen Ausleihen beim Start von Alma und swisscovery über Aleph mit den bestehenden, gut funktionierenden Prozessen sichergestellt werden konnte. Zudem gelang es so, den Ausleihstopp für Benutzende sehr kurz zu halten, da vor dem Go-Live mit Alma nur die ausgeliehenen Exemplare in Alma gesperrt werden mussten und keine Datenmigration von Ausleihdaten nötig war. Im NEBIS-Verbund war die Ausleihe von Medien lediglich während vier Tagen nicht möglich.

Der Parallelbetrieb erwies sich als sehr komplex. Einerseits für das Ausleihpersonal, welches zwei Systeme zu bedienen hatte. Andererseits für die Systemverantwortlichen, welche die Prozesse so einrichten mussten, dass mit Aleph und Primo nur die Abwicklung von offenen Ausleihen möglich war, die Neuausleihe oder das Katalogisieren von Medien aber unterbunden wurde. Für die Benutzer*innen bedeutete es, dass sie während knapp vier Monaten zwei Benutzerkonten hatten.

Die Übergangszeit von vier Monaten bewährte sich: Fast alle der zu Beginn noch offenen knapp 200’000 Ausleihen in NEBIS waren Ende März 2021 abgeschlossen. Aleph konnte somit plangemäss am 31. März 2021 abgeschaltet werden.

11. Lessons learned und Empfehlungen für die Planung einer Migration nach Alma

Das Teilprojektteam konnte während der Projektlaufzeit viele wertvolle Erfahrungen sammeln. Die „Lessons learned“ lassen sich wie folgt zusammenfassen:

Die von Ex Libris eng getaktete Projektplanung mit wenig terminlichem Spielraum kann bei einzelnen Schlüsselpersonen zu einer sehr hohen Arbeitsbelastung führen. Es gilt folglich, die Schlüsselpersonen zu identifizieren, deren Ressourcen einzuplanen und sie von anderen Aufgaben zu entlasten. Da der NEBIS-Verbund einer von sechs Datenlieferanten und die termingerechte Lieferung der extrahierten Daten für den Go-Live essenziell war, wurden Stellvertretungen für die Schlüsselpersonen eingeplant. Die wichtigste Rolle nahmen dabei die Systembibliothekar*innen ein. Im NEBIS-Verbund wurde ein Migrationsverantwortlicher sowie drei Stellvertretende (zwei für die Aleph-Datenextraktion und einer für die SFX-Extraktion) eingesetzt.

Für die Datenextraktion wurden im „Change NEBIS“ Projekt drei Tage Pufferzeit eingeplant, um sicherstellen zu können, dass die Daten termingerecht geliefert werden können. Trotz sorgfältiger Planung lässt sich nicht ausschliessen, dass ein Datenextrakt ggf. wiederholt werden muss. Da ein solcher bis zu 20 Stunden dauern kann, ist es je nach Grösse der zu migrierenden Datenbank ratsam, zwei bis drei Tage Pufferzeit für die Migrationsphase einzubauen. Für den NEBIS-Verbund bewährte sich dies, da eine der drei Aleph Datenextraktionen wiederholt werden musste.

Da die drei Testmigrationen nahe aufeinanderfolgten und die Testphasen kurz waren, blieb zu wenig Zeit, um Erkenntnisse zu gewinnen und die Daten entsprechend anzupassen, so dass diese bei der nächsten Testmigration geprüft werden konnten. Rückblickend wäre es sinnvoller gewesen, nur zwei Testmigrationen mit genügend Abstand zu planen. Längere Testphasen hätten zudem den Testpersonen geholfen, sich besser in das zukünftige System einarbeiten zu können.

Das von Ex Libris eingesetzte Projektteam war nicht mit den Aleph-Eigenheiten vertraut. Die Projektbeteiligten versuchten sich daher so früh wie möglich in das neue System Alma einzuarbeiten, um sich mit dem Alma-Wording und der Datenstruktur vertraut zu machen. Dies erleichterte die Kommunikation mit dem Projektteam von Ex Libris. Erschwerend war jedoch, dass die Alma-Dokumentation31, welche zwar offen zugänglich ist und das erste Alma Testsystem, welches Ex Libris für die Einarbeitung zur Verfügung stellte, nicht die zukünftige Topologie von SLSP berücksichtigte. So konnten z.B. Workflows, die durch die Nutzung einer Networkzone in Alma anders sind, erst nach der zweiten Testmigration im Herbst 2019 erstmals geprüft werden.

Gewinnbringend war, dass sich Expert*innen aus den Fachbereichen Katalogisierung, Erwerbung, elektronische Medien sowie Ausleihe und Benutzung in Alma eingearbeitet hatten und dadurch über das nötige Knowhow verfügten, um die migrierten Daten zu testen und Bereinigungen vorzubereiten. Es empfiehlt sich daher, genügend Ressourcen für die Migrationstests einzuplanen.

Das Knowhow in Projektmanagement, welches die Projektleitung sowie die Teilprojektleitenden von „Change NEBIS“ einbrachten, erlaubte es, die Arbeiten strukturiert anzugehen und den Überblick zu behalten. Dass das Projekt „Change NEBIS“ drei Jahre vor der Datenmigration gestartet wurde, half insbesondere dabei, die Kommunikations- und Entscheidungswege zu festigen. Die Vorbereitungen für die Datenmigration waren ab Anfang 2019 so arbeitsintensiv, dass sich das bereits eingespielte Projektteam als vorteilhaft erwies.

Die Bereinigungsarbeiten frühzeitig zu planen und zu starten, stellte sich als wichtig heraus. Die vorgenommene Priorisierung half dabei, dass der Fokus stets auf den essenziellen Datenbereinigungen lag. Ohne diesen Fokus hätte man sich leicht in den unzähligen Bereinigungsfällen verlieren können. Die Migrationsverantwortlichen versuchten zudem auch die Bereinigungsfunktionen, welche Alma anbietet, zu berücksichtigen. Denn mit den Alma-Prozessen32 ist die Bereinigung von Daten zum Teil einfacher durchzuführen als mit Aleph. Die Planung eines Bereinigungsprojektes nach der Migration darf nicht vergessen gehen. Bei der Zusammenlegung von Datenbanken mit bibliografischen Daten entstehen Dubletten, deren Bereinigung strukturiert anzugehen und für die Ressourcen einzuplanen sind.

Vor der Migration wurden nicht mehr oder selten verwendete Elemente in den Exemplardaten wie z.B. Standorte, Ausleih- oder Bearbeitungsstatus etc. nach Möglichkeit konsolidiert oder gelöscht. So reduzierte beispielsweise die ETH-Bibliothek ihre Magazinstandorte in Aleph. Dies erleichterte anschliessend das Einrichten der Drucker und Ausleihtheken in Alma für die Bibliothek.

12. Fazit

Eine Datenmigration dieser Grösse und Komplexität durchzuführen, ist ein grosser Kraftakt. Im Teilprojekt „Applikationen und Daten“ wurden insgesamt rund 5’000 Stunden für die Projektarbeiten aufgewendet.

Rückblickend zeigte sich, dass sich die frühzeitige und aufwändige Planung des Projekts gelohnt hat: Die NEBIS-Datenmigration erfolgte termingerecht und reibungslos. Auch die Datenbereinigungen, die viele Ressourcen beanspruchten, zeigten ihre Wirkung. Alle Daten fanden ihren Weg in Alma, wurden in die richtige Institution Zone migriert und der richtigen Bibliothek zugeordnet. Die Migration der E-Ressourcen-Daten verlief ebenfalls erfolgreich. Die E-Ressourcen, welche die einzelnen Bibliotheken lizenziert hatten, konnten in Alma für die entsprechenden Bibliotheken aktiviert werden und waren ab Tag eins von swisscovery recherchierbar.

Neben notwendigen Anpassungen in Erwerbungsdaten, die in Alma teilweise mit automatisierten Prozessen angepasst werden können, erzeugen v.a. Signaturen in migrierten Exemplaren und Holdings Nachbearbeitungsaufwand. Diese konnten aufgrund der neuen Datenstruktur in Alma nicht in allen Fällen richtig zugeordnet werden und müssen daher manuell korrigiert werden. Die Katalogisierenden in den einzelnen Bibliotheken werden insbesondere Dubletten von Reihenaufnahmen und Aufnahmen von mehrteiligen Monografien bereinigen müssen. Diese Dubletten liessen sich bei der Zusammenlegung der Verbunddatenbanken, trotz des ausgeklügelten und bei der Migration bewährten Algorithmus von swissbib, nicht verhindern. Pendent ist zudem die Nachbearbeitung der zahlreichen analytischen Aufnahmen, deren Exemplare mit einer übergeordneten Aufnahme verknüpft und aktuell für die Benutzung noch nicht funktional sind.

Die Tools und Prozesse, die Ex Libris für die Migration anbietet, sind zwar sehr ausgefeilt, werden aber der Migration einer komplexen Verbundstruktur nicht immer gerecht. So mussten die Migrationsverantwortlichen öfter auf Umgehungslösungen ausweichen.

Letztendlich darf aber auch festgehalten werden, dass es trotz der vielschichtigen Ausgangslage, den vielen Abhängigkeiten und den komplexen Arbeitsschritten gelungen ist, die neuen Systeme pünktlich und ohne grössere Komplikationen in Betrieb zu nehmen.

Dass die Datenmigration der NEBIS-Daten einwandfrei gelungen ist, ist dem erfahrenen und engagierten Projektteam und der guten Zusammenarbeit innerhalb der ETH-Bibliothek, aber auch mit den zahlreichen Kolleg*innen der anderen Bibliotheken, Verbünde, SLSP, swissbib und Ex Libris zu verdanken.

Literaturverzeichnis

• Bauer, Bruno; Lackner, Markus; Schubert, Bernhard: Implementierung des neuen Bibliotheksmanagementsystems Alma an 14 Einrichtungen im Österreichischen Bibliothekenverbund – Feedback aus der Perspektive der Functional Experts, in: Mitteilungen der Vereinigung Österreichischer Bibliothekarinnen und Bibliothekare, 71(2), 2018, S. 320–350. Online: <https://doi.org/10.31263/voebm.v71i2.2136>.
• Beiler, Christian; Gratzl, Petra; Schubert, Bernhard; u.a.: Erschließungsarbeit in Alma – Erfahrungen aus dem OBV vor, während und nach der Aleph-Ablöse, in: Mitteilungen der Vereinigung Österreichischer Bibliothekarinnen und Bibliothekare, 71(2), 2018, S. 282–306. Online: <https://doi.org/10.31263/voebm.v71i2.2134>.
• Bissegger, Judith: Netzwerk Metadatenmanagement. Die Brücke zwischen Katalogisierung und IT, 2018, Online: <https://www.slideshare.net/ETH-Bibliothek/netzwerk-metadatenmanagement>, Stand: 25.08.2021.
• b.i.t.verlag gmbh (HG.): b.i.t. online, 24(3), 2021. Online: <https://b-i-t-online.de/heft/2021-03-index.php>, Stand: 25.08.2021.
• Dartsch, Maria; Dulski, Sebastian; Engels, Frauke, u.a.: Einführung des cloudbasierten Bibliothekssystems Alma in Berlin – ein Erfahrungsbericht, in: ABI Technik, 38(2), 2018, S. 128–141. Online: <https://doi.org/10.1515/abitech-2018-2002>.
• Hänger, Christian; Klein, Annette: Alma an der UB Mannheim: ein Update, in: ABI Technik, 38(2), S. 145–151. Online: <https://doi.org/10.1515/abitech-2018-2004>.
• Küssow, Jürgen; Märchy, Selina: Regelwerke im multilingualen Kontext – ein Erfahrungsbericht aus einem multilingualen Verbund, in: o-bib, 4(3), 2017, S. 16–26. Online: <https://doi.org/10.5282/o-bib/2017H3S16-26>.
• Neubauer, Wolfram: „Gemeinsam sind wir stärker“: das Kooperationsprojekt Swiss Library Service Platform (SLSP), in: Bibliotheken der Schweiz: Innovation durch Kooperation, 2018, S. 124–144. Online: <https://www.degruyter.com/document/doi/10.1515/9783110553796-006/html>, Stand: 25.08.2021.