Custom Software · 5 Min. Lesezeit
Legacy-Migration: fünf Risiken und die Prüfungen vor dem Go-live
Am Montag nach einer Migration lassen sich neue Aufträge erfassen. Erst beim Monatsabschluss fällt auf, dass alte Gutschriften anders verrechnet werden. Die Software wirkt fertig, aber ein wichtiger Geschäftsfall fehlt. Solche Lücken lassen sich mit gezielten Vorbereitungen früher finden. Dieser Artikel beschreibt fünf Risiken, die Nachweise zu ihrer Prüfung und einen Umstellungsplan, der auch neue Daten berücksichtigt.
Verdeckte Abläufe: die seltenen Fälle zuerst suchen
Eine Funktionsliste aus dem Hauptmenü ist unvollständig. Exportskripte, Makros, Druckvorlagen und nächtliche Aufgaben können außerhalb der Anwendung liegen. Fragen Sie die Personen, die Monatsabschluss, Reklamationen und Ausnahmen bearbeiten. Welche Datei wird wann wohin kopiert? Welche Zahl wird vor dem Versand manuell korrigiert?
Sammeln Sie repräsentative Vorgänge und ihre erwarteten Ergebnisse. Neben normalen Aufträgen gehören Storno, Teilzahlung, Rücknahme und rückwirkende Korrektur hinein, soweit sie im Betrieb vorkommen. Verwenden Sie diese Fälle später für die Abnahme. Eine Funktion gilt als verstanden, wenn das Team erklären kann, warum ihr Ergebnis fachlich richtig ist.
Bestand aufnehmen
Datentypen, Schnittstellen und führendes System bestimmen.
Probelauf durchführen
Mit realistischen Daten kopieren und wiederholte Übertragungen testen.
Fachlich abgleichen
Beziehungen, Summen und kritische Einzelfälle prüfen; Abweichungen erklären.
Umstellung freigeben
Akzeptanzkriterien, Rückweg und Zuständigkeiten gemeinsam bestätigen.
Eigene Prüfreihenfolge. Jeder Übergang braucht ein sichtbares Ergebnis und eine verantwortliche Person.
Datenfehler: nicht nur zählen, sondern Beziehungen prüfen
Ein Import mit gleich vielen Datensätzen kann trotzdem Kunden verwechseln, Dezimalstellen verschieben oder historische Preise durch aktuelle Werte ersetzen. Erstellen Sie eine Zuordnung für Felder, IDs, Einheiten, Zeitzonen und fehlende Werte. Jede Umwandlung braucht eine Regel und eine Liste der nicht automatisch lösbaren Fälle.
Ein Beispielsatz aus einem fiktiven Großhandel: 12.000 Aufträge werden übernommen. Die Anzahl stimmt, aber 240 Positionen verlieren ihre Zuordnung zu den Aufträgen. Erst die Prüfung der Beziehungen zeigt den Fehler. Prüfen Sie deshalb auch Summen je Zeitraum, offene Salden und Datensätze ohne gültigen Bezug.
Bereinigung ist eine fachliche Entscheidung. Zwei ähnlich geschriebene Firmen sind nicht zwingend derselbe Kunde. Lassen Sie unklare Zusammenführungen bestätigen und bewahren Sie die ursprüngliche Zuordnung nachvollziehbar auf.
Parallelbetrieb: für jede Information ein führendes System
Wenn beide Anwendungen denselben Lagerstand verändern dürfen, entsteht ein Konflikt, den ein nächtlicher Abgleich nicht automatisch richtig löst. Schreiben Sie für jeden wichtigen Datentyp auf, welches System führt, in welche Richtung übertragen wird und wann diese Verantwortung wechselt.
Testen Sie verspätete und doppelte Nachrichten sowie den Ausfall einer Schnittstelle. Eine Übertragung, deren Bestätigung verloren geht, darf beim erneuten Versuch keinen zweiten Auftrag erzeugen. AWS beschreibt dieses Prinzip als idempotente Verarbeitung. Für die Abnahme genügt ein konkreter Nachweis: Derselbe Vorgang wird mehrfach zugestellt, die geschäftliche Wirkung tritt einmal ein.
Wachsender Umfang: jede Änderung gegen den Umstellungstermin prüfen
Während der Migration entdeckt das Team Wünsche, die seit Jahren offen sind. Einige sind notwendig, andere verschieben nur die Fertigstellung. Führen Sie getrennte Listen für betriebsnotwendige Funktionen, Fehler und spätere Verbesserungen.
Eine neue Anforderung bekommt eine Auswirkung auf Aufwand, Daten und Tests. Dann entscheidet die fachlich verantwortliche Person, ob sie in die erste Version gehört und welcher andere Umfang gegebenenfalls entfällt. Ein Festpreis schützt nicht vor einem unklaren Auftrag. Er braucht eine gemeinsam verstandene Grenze.
Abnahme: die Fachabteilung muss echte Arbeit erledigen können
Ein Klicktest durch das Entwicklungsteam deckt fachliche Abweichungen nur teilweise auf. Lassen Sie künftige Anwender vollständige Aufgaben mit realistischen, datenschutzgerecht bereitgestellten Beispielen durchführen. Beobachten Sie auch Suchaufwand, Berechtigungen und die Verständlichkeit von Fehlermeldungen.
Die Abnahme hält fest, welche Fälle bestanden sind und welche offenen Punkte den Start verhindern. Eine Schulung ersetzt diesen Nachweis nicht. Ein ausgelieferter Bildschirm ebenfalls nicht.
| Risiko | Vor dem Start vorlegen | Wer entscheidet fachlich? |
|---|---|---|
| Verdeckte Abläufe | Liste kritischer Fälle mit erwartetem Ergebnis | Verantwortliche des jeweiligen Prozesses |
| Datenabweichungen | Abgleich von Beziehungen, Summen und Ausnahmen | Datenverantwortliche und Fachabteilung |
| Parallelbetrieb | Datenführungsplan und Tests für doppelte Übertragung | System- und Prozessverantwortliche |
| Umfang wächst | Freigegebener Umfang und spätere Wünsche | Projektauftraggeber |
| Alltagsnutzung scheitert | Erledigte Aufgaben durch künftige Anwender | Benannte Abnahmeverantwortliche |
Der Rückfallplan beginnt vor der ersten neuen Buchung
Legen Sie einen letzten Datenabgleich und bei Bedarf ein begrenztes Schreibfenster fest. Danach folgen die technischen Prüfungen und die fachliche Freigabe. Für einen Abbruch gibt es konkrete Kriterien, etwa nicht ausgleichbare Bestandsdifferenzen oder fehlende Verarbeitung von Zahlungen.
Sobald im neuen System geschrieben wird, kann eine einfache Wiederherstellung neue Arbeit löschen. Der Plan muss beschreiben, wie diese Vorgänge gesichert und in einen Rückwechsel oder eine Korrektur übernommen werden. Microsoft weist bei sicheren Veröffentlichungen ausdrücklich auf die besondere Komplexität von Daten- und Schemaänderungen hin.
Führen Sie eine Probe mit Zeitmessung durch. Wer entscheidet? Wer sperrt Schreibzugriffe? Wer informiert die betroffenen Mitarbeiter? Ein Plan, dessen Zugangsdaten fehlen oder dessen zuständige Person im Urlaub ist, funktioniert im Ernstfall nicht.
Wann die Migration wirklich abgeschlossen ist
Nach dem ersten Betriebstag bleiben die seltenen Abläufe zu prüfen. Definieren Sie eine Beobachtungsphase, in der Fehler zugeordnet und Datenabgleiche wiederholt werden. Das alte System wird erst stillgelegt, wenn verbleibende Abhängigkeiten, Archivzugriff und offene Vorgänge geklärt sind.
Für das erste Planungsgespräch reichen ein Ablaufbild, die wichtigsten Datenquellen und ein konkreter schwieriger Geschäftsfall. Daraus lässt sich ein Prüfauftrag formulieren, bevor der ganze Umzug geschätzt wird.