Eine individuell entwickelte PHP-Anwendung läuft seit Jahren zuverlässig. Mitarbeiter kennen die Abläufe, Kundendaten sind vorhanden und wichtige Geschäftsprozesse funktionieren. Doch irgendwann häufen sich Probleme: Updates werden schwieriger, neue Funktionen kosten immer mehr Aufwand und der ursprüngliche Entwickler ist möglicherweise nicht mehr verfügbar. Dann stellt sich eine grundlegende Frage: Sollte das Unternehmen die bestehende PHP-Anwendung modernisieren oder eine neue Software entwickeln lassen? Eine pauschale Antwort gibt es nicht. Entscheidend sind der technische Zustand, die geschäftliche Bedeutung und die Risiken beider Wege.
1. Warum Unternehmen ältere PHP-Anwendungen weiter nutzen
In vielen Unternehmen laufen Anwendungen, die vor mehreren Jahren individuell entwickelt wurden.
Solche Systeme übernehmen häufig Aufgaben, die für den täglichen Betrieb wichtig sind:
- Verwaltung von Kunden- und Auftragsdaten
- Interne CRM- oder ERP-Funktionen
- Bestell- und Freigabeprozesse
- Individuelle Warenwirtschaftsfunktionen
- Datenaustausch mit externen Systemen
- Verarbeitung von Formularen und Dokumenten
- Automatisierung wiederkehrender Geschäftsabläufe
- Individuelle Funktionen von Websites und Onlineshops
Im Laufe der Zeit wurden diese Anwendungen oft an die tatsächlichen Anforderungen des Unternehmens angepasst.
Dadurch enthalten sie wertvolles Prozesswissen, das in keiner allgemeinen Softwarebeschreibung vollständig dokumentiert ist.
Alt bedeutet nicht automatisch schlecht
Das Alter einer Anwendung allein sagt wenig über ihre Qualität aus.
Eine ältere PHP-Anwendung kann technisch nachvollziehbar aufgebaut, gut dokumentiert und zuverlässig betreibbar sein.
Umgekehrt kann auch relativ neue Software erhebliche Probleme verursachen, wenn grundlegende Qualitätsanforderungen nicht berücksichtigt wurden.
Deshalb sollte eine Modernisierungsentscheidung nicht allein auf dem Entwicklungsjahr oder der optischen Gestaltung beruhen.
Wichtiger ist, ob die Anwendung ihre Aufgaben erfüllt, sicher betrieben werden kann und mit vertretbarem Aufwand weiterentwickelt werden kann.
2. Woran erkennt man, dass eine PHP-Anwendung modernisiert werden sollte?
Modernisierungsbedarf zeigt sich häufig nicht durch einen einzelnen großen Ausfall.
Oft entstehen zunächst kleinere Probleme, die mit der Zeit zunehmen.
Veraltete PHP-Versionen
Wenn eine Anwendung eine nicht mehr unterstützte PHP-Version benötigt, kann das Sicherheits- und Betriebsrisiken verursachen.
Ein Versionswechsel ist jedoch nicht immer mit einer einfachen Änderung der Serverkonfiguration erledigt.
Ältere Funktionen, Bibliotheken und individuelle Erweiterungen können Anpassungen erforderlich machen.
Welche PHP-Versionen offiziell unterstützt werden, lässt sich in der PHP-Dokumentation überprüfen.
Neue Funktionen werden zunehmend aufwendig
Ein weiteres Warnsignal ist, wenn selbst kleine Änderungen unerwartet viel Zeit benötigen.
Mögliche Ursachen sind:
- Starke Abhängigkeiten zwischen einzelnen Programmteilen
- Fehlende Trennung von Geschäftslogik und Benutzeroberfläche
- Unübersichtliche Datenbankzugriffe
- Unvollständige Dokumentation
- Fehlende automatisierte Tests
- Veraltete oder nicht mehr gepflegte Bibliotheken
Der bisherige Entwickler ist nicht mehr verfügbar
Wenn eine Anwendung über Jahre von einer einzigen Person betreut wurde, kann deren Weggang zu erheblichen Unsicherheiten führen.
Das bedeutet jedoch nicht, dass die Software automatisch neu entwickelt werden muss.
Ein anderer Entwickler kann vorhandenen Code analysieren, technische Abhängigkeiten erfassen und die Weiterentwicklung übernehmen.
Mehr dazu erklären wir in unserem Beitrag PHP-Entwickler nicht mehr verfügbar: Bestehende Software sicher übernehmen.
Schnittstellen funktionieren nicht mehr zuverlässig
Eine PHP-Anwendung kann technisch unverändert bleiben und trotzdem Probleme verursachen, wenn angebundene Systeme ihre Schnittstellen ändern.
Das betrifft beispielsweise:
- Zahlungsanbieter
- CRM- und ERP-Systeme
- Versanddienstleister
- Externe Datenbanken
- Authentifizierungsdienste
- Cloud-Anwendungen
In solchen Fällen ist häufig keine vollständige Neuentwicklung erforderlich. Möglicherweise genügt eine gezielte Anpassung der betroffenen Integration.
3. Was bedeutet es, eine bestehende PHP-Anwendung zu modernisieren?
Softwaremodernisierung bedeutet nicht zwangsläufig, den gesamten Quellcode auszutauschen.
Vielmehr geht es darum, technische Schwachstellen zu reduzieren und die Anwendung für aktuelle und zukünftige Anforderungen vorzubereiten.
PHP-Version aktualisieren
Eine Modernisierung kann damit beginnen, die Anwendung mit einer unterstützten PHP-Version kompatibel zu machen.
Dafür müssen gegebenenfalls veraltete Funktionen ersetzt, Bibliotheken aktualisiert und bestehende Abläufe getestet werden.
Quellcode schrittweise verbessern
Beim sogenannten Refactoring wird die interne Struktur des Codes verbessert, ohne das beabsichtigte Verhalten der Anwendung zu verändern.
Das kann die Wartbarkeit erhöhen und spätere Änderungen erleichtern.
Wichtig ist, dass die vorhandenen Funktionen vor und nach den Änderungen überprüft werden können.
Veraltete Bibliotheken ersetzen
Viele PHP-Anwendungen verwenden externe Pakete und Bibliotheken.
Wenn diese nicht mehr gepflegt werden, können technische und sicherheitsrelevante Probleme entstehen.
Eine Modernisierung kann deshalb auch den Austausch einzelner Abhängigkeiten umfassen.
Datenbankzugriffe überprüfen
Langsame oder fehleranfällige Anwendungen müssen nicht zwangsläufig vollständig ersetzt werden.
Manchmal liegen die Ursachen in ineffizienten Datenbankabfragen, fehlenden Indizes oder einer ungünstigen Verarbeitung großer Datenmengen.
Eine gezielte Untersuchung kann zeigen, welche Optimierungen sinnvoll sind.
Schnittstellen modernisieren
Bestehende Anwendungen lassen sich häufig mit aktuellen Systemen verbinden, ohne ihre gesamte Architektur auszutauschen.
Beispielsweise können neue API-Anbindungen ergänzt oder bisherige Datenaustauschprozesse überarbeitet werden.
Entscheidend ist, dass Änderungen an Schnittstellen die bestehenden Geschäftsprozesse nicht unbeabsichtigt beeinträchtigen.
4. Wann ist eine vollständige Neuentwicklung sinnvoll?
Eine Neuentwicklung kann die bessere Entscheidung sein, wenn die bestehende Anwendung grundlegende Anforderungen nicht mehr erfüllt.
Allerdings sollte dieser Schritt auf nachvollziehbaren technischen und wirtschaftlichen Gründen beruhen.
Die Geschäftsprozesse haben sich grundlegend verändert
Wenn eine Anwendung ursprünglich für wenige Mitarbeiter entwickelt wurde, inzwischen aber zahlreiche Standorte, Rollen und komplexe Prozesse unterstützen soll, kann die bisherige Struktur an Grenzen stoßen.
Eine neue Architektur kann dann sinnvoll sein.
Wesentliche technische Anforderungen lassen sich nicht mehr angemessen erfüllen
Eine Neuentwicklung kann infrage kommen, wenn notwendige Sicherheits-, Integrations- oder Betriebsanforderungen mit der bestehenden Architektur nur unter unverhältnismäßigem Aufwand erreichbar sind.
Das muss allerdings technisch untersucht werden.
Ein unübersichtlicher Quellcode allein ist noch kein ausreichender Beleg dafür, dass eine vollständige Neuentwicklung wirtschaftlicher wäre.
Die Anwendung soll zu einem neuen Produkt werden
Ein internes Werkzeug, das künftig als eigenständiges Softwareprodukt angeboten werden soll, kann andere Anforderungen haben.
Dazu gehören beispielsweise Mandantenfähigkeit, Benutzerverwaltung, Schnittstellen und eine langfristig erweiterbare Architektur.
In solchen Fällen kann eine grundlegende technische Neuausrichtung notwendig werden.
Die vorhandene Lösung deckt den Bedarf nicht mehr ab
Manchmal ist nicht die technische Qualität das Hauptproblem.
Die Software passt schlicht nicht mehr zu den aktuellen Geschäftsprozessen.
Dann sollte allerdings auch geprüft werden, ob eine geeignete Standardsoftware infrage kommt.
Eine individuelle Neuentwicklung ist nicht automatisch die wirtschaftlich beste Alternative.
5. PHP-Modernisierung oder Neuentwicklung: Der direkte Vergleich
Beide Ansätze haben unterschiedliche Stärken und Risiken.
| Kriterium | Bestehende PHP-Anwendung modernisieren | Software neu entwickeln |
|---|---|---|
| Bestehende Geschäftsprozesse | Können häufig weitgehend erhalten bleiben | Müssen vollständig erfasst und neu umgesetzt werden |
| Vorhandene Funktionen | Werden gezielt angepasst | Müssen neu implementiert oder ersetzt werden |
| Technische Altlasten | Können schrittweise reduziert werden | Bestehende Codebasis kann ersetzt werden |
| Projektumfang | Kann in kleinere Maßnahmen aufgeteilt werden | Umfasst häufig mehrere zusammenhängende Entwicklungsphasen |
| Risiko für den laufenden Betrieb | Abhängig von Umfang und Qualität der Änderungen | Besonders beim Datenumzug und Systemwechsel relevant |
| Datenmigration | Nicht immer erforderlich | Häufig ein wesentlicher Projektbestandteil |
| Technische Architektur | Wird innerhalb bestehender Rahmenbedingungen verbessert | Kann grundsätzlich neu gestaltet werden |
| Investitionsbedarf | Abhängig von Zustand und Umfang der notwendigen Maßnahmen | Abhängig von Funktionsumfang, Migration und Einführung |
| Langfristige Wartbarkeit | Kann durch gezielte Maßnahmen verbessert werden | Hängt von Qualität und Pflege der neuen Lösung ab |
Wichtig: Eine Neuentwicklung ist nicht automatisch sicherer, günstiger oder langfristig wartbarer.
Auch neue Software kann technische Schwächen enthalten.
Entscheidend sind eine geeignete Architektur, nachvollziehbare Anforderungen, Tests und eine langfristig organisierte Wartung.
6. Welche Faktoren beeinflussen Aufwand und Kosten?
Unternehmen möchten verständlicherweise wissen, welcher Weg wirtschaftlicher ist.
Eine belastbare Einschätzung ist jedoch erst möglich, wenn der Zustand der bestehenden Anwendung und die gewünschten Ergebnisse bekannt sind.
Aufwand einer Modernisierung
Der Modernisierungsaufwand hängt insbesondere davon ab:
- Wie umfangreich ist die vorhandene Anwendung?
- Welche PHP-Version und Bibliotheken werden verwendet?
- Wie gut ist der Quellcode strukturiert?
- Gibt es technische Dokumentation?
- Welche Funktionen müssen erhalten bleiben?
- Welche Schnittstellen sind angebunden?
- Welche Tests existieren bereits?
- Welche Anforderungen sollen zusätzlich erfüllt werden?
Aufwand einer Neuentwicklung
Bei einer Neuentwicklung entstehen zusätzliche Aufgaben, die häufig unterschätzt werden.
Dazu gehören:
- Analyse und Dokumentation bestehender Geschäftsprozesse
- Definition fachlicher Anforderungen
- Entwicklung der neuen Architektur
- Umsetzung aller benötigten Funktionen
- Übernahme vorhandener Daten
- Integration externer Systeme
- Funktionale und technische Tests
- Schulung und Einführung
- Umstellung des laufenden Betriebs
Warum ein direkter Preisvergleich schwierig ist
Eine kleine Modernisierung und eine vollständige Neuentwicklung sind keine gleichwertigen Leistungsumfänge.
Deshalb sollte nicht nur verglichen werden, was die unmittelbare Umsetzung kostet.
Wichtiger ist, welche geschäftlichen Anforderungen nach Abschluss erfüllt werden und welche Folgekosten entstehen können.
Bei einer wirtschaftlichen Bewertung sollten deshalb auch Betrieb, Wartung, Schulung, Ausfallrisiken und zukünftige Erweiterungen berücksichtigt werden.
7. Welche Risiken werden bei der Entscheidung häufig unterschätzt?
Unbekannte Geschäftsregeln
In individuell entwickelten Anwendungen befinden sich häufig Regeln, die über Jahre entstanden sind.
Beispielsweise können bestimmte Kundengruppen besondere Konditionen erhalten oder Aufträge abhängig von internen Kriterien verarbeitet werden.
Wenn solche Regeln nicht dokumentiert sind, können sie bei einer Neuentwicklung übersehen werden.
Versteckte technische Abhängigkeiten
Eine PHP-Anwendung kann mit zahlreichen externen Systemen verbunden sein.
Manche Integrationen sind den heutigen Verantwortlichen möglicherweise nicht vollständig bekannt.
Vor größeren Änderungen sollte deshalb untersucht werden, welche Daten wohin übertragen werden.
Unterschätzte Datenmigration
Die Übernahme vorhandener Daten kann zu den anspruchsvollsten Teilen einer Neuentwicklung gehören.
Unterschiedliche Datenstrukturen, historische Sonderfälle und unvollständige Datensätze müssen berücksichtigt werden.
Eine Migration sollte deshalb geplant, getestet und überprüfbar durchgeführt werden.
Fehlende Rückfallmöglichkeiten
Wenn eine neue Version produktiv eingesetzt wird, können unerwartete Fehler auftreten.
Deshalb sollte vorab geklärt werden, wie sich der Betrieb bei Problemen wiederherstellen lässt.
Eine Rückkehr zur vorherigen Version ist insbesondere nach Datenbankänderungen nicht immer einfach möglich.
Zu große Änderungen auf einmal
Wenn gleichzeitig die PHP-Version, Datenbank, Benutzeroberfläche und mehrere Schnittstellen geändert werden, steigt die Komplexität der Fehlersuche.
Wo technisch sinnvoll, können kleinere und nachvollziehbare Schritte helfen, Risiken besser zu kontrollieren.
8. Wie funktioniert eine schrittweise PHP-Modernisierung?
Eine schrittweise Modernisierung kann sinnvoll sein, wenn die bestehende Anwendung grundsätzlich weiter genutzt werden soll.
Der genaue Ablauf hängt von ihrer technischen Architektur ab.
-
Technische Bestandsaufnahme durchführen.
Zunächst werden PHP-Version, Frameworks, Bibliotheken, Datenbank, Schnittstellen und Betriebsumgebung untersucht.
-
Geschäftskritische Funktionen identifizieren.
Es wird geklärt, welche Prozesse zuverlässig funktionieren müssen und welche Auswirkungen ein Ausfall hätte.
-
Risiken priorisieren.
Sicherheitsprobleme, nicht unterstützte Komponenten und besonders fehleranfällige Funktionen werden bewertet.
-
Testmöglichkeiten schaffen.
Wo erforderlich, werden geeignete Testumgebungen und Prüfverfahren vorbereitet, damit Änderungen nicht ausschließlich am Produktivsystem erprobt werden.
-
Änderungen in sinnvolle Abschnitte aufteilen.
Beispielsweise können zunächst kritische Abhängigkeiten aktualisiert und anschließend einzelne Anwendungsteile überarbeitet werden.
-
Funktionen nach Änderungen überprüfen.
Besonders wichtige Geschäftsprozesse und Schnittstellen sollten gezielt getestet werden.
-
Ergebnisse dokumentieren.
Wesentliche technische Entscheidungen, Änderungen und bekannte Einschränkungen werden nachvollziehbar festgehalten.
-
Weitere Maßnahmen bewerten.
Nach jedem größeren Abschnitt kann entschieden werden, welche Modernisierungsschritte weiterhin sinnvoll sind.
Kann man einzelne Anwendungsteile vollständig ersetzen?
Ja. Zwischen einer kleinen Aktualisierung und einer vollständigen Neuentwicklung gibt es weitere Möglichkeiten.
Bestimmte Funktionen können schrittweise durch neue Komponenten ersetzt werden, während andere Teile der bestehenden Anwendung zunächst erhalten bleiben.
Ob eine solche Vorgehensweise technisch geeignet ist, hängt insbesondere von den Abhängigkeiten zwischen den Anwendungsteilen ab.
Eine häufig verwendete Architekturstrategie für die schrittweise Ablösung bestehender Systeme wird als Strangler-Fig-Pattern bezeichnet.
Sie ist jedoch kein allgemeingültiges Rezept. Bei stark miteinander verbundenen Komponenten kann ihre Umsetzung zusätzlichen Aufwand verursachen.
9. Drei typische Situationen aus dem Unternehmensalltag
Die folgenden Beispiele sind fiktiv und dienen der Veranschaulichung möglicher Entscheidungen.
Beispiel 1: Interne Auftragsverwaltung mit älterer PHP-Version
Ein Handelsunternehmen verwendet eine individuell entwickelte Anwendung zur Verwaltung von Kundenaufträgen.
Die Software erfüllt ihre Aufgaben zuverlässig, benötigt jedoch eine veraltete PHP-Version.
Die Geschäftsprozesse haben sich kaum verändert.
Möglicher Ansatz: Zunächst prüfen, welche technischen Anpassungen für den Betrieb mit einer unterstützten PHP-Version erforderlich sind.
Wenn die Anwendung strukturell weiter nutzbar ist, kann eine gezielte Modernisierung wirtschaftlicher sein als die vollständige Neuentwicklung aller Funktionen.
Beispiel 2: Individuelles CRM mit neuen Integrationsanforderungen
Ein Dienstleistungsunternehmen nutzt ein eigenes CRM-System.
Neue Anforderungen entstehen durch die Anbindung einer Buchhaltungssoftware und die Automatisierung von Datenübertragungen.
Das vorhandene CRM funktioniert ansonsten zufriedenstellend.
Möglicher Ansatz: Prüfen, ob die benötigten Schnittstellen in die bestehende Anwendung integriert werden können.
Eine neue Software ist möglicherweise nicht erforderlich, wenn sich die Anforderungen durch klar abgegrenzte Erweiterungen erfüllen lassen.
Beispiel 3: Stark verändertes Geschäftsmodell
Ein Unternehmen hat eine interne PHP-Anwendung ursprünglich für wenige Mitarbeiter entwickelt.
Inzwischen soll daraus eine Plattform mit unterschiedlichen Kundenkonten, umfangreicher Rechteverwaltung und zahlreichen externen Integrationen werden.
Die ursprüngliche Architektur ist auf diese Anforderungen nicht ausgelegt.
Möglicher Ansatz: Eine grundlegende Architekturprüfung durchführen und Modernisierung, schrittweisen Ersatz sowie Neuentwicklung vergleichen.
Wenn die neue Plattform fachlich und technisch kaum noch der ursprünglichen Anwendung entspricht, kann eine Neuentwicklung gerechtfertigt sein.
10. Checkliste: Bestehende PHP-Anwendung modernisieren oder ersetzen?
Vor einer Entscheidung sollten Unternehmen folgende Fragen beantworten:
- Geschäftlicher Nutzen: Erfüllt die bestehende Anwendung ihre wichtigsten Aufgaben?
- Technischer Zustand: Sind die verwendeten PHP-Versionen und Abhängigkeiten noch geeignet?
- Quellcode: Ist der aktuelle Code vollständig verfügbar?
- Dokumentation: Sind Architektur und Geschäftsregeln nachvollziehbar?
- Wartbarkeit: Können Änderungen mit vertretbarem Aufwand umgesetzt werden?
- Sicherheit: Gibt es bekannte Schwachstellen oder nicht mehr unterstützte Komponenten?
- Daten: Welche Informationen müssten bei einem Systemwechsel übernommen werden?
- Schnittstellen: Welche externen Systeme sind angebunden?
- Geschäftsprozesse: Welche Abläufe müssen unverändert erhalten bleiben?
- Neue Anforderungen: Welche Funktionen werden tatsächlich benötigt?
- Betriebsrisiko: Welche Auswirkungen hätte ein Ausfall während der Umstellung?
- Wirtschaftlichkeit: Welche Kosten entstehen bei Umsetzung, Betrieb und zukünftiger Wartung?
- Alternativen: Kommen Modernisierung, teilweiser Ersatz, Standardsoftware oder Neuentwicklung infrage?
Wenn wesentliche Antworten fehlen, ist eine technische Bestandsaufnahme häufig der sinnvollere nächste Schritt als eine sofortige Entscheidung für eine vollständige Neuentwicklung.
11. Häufige Fragen zur Modernisierung alter PHP-Anwendungen
Kann man eine alte PHP-Anwendung auf eine aktuelle PHP-Version umstellen?
In vielen Fällen ist das möglich. Der notwendige Aufwand hängt davon ab, welche PHP-Funktionen, Frameworks und Bibliotheken verwendet werden. Vor einer Umstellung sollten technische Abhängigkeiten untersucht und wichtige Funktionen getestet werden.
Ist es günstiger, bestehende PHP-Software zu modernisieren oder neu zu entwickeln?
Das hängt vom Zustand der bestehenden Anwendung und den zukünftigen Anforderungen ab. Wenn nur bestimmte Komponenten angepasst werden müssen, kann eine Modernisierung wirtschaftlicher sein. Bei grundlegenden technischen oder fachlichen Veränderungen kann eine Neuentwicklung sinnvoll werden. Eine belastbare Entscheidung benötigt eine individuelle Prüfung.
Kann man PHP-Code modernisieren, ohne die gesamte Anwendung neu zu schreiben?
Ja. PHP-Versionen, Bibliotheken, Datenbankzugriffe, Schnittstellen und einzelne Anwendungsteile können unter geeigneten Voraussetzungen schrittweise modernisiert werden. Nicht jede Verbesserung erfordert einen vollständigen Neustart.
Was passiert, wenn der ursprüngliche PHP-Entwickler nicht mehr erreichbar ist?
Ein anderer Entwickler kann sich grundsätzlich in den vorhandenen Code einarbeiten. Wichtig sind der Zugriff auf Quellcode, Datenbank und Betriebsumgebung. Eine technische Bestandsaufnahme hilft, den Zustand der Anwendung und mögliche Risiken zu beurteilen.
Ist eine neue PHP-Anwendung automatisch sicherer als eine alte?
Nein. Sicherheit hängt nicht allein vom Alter der Software ab. Auch neu entwickelte Anwendungen können Schwachstellen enthalten. Entscheidend sind unter anderem unterstützte Komponenten, sichere Implementierung, regelmäßige Wartung und geeignete Prüfverfahren.
Kann eine PHP-Anwendung während der Modernisierung weiterlaufen?
Häufig lassen sich Änderungen vorbereiten und testen, während die bisherige Version produktiv bleibt. Ob und wann Unterbrechungen notwendig sind, hängt von der technischen Architektur, Datenbankänderungen und dem geplanten Umfang ab. Ein unterbrechungsfreier Betrieb kann nicht pauschal zugesichert werden.
Wann lohnt sich eine technische Analyse vor der Modernisierung?
Eine Analyse ist besonders sinnvoll, wenn der Zustand des Quellcodes unbekannt ist, wichtige Dokumentation fehlt oder größere Änderungen geplant sind. Sie kann helfen, technische Risiken und geeignete Vorgehensweisen zu erkennen.
Kann Kubertino bestehende PHP-Anwendungen modernisieren?
Kubertino unterstützt Unternehmen bei der Untersuchung, Fehlerbehebung und vereinbarten Weiterentwicklung bestehender PHP-Anwendungen. Ob eine konkrete Modernisierung möglich und sinnvoll ist, hängt vom technischen Zustand und den Anforderungen des jeweiligen Projekts ab.
Fazit: Nicht jede alte PHP-Anwendung muss neu entwickelt werden
Eine ältere PHP-Anwendung kann für ein Unternehmen weiterhin einen hohen Wert besitzen.
Sie enthält häufig über Jahre entwickelte Funktionen und bildet wichtige Geschäftsprozesse ab.
Eine vollständige Neuentwicklung kann deshalb zusätzliche Risiken verursachen, wenn vorhandene Abläufe und technische Abhängigkeiten nicht ausreichend berücksichtigt werden.
Gleichzeitig ist eine Modernisierung nicht in jedem Fall die richtige Lösung.
Wenn grundlegende Anforderungen nicht mehr wirtschaftlich erfüllt werden können, sollte auch eine neue Architektur geprüft werden.
Die wichtigste Entscheidung lautet deshalb nicht sofort „modernisieren oder neu entwickeln“, sondern zunächst: Was funktioniert, welche Probleme bestehen und welche Veränderungen sind tatsächlich notwendig?
Eine technische Bestandsaufnahme kann dafür die Grundlage schaffen.