Eine gewachsene Dokumentenablage sieht von außen oft einfacher aus, als sie ist. Es gibt Ordner, Dateien und eine Datenbank. Also alles exportieren, nach OpenKM kopieren und fertig?
Genau dieser Ansatz hätte bei unserer eigenen Migration nicht funktioniert. Der untersuchte Sicherungsbestand umfasste rund 186,5 GB und 47.172 Dateien. Dahinter standen nicht nur normale Dokumente, sondern auch E-Mails, Metadaten, Beziehungen, historische Löschbereiche, technische Begleitdateien, veraltete Software, Fernwartungsaufzeichnungen und Dateien, die zwar noch vorhanden waren, aber fachlich nicht mehr gebraucht wurden.
Die entscheidende Frage lautete deshalb nicht: Wie bekommen wir möglichst viele Dateien nach OpenKM?
Sie lautete: Wie übernehmen wir genau den benötigten Bestand vollständig, nachvollziehbar und ohne unbemerkten Verlust?
Eine Migration beginnt mit einer belastbaren Sicherung
Bevor wir das erste Dokument übertragen haben, mussten wir wissen, ob der Ausgangsbestand überhaupt zuverlässig gesichert und wiederherstellbar war.
Wir haben deshalb Datenbank und Dateibestand getrennt gesichert, die Datenbank testweise wiederhergestellt und sämtliche 47.172 Sicherungsdateien per SHA-256 mit dem Ausgangsbestand verglichen. Erst nachdem dieser Rückweg belegt war, begann die eigentliche Migration.
Das klingt vorsichtig. In Wirklichkeit spart es Zeit: Wer ohne belastbare Ausgangsbasis migriert, kann später kaum unterscheiden, ob eine Datei schon vorher fehlte, falsch zugeordnet war oder beim Import verloren ging.
Die größte Arbeit lag nicht im Upload
Das Quellsystem enthielt verschiedene Profile für Kontakte, Verträge, Mappen, Projekte, archivierte Projekte und Vorgänge. Dazu kamen Beziehungen zwischen den Datensätzen und physische Dokumentordner, deren Struktur nicht immer eindeutig mit der Datenbank übereinstimmte.
Wir haben den Bestand deshalb schrittweise inventarisiert:
- Welche Datensätze existieren tatsächlich?
- Welche Dateien gehören zu welchem Datensatz?
- Welche Verweise sind eindeutig, welche verwaist?
- Welche Dateien sind Dokumente und welche echte E-Mails?
- Welche Inhalte sind fachlich noch erforderlich?
- Welche technischen oder sicherheitsrelevanten Altdateien dürfen nicht ungeprüft ins neue DMS gelangen?
Dabei zeigte sich ein typisches Migrationsproblem: Technisch vorhanden bedeutet nicht automatisch fachlich relevant.
Alte Installationsdateien, Schulungsvideos, temporäre Dateien oder frühere Fernwartungssitzungen hätten das neue System nur belastet. Andere Inhalte waren dagegen trotz ungewöhnlicher Dateiformate wichtige Originalbelege und mussten unverändert erhalten bleiben.
Sollmanifest statt Hoffnung
Für jedes Migrationslos haben wir vor dem Import ein Sollmanifest erzeugt. Es enthielt unter anderem:
- Quelldatensatz und Zielakte,
- relativen Dateipfad,
- Dateigröße,
- SHA-256-Prüfsumme,
- vorgesehenen Objekttyp,
- dokumentierte Ausschlüsse,
- erwartete Beziehungen und Metadaten.
Das Manifest war anschließend versiegelt. Der Import durfte nur gegen genau diesen geprüften Stand laufen. Änderte sich eine Quelldatei oder wich die Anzahl vom Soll ab, musste der Lauf stoppen.
Damit wurde aus einer schwer kontrollierbaren Kopieraktion ein überprüfbarer Prozess.
E-Mails sind keine beliebigen Dateien
Ein wesentlicher Lernpunkt betraf Outlook-Nachrichten. Eine MSG-Datei einfach als Dokument abzulegen, bewahrt zwar ihre Bytes, nutzt aber nicht die E-Mail-Funktionen von OpenKM.
Wir haben MSG-Dateien deshalb als native Mailobjekte übernommen. Absender, Empfänger, Betreff, Datum und Anlagen bleiben damit im vorgesehenen Objektmodell nutzbar.
Historische Nachrichten brachten allerdings Sonderfälle mit: fehlende Kopfzeilen, ungewöhnliche Zeichen und einzelne Emojis, die nicht mit jeder Datenbankkonfiguration harmonierten. Für diese Fälle erzeugten wir kontrollierte EML-Fassungen. Das jeweilige Original-MSG wurde komprimiert in die EML eingebettet. So blieb das Original vollständig erhalten, während OpenKM ein technisch stabiles Mailobjekt erhielt.
Rücklesen ist wichtiger als Hochladen
Ein erfolgreicher HTTP-Status beweist noch keine erfolgreiche Migration. Deshalb haben wir jedes übertragene Dokument und jedes Mailobjekt anschließend wieder aus OpenKM heruntergeladen.
Die zurückgelesenen Inhalte wurden erneut auf Größe und SHA-256-Prüfsumme geprüft. Erst dann galt ein Objekt als abgenommen.
Danach lief jedes Los ein zweites Mal. Dieser Idempotenztest musste alle vorhandenen Records und Inhalte wiedererkennen und durfte weder Dubletten noch neue Versionen erzeugen.
Der abschließende Vorgangslauf zeigt das Prinzip kompakt:
- 35 echte OpenKM-Records,
- 92 Dokumente,
- 80 native Mailobjekte,
- vollständige Rücklesung von 69.435.160 Quellbyte,
- im Wiederholungslauf null neue Records und null erneute Uploads.
Vollständig heißt nicht: alles kopieren
Ein sauberer Projektabschluss braucht auch eine ehrliche Definition von Vollständigkeit.
Wir haben bewusst nicht jede historische Datei übernommen. Nicht mehr benötigte Profile, veraltete Schulungsbestände, Installer, technische Begleitdateien, physische Löschbereiche und potenziell sensible Altdateien wurden ausdrücklich ausgeschlossen. Jeder Ausschluss blieb mit Pfad, Größe, Prüfsumme und Begründung dokumentiert. Die unveränderte Sicherung bleibt als Herkunfts- und Rückfallquelle erhalten.
Die Migration ist deshalb vollständig, weil jedes Objekt des vereinbarten Umfangs entweder geprüft übernommen oder nachvollziehbar ausgeschlossen wurde – nicht weil das Zielsystem unterschiedslos mit Altbeständen gefüllt wurde.
Was Unternehmen daraus mitnehmen können
Der Engpass einer DMS-Migration ist selten die reine Übertragungsgeschwindigkeit. Entscheidend sind Zuordnung, fachliche Auswahl, Nachweisbarkeit und Wiederholbarkeit.
Ein belastbares Migrationsverfahren sollte mindestens diese Fragen beantworten:
- Ist der Ausgangsbestand vollständig gesichert und wiederherstellbar?
- Sind Datensätze, Dateien, E-Mails und Beziehungen vollständig inventarisiert?
- Ist vor dem Import eindeutig festgelegt, was übernommen und was ausgeschlossen wird?
- Werden Originale aus dem Zielsystem zurückgelesen und kryptografisch geprüft?
- Kann ein abgebrochener Lauf sicher fortgesetzt werden?
- Erzeugt ein Wiederholungslauf garantiert keine Dubletten?
- Bleiben Entscheidungen und Abweichungen später nachvollziehbar?
Wenn diese Fragen unbeantwortet bleiben, ist eine Migration vor allem ein Vertrauensvorschuss. Wenn sie belegt beantwortet werden, entsteht ein kontrollierter Führungswechsel zum neuen DMS.
Unser Fazit
Die eigene Migration hat unsere Sicht auf Datenübernahmen geschärft. Gute Werkzeuge sind wichtig. Noch wichtiger ist ein Verfahren, das technische Integrität mit fachlichen Entscheidungen verbindet.
Genau daraus entsteht für kleine und mittlere Unternehmen der eigentliche Nutzen: kein bloßer neuer Speicherort, sondern ein nachvollziehbarer, bereinigter und künftig nutzbarer Dokumentenbestand.
Wer vor einer DMS-Ablösung steht und noch nicht weiß, wie sich gewachsene Daten, E-Mails und Sonderfälle sicher nach OpenKM überführen lassen, kann mit uns zunächst den Bestand und die Risiken strukturiert klären.
