Bei dem Zusammentreffen mit den Mitarbeitern der Firma Zetcom Mitte März, mit denen die zu migrierenden Daten besprochen wurden (Detailspezifikation), stellten sich einige Dinge als nachteilig heraus.
1. Eine der zu migrierenden Dateien lag in einem derart veralteten Zustand vor (Access 2000), dass es im Haus nur noch einen einzigen Computer gab, auf dem man die Daten aufrufen konnte. Wir haben darauf spekuliert, dass es reichen würde, wenn zum Migrationsgespräch der Leiter dieser betreffenden Sammlung, der die Inhalte der Datenbank überschauen sollte, hinzukommt und den Mitarbeitern von Zetcom die entsprechenden Auskünfte persönlich erteilt. Dies hat sich als zutreffend herausgestellt. Im Prinzip ist diese Vorgehensweise allerdings nicht zu empfehlen, denn man sollte sich jede Spalte vor der Migration genau von oben bis unten ansehen, auch wenn es sich wie in diesem Fall um 30.000 Datensätze handelt.
2. Die Software, mit der wir zur Detailspezifikation die zu migrierende Datei ansehen wollten (FileMaker), war nur mit zwei Lizenzen im Haus vorhanden und nur in einer anderen Liegenschaft ca. 500m Luftlinie entfernt an zwei Computern anderer Kollegen verfügbar. Die Verantwortliche für den Migrationsprozess kannte sich nicht (wie auch kein anderer im Haus, sogar die User) mit der Benutzung, Administration und den Details dieses Programms aus. So war es schwierig bis fast unmöglich, vorher Änderungen an den Daten vorzunehmen, ohne eine gewisse Einführung in das Programm.
3. Da das Software-Unternehmen, dass eine der zu migrierenden Datenbanken seinerzeit programmiert hat (Nr. 6), insolvent geworden ist, lag zum Zeitpunkt der Migration nur noch ein Datenbank-Dump (eine Kopie der Datenbank) bzw. ein Export in Excel vor, so dass die Datenstruktur live in der Datenbank nicht mehr nachvollzogen werden konnte.
Für die Projektleiterin als Verantwortliche für den Migrationsprozess war es neben diesen technischen Problemen weder auf die Schnelle noch von Wissen her möglich, die Datenqualität im Detail zu beurteilen oder sogar inhaltlich zu verbessern. Dennoch kann man auf eine „strukturelle“ „technische“ Richtigkeit achten: Es kam bei den Gesprächen über die Details des Migrationsprozesses heraus, dass für eine gute Qualität des Endergebnisses wichtig ist, dass entweder jede Information in einem extra-Feld vorliegt, so dass sie bequem an die richtige Stelle gelenkt werden kann, oder die Angaben mit einer maschinellen, nämlich 100%igen Präzision immer identisch eingetragen sind.
Dazu ein paar Beispiele: Wir hatten ein Feld mit Maßen, dass nach der Struktur der vorherigen Datenbank völlig richtig mit den Maßen von Höhe, Breite und Tiefe mit drei Werten, getrennt durch „x“, befüllt war (also z. B.: 35x34x56 oder 35cm x 34cm x 56cm). Nun sah die neue Datenbank die Trennung der drei Werte in eigene Felder für Höhe, Breite und Tiefe vor. Nur wenn in allen, aber wirklich allen Feldern (in diesem Fall z. B. 14.400 Mal) die Einträge immer gleich sind, einschließlich der verwendeten Leerzeichen zwischen den „x“, können diese Daten maschinell getrennt werden. Sollte mal ein Tippfehler vorkommen, passiert an dieser Stelle bei der Übernahme ein Fehler.
Die Erfahrung lehrt, dass von Menschen erzeugte Daten ebenso wie solche von Museumsobjekten sich dieser 100%-Regel entziehen. So muss man neben schlichten Fehlern z. B. mit Zusätzen zu den Maßen im Sinne eines Kommentars rechnen (z. B. „mit Sockel 15 cm“) und anderen Ausnahmen, für die dann eine eigene Spalte einzurichten wäre. Kennt man die Regeln für die Übernahme genau (und von Firma zu Firma dürften dort Unterschiede sein), kann man vor der Migration seinen Datenbestand nach diesen Kriterien optimieren, ohne in die Inhalte gehen zu müssen. Inhaltliche Fehler bleiben natürlich bestehen und werden auch durch eine neue Datenbank nicht besser. Dort wirken die Fehler nur noch deplazierter.
Häufig dürfte es sich bei einer Migration um ein Überspielen einer einfachen Datenstruktur in eine komplexere handeln. Es bietet sich an, sich vor der Migration den Aufwand der Bereinigung vorher bzw. hinterher sehr klar und deutlich vor Augen zu führen. Bei uns war es leider so, dass wir zwar vor der Detailspezifikation Zeit gehabt hätten, diese Bereinigungen durchzuführen, aber nicht abschätzen konnten, dass dies nötig sein würde. Und nach der Detailspezifikation war der Zeitplan so eng, dass wir nur noch Details ändern konnten, bevor wir die Dateien endgültig abgeben mussten. Wären wir uns der Konsequenzen für die anschließende Bereinigung, die übrigens derzeit immer noch nicht abgeschlossen ist!, bewusst gewesen, hätten wir natürlich den Zeitplan in Frage gestellt. Es kam uns sogar so vor, als hätte uns die Firma gern vorher über den aus unserer Sicht für erfahrene Datenmigrierer absehbaren Bereinigungsaufwand aufmerksam machen können. Dieser Eindruck kam zustande, weil die Firma zur kostenmäßigen Veranschlagung der Datenmigration gesagt hatte, sie würde die Daten „analysieren“. Bei uns entstand – etwas naiv im Nachhinein – der Eindruck, als würde sich die Firma der Daten in irgendeiner Hinsicht „annehmen“, uns Unerfahrene beraten und die Daten auf der Basis ihrer umfangreichen Migrationserfahrung mit technischen Mitteln womöglich noch „verbessern“, indem die Firma Probleme erkennt und technisch löst oder uns eben auf sie hinweist. Dies war ein folgenschwerer Irrtum.
Aber dennoch bleibt im Nachhinein der Wunsch, vorher auf den abzusehende Bereinigungsaufwand hingewiesen worden zu sein. Wir hatten zum Bereinigen mehr die Inhalte im Blick. Heute wissen wir, dass sogar eine Migration von einer hochkomplexen Software in eine andere zu z. T. erheblichem Bereinigungsaufwand führt, allein deswegen, weil beide Programme ihre Inhalte technisch oder strukturell auf eine andere Weise ablegen.
Ein anderes Beispiel veranschaulicht ein ähnliches Problem: In der FileMaker-Datei zu 21.700 Photographien hat der Eingebende über 20 Jahre für jedes Foto neu den Autor (den Fotografennamen) angelegt und hingeschrieben. In neueren Systemen wie auch im MuseumPlus ist dieses Problem heute überwiegend so gelöst, dass nur noch einmal ein Künstlername geschrieben wird und dieser dann, wenn man ihn braucht, mit dem entsprechenden Objektdatensatz nur noch verknüpft wird und entsprechend tausende Male zweitverwendet werden kann. Beim Schreiben dieser Namen hat der Eingebene (natürlich!) Fehler gemacht: Mal war das Komma zwischen Namen und Vornamen ein Punkt oder ein Semikolon geworden, mal fehlten Buchstaben etc. Weil die Namensspalte vorher nicht bereinigt war, hat jede andere Schreibweise des Namens, auch wenn es sich nur um ein Komma handelte, einen neuen Künstlerdatensatz verursacht, so dass bis zu fünf Namensvarianten und damit Datensätze pro Person existierten. Bei knapp 10.000 Künstlern wächst sich die Bereinigung allein dieser Spalte zu einer Monate umfassenden Tätigkeit aus.
Ein klarer Nachteil war, dass die Datenbank hier nicht vor Ort installiert war, so dass die Möglichkeiten, sich als Laie das Migrationsergebnis Spalte für Spalte vor Augen zu führen, so gut wie unmöglich war.
