01.04.2026: Ein Komplett-Relaunch klingt verlockend: Tabula rasa, moderner Stack, alles richtig machen. In der Praxis bedeutet es: 18-24 Monate Parallelbetrieb, Feature-Parität als bewegliches Ziel, ein Team das gleichzeitig altes und neues System pflegt - und am Ende ein Go-live unter enormem Druck, bei dem die Hälfte der Spezialfälle fehlt, die das alte System über Jahre gelernt hat.
Veraltete Technik ist ein Symptom. Die eigentliche Herausforderung ist, dass Geschäftslogik über Jahre in Code gewandert ist, den niemand vollständig versteht. Preisberechnungen mit 47 Sonderfällen. Versandregeln, die auf Datenbankabfragen basieren statt auf Konfiguration. Kundenspezifische Workflows, die als Quick-Fix entstanden und nie aufgeräumt wurden. Diese Logik muss verstanden, dokumentiert und überführt werden - nicht einfach „neu gebaut".
Kernaussage: Wer sein Legacy-System ersetzen will, muss es zuerst wirklich verstehen. Nicht den Code - sondern die Geschäftsregeln, die darin stecken.
Und genau darin liegt eine enorme Chance: Dieser Prozess zwingt dazu, Abläufe zu hinterfragen, die seit Jahren niemand angerührt hat. Brauchen wir diese 47 Sonderfälle wirklich - oder sind 12 davon obsolet? Können wir Preislogiken vereinfachen? Prozesse automatisieren, die bisher manuell liefen? Das Ergebnis einer guten Migration ist nicht nur ein neues System - sondern dokumentierte, optimierte Geschäftsprozesse, die bereit sind für moderne Automatisierung und KI-gestützte Weiterentwicklung.
Statt das alte System auf einen Schlag zu ersetzen, ziehen wir eine moderne API-Schicht ein, die als Vermittler zwischen Frontend, Backend-Systemen und bestehender Infrastruktur fungiert. Das Legacy-System bleibt laufen - wird aber Stück für Stück entlastet und abgelöst.
Spryker trennt die Architektur konsequent in Schichten: Frontend, API-Schicht (Glue API), Geschäftslogik (Backend) und Infrastruktur. Die Glue API ist der zentrale Zugangspunkt - sie stellt standardisierte Endpunkte bereit, hinter denen beliebige Backend-Systeme stehen können. Während der Migration kann die API gleichzeitig auf das alte und das neue System zugreifen - und schrittweise umschalten.
ERPs, PIMs, Lagerverwaltung - diese Systeme werden unterhalb der API-Schicht angebunden und können unabhängig voneinander ausgetauscht oder modernisiert werden. SAP, Dynamics, Eigenentwicklungen - alles dockt über standardisierte Schnittstellen an. Das Commerce-Frontend merkt davon nichts.
Klassische Migrationen scheitern an der Gleichzeitigkeit: Alles muss auf einmal funktionieren. Die Schichtenarchitektur löst genau dieses Problem. Jede Schicht kann unabhängig modernisiert werden. Das Frontend kann heute schon modern sein, während das Backend noch ein halbes Jahr braucht. Und: Neue Features werden direkt in der neuen Architektur gebaut - jedes Feature beschleunigt die Migration, statt sie zu blockieren.
Magento bleibt zunächst als Backend bestehen. Ein neues Headless-Frontend wird davor geschaltet und nutzt die Magento-REST/GraphQL-API. Parallel werden einzelne Backend-Funktionen herausgelöst: Suche wandert zu Elasticsearch, Preisberechnung wird über die API-Schicht entkoppelt, der Checkout wird modernisiert. Magento wird schrittweise auf seine Rolle als Bestelldatenbank reduziert - und am Ende durch eine Plattform ersetzt, die zur Situation passt: Spryker, commercetools, Shopware oder SAP Commerce Cloud.
Nicht jede SAP-Installation braucht einen Plattformwechsel - oft ist Modernisierung innerhalb des Ökosystems der bessere Weg. Wir entflechten gewachsene Customizations, ersetzen veraltete ImpEx-basierte Integrationen durch saubere API-Anbindungen und nutzen die aktuellen SAP-Commerce-Funktionen (Composable Storefront, Integration API). Gleichzeitig werden Drittanbieter-Services (Suche, PIM, Pricing) über eine API-Schicht angebunden - so wird die Architektur flexibler, ohne die bestehende Investition aufzugeben.
Eigenentwicklungen sind oft die anspruchsvollsten Migrationen - weil die Geschäftslogik nirgends dokumentiert ist und vollständig im Code lebt. Hier investieren wir besonders viel in Phase 1: Systematische Erfassung der Geschäftsregeln durch Code-Analyse, Datenbankauswertung und Interviews mit den Fachabteilungen. Das Ergebnis ist ein Geschäftsregel-Katalog - und gleichzeitig die Grundlage, um Prozesse zu hinterfragen: Was davon ist noch nötig? Was kann vereinfacht, zusammengelegt oder automatisiert werden? Was kann in Zukunft KI-gestützt ablaufen? Die Migration wird so zur Chance, nicht nur die Technik zu modernisieren, sondern die Geschäftsprozesse insgesamt zukunftsfähig zu machen.
Wichtig: Kein Migrationspfad ist wie der andere. Diese Szenarien sind Ausgangspunkte - die konkrete Strategie ergibt sich immer aus der Analyse Ihres spezifischen Systems, Ihrer Teamkapazität und Ihrer Geschäftsprioritäten. Wir arbeiten technologieagnostisch: Ob Spryker, SAP Commerce Cloud, commercetools, Shopware oder Salesforce Commerce - wir empfehlen, was zu Ihrer Situation passt.
Bestands- und Kundendaten, Bestellhistorien, Preisvereinbarungen - alles muss sauber überführt werden. Wir migrieren Daten nicht am Stichtag, sondern kontinuierlich: Ein Synchronisationsprozess hält beide Systeme parallel aktuell. Am Tag der Umschaltung sind die Daten bereits im neuen System - geprüft und validiert.
Das Legacy-System hat über Jahre Verbindungen aufgebaut, die niemand dokumentiert hat. Ein Cron-Job, der nachts CSV-Dateien für den Großhändler generiert. Ein Webhook, der das Lager-System triggert. Ein Redirect, der SEO-Traffic auf alte URLs lenkt. Wir erfassen diese Abhängigkeiten systematisch in Phase 1 - mit Traffic-Analyse, Datenbankauswertung und gezielten Interviews.
Lange Migrationen verlieren an Schwung. Nach 6 Monaten fragt das Management: „Sind wir schon fertig?" Das Problem: Nicht jede Phase liefert sichtbare Ergebnisse. Wenn das Team monatelang Backend-Infrastruktur umbaut - Datenbankmigrationen, Schnittstellenumbauten, Integrationsschichten - sieht das Frontend erstmal gleich aus. Das muss von Anfang an kommuniziert werden. Wir arbeiten deshalb mit transparenten Migrations-Dashboards: Welche Module sind migriert? Welche Datenflüsse laufen schon über die neue Architektur? Wie hat sich die Systemstabilität verändert? Fortschritt wird messbar - auch wenn er für den Endnutzer noch nicht spürbar ist. Und wo möglich, planen wir sichtbare Quick Wins bewusst zwischen die infrastrukturellen Phasen.