Legacy-Unterstützung
Wir prüfen eine bestehende Anwendung, bevor über Schutz, Modernisierung, Upgrade oder den Austausch eines Moduls entschieden wird.
Ein Audit ist keine schnelle Code-Durchsicht und keine Liste von Stilhinweisen. Es ersetzt Annahmen durch bestätigte Informationen: Was leistet das System, welche Geschäftsprozesse hängen daran, wo liegt das Risiko und was sollte zuerst geschehen? Auch bei unvollständiger Dokumentation kann eine ältere Anwendung wertvolles Wissen über Sonderfälle, Preise, Dokumente, Kunden und Integrationen enthalten.
Ausgangspunkt sind Folgen, nicht Framework-Versionen. Funktionieren Bestellungen, Zahlungen, Rechnungen und Kundenzugänge verlässlich? Was blockiert die Weiterentwicklung? Welche Daten müssen konsistent bleiben? Wer behandelt einen Vorfall und wie erfährt das Unternehmen davon?
Geschäftsprozesse
Bestellungen • Zahlungen • Dokumente • Zugänge
│
▼
Auditbereiche
Code und Abhängigkeiten • Daten • Integrationen • Sicherheit
Tests • Deployment • Worker • MonitoringGeprüft werden können PHP- und Framework-Versionen, Bibliotheken, Architektur, Datenbankabfragen und Migrationen, API-Integrationen, Authentifizierung, Autorisierung, Mandantengrenzen, Secrets und Deployment. Ein Audit ist nicht automatisch ein vollständiger Sicherheitsaudit und kein Beweis für die Abwesenheit von Schwachstellen; die Aussagekraft hängt von Umfang und verfügbaren Unterlagen ab.
Der Bericht trennt Fakten von Bewertungen. Ein Log über einen gestoppten Rechnungs-Worker ist ein Beleg. Das Risiko wartender Dokumente für bezahlte Bestellungen folgt aus Beleg und Prozessbeschreibung. Die Priorität richtet sich zusätzlich nach Geschäftsauswirkung, Häufigkeit und Wiederherstellungsmöglichkeiten.
| Element | Beispiel | |---|---| | Beobachtung | Rechnungs-Worker startet nach manchen Releases nicht neu. | | Beleg | Logs, Konfiguration und Release-Historie. | | Risiko | Bezahlte Bestellungen warten möglicherweise auf Dokumente. | | Empfehlung | Worker prüfen, Status sichtbar machen, Neustart beschreiben. | | Priorität | Mit dem Unternehmen nach Wirkung und Dringlichkeit festlegen. |
Nehmen wir eine hypothetische Symfony-Anwendung für Checkout, Zahlungen, Rechnungen, E-Mails und ein Betriebs-Backend. Sie beschreibt kein GiSoft-Kundenprojekt. Das Audit kann einen stabilen Checkout, aber unzureichend geprüfte Zahlungs-Callbacks, Rechnungsjobs ohne sichtbaren Zustand und manuelle Wiederholungen mit Doppelverarbeitungsrisiko zeigen.
Das verlangt nicht automatisch Ersatz. Zuerst prüfen wir maßgeblichen Bestellstatus, die Grenze zwischen Anwendungslogik und Zahlungsanbieter, Timeout-Verhalten, dauerhaft gespeicherte Versuche und Tests für den kritischen Ablauf. Eine stabile Kennung hilft, denselben Fall zu erkennen; Idempotenz braucht zusätzlich Zustand, Schutz vor Parallelität, Eindeutigkeitsregeln und passendes Anbieter-Verhalten.
Das Audit prüft Datenverantwortung und ob Synchronisation zwei führende Systeme erzeugt. Leistung wird anhand realer Abfragen und Last bewertet, nicht mit der Annahme, jedes SQL oder jeder Monolith müsse ersetzt werden. Hinzu kommen Wiederholungen, Timeouts, Webhooks, Integrationszugänge, Worker, Backups, Monitoring und Wiederherstellungsdokumentation.
Zugriffskontrolle wird auf dem Server geprüft: Identität, Rollen, Berechtigungen, Mandantentrennung und deaktivierte Konten. Ein ausgeblendeter Button ist keine Sicherheitsmaßnahme. Bei vertraulichen Informationen werden Zugriffsgrenzen vereinbart, Datenexposition minimiert und nicht überprüfbare Bereiche benannt.
Erkenntnisse + Geschäftskontext
│
├── stabiles Modul beibehalten
├── sofortigen Schutz umsetzen
├── Betrieb stabilisieren
├── Bereich gezielt modernisieren
└── Ersatz oder breitere Neuentwicklung planenEin Auditbericht ist weder ein fertiges technisches Design noch eine Ergebnisgarantie. Er hält Umfang, bestätigte Erkenntnisse, Annahmen und Grenzen, Risiken mit Geschäftswirkung, Empfehlungen und eine begründete Reihenfolge fest. Er nennt auch Entscheidungen, die weitere Informationen oder eine getrennte Untersuchung brauchen.
GiSoft verbindet Gespräche mit den Menschen im System, technische Analyse und Produktionsverhalten. So entsteht eine Grundlage für Schutz, Stabilisierung, schrittweise Modernisierung, Modulersatz oder breiteren Neubau statt einer Entscheidung allein nach dem Alter der Technologie.