Migration: Move or Stay

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".