In langjährig genutzter Software steckt Geschäftslogik selten nur im Quellcode. Ein Teil liegt in Konfiguration, Daten, Exportvorlagen und Schnittstellen. Ein weiterer Teil lebt in Arbeitsanweisungen oder im Wissen erfahrener Anwender. Wer nur sichtbare Masken nachbaut, verliert genau die Regeln, die den Betrieb zusammenhalten.
Verhalten aus mehreren Quellen erheben
Interviews sind wichtig, reichen aber nicht. Kombinieren Sie Prozessbeobachtung, bestehende Dokumentation, Datenprofile, Systemkonfiguration, Supportfälle und konkrete Transaktionen. Fragen Sie bei jedem Schritt nach Varianten: Was passiert bei fehlenden Daten, Rücknahme, Vertretung, verspäteter Freigabe oder widersprüchlichen Quellen?
Die häufigste Version eines Ablaufs ist nicht automatisch die risikoreichste. Monats- oder Jahresprozesse, seltene Reklamationen und regulatorisch relevante Korrekturen brauchen eigene Aufmerksamkeit.
Regeln von Reibung unterscheiden
Ein Workaround kann eine wichtige Kontrolle oder bloß historisch gewachsene Reibung sein. Dokumentieren Sie für jede Regel Zweck, Owner, Eingaben, Entscheidung, Ausgabe und Konsequenz bei Fehler. Erst danach wird entschieden, ob das Zielsystem sie bewahrt, vereinfacht oder bewusst entfernt.
Diese Entscheidung braucht fachliche Freigabe. „Das alte System macht es so“ ist weder ausreichende Begründung für Kopieren noch für Weglassen.
Charakterisierungstests aufbauen
Martin Fowler beschreibt Characterization Tests als Tests, die aktuelles Verhalten festhalten, bevor es verändert wird. Bei einer Ablösung können repräsentative Eingaben durch Alt- und Zielsystem laufen. Abweichungen werden nicht automatisch als Fehler gewertet, sondern fachlich klassifiziert: beabsichtigte Verbesserung, tolerierbare Differenz oder Paritätsverletzung.
Szenarien in einer fachlich lesbaren Form wie Given–When–Then helfen, Grenzfälle gemeinsam zu prüfen. Sie ersetzen keine weiteren Testarten, schaffen aber eine verbindliche Sprache zwischen Fachbereich und Engineering.
Parität explizit begrenzen
„Alles wie bisher“ ist nicht testbar. Definieren Sie kritische Verhaltensbereiche: Berechnung, Statuswechsel, Berechtigung, Import/Export, Benachrichtigung und Integrationsereignis. Legen Sie akzeptierte Unterschiede und Nicht-Ziele fest.
Ein Paritätskatalog wird Teil der Abnahme. Jede Regel verweist auf Quelle, Szenario, erwartetes Ergebnis und Verantwortlichen. So bleibt auch nach der Migration nachvollziehbar, warum das neue System sich in einer bestimmten Situation so verhält.
Der Neubau bewahrt damit nicht jede Eigenheit. Er bewahrt die fachlich entschiedene Logik und entfernt Komplexität bewusst – mit Beleg statt Erinnerung.