Bestandssysteme modernisieren

Gewachsenes System, aktueller Unterbau

Magento 1, OXID, Zend Framework oder eine gewachsene PHP-Eigenentwicklung auf einen Stand bringen, der wieder Sicherheits-Updates bekommt und in dem Erweiterungen ohne Bauchschmerzen möglich sind.

PHP seit 1998 Magento seit 2008 Analyse vor dem Angebot
Was im Lieferumfang ist

Erst verstehen, dann ablösen

Ein gewachsenes PHP-System ist selten schlecht gebaut. Es ist über zehn oder fünfzehn Jahre entstanden, von mehreren Entwicklern, unter wechselnden Anforderungen. Darin stecken viele fachliche Entscheidungen, die nirgends dokumentiert sind, sich aber im Alltag bewährt haben: eine Preisregel für einen bestimmten Kundenkreis, eine Ausnahme für einen Lieferanten, eine Sonderbehandlung für Altbestellungen. Genau dieses Wissen ist der Wert der Anwendung, und genau darum geht es bei einer Modernisierung: es zu erhalten und auf einen Unterbau zu stellen, der wieder gepflegt wird.

Die häufigsten Ausgangslagen sind Magento 1, das seit Juni 2020 keine offiziellen Sicherheits-Updates mehr bekommt, OXID-Shops, Anwendungen auf dem Zend Framework (ZF1 und ZF2), das inzwischen unter dem Namen Laminas weiterlebt, sowie Eigenentwicklungen in reinem PHP, die ohne Framework begonnen wurden. Wohin die Reise geht, entscheidet sich nach der Analyse: Shops meist Richtung Migration zu Shopware 6 oder Magento 2, Anwendungen Richtung Symfony oder Laravel.

Am Anfang steht deshalb immer eine Analyse des Bestands: Umfang der Codebasis, die fachlichen Regeln und wo sie versteckt sind, Datenmengen, angebundene Systeme wie Warenwirtschaft, Zahlung und Versand. Ein besonders lohnender Teil davon ist die Frage, was überhaupt noch benutzt wird. In gewachsenen Anwendungen liegen regelmäßig ganze Bereiche brach, die einmal für eine Aktion gebaut wurden. Was niemand mehr aufruft, muss auch nicht migriert werden, und das spart oft mehr als jede technische Optimierung.

Die eigentliche Umstellung läuft in Abschnitten, nicht als ein großer Sprung. Wo es sich anbietet, laufen altes und neues System eine Zeit lang nebeneinander, und der Verkehr wandert Bereich für Bereich hinüber. Das verteilt das Risiko und macht früh sichtbar, ob die neue Lösung im Alltag trägt. Fehlen Tests, was bei alten Anwendungen der Normalfall ist, entstehen sie zuerst an den kritischen Stellen: Sie beschreiben, was das System tatsächlich tut, und sind damit der Maßstab, an dem sich die neue Fassung messen lässt.

Zum Auftrag gehört auch die ehrliche Variante der Antwort. Manchmal ergibt die Analyse, dass ein Neuaufbau der Kernfunktionen günstiger ist als eine Übersetzung Zeile für Zeile, manchmal auch das Gegenteil: auf dem Bestand bleiben und nur einzelne Teile ablösen, etwa mit einem PHP-Update oder einem Code-Review als erstem Schritt. Beides wird benannt, auch wenn es den kleineren Auftrag bedeutet.

Die Zusammenarbeit läuft standardmäßig zu 100 % remote und damit ortsunabhängig, direkt mit Auftraggebern, als Verstärkung für Agenturen und über IT-Vermittler; Modernisierungen laufen meist über mehrere Monate. Weil dabei mit echten Kunden- und Auftragsdaten gearbeitet wird, gehört ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zum Auftrag. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich, etwa für die Klärung der Anforderungen mit den Fachabteilungen.

Aktuelle Verfügbarkeit · Eingeschränkt

Freie Kapazität ab 01.09.2026

25% für neue Projekte

Antwort innerhalb von 2-5 Werktagen je nach Projektgröße.

Anwendungsfälle

Was eine Modernisierung bringt

Das System soll wieder Sicherheits-Updates bekommen

Magento 1 bekommt seit Juni 2020 keine offiziellen Sicherheits-Updates mehr, das Zend Framework ist seit Jahren abgelöst. Auf einem gepflegten Stand schließt der Hersteller Lücken wieder selbst, statt dass jede einzelne von Hand nachgebaut wird.

Neue Funktionen sollen wieder zügig gehen

Wenn ein großer Teil der Entwicklungszeit dafür draufgeht, den Bestand am Laufen zu halten, bleibt wenig für Neues. Nach der Modernisierung werden Erweiterungen wieder zur normalen Aufgabe statt zum Risiko.

Das Wissen soll wieder im Haus sein

Wer das System gebaut hat, ist nicht mehr da, die Dokumentation ist alt. Eine Modernisierung ist immer auch eine Bestandsaufnahme: Was die Anwendung fachlich tut, wird dabei wieder nachvollziehbar festgehalten.

Der Shop oder das Portal soll wachsen können

Mehr Artikel, mehr Bestellungen, mehr gleichzeitige Nutzer. Ein aktueller Unterbau bringt Zwischenspeicher, Suche und Verarbeitung im Hintergrund von Haus aus mit, statt dass jede Last mit zusätzlicher Server-Leistung aufgefangen wird.

Anforderungen an Datenschutz und Barrierefreiheit stehen an

DSGVO-Themen wie Auskunft und Löschung, Einwilligungen, seit Juni 2025 auch das Barrierefreiheitsstärkungsgesetz. In einem aktuellen System lassen sich solche Anforderungen mit Bordmitteln umsetzen statt mit Sonderlösungen.

Mobil und über Schnittstellen erreichbar werden

Das alte Frontend ist auf Desktop ausgelegt, eine Schnittstelle für App oder Partner fehlt. Bei der Modernisierung entsteht beides gleich mit, statt später aufgesetzt zu werden.

Der Betrieb wird teurer als nötig

Alte PHP-Versionen zwingen zu speziellen Hosting-Angeboten oder verlängertem Support. Mit einem aktuellen Stand steht wieder die volle Auswahl an Hostern offen.

Eine Zweitmeinung vor der Entscheidung

Oft ist gar nicht klar, ob überhaupt migriert werden sollte. Eine nüchterne Analyse mit Aufwandsschätzung beantwortet das, auch wenn das Ergebnis lautet: erst einmal auf dem Bestand bleiben und gezielt einzelne Teile ablösen.

Vorgehen

Wie die Ablösung abläuft

Alte Systeme geben ihr Wissen unterschiedlich bereitwillig preis, deshalb schwankt vor allem der erste Schritt. Danach steht eine belastbare Schätzung. Vertragsbasis ist ein Dienstvertrag mit Abrechnung nach Aufwand.

  1. 1

    1. Analyse des Bestands

    Lesender Zugriff auf Code und Datenbank, dann die Bestandsaufnahme: Umfang, fachliche Regeln, Datenmengen, angebundene Systeme, was tatsächlich benutzt wird und was toter Ballast ist. Ergebnis ist ein Konzept mit Vorgehen und Aufwandsschätzung, samt einer ehrlichen Empfehlung, wenn ein Neuaufbau günstiger wäre als eine Migration.

  2. 2

    2. Zielbild und Datenmodell

    Festlegen, worauf migriert wird und wie die alten Daten auf das neue Modell abgebildet werden. Wichtige Entscheidungen werden schriftlich festgehalten, damit später nachvollziehbar bleibt, warum etwas so gebaut wurde.

  3. 3

    3. Schrittweise Ablösung

    Bereich für Bereich, mit regelmäßig lauffähigen Zwischenständen. Wo es sinnvoll ist, laufen alt und neu eine Zeit lang nebeneinander und der Verkehr wandert Stück für Stück hinüber, statt alles an einem Tag umzuschalten.

  4. 4

    4. Datenübernahme

    Übernahme-Skripte für Stamm- und Bewegungsdaten, erst mit einem Teildatenbestand zur Probe, dann mit Prüfberichten: Was wurde übernommen, was bewusst weggelassen, wo weichen Summen ab.

  5. 5

    5. Umstellung und begleiteter Start

    Wechsel zu einer verkehrsarmen Zeit, danach eine Phase erhöhter Aufmerksamkeit mit kurzen Wegen für Rückmeldungen. Am Ende Dokumentation und Übergabe an das Team, das den Betrieb weiterführt.

FAQ

Fragen zur Modernisierung

Was kostet die Modernisierung eines Bestandssystems?

Die Arbeit läuft nach Aufwand auf Tagessatzbasis; die Tagessätze stehen offen auf der PHP-Fullstack-Seite. Der Aufwand hängt vor allem am Ausgangssystem und an der Zahl der fachlichen Sonderfälle, weniger an der Zahl der Bildschirme. Deshalb steht am Anfang immer eine Analyse des Bestands, die den Umfang belastbar schätzt, statt vorab eine Zahl zu nennen, die niemand halten kann.

Wohin migriert man ein altes System?

Das hängt davon ab, was die Anwendung leistet. Bei Magento 1 sind je nach Größe und Team Migration zu Shopware 6 oder Magento 2 die üblichen Ziele. Bei OXID stellt sich dieselbe Frage. Anwendungen auf dem Zend Framework oder gewachsene Eigenentwicklungen gehen meist nach Symfony oder Laravel. Die Empfehlung kommt nach der Analyse und mit Begründung, nicht vorab.

Wie lange dauert so ein Vorhaben?

Seriös lässt sich das erst nach der Analyse sagen, weil der Aufwand fast vollständig von den fachlichen Sonderfällen abhängt und nicht vom Umfang, den man von außen sieht. Was sich sagen lässt: Es wird in Abschnitten gearbeitet, damit früh etwas Lauffähiges existiert und nicht monatelang ins Blaue entwickelt wird. Ein reines PHP-Update ist dagegen ein deutlich kleineres Vorhaben.

Welcher Zugriff auf das Altsystem wird gebraucht?

Für die Analyse genügt lesender Zugriff auf Code und Datenbank. Entwickelt wird danach auf einer Kopie, das Altsystem läuft bis zur Umstellung ganz normal weiter. Eine Vertraulichkeitsvereinbarung gibt es auf Wunsch vorab; wo echte Personendaten im Spiel sind, gehört ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO dazu.

Was passiert mit den alten Daten?

Übernommen werden in der Regel Stammdaten wie Artikel, Kategorien und Kunden, Bewegungsdaten im vereinbarten Zeitraum sowie Inhaltsseiten. Bewusst nicht übernommen werden meist Testdatensätze, gelöschte Einträge und alte Protokolle. Welche Zeiträume sinnvoll sind, hängt an den Aufbewahrungspflichten und wird vorher festgelegt. Vor der Umstellung gibt es einen Abgleichbericht, der zeigt, was übernommen wurde und was nicht.

Wie steht es um Suchmaschinen-Rankings nach einer Shop-Migration?

Der wichtigste Punkt ist eine vollständige Zuordnung der alten Adressen auf die neuen, per dauerhafter Weiterleitung. Dazu kommen Seitentitel, Beschreibungen und strukturierte Daten. Was sich nicht versprechen lässt, sind Positionen: Rankings hängen von vielen Faktoren ab, die niemand steuert. Was sich zusagen lässt, ist saubere Arbeit an genau den Stellen, die man beeinflussen kann.

Was, wenn eine Migration gar nicht die richtige Antwort ist?

Dann steht das so im Ergebnis der Analyse. Manchmal ist der Bestand in einem Zustand, in dem ein Neuaufbau der fachlichen Kernfunktionen ehrlicher ist als eine Übersetzung Zeile für Zeile. Manchmal reicht auch der umgekehrte Weg: auf dem Bestand bleiben und nur einzelne Teile ablösen. Beides wird offen benannt, auch wenn es den kleineren Auftrag bedeutet.

Wer betreut das System nach der Umstellung?

Auf Wunsch läuft die laufende PHP-Betreuung weiter, alternativ übernimmt das interne Team oder die bisherige Agentur. Damit das ohne Reibung geht, entstehen Dokumentation, Tests und Übergabegespräch als Teil des Projekts und nicht als Nachtrag. Der Quelltext liegt ohnehin im Git-Repository des Auftraggebers.
Verwandte Leistungen

Auch interessant

PHP-Fullstack

PHP-Update 7 → 8

Mehr erfahren

PHP-Fullstack

PHP Code-Review & Audit

Mehr erfahren

Shopware

Shopware Migration

Mehr erfahren

Tagessätze und Wartungspakete stehen offen.

Für Altsystem modernisieren gilt derselbe Satz wie für jede andere Aufgabe: 760 bis 1.080 € pro Tag netto (95 bis 135 € pro Stunde), je nach Laufzeit und Dringlichkeit, Wartungspakete ab 349 € pro Monat. Alle Stufen im Detail auf der PHP-Seite. Was eine konkrete Aufgabe kostet, ergibt sich aus der Aufwandsschätzung nach dem Erstgespräch.

Bestandssystem, das wieder tragen soll?

Eine kurze Beschreibung des Altsystems und der wichtigsten Ziele genügt. Antwort mit erster Einschätzung innerhalb von 2-5 Werktagen.

Tagessätze 760-1.080 € netto · Antwort in 2-5 Werktagen · Direktkontakt