Legacy-Unterstützung
Wir modernisieren bestehende Anwendungen schrittweise und schützen dabei Prozesse, Daten und Integrationen, die für das Unternehmen weiter wertvoll sind.
Modernisierung heißt nicht, alles Alte auszutauschen. In einer seit Jahren genutzten Anwendung stecken oft wichtige Geschäftsregeln, Sonderfälle, Kundendaten und Integrationen, deren Ersatz mehr Risiko als Nutzen schaffen würde. Am Anfang steht deshalb die geschäftliche Frage: Soll die Bearbeitung schneller werden, das Betriebsrisiko sinken, Releases einfacher werden oder ein bestimmter Bereich weiterentwickelt werden?
Technik dient diesem Ziel. Ein neueres Framework, Cloud, Microservices, ein neues Frontend oder KI rechtfertigen für sich allein keinen Neubau.
Vor einer Änderung klären wir kritische Abläufe, Datenverantwortung, den Einfluss von Integrationen und den Unterschied zwischen belegten Problemen und Vermutungen. Ein Audit verbindet Produktionsverhalten, Support-Fälle, Code, Abhängigkeiten, Daten und Deployment. Bei aktuellen Störungen folgt zuerst Stabilisierung: Fehler sichtbar machen, wichtige Workflows schützen und Wiederherstellung beherrschbar machen.
Bestehendes System + Geschäftsziele
│
▼
Audit und Risikobewertung
│
┌────────┴────────┐
▼ ▼
Stabilisierung gezielte Änderung
│ │
└────────┬────────┘
▼
Deployment und PrüfungDas Ergebnis muss kein vollständiger Neubau sein. Manchmal ist es besser, ein stabiles Modul zu behalten, einen Engpass zu beseitigen oder eine Integration klarer abzugrenzen.
Eine sichere Etappe hat Ziel und Grenze, etwa Reporting, Katalog, Datenimport oder Rechnungsstellung. Sie legt fest, welches System für Daten maßgeblich ist, wer sie ändern darf, wie eine fehlgeschlagene Synchronisierung behandelt wird und wann das alte Modul außer Betrieb gehen kann.
Alter und neuer Code können gemeinsam laufen, wenn Anfragen bewusst geroutet werden, Datenverantwortung nicht doppelt liegt und Ergebnisse vergleichbar sind. Das garantiert weder unterbrechungsfreie Arbeit noch ist es immer der beste Weg. Je nach Umfang und Abhängigkeiten kann der Austausch eines kleinen Moduls in einem Schritt oder eine breitere Neuentwicklung sicherer sein.
Nutzer
│
▼
Kontrolliertes Routing
├── bestehendes Modul ─┐
└── modernisiertes Modul┼── gemeinsame Regeln und Zugriffskontrolle
│
ein festgelegtes führendes System
│
Ergebnisse vergleichen → altes Modul abschaltenNehmen wir eine hypothetische Symfony-Anwendung für Checkout, Zahlungen, Rechnungen, Benachrichtigungen und ein Betriebs-Backend. Dies ist kein GiSoft-Kundenprojekt. Der Checkout kann funktionieren, während Zahlungsaufrufe in Controllern verstreut sind und die Rechnungsstellung nach Timeouts hängen bleibt.
Die erste Änderung muss nicht die Anwendung ersetzen. Bestellformular und Preisregeln können bleiben, während ein Zahlungsadapter, ein dauerhaft gespeicherter Bestellstatus und ein kontrollierter Hintergrundjob für Rechnungen eingeführt werden. Eine E-Mail darf nicht darüber entscheiden, ob eine Bestellung bezahlt ist.
Checkout und Bestellregeln ── gespeicherter Status ──► Rechnungsstellung
│ │ │
▼ ▼ ▼
Zahlungsadapter Betriebssicht Buchhaltungssystem
│
└── Antwortprüfung, Timeouts, Verlauf der VersucheEin Timeout beweist nicht, dass Zahlung oder Rechnung fehlgeschlagen sind. Eine sichere Wiederholung braucht dauerhaften Zustand, Schutz gegen parallele Verarbeitung, eindeutige Datenbankregeln und passendes Verhalten des Anbieters. Eine Bestell-ID allein garantiert keine Idempotenz. Wenn die externe Aktion bereits erfolgt sein kann, sind Statusprüfung oder Korrektur sicherer als ein blindes Retry.
Ein Upgrade von PHP, Symfony, Laravel oder Abhängigkeiten kann Wartbarkeit und Sicherheit verbessern, braucht aber Kompatibilitätsprüfungen, Schutz der kritischen Regeln und einen belastbaren Deploymentweg. Nicht jede Anwendung benötigt ein neues Frontend, Container oder getrennte Dienste. Serverseitig gerenderte Oberflächen oder jQuery können passend bleiben, wenn sie Nutzerbedürfnisse erfüllen und die notwendige Entwicklung nicht blockieren.
Auch die Datenbank wird nicht bei jeder Änderung migriert. Vorher prüfen wir Leistung, Datenverantwortung, Qualität der Migration und die Möglichkeit, eine lokale Änderung zurückzunehmen. Direktes SQL kann sinnvoll sein. Beim Modulersatz sind versionierte Migrationen, ein vereinbartes führendes System und kontrollierte Importe sicherer als eine dauerhafte bidirektionale Synchronisierung ohne Verantwortung.
Charakterisierungstests halten bestehendes Verhalten vor dem Refactoring fest. Besonders wertvoll sind Tests für Checkout, Preise, Berechtigungen, Zahlungen, Rechnungen und kritische Integrationen. Nach einem Release prüfen wir neben Code auch Konfiguration, Migrationen, Worker, periodische Jobs und Produktionssignale.
Ein Code-Rollback macht weder eine eingezogene Zahlung noch eine E-Mail oder ein an ein ERP übergebenes Dokument rückgängig. Solche Folgen brauchen Forward Recovery: geprüften Endzustand, sichere Korrektur und klare Verantwortung. Monitoring soll technische Signale mit der Geschäftskennung verbinden, ohne unnötig sensible Daten zu speichern.
Modernisierung betrifft zudem Authentifizierung, serverseitige Autorisierung, Rollen, Mandantentrennung, Secrets und aktuelle Integrationszugänge. Ein Framework- oder Infrastrukturwechsel liefert diese Eigenschaften nicht automatisch.
GiSoft priorisiert nach Geschäftswert, Risiko, Problemhäufigkeit, Abhängigkeiten und künftigen Wartungskosten. Eine kleine überprüfbare Änderung passt zu einem eng begrenzten Problem; ein Modulersatz zu klarer Verantwortung. Eine breitere Neuentwicklung wird erwogen, wenn Grenzen, Daten oder Sicherheit sichere Etappen nicht zulassen.
KI kann Teil eines kontrollierten Workflows sein, rechtfertigt aber keinen Neubau. Zuerst brauchen Datenquellen, Rechte, Audit-Trail und die Verantwortung der Anwendung für endgültige Aktionen Klarheit.
Das Ergebnis ist mehr als neuer Code: ein messbarer Plan mit geschützten Workflows, überprüftem Release, verbleibenden Risiken und einem geschäftlich begründeten nächsten Schritt.