Archivmigration: Ein Crashkurs

Schon bei der Einführung eines ECM sollte eine mögliche zukünftige Migration daher mitbetrachtet werden. Immerhin geht es um sensible Unternehmensdaten, die über sehr lange Zeiträume hinweg aufbewahrt werden müssen. Grund genug für Pentadoc, Ihnen einen umfangreichen und fundierten Überblick zu bieten.

Womit befassen wir uns im Folgenden? 

I. Migrationsformen

Wann empfiehlt sich eine weiche Migration und welche Vor- und Nachteile bietet im Gegensatz dazu die harte Migration? Daneben gibt es zahlreiche Mischformen, die speziell im Enterprise Segment zum Einsatz kommen. Und wie unterscheidet sich die Softwaremigration von der Datenmigration? Kann ich Backend und Frontend voreinander trennen? Müssen die Dokumente physisch angefasst und verschoben oder sogar konvertiert werden? 
Wir geben Ihnen einen Überblick über die verschiedenen Migrationsarten und -verfahren und hilft Ihnen, die für Ihre Situation passende Migrationsstrategie zu finden. 

II. Projektphasen einer Migration

Eine bevorstehende Migration ist ein komplexes Thema, das nicht selten auch sehr zeit- und kostenintensiv ist. Je nach Komplexität kann eine klassische Umsetzung nach Wasserfall aber auch eine agile Arbeitsweise zielführend sein. Egal wie, es ist immer wichtig, die richtigen Schritte zum richtigen Zeitpunkt zu tun, um die Projektlaufzeit nicht aus dem Ruder laufen zu lassen. So kann mit der richtigen Migrationsstrategie und einer passenden Speicher-/Softwareauswahl der Migrationsprozess der Dokumente, der bei großen Archiven Jahre dauern kann, bereits parallel zur Software Installation und Konfiguration gestartet werden. Durch diese Parallelisierung kann die Projektlaufzeit oft erheblich verringert werden.

III. Risiken und Erfolgsfaktoren

Auch bei einer detailliert geplanten Migration gibt es immer Risiken, die unter Umständen schwerwiegende Folgen haben können, die das gesamte Unternehmen existenziell bedrohen. Risiken müssen vom ersten Tag an systematisch analysiert und passende Gegenmaßnahmen definiert werden.Risikoanalyse und Abwehrplanung („Risk and Mitigation“) ist ein ständiger Prozess, der das gesamte Projekt begleitet.Hierbei können Sie auf die langjährige Erfahrung von Pentadoc zählen, die mit ihren erfahrenen Berater*innen und mittels ausgereifter Methoden die Risiken minimiert und damit die Migration sicher ins Ziel steuert. 

Migration eines ECM: Ein Buch mit sieben Siegeln, ein notwendiges Übel oder eine Chance!? 

Ein ECM wird in aller Regel zunächst mit einer langfristigen Perspektive eingeführt. Um so plötzlicher kann sich der Bedarf für eine Migration ergeben und den Projektalltag ordentlich durcheinanderbringen.

Es bedarf somit schon zur Einführung eines ECM einer genaueren Betrachtung möglicher Migrationsszenarien! 

Immerhin geht es um sensible Daten, also Informationen, die die Grundwerte des Unternehmens betreffen oder gar selbst darstellen und vielfach über mehrere Jahrzehnte aufbewahrt werden müssen. Fachbereiche haben jahrelang mit ihnen gearbeitet und sie innerhalb von Entscheidungsketten genutzt. Möglicherweise sind bereits Abschlüsse von Vorgängen erfolgt. Denkbar ist aber auch, dass Akten längere Verweildauern haben – wie zum Beispiel bei Versicherungen – und erst nach Ablauf von Vertragslaufzeiten abgeschlossen werden können. Danach tritt die gesetzliche Aufbewahrungspflicht ein. Im Lebensversicherungsbereich ist eine Aufbewahrungszeit von 100 Jahren und mehr keine Seltenheit. Was tun mit Beständen in Systemen, die an ihre physischen, logistischen oder versionsbedingten Grenzen stoßen? 

So verwundert es kaum, dass die häufigsten Gründe einer Migration wie folgt lauten: 

1. IT-Konsolidierung nach einer Fusion oder Unternehmensübernahme
2. Wechsel der Unternehmensstrategie vom On-Prem Datacenter hin zu einer Cloud Strategie 
3. Unzufriedenheit der Anwender*innen mit dem vorhandenen ECM-System
4. Der Support des ECM-Systems wird seitens des Herstellers gekündigt. Dies kann infolge einer Insolvenz oder Übernahme der Fall sein.
5. Die Integrationsfähigkeit in moderne Softwareumgebungen ist nicht gegeben.
6. Die Upgrade- beziehungsweise Update-Fähigkeit von angeschlossenen Drittsystemen ist nicht mehr gegeben (zum Beispiel Betriebssystem, ERP).
7. Die Laufwerke beziehungsweise die Medien-Typen sind veraltet und damit ineffektiv. 

Darüber hinaus kann es notwendig sein, Archivbestände zu verifizieren. Kaum ein Archivsystem läuft jahrelang störungsfrei und kein*e Administrator*in ist fehlerfrei. Versionen von Datenbanken und anderen Komponenten werden aktualisiert und haben nicht immer nur positive Auswirkungen auf die Funktionsqualität des Systems. 

Folglich gibt es eine Reihe von Notwendigkeiten, die zu Prüf- und Migrationsbetrachtungen von Archiven oder ähnlichen Systemen führen. Aus welchem Grund sollten Sie also Ihrem Archiv und seinem Bestand etwas Aufmerksamkeit widmen? 

• Zum Ersten wären da reine Sorgfaltsgesichtpunkte. Jedes Archiv hat in seinem Lebenszyklus Unregelmäßigkeiten erfahren. Überprüfen Sie den Bestand und die Arbeitsweise des Archivs. Vergewissern Sie sich, dass Ihr Datenbestand den zertifizierten Richtlinien wie AO, GoBD, DSGVO und so weiter entspricht. 
• Reorganisieren Sie Ihren Datenbestand: Eine am Anfang der Installation getroffene Entscheidung zur Struktur der Datenhaltung und gegebenenfalls deren Zugriff kann überholt sein oder nicht mehr den Erfordernissen Ihrer Anwender*innen entsprechen.  
• Wechsel des DMS oder Archivsystems: Zu diesem Komplex gehört auch die Umsetzung von per COLD eingestellten Dokumenten. Diese können je nach gebendem System unterschiedliche Ausprägungen haben. Sekundärindex, Formulare (sowie deren Verwaltung) und Versionen sind nur einige Stichworte. 
• Reduzierung der Archivformate: Archive können eine Vielzahl von Formaten speichern, deren Anzeige von dem/den Viewer/n abhängig ist oder werden kann. Ziel sollte es sein, möglichst wenig editierbare und unterschiedliche Formate in einem Archiv zu halten. Eine Vereinheitlichung kann neben weiteren mittels PDF/A oder „Vertiffung“ erfolgen. Gerade alte Archivformate wie MO:DCA sind in einer Zeit, in der Dokumente in Webportalen an Kund*innen gegeben werden, nicht mehr zeitgemäß. 
• Wechsel der physikalischen Archivbasis: Zeitgemäße Objektspeicher, egal ob lokal oder in der Cloud, haben immense Vorteile bei Sicherheit und Zugriffsgeschwindigkeit. Diese ermöglichen zum Beispiel Migrationen des Archivsystems, ohne den Dokumentenbestand zu bewegen.  

Migrationsformen 

Grundsätzlich werden zwei Arten der Migrationen unterschieden: Softwaremigration und Datenmigration

Von einer Softwaremigration spricht man, wenn zu einem ECM-System des gleichen oder eines unterschiedlichen Herstellers gewechselt werden muss. Ebenso wird von einer Softwaremigration gesprochen, wenn zum Beispiel in Folge einer IT-Konsolidierung die Zusammenführung von Beständen aus Systemen des gleichen Herstellers beziehungsweise eines anderen Herstellers ansteht. 

Von einer Datenmigration spricht man, wenn Daten beispielsweise im Zuge eines Formatwechsels, Medienwechsels oder Hardwarewechsels (zum Beispiel Jukebox) übertragen werden müssen. Als Sonderform der Datenmigration kann die Initial-Digitalisierung oder Altdatenübernahme von Papierdokumenten gesehen werden. Dieses Thema muss gesondert behandelt werden und wird in einem der folgenden Abschnitte kurz beschrieben. 

In Abhängigkeit der gewählten Migrationsart können dann unterschiedliche Migrationsverfahren angewendet werden: 

• Big Bang 
• Stufenweise Migration
• Integrative Migration
• Kombinierte Verfahren 

Bei einem Big Bang (auch „harte“ Migration genannt) wird das neue ECM-System fertig installiert und konfiguriert, dann die Daten an einem Wochenende von Alt nach Neu migriert und schließlich das alte System abgeschaltet.

Auf den ersten Blick erscheint dies unmöglich, da die Migration der Dokumente und Indexdaten oft Wochen, Monate oder sogar Jahre dauert. Dazu werden über einen langen Zeitraum über immer kleiner werdende Deltas das alte und neue Archiv synchronisiert, bis das letzte Delta so klein ist, dass es in wenigen Stunden migriert werden kann. An dem besagten Wochenende wird nur noch dieses letzte Delta migriert und schließlich die Systeme von Alt auf Neu umgeschaltet.  

Der Nachteil dieser Migration ist, dass die Anwender*innen von heute auf morgen alle zusammen auf eine neue Oberfläche geleitet werden. Des Weiteren ist sehr viel Vorarbeit und Koordination notwendig, damit an diesem Wochenende der Umstellung die neuen Systeme produktionsreif sind und alle Benutzer*innen das neue ECM verwenden können und nachgewiesen werden kann, dass alle Daten korrekt übernommen wurden. An diesem letzten Wochenende müssen auch alle Schnittstellen umgestellt werden, bei vielen Schnittstellen empfiehlt es sich, im Vorfeld Weichen zu implementieren, so dass die Umstellung ohne Deployment stattfinden kann.

Speziell bei großen Umgebungen mit vielen Benutzer*innen, die intensiv mit dem ECM-System arbeiten, führt der Big Bang in den Wochen nach der Umstellung zu einer supportintensiven Zeit oder sogar zur Verringerung der Produktivität der Sachbearbeiter*innen. Das dadurch entstehende zusätzliche Arbeitsvolumen kann die IT-Abteilungen und die Sachbearbeiter*innen schnell stark überlasten und zu großen Problemen führen. Um dies zu vermeiden, empfiehlt es sich, die Migration von Backend und Client voneinander zu trennen. In der Migrationsvorbereitung wird der bestehende Client an das Backend des neuen ECM-Systems angebunden. Dazu gibt es mehrere Verfahren, je nachdem, ob Sie Zugriff auf den Quellcode des bestehenden ECM haben oder nicht. Nach dem Big Bang arbeiten zunächst noch alle mit dem alten Client, die Migration hat also nur im Hintergrund stattgefunden. Nach der erfolgreichen Migration des Backends werden nun die Clients Stück für Stück umgestellt – in einem gemäßigten Tempo, sodass weder der Support, noch die Sachbearbeiter*innen überlastet werden.   

Bei der stufenweisen Migration (auch „weiche“ Migration genannt) wird sukzessive respektive schrittweise – „ohne Bruch“ – das alte System in die neue Umgebung migriert – zum Beispiel Abteilung für Abteilung.

Innerhalb der Daten der Abteilung wird dann, wie oben beim Big Bang beschrieben, vorgegangen. Durch die kleineren Arbeitspakete ist die einzelne Umstellung überschaubarer und einfacher durchzuführen. Das heißt aber auch, dass für die Zeitdauer der Migration Alt- und Neu-System parallel betrieben werden. Arbeiten Anwender*innen in Bereichen, die zu verschiedenen Zeiten migriert werden, müssen sie mit zwei Systemen parallel arbeiten, was eine Mehrbelastung bedeutet. Zudem sind viele Umstellungen an vielen Wochenenden notwendig, was in Zeiten knapper IT-Mitarbeiter*innen eine häufige Hürde darstellt. 

Die "integrative" Migration geht noch einen Schritt weiter als die "weiche" Migration, basiert aber auf ähnlichen Prinzipien.

Das Ziel der "integrativen" Migration ist der Parallelbetrieb unterschiedlicher Systeme unter einem führenden ECM-System. Damit kann die Migration selbst „on the fly“ – also Dokument für Dokument durchgeführt werden.

Um das Ziel zu erreichen, existieren verschiedene Verfahren, zum Beispiel kann man durch Zusatzprogrammierung das Neu-System in die Lage versetzen, auf die Index-Datenbanken und die Dokumente des Alt-Systems zuzugreifen. Bei einem anderen Verfahren wird der Zugriff auf das ECM-System über eine dazwischengeschaltete Weiche gesteuert. Die Weiche weiß immer, ob das Dokument im neuen oder alten Backend liegt. Sie ermöglicht in vielen Fällen auch den parallelen Einsatz von altem und neuem Client. Ein weiteres Verfahren besteht darin, dass man die beiden Backends synchronisiert, dabei werden ähnliche Verfahren wie bei der Delta-Migration beim Big Bang verwendet und schließlich die beiden Systeme synchron betrieben. Nun können die Benutzer*innen fließend umgestellt werden – und falls etwas schief geht auch ohne Unterbrechung auf den alten Client zurückwechseln.  

Die „on Demand“ Migration, ist quasi eine „integrative“ Migration ohne Big Bang:

Hier verbleiben die Dokumente so lange im Altsystem, bis sie durch eine*n Bearbeiter*in aufgerufen werden. Dann werden diese Dokumente „on the fly“ migriert.

Dokumente, die nie aufgerufen werden, werden nach Ablauf der Aufbewahrungsfrist mit dem alten ECM-System „entsorgt“.

Innerhalb der aufgeführten Migrationsarten gibt es noch weitere Varianten, zudem kann man die einzelnen Arten miteinander kombinieren. Es ist wichtig, die richtige Migrationsstrategie für Ihr Unternehmen auszuarbeiten – es gibt nicht die eine Migrationsart oder die eine Migrationsstrategie die immer zum Erfolg führt. Pentadoc verfügt über Methoden, die für Sie beste Migrationsstrategie zu erarbeiten. 

Projektphasen einer Migration

Eine Migration lässt sich grob in fünf Projektphasen untergliedern: 

 1. Ist-Zustand-Erfassung 

 2. Konzeption/Planung

 3. Realisierung

    3.1 Implementieren der Migrationsumgebung

    3.2 Implementieren/Konfigurieren neues ECM

    3.3 Migration Dokumente und Index

 4. Kontrolle/Abnahme 

Je nach Migrationsstrategie sind die Phasen 3.1 bis 3.3 nicht unbedingt aufeinanderfolgend. Sie können zum Teil parallel stattfinden. Es kann zum Beispiel bei modernen ECM-Systemen mit der Migration der Dokumente vor der Installation/Konfiguration der eigentlichen neuen ECM-Software begonnen werden.   

Ist-Zustand-Erfassung 

Der Ist-Zustand wird mit verschiedenen Werkzeugen, wie Fragenbögen, erfasst. Die Analyse des Ist-Zustandes dient dabei als effiziente Grundlage für die Planung der Konfiguration und des Customizings des neuen Systems. Zudem wird in diesem Kontext auch die Kosten- und Zeitplanung durchgeführt. 

Dabei gilt es insbesondere, die folgenden Faktoren näher zu untersuchen: 

• Dokumentenstruktur (Vorgänge, Aktenpläne, …)
• Indexstruktur (Attribute, Indexe)
• Verwaltungsinformationen (Berechtigungen, Systemdaten)
• Funktionen (Prozesse, Suchen, Sichten, …)
• Front-End-Programme 

In dieser Projektphase gilt es zudem, Antworten und Entscheidungen auf folgende Fragen zu bekommen: 

• Was für ein gebendes System bildet die Basis?  
  Wie ist die Einbettung in die IT-Struktur des Hauses, welche Gegebenheiten sind zu beachten? 
• Systembeschaffenheit 
  Gibt es proprietäre Komponenten, beispielsweise im Bereich Betriebssystem, Datenbank, Archivmedien und so weiter? 
• Struktur des Bestandes 
  Festplatten, optische Datenträger oder andere wie etwa Bänder oder Partitionen 
• Ist der Bestand konsistent? 
  Die wenigsten Archive sind über ihre Nutzungsdauer störungsfrei gelaufen. Meist ergeben sich Abweichungen zwischen Datenhaltung und –verwaltung. 
• Wie sieht das empfangende System aus? 
  Und wie sollten dementsprechend Daten aufbereitet sein? Es geht hier nicht nur um grundsätzliche Funktionsweisen, sondern um effiziente Übernahmemöglichkeiten, speziell bei Cloud Zielen und bei größeren oder zeitkritischen Beständen. 
• Wie müssen Daten behandelt werden? 
  Als Beispiel sind hier Änderungen von Grafikformaten zu nennen (JPG, TIFF, PDF/A, oder andere). Auch Konvertierung von Single- in Multipage kann gefordert sein. Nicht selten sind noch Archivformate wie MO:DCA im Einsatz, die im Rahmen der Migration abgelöst werden sollen. 
• Wie müssen Verwaltungsdaten und Suchbegriffe aufbereitet werden? 
  Strukturen von Datenbanken oder allgemein die Haltung von Suchbegriffen ändert sich bei erweiterten Funktionalitäten. Strukturen von insertfähigen Sätzen müssen definiert werden. 
• Welche Protokolle sollen geführt werden? 
  Solche zur Bestandsaufnahme, Behandlung, Datenübertragung, Import Zielsystem, Vergleich von Alt- und Neubestand. Ist eine Abnahme durch den/die Wirtschaftsprüfer*in gefordert oder gewünscht? Welche Daten benötigt der/die Wirtschaftsprüfer*in? 
• Fehlerbehandlung/Eskalationsmanagement 
  Was soll im Fall eines Problems getan werden? Beispiele: Kein Dokument zum Attributsatz, Seitenanzahl des Dokumentes abweichend, Grafik beschädigt, Attributsatz unvollständig (Pflichtfelder sind leer) und so weiter 
• Wie soll ein Transfer von Daten zwischen Alt- und Neusystem erfolgen? 
  LAN, WAN, andere DV-Leitungen und Datenträgeraustausch sind nur einige Möglichkeiten. Die Sicherheit steht im Vordergrund. 
• Sicherheit beim Operating 
  Alle Aktionen, Tools und Werkzeuge können so konzipiert und eingesetzt werden, dass das kontrollierte Bedienen den Kund*innen überlassen werden kann. Die nach Konzept erstellten Komponenten werden übergeben und der Funktionsweg geschult. Den Kund*innen ist die Bedienung über den erforderlichen Zeitrahmen nach eigenem Ermessen möglich. Aufsetzpunkte erlauben bei Problemsituationen das Rücksetzen gestörter Programmabläufe.  
• Daneben gilt es, den Bestand vom Umfang her zu bewerten.
  Die Größe des Archivs ist ein entscheidender Faktor bei anstehenden Migrationsprojekten. Folgende Kennzahlen sind wichtig: die absolute Größe des Archivdatenbestandes, die Anzahl der Dokumente und die Anzahl der Dokumentenseiten. Der Dokumentenbestand sollte gleich dem Bestand der (Recherche-) Sätze in der Datenbank sein. Die Seiten sollten hochgerechnet mit einem durchschnittlichen Speicherbedarf der tatsächlichen Speicherbelegung auf den Archivmedien entsprechen. Verwaltungsdaten auf den Archivmedien werden herausgerechnet. 

Konzeption und Planung

Diese Projektphase findet in enger Zusammenarbeit mit dem Archiv-Anbieter statt und ist grundlegend für die spätere Migrationsstrategie. Je nach Projektphase können zu dem Zeitpunkt nicht alle Fragen beantwortet werden. Möglicherweise müssen zu einigen Fragestellungen PoCs durchgeführt werden, um beispielsweise Konvertierungszeiten oder Daten-Transferzeiten abzuschätzen. Bei großen Projekten empfiehlt sich eine agile Vorgehensweise, in der man sich Schritt für Schritt der Migration nähert. Bei kleineren Migrationen empfiehlt es sich, in einer Konzeption die Antworten aus dem Kapitel Ist-Zustand-Erfassung in ein lückenloses Feinkonzept zu überführen. Hier sind Blueprints von erfahrenen Migrationspartner*innen sehr hilfreich.  

In dieser Projektphase gilt es insbesondere noch Antworten und Entscheidungen auf folgende Fragen zu bekommen:

• Wie und wann soll migriert werden? 
  Dabei wird nicht nur die zeitliche Abfolge berücksichtigt, sondern auch die bisherige Verfügbarkeit sichergestellt! Kein Archiv oder Datenbestand kann tagelang aus dem Praxisbetrieb genommen werden. 
• Kann ein dediziertes Migrationssystem eingesetzt werden? 
  Ein solches hat den Vorteil, ohne Auswirkungen auf die Praxisrechner des/der Kund*in zu arbeiten. 
• Welche Arbeiten können als Dienstleistungen vergeben werden?  
  Dies ist an vielen Stellen effizienter als eigene Bereitstellung von Systemen und Personal. 

Durchführung/Realisierung

Die Durchführung einer Migration soll an dem Beispiel einer „harten“ Migration verdeutlicht werden. 
Bei der „harten“ Migration sind die folgenden Schritte zu durchlaufen: 

1. Aufsetzen des Migrationsprozesses
2. Aufbau Migrationsumgebung
3. Test-Export 
4. Test-Import
5. Export des gesamten Daten-/Dokumentenbestands (mit mehreren Deltas)  
6. Import des Dokumentenbestandes (zyklisch passend zu 5.)  
7. Frozen-Zone und Cut-Over 

Beim Aufbau der Migrationsumgebung ist die benötigte Hardware (zum Beispiel Ausleseserver, Datenbankserver, Jukebox) zu konfigurieren und die Migrationssoftware und -datenbank muss mit dem zuvor definierten Index-Mapping und der Logging-Struktur aufgebaut werden. Unter Umständen müssen Migrationsstrecken für die Dokumente aufgebaut werden. Anschließend wird der Migrationsprozess durch Konfigurieren und Modifizieren von Migrationstools (zum Beispiel Klassifizierung, Fehlerbehandlung, Abgleich (Dokumentenebene), Bereitstellung) aufgesetzt. 

In der Phase der Realisierung werden dann die Schritte Auslesen, Datenabgleich, Dokumentenprüfung, Klassifizierung, Fehlerbehandlung/-analyse, Konvertierung von Image-Formaten, Bereitstellung Objekte und Metadaten durchlaufen. Nach erfolgter Auslagerung der Dokumente und Metadaten kann ein Test-Import zur Bestätigung und Abnahme des Migrationsverfahrens auf dem Zielsystem erfolgen. Nach erfolgreicher Abnahme des Test-Imports wird dann der gesamte Dokumentenbestand importiert. In der nun folgenden Frozen-Zone wird der Übergang vom Alt- auf das Neu-System vollzogen. Dazu wird das Alt-System gestoppt und das Dokumenten-Delta ermittelt. Nach erfolgter Übernahme und Bereitstellung des Dokumenten-Deltas im Neu-System kann dieses in Produktion gehen. Jedoch muss zuvor die Abnahme des gesamten Dokumentenbestands gemäß Migrations-Feinkonzept erfolgen. 

Programm-Migration

Bei der Programm-Migration werden die verwendeten Applikationen, falls erforderlich, neu entwickelt oder es findet eine Anpassung der Applikationen an das neue System statt. Das Frontend sollte möglichst unverändert bleiben, um die Anwenderakzeptanz zu gewährleisten. 

Kontrolle/Abnahme

Ständige Kontrollen begleiten eine reibungslose Migration und auftretende Unstimmigkeiten müssen in jeder Phase sofort mit dem Archivanbieter abgestimmt werden.

Nach erfolgreicher Migration muss noch der erfolgte Prozess in Form einer Projektdokumentation inklusive sämtlicher Migrationsprotokolle dokumentiert werden. Dies wird häufig bereits durch die Gesetzgebung gefordert, insbesondere etwa bei BaFin-kontrollierten Unternehmen oder im öffentlichen Sektor.

Bei einer Migration von Enterprise Archiven mit großen Dokumentenmengen und hoher Zugriffsfrequenz müssen die Schritte 1-7 je nach individueller Migrationsstrategie weiter differenziert oder durch weitere Schritte ergänzt werden.  

Risiken und Erfolgsfaktoren

Bei einer Migration kann eine Menge passieren, was nicht selten dazu führt, dass Migrationsprojekte in Schieflage geraten. Exemplarisch sollen hier einige typische „Stolpersteine“ aufgeführt werden:

• Fehlende fachliche Kompetenz im Projektteam und bei dem/der Projektleiter*in
• Zu optimistische Ressourcen-, Zeit- und Kostenplanung
• Die Konsistenz zwischen Archivsystem und Drittsystemen muss gegeben bleiben (Beispiel: Über ArchiveLink verknüpfte Dokumente aus SAP).
• Spezifische Anpassungen am ECM müssen gegebenenfalls. nachprogrammiert werden, insbesondere sollten Veränderungen am Userinterface vermieden werden.
• Große Datenmengen in teilweise proprietären Formaten können nicht konvertiert werden.
• Eine Belastung des laufenden Geschäftsbetriebes des gesamten Unternehmens
• Schlecht geplante Zeitfenster
• Wirtschaftsprüfer*in nimmt Migration nicht ab
• Neues System kann vom Kunden nicht gewartet werden
• Hersteller der vorhandene ECM-Lösung verweigert notwendige Zusammenarbeit 

Die beschriebenen Stolpersteine können durch entsprechend strukturiertes Vorgehen und durch das richtige Know-how vermieden werden. Dieses Know-how kann man nur durch Projekterfahrung erlangen, denn nur in der Praxis treten die meisten der beschriebenen Probleme auf. Dieses Know-how haben die Pentadoc Berater*innen im Laufe unzähliger Migrationsprojekte erworben.

Unternehmen, die über ein erforderliches Know-how verfügen, delegieren meist dennoch derartige Tätigkeiten infolge zeitlicher Engpässe oder auch aus Gründen der Effizienz. Die eigene, empirische Herangehensweise ist ein theoretisch möglicher Weg, aber ein riskanter! 

Neben den erwähnten Risiken können einer Migration aber auch Erfolgsfaktoren abgewonnen werden. So können Hardwareinvestitionen (zum Beispiel Server, Scanner oder Speichersystem) nach der Abschreibungsfrist durch Neugeräte mit niedrigeren laufenden Kosten ersetzt werden. Speziell die Migration in eine standardisierte Cloud Umgebung kann bei Enterprise Systemen zu einer jährlichen Ersparnis im Bereich von mehreren Millionen Euro liegen.

Doch neben den quantitativen Erfolgsfaktoren stehen bei einer Migration die qualitativen Vorteile klar im Vordergrund. Eine neue, moderne ECM-Lösung kann Ihr gesamtes Unternehmen beflügeln und ermöglicht ihnen neue und effizientere Geschäftsprozesse!