Gewachsene Onlineshops: Refactoring oder Relaunch?

Wie Sie Risiken senken, Betrieb sichern und Schritt für Schritt modernisieren

Relaunch klingt sauber – Refactoring ist oft realistischer

Viele Unternehmen kommen irgendwann an den Punkt, an dem ihr Onlineshop „gewachsen“ ist: Über Jahre wurden Funktionen ergänzt, Erweiterungen nachgerüstet, Tracking und Einwilligungsverwaltung nachgezogen, Templates angepasst, und provisorische Lösungen wurden schrittweise zum Standard. Häufig entsteht daraus der Wunsch nach einem Neustart. Ein Relaunch klingt dann attraktiv: neues Design, neue Technik, ein aufgeräumter Code-Stand, klare Strukturen, alles einmal „richtig“.

In der Praxis ist ein Relaunch jedoch selten ein sauberer Schnitt. Meist ist er ein Großprojekt mit vielen unbekannten Variablen und einer hohen Zahl an Abhängigkeiten. Sie verändern nicht nur das Aussehen, sondern gleichzeitig Datenflüsse, Schnittstellen, Seitentypen und Prozesse. Typische Themen sind:

• Datenmigration und Datenqualität, etwa Varianten, Kundenkonten, Bestellhistorie und Produktattribute
• URL-Struktur, Weiterleitungen und die Absicherung bestehender Rankings
• Tracking, Einwilligungsverwaltung, Tag-Management und Auswertung
• Zahlungsarten, Versandlogik, Retourenprozesse und Anbindungen an Dienstleister
• Schnittstellen zur Warenwirtschaft, Import- und Exportstrecken sowie Automatisierungen
• Cache-Strategie, Performance, Barrierefreiheit sowie technische SEO-Signale und Inhalte

Jede dieser Dimensionen kann ein eigenes Teilprojekt sein. Das zentrale Risiko entsteht, wenn alles gleichzeitig geändert wird. Treten anschließend Ranking-Verluste, Conversion-Einbrüche oder Fehler im Checkout auf, lässt sich die Ursache oft nur schwer isolieren. Sie verlieren damit genau das, was im laufenden Betrieb wichtig ist: Kontrolle. Zusätzlich entsteht ein reales Betriebsrisiko, weil der Onlineshop während der Umsetzung weiter verkaufen muss. Parallelbetrieb, Übergangslösungen und kurzfristige Korrekturen verursachen dann nicht selten zusätzliche Kosten.

Refactoring setzt genau hier an – nicht als „Kosmetik“, sondern als kontrollierte Modernisierung im laufenden Betrieb. Statt „alles neu“ wird das System Schritt für Schritt stabiler: riskante Komponenten werden entschärft, technische Altlasten werden reduziert, Performance-Bremsen werden identifiziert und beseitigt, und Prozesse werden messbar gemacht. Der entscheidende Vorteil: Sie behalten währenddessen Kontrolle über Umsatz, Sichtbarkeit und Betrieb. Änderungen können klein gehalten, getestet und bei Bedarf zurückgenommen werden.

Wichtig ist dabei die Perspektive: Refactoring ist nicht „Wir fassen den Code an, weil er alt ist“, sondern eine Strategie, um geschäftliche Ziele zu erreichen. Dazu zählen weniger Ausfälle, bessere Ladezeiten, weniger Supportfälle, schnellere Weiterentwicklung, planbare Updates und eine sauberere Datenbasis. Wenn diese Ziele im Vordergrund stehen, wird auch klar, wann ein Relaunch tatsächlich sinnvoll ist: etwa dann, wenn das Fundament nicht mehr tragfähig ist oder ein Plattformwechsel zwingend notwendig wird. In vielen Fällen ist es jedoch wirtschaftlicher, das bestehende System in Etappen zu modernisieren – und genau darin liegt die Stärke eines professionell geplanten Refactorings.

Warnsignale: Wann Refactoring dringend wird

Ob Refactoring dringend ist, lässt sich häufig an wiederkehrenden Symptomen erkennen – nicht nur in der Technik, sondern auch in den Abläufen. Ein erstes Warnsignal ist, wenn Änderungen regelmäßig Nebenwirkungen auslösen: Ein kleines Template-Update führt zu Darstellungsfehlern, ein Plugin-Update bricht einen Schritt im Checkout, eine scheinbar harmlose Anpassung verschlechtert die Messwerte zur Nutzererfahrung oder verursacht Tracking-Probleme. Wenn Weiterentwicklung mehr Risiko als Fortschritt erzeugt, schränkt das Ihre Handlungsfähigkeit spürbar ein.

Ein zweites Warnsignal ist schleichende Instabilität. Dazu gehören wiederkehrende Timeouts, sporadische Serverfehler, unerklärliche Leistungsspitzen, geplante Hintergrundprozesse, die gelegentlich hängen bleiben, oder Schnittstellen, die nur durch manuelle Nacharbeit zuverlässig funktionieren. Viele Teams gewöhnen sich an solche Effekte, bis die Kosten sichtbar werden: Supportaufwand steigt, Abbrüche nehmen zu, interne Abläufe werden langsamer, und Änderungen werden hinausgeschoben, weil niemand das Risiko tragen will.

Ein drittes Warnsignal betrifft Datenqualität und Konsistenz. Wenn Produktdaten nicht zuverlässig zwischen Warenwirtschaft, Onlineshop und Marktplätzen übereinstimmen, wenn Preislogiken nicht mehr nachvollziehbar sind, wenn Bestände in Ausnahmefällen falsch laufen oder wenn mehrere „Wahrheitsquellen“ existieren, entsteht operatives Chaos. Gleichzeitig wird es schwierig, Reporting, Analyse und Automatisierung stabil aufzubauen. In solchen Fällen beginnt Refactoring häufig nicht im Frontend, sondern bei klaren Daten- und Prozessdefinitionen.

Auch SEO und Sichtbarkeit liefern Hinweise. Wenn Indexierungsprobleme zunehmen, Weiterleitungen unklar werden, Canonical-Verweise inkonsistent sind oder strukturierte Daten Warnungen erzeugen, ist das oft ein Symptom gewachsener Strukturen. Performance-Probleme sind ebenfalls ein klares Signal: Wenn die Antwortzeit des Servers dauerhaft hoch ist, die größte Inhaltseinheit spät lädt oder die Seite „gefühlt“ langsam bleibt, obwohl bereits optimiert wurde, ist häufig die Architektur oder die Strategie für Dateien und Zwischenspeicher nicht mehr sauber.

Ein sehr pragmatischer Indikator ist die Team-Kommunikation. Wenn Sätze fallen wie „Das fassen wir lieber nicht an“ oder „Das darf niemand ohne Person X anfassen“, ist Wissen zu stark an Einzelne gekoppelt und das System hat zu wenig Leitplanken. Refactoring bedeutet dann nicht nur Code-Verbesserung, sondern auch Dokumentation, Standards, Tests, Monitoring und klare Verantwortlichkeiten.

• Änderungen verursachen regelmäßig unerwartete Fehler in kritischen Bereichen.
• Instabilität zeigt sich in wiederkehrenden Ausfällen oder sporadischen Störungen.
• Datenflüsse sind unklar, und Ergebnisse sind nicht zuverlässig reproduzierbar.
• Wissen ist an einzelne Personen gebunden, statt im Team verankert zu sein.

Wenn mehrere dieser Warnsignale gleichzeitig auftreten, ist Refactoring kein „nice to have“ mehr, sondern ein Thema von Stabilität und Wirtschaftlichkeit. Je früher Sie reagieren, desto kleiner bleibt der Eingriff. Je länger Sie warten, desto mehr wird Modernisierung zu einer riskanten Notfallmaßnahme.

Refactoring-Strategie: Risiko rausnehmen statt alles neu

Ein erfolgreiches Refactoring beginnt nicht mit „Wir räumen den Code auf“, sondern mit einer klaren Strategie: Welche Risiken verursachen aktuell die höchsten Kosten, und welche Maßnahmen bringen den größten Stabilitätsgewinn bei möglichst geringem Eingriff? Ziel ist, den Onlineshop während der Modernisierung voll lieferfähig zu halten. Dafür braucht es ein Vorgehen, das technische, organisatorische und wirtschaftliche Aspekte zusammenführt.

Schritt 1 ist in der Regel eine Bestandsaufnahme. Dabei werden Seitentypen, kritische Pfade (zum Beispiel Suche, Produktdetail und Checkout), Integrationen, Hintergrundprozesse, externe Dienste, Plugins, Template-Anpassungen und Datenquellen systematisch erfasst. Parallel dazu setzen Sie Messpunkte, damit Veränderungen später objektiv bewertet werden können. Dazu gehören unter anderem:

• Performance-Kennzahlen wie Antwortzeit, Ladezeit der größten Inhaltseinheit und Layout-Stabilität
• Fehlerquoten, etwa 4xx/5xx, sowie auffällige Log-Einträge und deren Ursachencluster
• Datenqualität, zum Beispiel Plausibilitätsprüfungen für Preise, Bestände und Pflichtfelder
• Conversion-Pfade und kritische Abbruchstellen im Kaufprozess
• technische SEO-Signale wie Indexierbarkeit, Canonical-Logik und strukturierte Daten

Die Bestandsaufnahme liefert nicht nur eine Liste, sondern vor allem Prioritäten: Was ist kosmetisch, was ist geschäftskritisch, und welche Themen lassen sich in kleinen, sicheren Schritten verbessern?

Schritt 2 ist Entkopplung. Gewachsene Onlineshops leiden häufig darunter, dass Komponenten zu stark voneinander abhängen. Refactoring zielt darauf ab, Abhängigkeiten kontrollierbar zu machen: Schalter für neue Template-Bausteine, klare Trennung optionaler Skripte, definierte Übergabepunkte für Tracking und Einwilligungsverwaltung sowie Konfiguration statt fest im Code verankerter Logik. Dadurch können Änderungen isoliert getestet werden. Wenn etwas schiefläuft, lässt es sich gezielt deaktivieren, ohne den gesamten Onlineshop zu gefährden.

Schritt 3 priorisiert die Risikozonen. Bereiche, die regelmäßig Fehler erzeugen oder hohe Folgekosten haben, kommen vor „Schönheitsthemen“. Dazu zählen typischerweise Checkout und Zahlungsarten, Warenkorb, Preislogik, Bestandssynchronisierung, Import/Export, Performance-Bremsen, Cache-Invalidierung sowie routing- und canonical-relevante Mechanismen. Sobald diese Zonen stabil sind, lassen sich Design- und Komfortthemen deutlich sicherer angehen.

Schritt 4 ist ein iteratives Release-Modell. Statt eines großen Umstiegs werden Maßnahmen in kleinen Releases umgesetzt – jeweils mit klarer Definition: Was wurde geändert, wie wird gemessen, und wie sieht der Rückweg aus? Schritt 5 ergänzt Dokumentation und Standards: Namenskonventionen, Ablageorte für Konfiguration, Logging, Debug-Schalter und Verantwortlichkeiten. Viele Refactorings scheitern nicht an der Technik, sondern daran, dass Leitplanken fehlen und die nächste Änderung wieder unkontrolliert erfolgt. Refactoring ist langfristig am stärksten, wenn es nicht nur „Reparatur“ ist, sondern eine belastbare Arbeitsweise etabliert.

Technik & Betrieb: Stabilität messbar machen

Refactoring im laufenden Betrieb funktioniert nur dann zuverlässig, wenn Stabilität nicht „gefühlt“, sondern messbar gemacht wird. Ein Onlineshop ist ein produktives System: Er verkauft, verarbeitet Daten, hängt an Schnittstellen und muss erreichbar sein. Deshalb reicht es nicht, nur Code zu verbessern. Sie brauchen einen Betrieb, der früh zeigt, wenn sich etwas verschlechtert – bevor es Umsatz kostet.

Ein praktischer Ansatz ist ein kleiner, fester Satz an Referenzseiten und Prozessen. Typisch sind Startseite, eine Kategorie, zwei Produktdetailseiten mit unterschiedlicher Komplexität, die Suche, Warenkorb sowie der Einstieg in den Checkout. Diese Seiten werden regelmäßig gemessen, idealerweise automatisiert. Erfasst werden dabei zentrale Werte wie Antwortzeit des Servers, Ladezeit der größten Inhaltseinheit, Layout-Stabilität, Anzahl der Anfragen, blockierende Skripte und Bildgrößen. Ergänzend kommen technische Signale hinzu:

• Rate von 4xx/5xx-Fehlern und deren Verteilung über Seitentypen
• Last auf PHP-FPM, Datenbank und Zwischenspeicher, inklusive langsamer Abfragen
• Laufzeiten von Hintergrundprozessen, inklusive Ausreißern und Abbrüchen
• Trefferquoten im Cache und Fehlerquoten in Schnittstellen

Für gewachsene Onlineshops ist außerdem die Landschaft externer Komponenten entscheidend. Viele Performance-Probleme entstehen nicht durch zu wenig Serverleistung, sondern durch zu hohe Last im Browser: Tracking-Werkzeuge, Einwilligungsverwaltung, Chat-Widgets, Schriftarten, Tag-Manager, Retargeting und Tests. Diese Komponenten müssen nicht verschwinden, aber sie müssen beherrscht werden. Refactoring bedeutet hier: klare Regeln, wann welches Skript lädt, welche Seitentypen betroffen sind und welche Priorität der Browser erhält. Ein sauberer Einwilligungsfluss ist dabei nicht nur rechtlich relevant, sondern technisch messbar. Wenn eine Seite nach der Einwilligung plötzlich deutlich mehr lädt, gehört dieser Effekt in die Optimierung.

Ein weiterer Stabilitätshebel ist Datenqualität. Viele Fehler, die wie Programmfehler wirken, sind in Wahrheit Datenfehler: inkonsistente Attribute, fehlende Pflichtfelder, unerwartete Zeichensätze oder unbereinigte Importdaten. Deshalb sollten Plausibilitätsprüfungen Teil des Betriebs sein:

1. Ausreißer in Preisen, etwa ungewöhnlich hohe oder negative Werte.
2. Bestände, die unerwartet negativ werden oder nicht zur Warenwirtschaft passen.
3. fehlende Medien, unvollständige Varianten oder widersprüchliche Merkmale.
4. Auffällige Rückläuferquoten oder Fehlermeldungen in Schnittstellen.

Und schließlich: Logging und Debugging als Standard. Refactoring bedeutet nicht, alles mit Ausgaben zu überladen, sondern bewusst Schalter zu schaffen: Funktionsschalter, Debug-Parameter für bestimmte Komponenten, strukturierte Protokolle, eindeutige Korrelationskennungen und nachvollziehbare Fehlerkanäle. Das Ergebnis ist ein Onlineshop, der nicht nur „läuft“, sondern sich im Betrieb erklären lässt. Genau das ist die Voraussetzung, um weiterzuentwickeln, ohne jedes Mal Angst vor dem nächsten Update zu haben.

Roadmap & Kommunikation: So bleibt der Onlineshop lieferfähig

Refactoring ist nicht nur ein technisches Projekt, sondern Veränderungsarbeit im laufenden Betrieb. Damit der Onlineshop lieferfähig bleibt, brauchen Sie eine Roadmap, die Aufwand und Risiken transparent macht und regelmäßig sichtbaren Nutzen liefert. In vielen Unternehmen scheitert Modernisierung daran, dass schnelle Ergebnisse erwartet werden, während die Technik zunächst Grundlagen schaffen muss. Eine gute Roadmap übersetzt diese Grundlagen in messbare Etappen.

Bewährt hat sich ein 3-Phasen-Modell. Phase 1 fokussiert Stabilisierung und Transparenz. Hier werden Messpunkte gesetzt, kritische Ausfälle reduziert, große Performance-Bremsen identifiziert und die gefährlichsten Abhängigkeiten entschärft. Das Ergebnis ist oft nicht „schöner“, aber spürbar: weniger Störungen, weniger Supportfälle und planbarere Releases. Phase 2 ist Modernisierung mit Prioritäten. Hier werden zentrale Altlasten abgebaut: strukturierte Daten konsistent machen, Routing und Canonicals stabilisieren, Strategie für Dateien und Zwischenspeicher vereinheitlichen, Schnittstellen robuster machen und Datenflüsse klären. Phase 3 ist Optimierung und Ausbau. Erst wenn das Fundament stabil ist, sind größere Änderungen wie ein neues Bedienkonzept, neue Funktionen oder ein Systemwechsel deutlich weniger riskant.

Wichtig ist die Übersetzung in Geschäftsziele. Für Außenstehende klingt Refactoring schnell nach „Technik, die niemand sieht“. Deshalb sollten Maßnahmen immer mit Wirkung verbunden sein. Typische, gut berichtbare Effekte sind:

• sinkende Ladezeiten und stabilere Messwerte zur Nutzererfahrung
• weniger Ausfälle und geringere Fehlerraten in kritischen Prozessen
• sinkender Supportaufwand durch reproduzierbare Abläufe
• geringere Entwicklungszeit pro Funktion durch klare Standards und Leitplanken
• bessere Datenqualität und belastbarere Berichte
• konsistentere SEO-Signale und weniger Indexierungsprobleme

Wenn Sie diese Effekte regelmäßig mit Vorher/Nachher-Werten kommunizieren, entsteht Vertrauen und Budget wird planbarer. Für die Umsetzung gilt: kleine Releases, klarer Umfang und klare Abnahme. Jedes Release sollte beantworten: Was wurde geändert, wo ist es sichtbar, wie wird es gemessen und wie sieht der Rückweg aus?

Zusätzlich müssen Verantwortlichkeiten sauber definiert sein. Wer entscheidet bei Konflikten zwischen Marketing-Tracking und Performance? Wer pflegt Kennzahlen-Definitionen? Wer ist für Datenqualität in Importprozessen zuständig? Refactoring ist besonders erfolgreich, wenn es nicht an einer Person hängt, sondern als Standard im Team verankert wird.

Am Ende ist Refactoring häufig die wirtschaftlichere Alternative zum Relaunch, weil Sie Umsatzrisiken reduzieren, Sichtbarkeitsverluste vermeiden und kontinuierlich Wert schaffen. Ein Relaunch kann sinnvoll sein, aber er ist dann am stärksten, wenn er auf einem stabilen, dokumentierten und messbaren Fundament aufsetzt. Genau dieses Fundament bauen Sie mit Refactoring – und Sie müssen nicht warten, bis „alles fertig“ ist. Verbesserungen können Schritt für Schritt live gehen: kontrolliert, messbar und ohne Stillstand im Tagesgeschäft.

Unsere Lösungen für Sie – passend zum Thema