Migration: Move or Stay

4. November 2012 17:01 Uhr  |  Dr. Ulrich Kampffmeyer  |  Permalink


Grüne Wiese gibt es in Punkto ECM selten. Bei den meisten Organisationen und Unternehmen gibt es bereits "irgendetwas" im Keller – DMS, Archiv, ECM – wie auch immer genannt. Anstelle der Neubeschaffung tritt so häufig das Thema Ablösung oder Update.

Aktuelle Studien gehen davon aus, dass das Migration 2013 ein "hot topic" sein wird. Die Anbieter springen auch schon auf das Thema und bieten die günstige Ablösung, sogar unter Anrechnung ursprünglicher Lizenzen eines anderen Herstellers an. Das gesteigerte Interesse ist auch nicht ungewöhnlich, denn beim Thema Archivierung über Jahre und Jahrzehnte ist ja schon bei der Erstinstallation klar, dass man während der Lebensdauer Hardware austauschen und Software updaten muss. Viele Anwenderunternehmen sind inzwischen auf dem Weg von der dritten in die vierte Generation von Dokumentenmanagementlösungen. Und Migration ist immer noch die derzeit einzig praktikable Lösung für die Langzeitarchivierung ( http://bit.ly/Langzeitarchivierung), genaugenommen muss man sich auf eine kontinuierliche Migration während des gesamten Lebenszyklus der Aufbewahrung und Archivierung einrichten (http://bit.ly/Dunkles-Zeitalter) um sich von den schnellen Wechseln bei Produkten sowie dem "Warten" auf Abkündigungen unabhängig zu machen. 

Migration kann dabei auf sehr unterschiedliche Art und in unterschiedlichem Umfang erfolgen. "Migration" hat vielfältige Bedeutungen (http://de.wikipedia.org/wiki/Migration). Hier wird sie benutzt um die Umstellung von Systemen mit der Umlagerung oder dem Umkopieren von zugehörigen Anwendungen und Daten zu beschreiben. Migration hat so gesehen verschiedene Komplexitätsgrade, z.B.:

  • Austausch von Hardware mit 1:1 Umkopieren von Daten
  • Austausch der Speichersysteme und Speicherverwaltungssoftware mit 1:1 Umkopieren von Daten und Daten-Relationen
  • Update oder Austausch der Verwaltungsdatenbank mit 1:1 Umkopieren der Daten und Speicherort-Referenzen
  • Update oder Austausch der Anwendung (mit und ohne Datenbank, mit und ohne Dokumente usw.)
  • Update oder Austausch des Archivsystems mit Bereinigung des Dokumenten- und Index-Bestandes
  • und so weiter, und so weiter

Bereits diese kurze Auflisrtung gängiger Szenarien zeigt, dass das Thema Migration sehr komplex sein kann und einer genauen Planung und Erprobung vor der Umstellung bedarf. Die Kriterien dabei sind allerdings immer die gleichen: verlustfrei in Bezug auf Dokumente, Indexdaten, Relationen und Kontext. Die die Revisionssicherheit des Verfahrens  muss sichergestellt sein. Dies beinhaltet das Konzept der Migration, die Test des Migrationsverfahrens, die Dokumentation des produktiven Migrierens, den Vergleich von Ursprungs- und Quellsystem sowie die Behandlung eines gegebenenfalls auftretenden Deltas. Das Hauptproblem sind dabei meistens weniger die Objekte im Archiv selbst denn die Metadaten und die Kontextinformationen. Besonders komplex kann es werden, wenn der Produktionsbetrieb weiterläuft und die Migration in eine neue Umgebung parallel durchgeführt wird. Hier sind dann auch noch die Veränderungen während der Migration nachzuhalten und nachzuführen. 

Beim Thema Migration gibt es aber noch ein weitere Frage, die die Anwender immer aufs Neue bewegt: bleibe ich bei meinem bisherigen Anbieter oder wechsele ich zu einem anderen Anbieter oder Produkt. Im ersteren Fall also Update oder Upgrade, im zweiten Fall ein kompletter Wechsel, bei dem aber gegebenenfalls die Hardware- und Betriebssystemumgebung bestehen bleibt. Als zusätzliche Argumentation und aus Wirtschaftlichkeitsgesichtspunkten wird dann bei einem Produkt-, Intergator- und/oder Herstellerwechsel meistens noch eine funktionale Erweiterung in das Migrationsprojekt hineingepackt – und damit noch einmal das Risko für das Gelingen erhöht. Während bei einer Migration von Speichersystemen es noch relativ einfach ist den Hersteller zuwechseln, wird dies bei einer kompletten Anwendung mit zahlreichen Schnittstellen und individuellen Clienten sehr schwierig.

Psychologisch gesehen scheint der Wechsel auf einen neuen Anbieter und ein neues Produkt immer attraktiver als das Verbleiben beim vorhandenen Realisierer, da man beim letzteren ja alle Probleme kennt und sich auf diese konzentriert. Ein neues, vermeintlich moderneres System erscheint so zunächst als der strahlende weiße Ritter. Auf SIcherheit bedachte Organisationen präferieren aber das Update oder Upgrade der vorhandenen Plattform, da man ja schon den Anbieter lange kennt und ein Update oder Upgrade in einer vorhandenen Lösungsarchitektur einfacher und risikoloser erscheint.

In beiden Ansätzen steckt etwas Wahrheit.
Beim Wechsel auf ein neues Produkt kann man Fehler der Vergangenheit ausbügeln, z.B. ein nicht skalierbares System, ein System eines nicht mehr am Markt präsenten Anbieters, oder eine nicht auf den Anwendungszweck zugeschnittene Lösung entsorgen. Auch hier kommt es natürlich darauf an, was in welchem Umfang entsorgt werden soll und noch mehr – werden kann. Auch finanziell und aus Betriebssicht kann ein Wechsel interessant sein, wenn man nämlich zu viele redundante Systeme verschiedener Art und Hersteller über die Jahre angesammelt hat. Deshalb ist hier auch häufig das Thema "Abwahl" wichtiger als "Auswahl". Und es wird heute auch immer die Option der Cloud bei Produktwechselüberlegungen mit betrachtet. Letzteres reduziert nicht die Komplexität der Planung und der Entscheidungen. Nicht unterschätzt werden darf bei allen Planungen die Überlappung des Betriebs des Alt- und des Neusystems, um eine ausreichende Sicherheit bei der Verfügbarkeit und eine "Fallback"-Möglichkeit zu behalten.
Auf den ersten Blick erscheint es so, dass die Aufwände und Risiken bei einem Produktwechsel größer als bei Update oder Upgrade seien. Aber auch hier muss man in der Planung ins Detail gehen. Hat man zum Beispiel längere Zeit die Software nicht entsprechenden den Wartungsplänen des Anbieters upgedatet, dann ist der Aufwand für das Upgrade genauso groß wie für das neue System. Es gibt sogar Fälle, wo man aus mangelnder Abwärtskompatibilität zweimal migrieren musste, um auf die aktuelle Version zu kommen. Ähnlich sieht es aus, wenn man zahlreiche individuelle Änderungen, Anpassungen und Ergänzungen für die alte Lösung programmiert hat, die mit migriert werden müssen. Dies kommt einem Neuerstellen der Lösung gleich. Ein neues System mit mehr Funktionalität, das die individuell programmierten Teile überflüssig macht, hätte hier Vorteile. Aber vielfach tradiert man Unzulänglichkeiten des ursprünglichen Systems in die neue Umgebung, weil man sich "dran gewöhnt" hat.

Eine Entscheidung für den Umfang und die Art einer Migration ebenso wie für "Move" – neues Produkt/neuer Anbieter – oder "Stay" – nur Upgrade mit vorhandenem Anbieter – muss wohlüberlegt und durchgeplant sein. Migrationen von großen Daten- und Dokumentenbeständen neben dem normalen Betrieb können Wochen, Monate oder gar Jahre dauern. Die einfachere oder "billigere" Lösung erweist sich dann häufig doch nicht als die optimale und wirtschaftliche Lösung. Ist die Migration aber schon gelaufen, geht der Weg meistens nicht zurück.

Und es gibt noch ein weiteres, alternatives Szenario für Migrationen – den (zeitweiligen) parallelen Betrieb des Altsystems zusammen mit dem neuen System. Der Zugriff auf die Dokumente und Daten beider Systeme wird für den Anwender transparent durch eine Zwischenschicht gelöst. Das Altsystem wird nur noch gelesen, im neuen System wird geschrieben, gelesen und gegebenenfalls die aus dem Altsystem aufgerufenen Informationen neu gespeichert. Entsprechend Nutzung und Aufbewahrungsfristen kann dann das Altsystem irgendwann abgeschaltet werden oder es muss zumindest zwischenzeitlich und ohne terminlichen Druck ein deutlich geringerer Bestand an Informationen migriert werden.

In Kürze werden die CMIS Content Management Interoperability Services in der Version 1.1 veröffentlicht. Diese Schnittstelle erlaubt den Zugriff auf "federated Repositories", d.h. verteilte Lösungen unterschiedlicher Hersteller, Art und Struktur. Mit der CMIS Version 1.1 kommen auch noch weitere Funktionen, die für das Records Management und die Archivierung benötigt werden. Hierzu gehören z.B. Aufbewahrungs- und Löschfristen. CMIS wird von einer wachsenden Zahl von ECM-Softwareanbietern unterstützt: z.B. IBM, Microsoft, EMC, Alfresco, Oracle etc.

Fasst man alle einzelnen Aspekte zusammen, wird man feststellen, dass Migration ein schwierigeres Thema ist als die Konzeption, Ausschreibung und Einführung einer neuen Lösung auf der "Grünen Wiese".

Dr. Ulrich Kampffmeyer

Curriculum auf Wikipedia https://de.wikipedia.org/wiki/Ulrich_Kampffmeyer

Ein Kommentar zu “Migration: Move or Stay

  • Migration ist ein Dauerthema
    15. November 2022 um 11:48
    Permalink

    Vor 10 Jahren haben wir in unserem Blog zum Thema Migration, auch unter dem Gesichtspunkt „bleiben beim Anbieter „oder „wechseln von Produkt und Hersteller“ geschrieben. Liest man aktuelle Nachrichten von Anbietern, wie z.B. ISIS-Papyros, so häufen sich die Anfragen zur Migration von DM-, Archiv- und ECM-Systemen. Viele Unternehmen sind inzwischen in der 2., 3. oder gar 4. Generation ihrer Installationen angelangt. Es gilt die vorhandenen Informationen weiterhin nutzbar zu halten und eine zukunftssichere Lösung zu betreiben. Auch hier haben Angebote von Cloud-Lösungen die Szene und den Bedarf an Lösungen verändert.
    Einmal ganz abgesehen davon, dass es unterschiedlichste Arten von Migrationen mit sehr verschiedener Komplexität gibt – vom einfachen Umkopieren eines Repository-Speichers bis hin zum Ersatz einer kompletten Anwendung mit aufwändigen Clienten, Workflows, Integration in andere Anwendungen und eAkten –  ganz abgesehen von den Konzepten der „weichen“, „harten“ und „integrativen“ Migration. Eines wird häufig unterschätzt oder schlicht vergessen: die verbesserte Erschließung der vorhandenen Informationen im Rahmen einer Migration. Häufig werden Migrationen unter kaufmännischen, sprich Kosten-Gründen, oder im Rahmen der Harmonisierung und Konsolidierung vorhandener Infrastrukturen geplant. Als Nebeneffekt kommt noch die Überprüfung der Verarbeitungsfähig- und Lesbarkeit der gespeicherten Informationsobjekte hinzu, die dann in längerfristig stabile Formate – Stichwort z.B. PDF/A-2, gewandelt werden. Zwei wesentliche Aspekte gehen dabei häufig „unter“:

    • Die Anpassung der Architektur der DM-Lösung mit getrennten Schichten, Diensten und separaten Anwendungen und Schnittstellen. Nur so kann man eine zukunftssichere Architektur erreichen, die auch flexibel in Bezug auf Ausbau oder gar Wechsel der Plattform, z.B. von Inhouse-On-Premises in eine Cloud-Variante ermöglichen kann. Bei langfristiger Archivierung ist eine solche Trennung von Repository, Archivanwendung, Datenbank, Schnittstellen und Nutzungsanwendungen essentiell. Möglichst wenig Komplexität und individuelle Anpassungen helfen. In Punkto Anwendungen bei der Archivierung gilt immer noch der Satz „je dümmer ein Archiv ist, desto länger hält es“. Also möglichst wenig individuelle Anpassungen sondern die Nutzung als stringenter Dienst.
    • Der zweite Punkt betrifft die Verbesserung der Erschließung und Nutzbarkeit. Bei der Ersteinrichtung eines DM-, ECM- oder Archiv-Systems kümmerte man sich selten intensiv um das Thema Metadaten, die die Verwaltung und Auffindbarkeit von Informationsobjekten erst möglich macht. Vielfach hat man die Lösung auch einfach an eine Anwendung gekoppelt, die dann für Datenbank, Metadaten und Recherche verantwortlich ist. Die Kriterien für die Nutzung ändern sich über die Zeit und ursprünglich eingerichtete Index-Datenbanken können dann diese Anforderungen nicht mehr erfüllen. Daher ist die Wandlung der Inhalte mit neuer Erschließung wichtig. Es geht dabei nicht nur um Volltext, den man beliebig recherchieren könnte (aber dann auf andere Hindernisse der richtigen Berechtigungen und Datenschutzaspekte stößt), sondern um eine Ergänzung und Vervollständigung der Metadaten. Hier helfen heute auch Lösungen mit Künstlicher Intelligenz und Maschinenlernen. Durch die Analyse, was die Mitarbeiter:innen benötigen, wie die Prozesse laufen und was für Informationen aktuell vorhanden sind, können Lücken in den „Altbeständen“ gefunden und aufgebessert werden. So kann auch als alten Daten und Informationsobjekten neues Wissen gewonnen werden.

    Natürlich gibt es noch viele andere Aspekte, die bei einer Migration bedacht werden müssen. Vom umfangreichen Testen bis hin zur Verfahrensdokumentation des Migrationsprozesses, der nachvollziehbar, ohne willkürliche Änderung und verlustfrei durchgeführt werden muss.  In unserem Seminar „Elektronischen Archivierung und Rechtsfragen des Dokumentenmanagements“ haben wir den Migrationsprozess ausführlich behandelt (http://bit.ly/3X45uLL). Auch die Artikel unserer Kollegen Dr. Joachim Hartmann und Dr. Dietmar Weiß (http://bit.ly/3Eaupoh) gehen auf das Thema Migration ausführlich ein.

    Zum Schluss: eine Migration muss genauso sorgfältig geplant und vorbereitet werden, wie eine Erstinstallation. Häufig kann außerdem der Fall eintreten, dass eine spätere Migration eines „nicht optimal eingerichteten“ Erstsystems teurer und aufwändiger kommt als die Ursprungslösung. Spätestens dann erübrigt sich auch das Kostenargument, was vielfach als Migrationsanlass herhalten muss. Es geht darum Information nutzbar zu machen und langfristig verfügbar zu halten.

    Antwort

Neuen Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich stimme zu, dass die von mir eingegebenen Daten einschließlich der personenbezogenen Daten an PROJECT CONSULT übermittelt und dort zur Prüfung der Freischaltung meines Kommentars verwendet werden. Bei Veröffentlichung meines Kommentars wird mein Name, jedoch nicht meine E-Mail und meine Webseite, angezeigt. Die Anzeige des Namens ist notwendig, um eine individuelle persönliche Kommunikation zu meinem Beitrag zu ermöglichen. Anonyme oder mit falschen Angaben eingereichte Kommentare werden nicht veröffentlicht. Zu Nutzung, Speicherung und Löschung meiner Daten habe die Datenschutzerklärung zur Kenntnis genommen.

Ich versichere, mit meinem Kommentar alle gültigen Vorgaben des Urheberrechts beachtet zu haben. Ich habe keine Bilder, Grafiken, Texte oder Links in meinem Beitrag verwendet, die durch CopyRight, Leistungsschutzrecht oder Urheberrecht geschützt sind. Für den Inhalt meines Kommentars bin ich trotz Prüfung und Freischaltung durch PROJECT CONSULT ausschließlich selbst verantwortlich. Meine Rechte am Beitrag werden bei PROJECT CONSULT nur durch die CC Creative Commons by-nc-nd Vorgaben gewahrt.