Ein altes Warenwirtschaftssystem führt häufig ein merkwürdiges Doppelleben. Im Tagesgeschäft wird es kaum noch benötigt. Gleichzeitig wagt niemand, es endgültig abzuschalten.
Der Grund ist nachvollziehbar: Niemand weiß mit letzter Sicherheit, welche Rechnungen, Kundendaten, Vorgänge und Nachweise ausschließlich dort vorhanden sind.
Genau vor dieser Situation standen wir mit MKS-Goliath. Das System stammte technisch aus einer anderen Zeit. Sein Datenbestand reichte jedoch über viele Geschäftsjahre und enthielt einen erheblichen Teil der kaufmännischen Vergangenheit der Faustmann UG.
Für uns war deshalb klar:
Dokumente sind Vermögen. Wir machen sie digital steuerbar.
Das bedeutete in diesem Fall: nicht vorschnell deinstallieren, nicht einfach einige PDF-Dateien kopieren und nicht darauf vertrauen, dass die aktuellen Tabellen des Altsystems die historische Wahrheit vollständig wiedergeben.
Stattdessen behandelten wir den Bestand wie ein zu sicherndes Unternehmensvermögen.
Ein altes Warenwirtschaftssystem sicher ablösen: die Ausgangslage
MKS-Goliath war über Jahre als Warenwirtschaftssystem eingesetzt worden. Der aktive Datenbestand umfasste unter anderem:
- Kundenstammdaten,
- Angebote,
- Auftragsbestätigungen,
- Lieferscheine,
- Rechnungen und Rechnungspositionen,
- offene Posten,
- Projekt- und Vorgangsdaten,
- PDF-Belege,
- E-Mails, Bilder und Office-Dokumente.
Der aktive Bestand bestand aus 24.032 Dateien mit einem Umfang von rund 3,14 GiB. Im Dokumentbereich fanden sich 3.189 Dateien, darunter 1.092 technisch bestätigte PDF-Dokumente.
Hinzu kamen unter anderem:
- 99 aktive Kunden,
- 429 aktive Rechnungen,
- 956 aktive Rechnungspositionen,
- 479 historische Projekte und Vorgänge.
Das alte System war damit keine bloße Softwareinstallation. Es war Träger eines erheblichen kaufmännischen und dokumentarischen Vermögens.
Best Practice 1: Den tatsächlichen Datenbestand finden
Bei älteren Systemen ist der sichtbare Installationsordner nicht zwangsläufig der Ort, an dem die Geschäftsdaten liegen.
Auch bei Goliath existierten mehrere ähnlich bezeichnete Verzeichnisse. Erst die lesende technische Untersuchung zeigte, welcher Pfad tatsächlich den aktiven Mandanten und die vollständigen Geschäftsdaten enthielt.
Nicht der vermutete Datenpfad wird gesichert, sondern der nachweislich aktive Datenbestand.
Dazu prüften wir laufende Prozesse, Mandanteneinstellungen, Verzeichnisstrukturen, Änderungszeitpunkte, Tabellen, Dokumentverzeichnisse und vorhandene Belegbeziehungen. Während dieser Analyse wurde nichts gelöscht, verändert oder deinstalliert.
Best Practice 2: Zuerst eine kalte, unveränderte Sicherung
Bevor wir Daten exportierten oder neu strukturierten, wurde Goliath regulär beendet. Anschließend prüften wir, dass kein Goliath-, MKS- oder Visual-FoxPro-Prozess mehr auf den Datenbestand zugriff.
Erst danach erstellten wir eine vollständige kalte Kopie.
Das Ergebnis:
- 24.032 Dateien in der Quelle,
- 24.032 Dateien im Archiv,
- keine fehlenden Dateien,
- keine Größenabweichung,
- keine SHA-256-Abweichung.
Für jede Datei wurden Pfad, Größe und SHA-256-Prüfsumme dokumentiert. Quelle und Archivkopie waren damit auf Dateiebene byteidentisch.
Das ist mehr als ein erfolgreicher Kopiervorgang. Es ist ein überprüfbarer Nachweis darüber, welcher Zustand gesichert wurde.
Die hier beschriebene Prüfung bezieht sich auf die lokale Archivkopie. Eine zusätzliche externe Sicherung und ein Wiederherstellungstest sind eigene nachgelagerte Prüfschritte; wir stellen sie in diesem Praxisbericht nicht als bereits abgeschlossen dar.
Best Practice 3: Originaldaten und portable Exporte gemeinsam erhalten
Die Goliath-Daten lagen überwiegend in Visual-FoxPro-Tabellen. Eine reine Sammlung der vorhandenen PDFs hätte deshalb nur einen Teil des Vermögens bewahrt.
Wir sicherten daher zwei Ebenen:
- den vollständigen unveränderten Originalbestand;
- portable, systemunabhängig nutzbare Exporte.
Aus den Tabellen erzeugten wir unter anderem:
- eine SQLite-Datenbank,
- strukturierte Rechnungsdaten,
- Rechnungspositionen,
- ausgewählte Kundenstammdaten,
- ein vollständiges Dokumentregister,
- JSONL-Dateien für spätere maschinelle Verarbeitung,
- SHA-256-Prüflisten und Exportberichte.
Sensible Felder wie Passwörter, Kreditkarten- und Bankdaten wurden nicht unnötig in die aufbereiteten Kundenexporte übernommen. Sie blieben ausschließlich im unveränderten Originalarchiv erhalten.
Damit wurde der Bestand unabhängig von der alten Goliath-Oberfläche auswertbar, ohne das technische Original zu verlieren.
Best Practice 4: Strukturierte Daten gegen Originalbelege prüfen
Ein besonders wichtiger Teil des Projekts war der Abgleich zwischen den aktuellen Datenbankwerten und den tatsächlich ausgegebenen Rechnungs-PDFs.
Von 429 aktiven Rechnungen ergab die automatische Prüfung:
- 345 Rechnungen mit übereinstimmendem DBF- und PDF-Endbetrag,
- 48 Rechnungen mit abweichenden Beträgen,
- 19 Rechnungen ohne eindeutige PDF-Zuordnung,
- 17 PDFs, deren Endbetrag nicht zuverlässig maschinell gelesen werden konnte.
Die Abweichungen waren keine theoretische Kleinigkeit. Bei einzelnen Vorgängen unterschieden sich aktuelle Tabellenwerte und archivierte PDF-Rechnungen erheblich. Teilweise ließen sich spätere Änderungen in den Datenbanktabellen nachvollziehen. Das ausgegebene PDF dokumentierte jedoch den damaligen Belegzustand.
Die Schlussfolgerung war eindeutig:
Strukturierte Daten und Originaldokumente dürfen nicht gegeneinander ausgespielt werden. Beide Ebenen müssen gemeinsam erhalten bleiben.
Die Datenbank liefert Struktur und Auswertbarkeit. Das PDF dokumentiert den tatsächlich ausgegebenen Beleg. Erst zusammen entsteht ein belastbarer historischer Zusammenhang.
Best Practice 5: Nicht Dateien, sondern Geschäftsakten migrieren
Eine einfache Migration hätte alle PDFs in einen großen Archivordner kopieren können. Technisch wären die Dateien dann vorhanden gewesen. Geschäftlich wären sie trotzdem nur eingeschränkt nutzbar geblieben.
Wir entschieden uns deshalb für fallorientierte digitale Akten in OpenKM. Der Goliath-Bestand erhielt einen eigenen Legacy-Bereich mit:
- Migration und Prüfprotokollen,
- einer eindeutigen Akte je Kunde,
- Kundenübersichten,
- getrennten Vorgangsakten,
- Aktenübersichten sowie Angeboten, Aufträgen, Lieferungen, Rechnungen und sonstigen Dokumenten im jeweiligen Zusammenhang.
Jeder Kunde erhielt eine eindeutige Kundenakte. Jeder stabile kaufmännische Vorgang erhielt eine eigene Vorgangsakte. Als Primärschlüssel verwendeten wir die interne Goliath-Vorgangsnummer. Kunden-, Projekt- und Rechnungsnummern blieben als zusätzliche Referenzen erhalten.
Damit wurden aus isolierten Dateien wieder nachvollziehbare Geschäftsvorgänge.
Bekannte Lücken wurden dokumentiert, nicht kaschiert
Bei einer Altbestandsmigration entsteht schnell die Versuchung, unvollständige Vorgänge nachträglich zu vervollständigen oder widersprüchliche Daten stillschweigend zu korrigieren.
Wir haben einen anderen Weg gewählt:
- Originaldokumente blieben unverändert.
- Fehlende Dokumente wurden als fehlend ausgewiesen.
- Unklare Zuordnungen kamen in einen kontrollierten Klärungsbereich.
- Abweichende Beträge wurden sichtbar dokumentiert.
- Widersprüche wurden nicht stillschweigend korrigiert.
- Bestehende Pilotdubletten wurden ohne ausdrückliche Freigabe nicht gelöscht.
Eine digitale Akte muss nicht perfekt erscheinen. Sie muss nachvollziehbar zeigen, was vorhanden ist, was fehlt und was ungeklärt bleibt.
Best Practice 6: Erst Pilot, dann Serienmigration
Vor dem vollständigen Import erprobten wir die Struktur mit zehn ausgewählten Vorgängen. Nach dem Upload wurden sämtliche Dokumente wieder aus OpenKM heruntergeladen und erneut per SHA-256 mit den Ausgangsdateien verglichen.
Der Pilot zeigte:
- 30 Dokumente erfolgreich hochgeladen,
- 30 Dokumente erfolgreich zurückgelesen,
- keine Prüfsummenabweichung,
- beim Wiederholungslauf keine neuen Ordner,
- beim Wiederholungslauf keine Dubletten.
Erst nach dieser technischen und fachlichen Prüfung wurde die Serienmigration freigegeben. Dieses Vorgehen begrenzt Risiken: Fehler in Aktenlogik, Benennung oder Zuordnung werden erkannt, bevor sie sich über den gesamten Bestand vervielfältigen.
Best Practice 7: Jeder Upload braucht eine Rückleseprüfung
Ein erfolgreich beantworteter Upload beweist noch nicht, dass das richtige Dokument vollständig im Zielsystem angekommen ist.
Deshalb wurde jedes importierte Dokument wieder aus OpenKM gelesen und erneut gehasht.
Der Serienimport umfasste:
- 99 aktive Kunden,
- 429 aktive Rechnungsvorgänge,
- 1.092 Original-PDFs,
- 410 eindeutig zugeordnete Rechnungs-PDFs,
- 682 PDFs im kontrollierten Klärungsbereich,
- 529 Kunden-, Akten- und Migrationsübersichten,
- insgesamt 1.621 manifestierte OpenKM-Dokumente.
Alle 1.621 Dokumente wurden aus OpenKM zurückgelesen und byteidentisch bestätigt.
Ein vollständiger Wiederholungslauf prüfte anschließend nochmals den gesamten Bestand:
- 1.621 vorhandene Dokumente gefunden,
- 1.621 Dokumente erneut verifiziert,
- kein neues Dokument erzeugt,
- keine Dublette erzeugt,
- kein Fehler aufgetreten.
Diese Idempotenz ist wichtig. Ein wiederholbarer Migrationslauf darf nicht bei jedem Start neue Kopien desselben Dokuments anlegen.
Aus Altbestand wird nutzbares Dokumentenvermögen
Der entscheidende Erfolg war nicht, dass Dateien von einem Ort an einen anderen kopiert wurden. Der Wert entstand auf mehreren Ebenen:
- Das technische Original blieb vollständig erhalten.
- Die Integrität wurde mit Prüfsummen nachgewiesen.
- Proprietäre Tabellen wurden portabel auswertbar.
- Originalbelege und Datenbankinformationen blieben gemeinsam erhalten.
- Kunden und Vorgänge wurden wieder als Aktenzusammenhang sichtbar.
- Abweichungen und Lücken wurden dokumentiert.
- Dokumente sind über Kunden-, Projekt- und Rechnungsbezüge auffindbar.
- Der Bestand kann künftig für Recherche, Nachweise und Wissensarbeit genutzt werden.
- Eine spätere Deinstallation des Altsystems kann auf einer belastbaren Entscheidungsgrundlage erfolgen.
Aus einem schwer zugänglichen Legacy-Bestand wurde damit kein bloßes Dateiarchiv, sondern eine kontrollierbare Wissens- und Nachweisinfrastruktur.
Der strategische Ansatz von Faustmann
Nach der Engpasskonzentrierten Strategie beginnt eine gute Lösung nicht bei der Software, sondern beim brennendsten Problem der Zielgruppe.
Für Unternehmen mit einem alten Warenwirtschaftssystem lautet dieser Engpass häufig:
Wir möchten das Altsystem ablösen, können aber nicht sicher beurteilen, welche Daten, Dokumente und Nachweise dadurch verloren gehen könnten.
Der zwingende Nutzen besteht deshalb nicht primär in einem neuen DMS. Er besteht in Sicherheit und Handlungsfähigkeit:
- Das Altsystem verliert seine Funktion als einziges Zugangstor.
- Dokumente und Geschäftsdaten werden unabhängig nutzbar.
- Historische Vorgänge bleiben nachvollziehbar.
- Risiken und Datenlücken werden sichtbar.
- Die Abschaltung kann kontrolliert statt auf Verdacht erfolgen.
- Unternehmenswissen bleibt erhalten.
OpenKM ist dabei der technische DMS-Kern. Entscheidend ist jedoch die Verbindung aus Bestandsanalyse, Sicherung, Datenverständnis, Aktenlogik, Prüfbarkeit und langfristiger Nutzbarkeit.
Wir verkaufen deshalb nicht einfach eine Migration. Wir helfen dabei, gebundenes Dokumentenvermögen zu erkennen, zu sichern und wieder steuerbar zu machen.
Checkliste: Was Unternehmen aus diesem Projekt lernen können
Wer ein altes ERP-, Warenwirtschafts- oder Branchensystem ablösen möchte, sollte mindestens diese Reihenfolge einhalten:
- Aktiven Datenbestand zweifelsfrei identifizieren.
- System kontrolliert beenden.
- Vollständige kalte Kopie erstellen.
- Quelle und Archiv mit SHA-256 vergleichen.
- Strukturierte Daten und Originaldokumente sichern.
- Datenbankwerte gegen repräsentative Originalbelege prüfen.
- Kunden-, Projekt- oder Fallidentitäten bestimmen.
- Unklare Zuordnungen ausdrücklich dokumentieren.
- Einen kleinen Pilotbestand migrieren.
- Uploads durch Rücklesen und Prüfsummen bestätigen.
- Wiederholungslauf auf Dublettenfreiheit testen.
- Erst danach über Deinstallation oder Löschung entscheiden.
- Zusätzlich externe Sicherung und Wiederherstellung testen.
Fazit
Alte Software ist austauschbar. Die darin enthaltenen Dokumente, Nachweise und Geschäftszusammenhänge sind es nicht.
Wer einen Legacy-Bestand lediglich als technische Altlast behandelt, übersieht seinen wirtschaftlichen Wert. Wer ihn dagegen als Dokumentenvermögen versteht, stellt andere Fragen:
- Was ist tatsächlich vorhanden?
- Was ist das Original?
- Welche Zusammenhänge müssen erhalten bleiben?
- Welche Abweichungen bestehen?
- Wie lässt sich die Integrität beweisen?
- Wie wird der Bestand unabhängig vom Altsystem wieder nutzbar?
Genau darin liegt der Unterschied zwischen einer einfachen Datenkopie und einer strategischen Dokumentenmigration.
Dokumente sind Vermögen. Wir machen sie digital steuerbar.
Handlungsaufforderung
Steht bei Ihnen ein altes ERP-, Warenwirtschafts- oder Branchensystem vor der Ablösung?
Bevor Daten gelöscht oder Systeme deinstalliert werden, klären wir gemeinsam:
- welche Dokumente und Geschäftsdaten tatsächlich vorhanden sind,
- welche Abhängigkeiten zum Altsystem bestehen,
- wie ein unverändertes und prüfbares Archiv aufgebaut werden kann,
- welche Aktenstruktur den Bestand wieder nutzbar macht,
- und ob OpenKM als langfristige DMS-Basis passt.
Der strategische Einstieg ist ein begrenzter Legacy-Dokumenten-Check – zunächst lesend, ohne Veränderung des Altsystems. Mehr dazu auf unserer Seite Datenübernahme nach OpenKM.
