Migrationen sind das lästige Beiwerk bei der Erneuerung von IT-Systemen oder bei der Übernahme von IT-Systemen im Rahmen von Firmenübernahmen, Fusionen oder Firmenabspaltungen. Bei einer Migration sind immer Datenbestände und häufig auch Dokumentenbestände von einem Quellsystem in ein Zielsystem zu überführen. Führt man ein elektronisches Archivsystem ein, dann muss man sich von Anfang an auch auf das Thema Migration einlassen. 

Artikel "Migration von Daten und Dokumenten: ein Leitfaden" von Dr. Joachim Hartmann, Berater bei der PROJECT CONSULT Unternehmensberatung GmbH, Stuttgart, und Dr. Dietmar Weiß, Inhaber der DWB Dr. Dietmar Weiß Beratung; Berater bei der PROJECT CONSULT Unternehmensberatung GmbH, Stuttgart. Ursprünglich erschienen im DOK.Magazin in zwei Teilen: (1) bit.ly/1U3HoNG am 02.12.2014 (Ausgabe 6/2014) und (2) bit.ly/1QZQxkh am 06.03.2015 (Ausgabe 1/2015). Einen Folienvortrag "Migration von Daten und Dokumenten – ein Letfaden" von Dr. Joachim Hartmann findet sich hier: bit.ly/1QGND2F.

Den Artikel als PDF aufbereitet finden sie hier: bit.ly/Archiv_Migration

Dieser Beitrag konzentriert sich in allgemeiner Form auf die Migration von Dokumenten-beständen, wobei hierbei auch die Datenbestände inhaltlich mit abgedeckt sind, die aus revisorischen oder rechtlichen Gründen aus dem Quellsystem aufbewahrt werden müssen. Dargestellt wird, wie solche Migrationsvorhaben geplant und durchgeführt werden können. Neben der zwingend notwendigen Analysephase geht es dann um die notwendigen Maßnahmen und eine Übersicht der möglichen Fallstricke, die sich bei der technischen Umsetzung ergeben.

 

Migrationsverfahren: Auslöser und Herausforderungen

Jeder der ein IT-System mit gespeicherten oder archivierten Daten und Dokumenten betreibt oder nutzt, wird in mehr oder weniger kontinuierlichen Abständen mit einem Migrations-verfahren konfrontiert sein. Auslöser können beispielsweise neue Softwareverfahren, ein Technologiewechsel bei den Speichermedien oder eine Firmenübernahme sein. Hieraus entstehen bei Dokumententechnologien vielfältige Anforderungen bei der Migration der Dokumente und Ablagestrukturen und beim Import und Export der Indizes (Metadaten). Die Kernaufgabe bei der Migration von Dokumentenbeständen ist dabei einfach zu definieren: Die gesetzlichen, regulatorischen und betrieblichen Aufbewahrungspflichten sind zu gewährleisten, so dass trotz eines Migrationsverfahrens die unverfälschte Aufbewahrung nachgewiesen werden kann.

Hier treten eine Reihe von Herausforderungen auf – wie die folgenden ausgewählten Beispiele zeigen:

• Es ist unklar, welche Bestände aus den Quellsystemen überhaupt übernommen werden müssen.
• Die Quell- und Zielsysteme sind heterogen. Es müssen zuerst entsprechende Transformationsmechanismen definiert werden.
• Es sollen Daten und Dokumente aus Produktionssystemen übernommen werden, die erst noch aus diesen Systemen extrahiert werden müssen.
• Aufgrund von Personalfluktuation können wichtige Expertisen in den Quellsystemen verloren gegangen sein.
• Schleppende Zusammenarbeit oder Verweigerungshaltung bei externen Providern, wenn bei der Migration die Geschäftsgrundlage wegfällt.
• Altbestände finden sich über verschiedene Speichermedien verteilt. Kommen hier beispielsweise Bandsicherungen ins Spiel kann es zu extrem langen Migrationsdauern kommen. Beide Verfasser können aus Projekten mit geschätzten Migrationsdauern von mehr als 10 Jahren berichten.
   

Diese Herausforderungen lassen sich nur mit einem, der eigentlichen Migration vorgeschalteten Analyseprozess lösen.
 

Analysephase: Datenbestände und Migrationsbedarf ermitteln

Jedes Migrationsvorhaben, bei dem nur eine der genannten Herausforderungen auftritt, benötigt eine Analysephase (siehe  Abbildung 1), an die sich die eigentliche Umsetzungsphase mit der technischen Transformation der Dokumenten-bestände in das Zielsystem anschließt.

 
Abbi. 1: Analysephase in Migrationsprojekten

Die Analyse des Quellsystems muss alle vorhandenen Bestände umfassen, die möglicherweise aufbewahrt werden müssen. Dies können sowohl Dokumentenbestände als auch ausgelagerte Datenbestände oder Datenbestände in einem Anwendungssystem sein, das bei der Migration abgelöst und anschließend stillgelegt wird.

Nach der Identifizierung der vorhandenen Daten muss die Bedarfsanalyse in einem nächsten Punkt diejenigen Bestände herausfiltern, die bei einer Migration zu übernehmen sind. Dabei sind verschiedene Aspekte zu berücksichtigen, zu denen im konkreten Projekt weitere hinzukommen können. Beispiele hierfür sind:

Rechtliche und regulatorische Anforderungen

• Rechtliche und regulatorische Anforderungen müssen zum einen direkt aus Gesetzen oder staatlichen Richtlinien abgeleitet werden. Zum anderen können auch hauseigenen Standards (Policies, Governance Rules), Vorgaben oder Empfehlungen der Aufsichts-behörden oder Branchenempfehlungen hinzukommen.
• Darüber hinaus gibt es national und international noch jede Menge weitere aus Gesetzen und Richtlinien abgeleitete Dokumentations- und Aufbewahrungspflichten, auf die an dieser Stelle nicht weiter eingegangen werden kann.
• Gesetzestexte und staatliche Richtlinien besitzen naturgemäß selten Handlungsanweisungen für die konkrete technische Umsetzung. Deshalb besitzen Empfehlungen wie die des VOI zur revisionssicheren Archivierung eine große praktische Bedeutung.

Übernahme von Dokumenten zur rechtlichen Absicherung

• Risikobetrachtungen, Haftungsfragen z.B. nach dem Produkthaftungsgesetz, oder der Wunsch nach Beweissicherung können weitere Anforderungen auslösen. Hier spielen die gesetzlichen Verjährungsfristen eine große Rolle.
• Bei unklaren Anforderungen, wie sie häufig beispielsweise bei GDPdU-relevanten Daten vorkommen, mag es zudem wirtschaftlicher sein, bestimmte Bestände zu übernehmen, obwohl nicht zwingend eine Verpflichtung hierzu erkennbar ist. Der oft hohe Aufwand für eine verbindliche rechtliche Prüfung kann dann vermieden werden.
• Bei laufenden Rechtsstreitigkeiten oder wenn ein Titel für eine Forderung erwirkt ist, können sehr lange Aufbewahrungsfristen entstehen. Solche Dokumente müssen meist sehr mühselig identifiziert und ausgesondert werden.
   

Elektronische Daten und Dokumente und nicht elektronische Dokumente

Häufig wird man verschiedene Medien als Quellen finden:

• Elektronische Daten, die aus Anwendungssystemen exportiert und aufbewahrt werden müssen
• Elektronische Dokumente, die in File-, Archiv- oder Anwendungssystemen zu finden sind
• Nicht-elektronische Dokumente wie Papierakten oder aus der Mikroverfilmung
• Übernahme nach Art der Geschäftstätigkeit
• Bei aktiven, laufenden Geschäften müssen sämtliche geschäfts- und steuerrelevanten Daten in die aktiven Bestände übernommen werden. Die hierzu gehörende Dokumentation ist aufbewahrungspflichtig und muss identifiziert werden. Außerdem muss festgestellt werden, wie weit die Dokumentation rückwirkend übernommen werden muss, z.B. die Buchungshistorie.
• Bei nicht aktiven, also meist abgeschlossenen Geschäften, müssen meist nur noch die Dokumentations- und Aufbewahrungspflichten einschließlich der Steuer- und Haftungsanforderungen erfüllt werden.
   

Stichtagsübernahme

Die Frage, ab welchem Stichtag die Bestände übernommen werden müssen, ist gerade bei Firmenübernahmen häufig komplex. Relevant können sein:

• Das Datum des Firmenübergangs
• Das Datum des Geschäftsübergangs. Hier können auch mehrere Teilübergänge bei Geschäften vorliegen.

• Rückwirkende Aufbewahrungspflichten, insbesondere bei der Übernahme von laufenden Geschäften. Diese Frage kann sich auch dann stellen, wenn bei Teilübernahme einer Firma der Fortbestand der Quelldaten nicht gesichert ist.

  Die Abgrenzung der Stichtage muss aus Datenschutzgründen oder zur Wahrung von Betriebsgeheimnissen oft auf den Tag genau eingehalten werden.

Matching: Warum die Bestandsanalyse überarbeiten?

In vielen komplexen Migrationsprojekten hat sich in der Praxis gezeigt, dass der zunächst evaluierte Übernahmebestand nicht mit den tatsächlichen Anforderungen übereinstimmt. Der Grund liegt darin, dass die Bestandsanalyse meist technisch getrieben ist. Es werden IT-Systeme, Archivsysteme und gespeicherte Daten- und Dokumentenbestände analysiert. Die Bedarfsanalyse dagegen evaluiert die rechtlichen, fachlichen Anforderungen. Deshalb lassen sich häufig nicht alle gefundenen Bestände einer tatsächlichen Anforderung zuweisen und umgekehrt fehlen Dokumentenbestände, die die Fachseite eigentlich erwarten würde.

Die Diskrepanzen gilt es in einem Zuordnungs- und Überarbeitungsschritt (Matching) zu beseitigen. Dabei kann es vorkommen, dass Dokumentenbestände erst noch erzeugt werden müssen. Beispiel: Ein System, das die Messwerte aus den Überwachungssystemen eines Kraftwerks analysiert, soll abgelöst werden. Die Daten sind in der Datenbank dieses Systems in einem proprietären Format gespeichert. Das Risikomanagement des Unternehmens verlangt, dass diese Daten weiterhin zur Verfügung stehen müssen. Deshalb muss dieser Datenbestand zuerst extrahiert und in ein für die weitere Aufbewahrung geeignetes Format gewandelt werden. Wichtig ist hierbei: Die Verantwortung, welche Bestände migriert werden, liegt immer auf Seite der Fachbereiche. Die IT kann hier nur unterstützen und hinsichtlich technischer Restriktionen und Anforderungen beraten.

Ergebnis des Überarbeitungsschritts ist die Liste aller Übernahme- und Archivierungsobjekte (AO). Außerdem wird zu jedem AO eine Aufbewahrungs- und Löschfrist definiert. Die Aufbewahrungsfrist ist die Mindestaufbewahrungsdauer. Die Löschfrist setzt den Zeitpunkt, ab dem die Daten und Dokumente vernichtet sein müssen (z.B. aus datenschutzrechtlichen Anforderungen). Meist sind Aufbewahrungs- und Löschfrist identisch, schon alleine, um nicht unnötig lange Speicherkosten zu generieren.

 

 

Entwicklung von Umsetzungsszenarien: Wie übernehmen?

Ist man sich bewusst, was zu übernehmen ist, müssen mögliche Szenarien für die Umsetzung entwickelt werden. Diese sind stark von der Infrastruktur der Zielumgebung abhängig. Deshalb seien hier nur einige Beispiele genannt:

Migration in eine vorhandene Lösung

Besteht die Notwendigkeit des direkten Zugriffs für die weitere Nutzung eines Übernahmeobjekts, ist zu prüfen, ob hierfür bereits eine Anwendung besteht. Dies kann eine Fachanwendung oder ein vorhandenes Archivsystem sein. Hierbei können Konvertierungs- und Indizierungsläufe sowie Anpassungen am Datenmodell erforderlich sein, um die Informationen für die Anwendung verfügbar zu machen.

Migration in eine neu zu schaffender Lösung

Möglicherweise muss die Neubeschaffung eines Archiv- oder Anwendungssystems eigeleitet werden. Da dies immer die aufwändigste Lösung sein wird, muss hier unbedingt geprüft werden, ob die folgende Option kostengünstiger zu realisieren ist:

Externe Auslagerung

Es kann häufig wirtschaftlicher sein, Bestände bei externen Dienstleistern auszulagern, wenn beim Dienstleister entsprechende Speicherungs- und Zugriffsmöglichkeiten bereits vorhanden sind. Sind z.B. bei einer Firmenübernahme Bestände bereits bei einem externen Dienstleister gelagert, so kann es wirtschaftlicher sein, den Dienstleistungsvertrag anzupassen und zu übernehmen.

Ausalterung

Objekte, die nicht zwingend revisionssicher aufbewahrt werden müssen, können auf preiswerten Speicherplatz ausgelagert und dort über die verbleibende Aufbewahrungsfrist gespeichert und anschließend gelöscht werden. Dabei ist zu prüfen, ob die Daten oder Dokumentenformate zum Erhalt der späteren Nutzbarkeit konvertiert werden müssen.

Löschen

Die kostengünstigste Alternative ist das Löschen von Beständen, für die sich beim Matching kein Bedarf an weiterer Aufbewahrung ergeben hat. Neben der entsprechenden Absicherung durch Wirtschaftsprüfer, Außenprüfer oder durch den Rechtsbereich muss zwingend dokumentiert werden, was von wem auf Grund welcher Entscheidung gelöscht wurde.

Die einzelnen Übernahmeobjekte werden schließlich den vorgesehenen Umsetzungsszenarien zugeordnet.

Erfolgsfaktoren

Entscheidend für die Qualität der Planung eines Migrationsvorhabens sind zwei wesentliche Punkte:

• Der vollständige Abdeckungsgrad der vielfältigen Anforderungen, und
• Die Optimierung der vorhandenen Daten- und Dokumentenbestände auf die fachlichen Anforderungen

Analyse und Informationslandkarte

Bei der Planung von Migrationsvorhaben ist ein notwendiger erster Schritt die sorgfältige Analyse des Daten- und Dokumentenbestandes Dabei geht es vor allem darum, die technische Umsetzung im Detail zu planen und durchzuführen. Dazu müssen vor allem zwei Fragestellungen Beachtung finden – und vor der konkreten Durchführung beantwortet werden:

1. Was sind mindestens Bestandteile einer Dokumenten-Migration?
    
2. Welche Vorgehensweisen gibt es und liefern diese nachvollziehbare und dokumentierbare Ergebnisse?

Grundsätzlich gilt: Für die langfristige elektronische Aufbewahrung von Dokumenten, ist es sinnvoll, geeignete Formate zu evaluieren und festzulegen. Gerade bei Aufbewahrungsfristen, die über mehrere Jahrzehnte gehen, steht zu Beginn der Archivierung bereits fest, dass das Speicherformat im Laufe der Zeit höchstwahrscheinlich in ein anderes migriert werden muss. Aus Kompatibilitäts- und Kostengründen sollte daher in den Formaten archiviert werden, die nach aktuellem technischem Kenntnisstand eine lange Verfügbarkeit haben werden.

Bestandteile der zu migrierenden Dokumente identifizieren

Dokumente in ECM-Lösungen bestehen aus einem identifizierenden Teil, wie der Dokumentennummer und den Metabegriffen (wie z. B. Rechnung, Rechnungsnummer, Kundennummer, Vertragsnummer, Kundenname) sowie der eigentlichen Nutzdatei (Bild 1 fasst die wesentlichen Merkmale zusammen). Es kann sich hierbei um eine editierbare Office-Datei oder eine gescannte tif- oder pdf-Datei handeln. Es sind aber auch andere Formate möglich.

Nutzdatei-Formate

Nutzdatei-Formate sind dabei ein wichtiges Stichwort, denn die Migration von Archivsystemen wird unterschiedliche Formate liefern, die es hinsichtlich ihrer weiteren Verwendbarkeit zu überprüfen gilt. Bei der Nutzdatei, dem eigentlichen Dokument, gibt es den grundsätzlichen Unterschied zwischen CI-Dateien, also Text-Dateien, Zeichnungen, Office-Dateien und gescannten Dokumenten wie Tif-Dateien, pdf-Dateien. Reports und Druckspooldateien sind dem Wesen nach ebenfalls den CI-Daten zuzuschlagen und können beim Import nach bestimmten Sequenzen abgesucht und aufgetrennt werden. Dennoch stellen sie eine besondere Form dar und werden von den „kürzeren“ und direkt bearbeitbaren Office-Dateien unterschieden. Außerdem gibt es für Reports und Spooldateien häufig besondere Anzeigefunktionen, die weiter zu untersuchen sind.

Zusätzlich enthalten Dokumente gelegentlich Annotationen auf den Seiten der Nutzdatei. Möglich sind auch „logische Dokumente“, bei denen beispielsweise ein Vertrag in einem ECM-System aus mehreren Dateien besteht (Vertragsdokument sowie fünf Dateien für je einen Anhang). In diesem Fall gibt es eine logische Klammer um mehrere Dateien. Beim Export verursachen sowohl Annotationen sowie logische Klammern erfahrungsgemäß Schwierigkeiten, so dass diese Informationen im Zielsystem gegebenenfalls nicht exakt wiederhergestellt werden können.

Gegenwärtig kann man aufgrund von Normierungen und internationalen Standards folgende Formate als langzeitstabil erachten:

• RTF, ASCII – als Standard-Textformate
• PDF/A – für gescannte oder gewandelte Dokumente
• tif – für Dokumente in schwarz/weiß
• JPG – für Fotos
• MP3 – als Audioformat
• CSV, XML – für die Archivierung von Metadaten und Listenformaten
• HTML-  für Web-Formate

Videoformate und andere Multimediaformate sowie Formate für die Web-Seitenarchivierung sollten bei Bedarf separat untersucht werden.

Für die genannten Speicherformate sind folgende Anmerkungen zu ergänzen:

• Der Standard („A“ für Archivierung) ist seit 2005 als ISO 19005-normiert. Damit PDF/A als Langzeitformat einsetzbar ist, gelten einige Einschränkungen gegenüber den gebräuchlichen PDF-Formaten. So müssen z.B. alle Schriften fest eingebettet sein und verlinkte Elemente, Audio- und Video-Daten sind unzulässig. Seit 2012 gibt es die an die neueren Entwicklungen angepasste sowie PDF/A-3, die auch Anhänge beliebigen Typus einbetten kann. Die vorigen Varianten sind hierzu kompatibel.
• Das tif-Format besitzt häufig herstellerspezifische Erweiterungen zum Standard. Besonders bei mehrseitigen tif-Dateien ist darauf zu achten, dass herstellerspezifische Varianten entsprechend dokumentiert sind. Problematisch sind insbesondere elektronische Haftnotizen (sog. „Annotationen“) und Overlays in den Dokumentenseiten. Dieses Format mit diesen Elementen kann daher nur eingeschränkt empfohlen werden. Zwar gibt es im Allgemeinen keine Probleme bei der tif-Anzeige, allerdings sind bei sehr alten tif-Dokumenten durchaus Darstellungsprobleme mit heutigen Viewern bekannt. Es sollten daher Anzeige und Drucktests durchgeführt werden.
• Bei Office-Dateien gelten die bekannten Versionskompatibilitäten. Heute seltene Formate sind in aktuelle Formate ggf. zu konvertieren, durch Viewer anzeigbar zu machen oder über die kaufmännische Betrachtung der Aufbewahrungsfristen und fachliche Bewertung von der Migration auszuschließen.
• In diesem Zusammenhang sei ein immer wieder anzutreffendes Format genannt: MO:DCA (mixed object document content architecture). Es handelt sich dabei um ein Format für Verbunddokumente mit Text, grafischem Inhalt, Schriften und Barcodes, welches in AFP-Strömen vorkommen kann. Gelegentlich findet man auch gescannte Dokumente in diesem Format abgelegt. Hier gilt ebenfalls, dass es zu wandeln ist, wenn keine Anzeige- oder Druckfunktionen nach der Migration zur Verfügung stehen.

Grundsätzlich gilt: Soll das Originalformat erhalten bleiben, z.B. weil es weiterverarbeitet werden soll, muss ein Dokument sowohl in der Originalversion als auch in einer langzeitstabilen gewandelten Form archiviert werden.

Abb 2: Charakteristik eines elektronischen Dokumentes
 

Indexdateien

Bei den identifizierenden Bestandteilen eines Dokuments, den Indexdateien, stellt sich die Untersuchung der Lesbarkeit einfacher dar: Üblich sind hier eher Prüfungen der Darstellung vom Umlauten und des Regelwerks für die Indexwertdarstellung beim Export und für den Import. Die Besonderheiten der Indexdateien liegen in den Inhalten:

• Sind Trennzeichen für Indexspalten auch Bestandteil im Indexwert?
• Sind die Indexwerte alle korrekt oder ist eine Überarbeitung notwendig?
• Und nicht zuletzt stellt sich die Frage, ob mit dem Indexwert für exportierte Dateien auch eine Prüfziffer exportiert wird, damit ein Prüfverfahren für die Unversehrtheit der Datei verwendet werden kann.

Soweit Annotationen exportierbar sind, werden die Texte gegebenenfalls mit Koordinaten in die Indexdatei oder in zusätzlichen Indexdateien zur Verfügung gestellt. Steuerzeichen, Positionsangaben des Textes und Autorenverweise sollten für die Migration geprüft werden.
 

Zwei Migrationsverfahren zur Wahl

Hat man die Dokumentenformate untersucht und Verarbeitungsregeln erstellt, steht einem ordentlichen Transfer nichts entgegen. Für das Migrationsverfahren selbst ergeben sich dann zwei grundsätzliche Vorgehensweisen:

„On-the-Fly“-Migration mit laufenden Systemen

Bei der „On-the-Fly“-Migration (siehe Abbildung 3) werden die Dokumente und Daten aus einem System gelesen und in das Zielsystem übertragen. Lesen und Schreiben erfolgt über Standardfunktionen via API-Aufrufe. Es gibt im Prinzip keine Zwischenspeicherung exportierter Daten, sondern einen direkten Transfer. Im Quellsystem oder im Migrationswerkzeug wird eine Statustabelle geführt, welche Dokumente bereits transferiert wurden.
Voraussetzung für dieses Vorgehen ist, dass ein Migrationstool die Quell- und Zielsysteme direkt bedienen kann und entsprechende Schnittstellen bzw. Funktionsaufrufe besitzt. Ebenso ist selbstverständlich, dass beide Systeme verfügbar und mit einem Migrationsprogramm verbunden werden können.

Abb. 3: „On-the-Fly“-Migration ‒ Ablaufschema

Eine Variante dieses Verfahrens kann auch eine gemeinsame Archivschnittstelle (z. B. des ERP-Systems) sein, an die beide Archivsysteme angeschlossen sind. Eine Recherche-abfrage wird standardmäßig an das neue System geschickt. Kann diese nicht beantwortet werden, wird die Abfrage über die gleiche Anbindung an das „abzulösende“ System weitergegeben und in zweifacher Weise bedient: Die gefundenen Dokumente werden in das neue System kopiert und als „migriert“ gekennzeichnet. Die Client-Abfrage bzw. der Anwender bekommt die Dokumente dabei angezeigt.

Damit kann eine Migration im laufenden Betrieb mit nicht übermäßiger zusätzlicher Last durchgeführt werden und der nicht übertragene Rest wird in einer einmaligen abschließenden Aktion übertragen.

Klassisches Export-Import-Verfahren mit Zwischenspeicher

Das am meisten angewandte Verfahren ist der Export des relevanten Dokumentenbestandes und dessen Speicherung in einem Zwischenspeicher (siehe Bild 4). Der Export erfolgt gerne als Dateipärchen, also Nutzdatei (Dokument) und entsprechende Indexdatei. Es wird dazu eine Obergrenze an Dateien je Verzeichnis festgelegt und je nach Bedarf werden mehrere Verzeichnisse angelegt. Die erstellten Verzeichnisse können dann direkt für den Import verwendet oder „verpackt“, verschlüsselt und transferiert werden.

Beim Import wird ein systemunterstütztes Massenimportverfahren angewendet. Sowohl der Export wie auch der Import werden protokolliert, beim Import sollte für 100-prozentige Gewissheit die Prüfsumme des Dokumentes neu berechnet und mit dem ursprünglichen Wert verglichen werden.

Abb. 4: Klassisches Migrationsverfahren mit Export und Import

Vor- und Nachteile beider Migrationsverfahren

Vergleicht man beide Verfahren stellt man fest, dass jedes seine Vorzüge besitzt (siehe Tabelle).

Vergleichstabelle: Migrationsverfahren

„On-the-Fly“-Verfahren	Klassisches Verfahren
Beide Systeme müssen in Betrieb sein. Das Migrationstool muss beide Systeme erreichen können.	Das Verfahren kann bei entfernten Systemen in getrennten Netzen und unter getrennter Betriebsverantwortung eingesetzt werden.
Der Transfer benötigt sehr wenig Zwischenspeicher.	Das Verfahren kann bei unterschiedlichen Systemverfügbarkeiten eingesetzt werden.
Das langsamere System bremst das schnellere System aus.	Systembesonderheiten können ausgereizt werden, z. B. Parallelisierung des Imports.
Transformationen sind eher unerwünscht und erfordern einen Eingriff im Migrationstool.	Transformationsschritte können durch zwischengeschaltete Verfahren eingebaut werden.
	Das Verfahren benötigt mindestens den Platzbedarf des exportierten Gesamtvolumens, erfahrungsgemäß jedoch das Drei- oder Vierfache.

Aus dem Vergleich beider Verfahren geht hervor, dass bei einer Inhouse-Migration mit bekannter API und unkritischer Netz-und Performance-Infrastruktur das „On-the-Fly“-Verfahren sehr attraktiv ist. Das klassische Verfahren dagegen stellt relativ geringe Anforderungen bezüglich einer gleichzeitigen Systemverfügbarkeit. Es benötigt lediglich Zwischenspeicher und kann sonst in nahezu allen Umgebungen und Anwendungsszenarien eingesetzt werden.

Anwendungsszenarien konkretisieren Konzepte zum Datenaustausch

Grundsätzlich schließen sich zwei grundsätzliche Anwendungsszenarien an die geschilderten Vor- und Nachteile der beschriebenen Migrationsverfahren an: zum einen eine hausinterne Migration, wenn alle relevanten Systeme in einem Unternehmen oder gegebenenfalls in einem Mandanten eines Rechenzentrums verfügbar sind. Zum anderen eine Systemmigration zwischen selbständigen Organisationen bzw. Unternehmen. Letztere laufen i. d. R. nach dem klassischen Verfahren ab, da eine Öffnung der IT für eine API-gesteuerte Migration zumeist nicht möglich oder nicht gewünscht ist. Selbst wenn beide Unternehmen Leistungsbezieher desselben Rechenzentrums oder innerhalb eines Konzerns sind wird erfahrungsgemäß das klassische Verfahren bevorzugt.

Das grundsätzliche Procedere ist bei beiden Verfahren vergleichbar. Da bei einer hausinternen Migration die formalen Anforderungen an Liefer- und Empfangsnachweise jedoch geringer sind können sie daher gegebenenfalls auch entfallen. Um welche Nachweise es sich hier konkret handelt, wird im Folgenden beschrieben.

Für das eigentliche Migrationsverfahren wird in einem Konzept festgelegt (siehe Abbildung 5), welche Daten in welchen Mengen (Paketen) und Formaten geliefert werden. Für eine Systemmigration zwischen selbständigen Organisationen bzw. Unternehmen werden darin auch Umfang und Stichprobenmenge der Testmenge sowie auch Termine für die Test- und Produktionslieferungen vereinbart. Technisch sollte ein einheitliches Transportverfahren vereinbart werden. Neben der Versendung von verschlüsselten Festplatten mit Kurierdiensten können Austauschserver, welche mit leistungsstarken Leitungen verbunden sind, genutzt werden.

Spezifiziert werden die Menge an Dateien in Verzeichnissen oder in komprimierten Datenpaketen, Kennwörter sowie der Aufbau des Lieferscheins für die jeweilige Lieferung und idealerweise die „Packzettel“ bzw. Inventarlisten, die den Lieferungen beigelegt werden. Die abgebende Organisation benennt im Lieferschein Gegenstand und Liefermenge (z. B. 12.500 Dateien gescannte Buchungsbelege). In der Inventarliste sind dann alle Dateinamen mit Prüfziffer aufgelistet, damit der Empfänger über eine „Soll-Liste“ an zu importierenden Dateien verfügt.

Die Inventarliste entspricht im Wesentlichen dem Exportprotokoll und kann im Prinzip beim Lieferanten einfach erstellt werden. Der Empfänger quittiert den Empfang mit der Bestätigung des Lieferscheins (z. B. durch Eintragen des Abholdatums vom Datenaustauschserver) und schickt diesen als Bestätigung an den Versender zurück. Beim Auspacken der Dateien erfolgt einer Überprüfung der Prüfziffern und bei Abweichungen zu den gelieferten Werte in der Inventarliste kann die fehlerhafte Datei genau benannt und eine neue Lieferung angefordert werden.

Abb. 5: Sicheres Datenaustauschszenario mit Prüfziffern und Lieferscheinen

Das Verfahren ist hinreichend sicher und nachvollziehbar und reduziert den Prüf- und Dokumentationsaufwand erheblich, da unabhängig von der weiteren Verarbeitungsstrecke nach dem Verarbeitungsserver die Prüfziffer im Zielsystem belegt, dass der weitere Transport ohne Veränderung einherging, vorausgesetzt es finden keine Transformationen der Nutzdateien statt. Dieses Verfahren kann auch beim Datentransport via Festplatte angewendet werden. Anstelle der Paketverschlüsselung kann die Festplatte verschlüsselt sein, Lieferschein und Inventarliste werden wie oben beschrieben verwendet.

Bei einer organisationsinternen Migration spricht nichts dagegen, das Exportprotokoll mit Prüfziffern als „Soll-Liste“ für einen Abgleich mit dem Importverfahren zu verwenden, die formellen Schritte wie Lieferscheinquittierung oder Listenaufbereitung können natürlich entfallen. Weitere Details hängen erfahrungsgemäß von den konkreten Rahmenbedingungen der Migration ab und können allgemein formuliert an dieser Stelle nicht weiter ausgeführt werden.

Migrationswerkzeuge unterstützen Projektmanagement

Für den Abschluss des Beitrages soll noch ein kurzer Blick auf die Werkzeuge für das Projektmanagement-Team geworfen werden. Dabei kann man zwischen den eigentlichen Migrationstools und den Projektmanagement-Werkzeugen unterscheiden.

Migrationstools

Bei den unmittelbaren Migrationswerkzeugen handelt es sich in erster Linie um Export- und Importverfahren oder entsprechende Tools von Drittanbietern, die den Dokumentenbestand exportieren, mit Prüfziffern versehen und gegebenenfalls paketieren. Beim Import verhält sich die Betrachtung ebenso: Importverfahren oder Importtools übernehmen den Massenimport der angelieferten Daten und Dokumente. Der Abgleich der Inventar- oder Exportprotokolle mit den verarbeiteten Dokumenten ist systemspezifisch und erfordert eine projektspezifische Lösung. Ebenso sind Tools für die Erstellung von Lieferscheinen und Inventarlisten zu erstellen. Hier kann ein prozesssteuerndes Werkzeug eine wertvolle Hilfe sein.

Je nach Menge und Varianten bei der Verarbeitung empfiehlt sich eine datenbankgestützte Ablage der Lieferprotokolle und Inventarlisten, damit die Prüfungen performant bearbeitet und zu Dokumentationszwecken zusammengefasst und geprüft werden können. Wird nur ein System migriert, handelt es sich dabei zumeist um eine Datenbank des Migrationswerkzeuges. Werden mehrere Systeme mit mehreren unterschiedlichen Verfahren migriert, wird eine „Migrations-Datenbank“, die alle Protokollinformationen je Verfahren aufnimmt, die beste Lösung sein.

Workflow-Funktionen für die prozessgesteuerte Bearbeitung der Anlieferungen und Bestätigung von Eingängen sind sehr hilfreich, wenn auch nicht zwingend notwendig. Groupware-Lösungen mit Setzen von Statusinformationen aus Auswahllisten sind auch geeignet. Ebenso ist die Datenaustausch-Landschaft (vgl. Bild 4) aufzusetzen und zu implementieren. Automatische Verfahren und Namenskonventionen sind zu prüfen und im Vorfeld eingehend zu testen. Dabei sollte das entwickelte Verfahren nicht vom Standardfall funktionierender Lieferungen ausgehen, sondern auch Teillieferungen, Wiederholungslieferungen oder Stornierungen von Lieferungen berücksichtigen.

Projektmanagement-Werkzeuge

Für das Projektmanagement werden Projektplanungswerkzeuge (z. B. MS Project) und die übliche Office-Palette für die Erstellung von Dokumenten und Tabellen etc. benötigt. Gerade bei verteilten Projektgruppen und der zeitweisen Mitarbeit von Spezialisten sind Gruppentools zur Koordination und Mitteilung einheitlicher Informationsstände sehr hilfreich. Dazu gehören natürlich Telefonkonferenz-Möglichkeiten, aber vor allem eine für alle zugängliche Dokumentenablage, in der Dokumentationen, Status-Dokumente etc. abgelegt und eingesehen werden können.

Insbesondere für die Bearbeitung von Testfällen und die Beantwortung von damit verbundenen Fragen ist eine Testfallumgebung sehr hilfreich. Diese kann nicht nur in speziell dafür vorgesehenen Programmen, sondern auch in Gruppenplattformen wie Lotus Notes oder SharePoint eingerichtet und zur Verfügung gestellt werden. Das Projektmanagement sieht den Fortschritt der Testfallbearbeitung, erfasste Fragen und Fehler können von den entsprechenden Spezialisten eingesehen und beantwortet werden. Der Gesamtstatus kann also jederzeit ohne zu hohen manuellen Pflegeaufwand kontrolliert und letztendlich einfach dokumentiert werden – nicht zuletzt auch als Verwendungsmöglichkeit in einer Verfahrensbeschreibung.
Eine solche Plattform kann darüber hinaus grundsätzlich auch als Datenaustauschzentrale verwendet werden. Die Eignung hängt dabei aber vom festgelegten Transportverfahren ab.

Fazit

Eine Migration von Daten und Dokumenten von operativen Anwendungen oder von ECM-Lösungen ist ein vielschichtiges Thema, welches rechtliche, kaufmännische und technische Aspekte berücksichtigen muss. Vor allem ist aber Sorgfalt bei allen Teilaufgaben und Untersuchungen angebracht. Dies betrifft nicht zuletzt auch das Projektmanagement und die verwendeten Verfahren, die zur Migration eingesetzt oder entwickelt werden.
Der Beitrag hat die verschiedenen Themen angesprochen und system- und branchenunabhängig aufgezeigt. Unsere Erfahrungen zeigen, dass es sich lohnt, gewissenhaft und systematisch vorzugehen und entsprechende Experten für jede Projektphase einzubinden.

 

Den passenden Folienvortrag "Migration von Daten und Dokumenten – ein Letfaden" von Dr.  Joachim Hartmann zu diesem Beitrag finden Sie hier: bit.ly/1QGND2F

Den Artikel als PDF aufbereitet finden sie hier: bit.ly/ArchivMigration