Legacy-Anwendungen modernisieren heißt nicht, die gesamte Software auf einmal neu zu schreiben. Für viele Unternehmen ist die bessere erste Frage: Welche Funktion muss sich ändern, was darf vorerst weiterlaufen, und wie bleibt ein Auftrag während des Übergangs korrekt? DAXS würde eine bestehende Windows- oder Linux-Anwendung deshalb nach Daten, Schnittstellen und Herstellerfreigaben zerlegen, bevor über eine neue Oberfläche, API oder Plattform entschieden wird.
Ein Umzug der vorhandenen VM kann Betriebssystem und Hardware entkoppeln, modernisiert aber die Anwendung selbst noch nicht. Die Abnahme einer VMware-/Proxmox-Migration ist ein eigener Schritt. Hier geht es um die längerfristige Änderung von Funktionen und Integrationen bei laufendem Geschäftsbetrieb.
Erst den Bestand beschreiben, dann eine Grenze ziehen
Eine Bestandsaufnahme braucht mehr als die Liste der Servernamen. Für jeden Dienst gehören Eigentümer, Benutzergruppen, Windows- oder Linux-Version, Datenbank und Treiber, Batch-Jobs, Dateifreigaben, Drucker, Identitätsquelle, eingehende und ausgehende Schnittstellen sowie Wartungs- und Lizenzvertrag in eine Anwendungskarte. Besonders wichtig sind wenig sichtbare Wege: ein nächtlicher CSV-Export an die Buchhaltung, ein Dienstkonto mit ablaufendem Passwort oder ein Arbeitsplatzclient, dessen Version an den Server gekoppelt ist.
Bei proprietärer Software entscheidet der Hersteller, welche Gastbetriebssysteme, Datenbankversionen, Treiber und Virtualisierungsumgebungen er unterstützt. Ein direkter Schreibzugriff in seine Datenbank kann eine vermeintlich einfache Integration sein, aber Geschäftsregeln, Gewährleistung und spätere Updates verletzen. DAXS würde zuerst eine dokumentierte API, einen freigegebenen Export oder ein Hersteller-SDK prüfen. Fehlt jeder unterstützte Integrationspunkt, kann „schrittweise ersetzen“ technisch oder vertraglich unpassend sein; dann braucht es eine andere Entscheidung mit dem Anbieter.
Ein Beispiel: Auftragsstatus erneuern, Auftragskern behalten
Angenommen, eine interne Auftragsverwaltung hat einen Windows-Anwendungsdienst, eine SQL-Datenbank und einen nächtlichen Export. Kunden fragen häufig nach dem Auftragsstatus; der alte Kern verarbeitet dagegen zuverlässig Bestellungen und Rechnungen. Die erste neue Funktion könnte eine lesende Statusansicht sein, die über eine freigegebene Schnittstelle versorgt wird. Der Auftragskern und seine Datenbank bleiben zunächst führend.
Eine vorgeschaltete Integrationsschicht übersetzt dabei alte Bezeichner und Statuswerte in ein dokumentiertes neues Modell. Dieses Prinzip ist als Adapter- oder Anti-Corruption-Layer bekannt. Es ist keine magische API vor einer unkontrollierten Datenbank: Berechtigungen pro Auftrag, Authentifizierung, Eingabeprüfung, Rate-Limits, Protokollierung und Antwortzeiten müssen neu geprüft werden. Laut OWASP gehören insbesondere objektbezogene Autorisierung und Authentifizierung zu den zentralen API-Risiken. Auch eine nur lesende Statusabfrage darf nicht fremde Aufträge preisgeben.
Erst wenn die lesende Funktion stabil ist, kann ein abgegrenzter Schreibprozess folgen, etwa die Erfassung eines einzelnen Auftragstyps. Nun wird die Datenhoheit kritisch: Solange der alte Kern führend ist, darf die neue Oberfläche nicht heimlich eine zweite, unabhängige Wahrheit erzeugen. Für jeden Datensatz muss feststehen, welches System schreiben darf, wie Eingaben eindeutig wiedererkannt werden und wie Fehlversuche, verspätete Nachrichten und Korrekturen abgeglichen werden. „Beide Systeme schreiben gleichzeitig“ ist ohne fachliches Konfliktmodell kein Übergangsplan.
Vier Etappen mit einem messbaren Stopppunkt
| Etappe | Änderung | Nachweis vor der nächsten Etappe |
|---|---|---|
| 1. Bestand sichern | Abhängigkeiten, Verträge, Datenflüsse und wiederherstellbare Sicherung erfassen | Restore von Anwendung und Datenbank im Testnetz; fachlicher Abgleich eines Musterauftrags |
| 2. Lesen abtrennen | Freigegebenen Export/API für neue Statusansicht nutzen | Status, Sichtrechte, Aktualisierungsverzug und Last gegen Altsystem messen |
| 3. Einen Schreibfall verlagern | Nur einen Auftragstyp über neue Schnittstelle führen; Datenhoheit festlegen | Jeder Auftrag genau einmal verbucht, Belege und Korrekturen abgeglichen, Rückweg geübt |
| 4. Altteil abbauen | Nur nach nachgewiesener Funktions- und Datenübernahme abschalten | Keine versteckten Aufrufer, Export-/Aufbewahrungspflichten und Herstellerabhängigkeiten offen |
Dieses stufenweise Ersetzen einzelner Funktionen ähnelt dem Strangler-Fig-Muster. Es passt nicht überall: Wenn Anfragen nicht umgeleitet werden können, der Anbieter jede Schnittstelle sperrt oder das ganze kleine System ohnehin leicht ersetzbar ist, kann ein Adapter mehr Aufwand als Nutzen schaffen. Die Übergangsschicht selbst braucht Monitoring, Kapazität und einen Betreiber; sie darf nicht zum neuen Single Point of Failure werden.
Rückweg vor dem ersten produktiven Schreibvorgang festlegen
Bei einer nur lesenden Statusansicht ist der Rückweg oft einfach: neue Ansicht deaktivieren, Auftragskern weiter nutzen und die Ursache untersuchen. Nach dem ersten Schreibvorgang auf einer neuen Datenbank reicht das Zurückschalten eines Proxys nicht mehr. Neue Aufträge, Stornos und Belege müssen in den alten Stand zurückgeführt oder fachlich nachbearbeitet werden. Für jeden Wechsel gehören daher ein letzter abgeglichener Datenstand, ein eindeutiger Schreibstopp, Export-/Importverfahren, Verantwortliche und eine Testübung in den Plan. Die Microsoft-Dokumentation zum stufenweisen Ersetzen warnt ausdrücklich vor dem steigenden Aufwand eines Rollbacks, sobald alte Datenobjekte entfernt wurden.
Auch die alte Umgebung darf während der Parallelphase nicht vergessen werden. Wenn Betriebssystem oder Anwendung keine Sicherheitsupdates mehr erhalten, sind die betroffenen Dienste, Netzpfade und Zugriffe gezielt zu begrenzen, zu überwachen und mit einem Ausstiegsdatum zu versehen. Eine neue API davor beseitigt die Schwachstelle im alten Kern nicht. Ob eine Isolierung für den konkreten Fall genügt, hängt vom Risiko und den verfügbaren Herstellermaßnahmen ab.
Aufwand und Grenzen ehrlich rechnen
Ein Vergleich über drei oder fünf Jahre enthält mindestens Bestandsanalyse, Anbieter- und Lizenzabklärung, Adapter-Entwicklung, Datenmapping, Sicherheitsprüfung, Testdaten, Fachbereichsabnahme, parallelen Betrieb, Monitoring und späteren Rückbau. Dazu kommen gegebenenfalls neue Betriebssystem-/Datenbanklizenzen und Schulung der Menschen, die beide Welten übergangsweise betreiben. Der parallele Betrieb ist ein bewusstes Kostenfeld, keine kostenlose Zwischenstufe. Eine schrittweise Lösung lohnt sich erst, wenn vermiedene Betriebsrisiken und neue Funktionen den tatsächlichen Aufwand rechtfertigen; eine allgemeine Einsparquote lässt sich daraus nicht ableiten.
DAXS würde mit dem Fachbereich einen kleinen, sichtbaren ersten Schnitt wählen, etwa die Statusauskunft im Beispiel, und ihn anhand von korrekten Daten, Antwortzeit, Supportfähigkeit und Restore abnehmen. Danach wird entschieden, welche nächste Funktion tatsächlich einen eigenen Dienst braucht. Für die technische Basis einer bestehenden VM beschreibt Proxmox im Unternehmen den Infrastrukturrahmen; API-Zugänge planbar betreiben ergänzt den späteren Schnittstellenbetrieb. Wer eine konkrete Anwendungskarte erstellen möchte, erreicht DAXS über Kontakt.
Quellen: Microsoft Azure Architecture Center: Strangler Fig Pattern · Microsoft: Anti-Corruption Layer Pattern · OWASP: API Security Top 10.