DMS-Migration: 8 Fehler, die Millionen kosten

Ein DMS ist keine Datenbank. Wenn Sie eine Datenbank migrieren, prüfen Sie Schema, Constraints, Indizes und Trigger. Fertig. Ein DMS-Umzug hat einen Faktor mehr — die Menschen, die damit arbeiten — und mindestens sechs Dinge, die man nicht sieht: ACLs, ArchiveLink-Konfiguration, Retention Policies, Signatur-Historie, Custom-Aspects und den Volltextindex. Jedes einzelne davon kann eine Migration in Woche 7 sprengen. Diese acht Themen kennen wir aus zehn Jahren SAP-DMS-Projekten. Wenn Sie eines davon abhaken, ohne es geprüft zu haben, sitzen Sie am Cutover-Wochenende länger, als Ihnen lieb ist.

1. ACLs, die niemand mehr versteht

Jedes gewachsene DMS hat Gruppen und Rechte, die in dreizehn Iterationen entstanden sind. Der ursprüngliche Grund, warum die Gruppe „Recht-Freigabe-Sonderfall-2018" existiert, ist mit dem damaligen Compliance-Officer in Pension gegangen. Wenn Sie diese Gruppen 1:1 kopieren, tragen Sie das Chaos mit. Wenn Sie sie neu machen, riskieren Sie, dass zwei Sachbearbeiter am Montag nichts mehr sehen können.

Was funktioniert: eine ACL-Inventur vor der Migration. Wir laufen mit einem Skript durch das Bestandssystem, listen jede aktive Gruppe mit letztem Nutzungs-Zeitstempel und Zahl der aktuell darauf beruhenden Dokumente. Alles, was seit 24 Monaten nicht benutzt wurde, kommt in eine Cleanup-Liste. Der Cutover startet mit einem sauberen Rechte-Set.

2. ArchiveLink schwenkt an einem Wochenende — oder nie

SAP hängt in der Regel per ArchiveLink am DMS. Die ContReps-Konfiguration ist im SAP hinterlegt, meist von einem Externen, den keiner mehr erreicht. Wenn Sie SAP-Cutover und DMS-Cutover nicht koordiniert planen, hat Ihr Rechnungswesen am Montag um 08:00 keine Anzeige-Möglichkeit für Belege. Wir haben das gesehen. Es ist nicht schön.

Der Move-Plan: DMS-neu läuft parallel. ArchiveLink zeigt weiterhin auf DMS-alt. Am Cutover-Wochenende schwenkt die ContReps-URL. In den Wochen davor werden die neuen Endpunkte mit Test-Belegen validiert. Der eigentliche Cutover-Schritt ist eine SAP-Config-Änderung, die 20 Minuten dauert.

3. Retention Policies migrieren nicht automatisch

„Wir behalten die Retention Policies bei" ist ein Satz, der in Discovery-Meetings oft fällt und selten hält. Retention-Policies sind DMS-spezifisch — was Alfresco als Aspect ausdrückt, ist in DocuWare eine Storage-Location-Regel, in OpenText ein Records-Management-Container. Die Semantik ist selten 1:1 übertragbar.

Was hilft: Retention Policies vor der Migration in einer plattformneutralen Tabelle festhalten (Dokumentklasse, Aufbewahrungsdauer, Löschtrigger, Legal Hold). Diese Tabelle ist ohnehin für die DSGVO-Dokumentation nützlich und wird nach dem Cutover das neue Regelwerk.

4. Signatur-Historie ist mehr als eine PDF-Datei

Eine eIDAS-qualifizierte Signatur ist an einen Zertifikatspfad gebunden. Wenn Sie das DMS wechseln, muss die Kette Signatur → Zertifikat → CA → Root weiterhin nachvollziehbar sein. Sonst gilt die Signatur nach dem Cutover als „nicht mehr verifizierbar" und Ihre PAdES-B-LTA-Ambition ist futsch.

Konkret: Signatur-Metadaten, Timestamp-Authorities, LTV-Informationen (Long-Term Validation) müssen mitgehen. Wir prüfen jede Signatur beim Import auf Validität und lassen Ausreißer in eine Manual-Review-Queue laufen, statt sie stumm zu kopieren.

5. Custom-Aspects — die Metadaten, die nicht im Standard-Schema sind

Alfresco-Aspects, ELO-Verschlagwortungs-Masken, d.velop-Formulare — jedes DMS hat Custom-Metadaten-Definitionen, die im Standard-Schema nicht abgebildet sind. Wenn Sie diese ignorieren, verlieren Sie Attribute, die Sachbearbeiter über Jahre gepflegt haben. Wenn Sie sie 1:1 übernehmen, tragen Sie technische Schulden mit.

Der Königsweg: Custom-Aspects werden zu Anfangsvorschlägen für den KI-Assistenten. Er lernt aus den bisher gepflegten Werten und kann bereits im Test-Run bessere Vorschläge machen als die alte Regel-Basis. Was Sie in Jahren händisch gebaut haben, wird ab Cutover-Tag automatisch weitergeführt.

6. Volltextindex neu bauen — Zeit und Speicher planen

Ein Volltextindex über 5 Millionen Dokumente ist ein paar Terabyte groß und dauert Stunden. Wenn Sie das erst am Cutover-Wochenende starten, riskieren Sie, dass am Montagfrüh die Suche „nichts findet" — obwohl das Dokument da ist. Der Nutzer merkt es. Und ruft an.

Was funktioniert: Volltextindex parallel zum Content-Import aufbauen. Am Cutover-Datum ist der Index synchron. Der Suche-Feature-Flag wird umgestellt, sobald die Deckung geprüft ist.

7. Change-Management: Ihre Sachbearbeiter sind das Nadelöhr, nicht das System

Ein modernes DMS mit KI-Klassifikation ändert die Arbeitsroutine der Sachbearbeiter. Wer bisher fünf Klicks pro Beleg gebraucht hat, macht jetzt zwei. Das klingt gut — und ist bei den ersten fünfzig Belegen auch gut. Beim ersten Beleg, bei dem die KI unsicher ist und der Sachbearbeiter selbst entscheiden muss, taucht das Muster auf: „Aha, die KI kann's also doch nicht." Das ist ein Change-Management-Moment, kein Software-Bug.

Was hilft: transparente Konfidenz-Scores. Der Sachbearbeiter sieht bei jedem Vorschlag, wie sicher die KI ist. Unter 80 % entscheidet der Mensch. Über 80 % geht es automatisch. So bleibt das Vertrauen intakt, weil die KI nicht überredet — sie fragt.

8. Rollback-Plan — der, den man hoffentlich nie braucht

Am Cutover-Wochenende geht etwas schief. Nicht bei uns, hoffentlich. Aber wenn: Sie brauchen einen Rollback-Plan, der in unter zwei Stunden zurück zum alten DMS führt. Klingt trivial. Ist es nicht.

Der einfache Fall: das alte DMS läuft 30 Tage lang im Read-Only-Modus weiter. Neue Belege gehen ins neue System, alte bleiben abrufbar aus dem alten. Falls ein Rollback nötig ist, wird der Read-Only-Modus aufgehoben und der neue Endpunkt zurück umkonfiguriert. Voraussetzung: Sie haben die Cutover-Reihenfolge so gebaut, dass Rollback tatsächlich möglich ist — kein einmaliger Schema-Break, keine „wir löschen jetzt die alten Daten"-Schritte am Cutover-Tag.

Was Sie mitnehmen

Eine DMS-Migration ist eine Change-Management-Übung mit Software-Anteil, nicht umgekehrt. Wenn Sie die acht Themen oben strukturiert angehen, ist die eigentliche Cutover-Nacht ein Non-Event. Wenn Sie eines davon ignorieren, wird es die längste Nacht Ihrer Karriere.

Wir haben deshalb einen Migrations-Discovery-Sprint definiert: zwei Wochen, in denen wir mit Ihrem Team die acht Themen durchgehen. Das Ergebnis ist ein Migrations-Plan, in dem für jedes Thema klar ist, wer wann was macht. Wenn Sie mehr wissen wollen, sagen Sie Bescheid.