Altbetrieb heißt nicht Stillstand

Warum “wir bauen neu” kein Plan ist – und was in der Übergangszeit wirklich zählt

Es beginnt oft mit einem Satz, der in Meetings erstaunlich souverän klingt:
“Der Shop ist ja schon uralt – das macht man heute ganz anders. Den müssen wir neu bauen!”

Technisch ist das selten falsch. Praktisch ist es fast nie die ganze Wahrheit.

Denn während über Shopware, Middleware, Schnittstellen und Roadmaps gesprochen wird, läuft der alte Shop weiter. Mit echten Bestellungen, echten Kunden und vor allem: echtem Umsatz. Und genau dort entsteht das eigentliche Risiko.

Der typische Ausgangspunkt: wirtschaftlich stabil, technisch ungeliebt

In vielen mittelständischen Umgebungen existieren Shops, die aus heutiger technischer Sicht “unorthodox” wirken:

Und trotzdem: Der Shop “funktioniert”, er generiert Umsatz – und das bereits seit vielen Jahren stabil. Die technische Bewertung (“alt”, “unsauber”, “nicht skalierbar”) steht dabei oft im Kontrast zur betriebswirtschaftlichen Realität: Der Betrieb läuft.

Der Reflex: Neuentwicklung als Allzwecklösung

Sobald ein System als Legacy eingeordnet wird, folgt fast automatisch der nächste Schritt: “Wir bauen Ihnen ein neues System!” - mit moderner Architektur, sauberen APIs, ERP-Anbindung, Middleware… was man eben alles so braucht bzw. wie man das heutzutage eben so macht.

Was in Präsentationen jedoch selten auftaucht, ist die betriebswirtschaftlich naheliegendste Frage: Was passiert bis der neue Shop tatsächlich live ist?

Zwischen “Entscheidung zum Neubau” und “Go-Live” liegen in der Praxis oft 12–24 Monate, manchmal sogar noch eine längere Zeit. Dazu kommen Projektmanager- oder gar Agenturwechsel, Schnittstellenprobleme, Prioritätsverschiebungen und Budgetanpassungen.

Die verdrängte Phase: Der Übergang

In dieser Übergangszeit entsteht ein paradoxes Szenario: Der alte Shop gilt intern bereits als “Auslaufmodell”, muss aber gleichzeitig den gesamten laufenden Betrieb tragen. Feature-Entwicklung wird gestoppt, Investitionen werden zurückgehalten, Wartung nur noch reaktiv betrieben und Dokumentation unterbleibt, weil “bald eh alles neu kommt”.

Das Ergebnis ist kein stabiler Altbetrieb, sondern ein vernachlässigtes Produktivsystem unter Volllast. Nicht das alte System wird dann zum Risiko, sondern die organisatorische Haltung ihm gegenüber.

“Der Shop lief doch jahrelang – warum geht jetzt plötzlich alles kaputt?”

Diese Frage taucht in meinen Projekten erstaunlich häufig auf und sie ist absolut nachvollziehbar.

Aus Sicht der Betreiber hat sich am System oft kaum etwas geändert. Der Shop lief stabil, teilweise über viele Jahre oder Jahrzehnte hinweg. Workflows sind eingespielt, Prozesse bekannt, Fehlerquellen vertraut.

Was sich jedoch sehr wohl verändert, ist die Umgebung. Typische Einflussfaktoren hier sind beispielsweise:

Das System selbst ist selten schlagartig instabil geworden. Häufiger trifft ein über Jahre gewachsenes System auf veränderte Rahmenbedingungen, während Wartung, Dokumentation und technische Aktualisierung im Zuge der geplanten Ablösung bereits zurückgefahren wurden. Und genau das passiert bei maßgeschneiderten Systemen, die nicht auf kontinuierlich gewarteten Plattformen laufen, besonders häufig.

Ein System, das ursprünglich für überschaubaren Traffic, manuelle Pflegeprozesse und einfache Nutzungsmuster ausgelegt war, muss heute oft mit automatisierten Zugriffen, API-Abfragen und deutlich komplexeren Integrationen umgehen.

Da dieses Thema eine detaillierte Betrachtung verdient, wird es in einer späteren Notiz noch mal gesondert beleuchtet.

Stabilisieren ist nicht gleich Modernisieren

Ein häufiger Denkfehler besteht darin, Stabilisierung mit Modernisierung zu verwechseln.

Modernisierung bedeutet:

Stabilisierung bedeutet hingegen:

Diese Maßnahmen verändern nicht die Grundarchitektur. Sie sichern vielmehr den laufenden Geschäftsbetrieb – und genau dieser darf nicht ausfallen, während der Neubau entsteht.

Das eigentliche Geschäftsrisiko liegt nicht im Legacy-System

Ein Shop ohne klassische Datenbank, mit Excel als Interface und historisch gewachsenen Strukturen wirkt aus Entwicklerperspektive wie ein Relikt.

Aus Betriebsperspektive kann er jedoch hochgradig robust sein:

Solche Systeme sind selten elegant programmiert, aber oft erstaunlich resilient – insbesondere dann, wenn Risiken aktiv überwacht und betriebliche Prozesse stabil gehalten werden.

Das größte Risiko entsteht häufig genau in der Phase, in der

Gerade bei langen Projektlaufzeiten und steigender Automatisierung im Netz wird ein unbeaufsichtigter Altbetrieb zunehmend verwundbar. Nicht, weil er alt ist, sondern weil er organisatorisch als reine Übergangslösung behandelt wird und damit Wartung, Monitoring und Verantwortlichkeiten schrittweise ausdünnen.

Die Übergangsphase ist ein eigenes Projekt

In der Praxis zeigt sich immer wieder: Der Neubau eines Shops ist ein Projekt – der Weiterbetrieb des Altsystems währenddessen ebenfalls und zwar mit eigenen Anforderungen wie:

Wer diese Phase ignoriert und nur das neue System im Blick hat, riskiert das aktuelle Geschäftsmodell.

Statt ausschließlich zu fragen: “Wie soll der neue Shop aussehen?” hilft oft eine zweite, deutlich realistischere Frage: “Wie sichern wir den Betrieb bis der neue Shop wirklich live ist?”…

Fazit: Neubau ersetzt keinen Plan für das Jetzt

“Alte Schätzchen” sind nicht automatisch das Problem aber ungeplante Übergangsphasen sind es deutlich häufiger. “Wir bauen neu” ist eine strategische Entscheidung aber noch lange kein operativer Betriebsplan.

Altbetrieb bedeutet nicht Stillstand. Er bedeutet laufendes Geschäft unter realen Bedingungen und in einem sich stetig ändernden technischen Umfeld. Ich unterstütze Projekte genau in dieser Übergangsphase – mit Fokus auf Stabilisierung, legacy-spezifischem Monitoring und gezielter Risikoabsicherung des laufenden Altbetriebs, während der neue Shop entsteht.