Migration zwischen klassischen Shop-Systemen: Was beim Wechsel zwischen etablierten deutschen Plattformen hängenbleibt — und wie aus dem Migrations-Anlass eine echte Modernisierung wird

Der Wechsel zwischen zwei klassischen deutschen Shop-Systemen — sei es vom älteren Open-Source-System mit hohem Marktanteil zur jüngeren API-First-Plattform oder zwischen zwei Mittelstands-Stacks — ist eines der häufigeren Migrations-Projekte im deutschen Mittelstand. Anders als beim SaaS-zu-Eigen-Wechsel sind beide Seiten technisch verwandt: relationale Datenbanken im Hintergrund, ähnliche Sortiments-Logiken, vergleichbare Begriffe wie Variante, Preisgruppe, Kundenkonto.

Trotzdem ist auch dieser Wechsel kein „Klicken-und-fertig“-Projekt. Die Detail-Brüche zwischen den Systemen sitzen genau dort, wo der Inhaber den größten Aufwand investiert hat: in den Sonder-Konfigurationen, den über Jahre gepflegten Inhalts-Blöcken, den Anbindungen an Warenwirtschaft und Versand. Dieser Artikel beschreibt die typischen Migrations-Routen, die Stellen, an denen es regelmäßig knirscht, und die Disziplin, mit der die Modernisierungs-Chance nicht verschwendet wird. Plattform-Namen vermeiden wir bewusst — die Kategorie ist klar.

Die typischen Wechsel-Anlässe

• System-Version wird ausläufig. Der Hersteller stellt eine ältere Version ein, der Inhaber muss entweder eine Major-Migration innerhalb des Systems machen oder gleich wechseln. Die zweite Option wird oft attraktiv, wenn der Funktions-Sprung im aktuellen System keinen wirklichen Mehrwert mehr bringt.
• Lizenz-Politik ändert sich. Was als kostenlose Open-Source-Variante begann, wird zur „Community Edition“, dann zur kostenpflichtigen „Enterprise Edition“ für alle Funktionen, die der Shop nutzt. Der Druck zum Wechsel kommt nicht aus der Technik, sondern aus dem Vertrag.
• Funktions-Lücken werden im alten System nicht geschlossen. Headless-Architekturen, KI-Integration, moderne Checkout-Komponenten sind im alten System nur über Drittmodule abbildbar — und die kosten oder sind nicht gepflegt.
• Performance-Grenze ist erreicht. Der alte Shop wird mit wachsendem Sortiment langsam, die Optimierungs-Optionen sind ausgereizt.
• Entwickler-Mannschaft wechselt. Die neue Mannschaft kommt aus einer anderen System-Welt. Das ist ein schwacher Grund alleine, aber oft der Auslöser, wenn die anderen Indikatoren schon im Hintergrund laufen.
• Vereinheitlichung mehrerer Shops. Inhaber mit mehreren Shops auf unterschiedlichen Systemen wollen konsolidieren — meist auf das System, das die meisten Funktionen abdeckt oder die niedrigsten Pflege-Kosten hat.

Was zwischen klassischen Systemen meist sauber durchläuft

• Sortiments-Stammdaten: Artikel-Nummer, Bezeichnung, Beschreibung, Basis-Preis, Steuersatz, Standard-Versandklasse. Diese Felder gibt es in allen klassischen Systemen.
• Kategorie-Hierarchien: Werden meist als Baum-Struktur abgebildet und lassen sich übertragen, manchmal mit kleiner Anpassung an die neue Kategorie-Tiefe-Logik.
• Bestell-Historie: Bestellung mit Positionen, Bestell-Datum, Bestell-Status, Käufer-Bezug. Datenmodell ist in den meisten Systemen vergleichbar.
• Kundenkonten: Name, Adresse, Mail. Passwörter müssen neu gesetzt werden (Hash-Inkompatibilität), aber das Konto selbst kommt mit.
• Standard-Mehrwertsteuer-Konfiguration: Regelsteuersatz, ermäßigter Satz, EU-Lieferschwellen-Mechanik.

Wo es zwischen klassischen Systemen regelmäßig knirscht

Varianten-Logik

Variant-Achsen werden in jedem System anders definiert. Das eine System kennt feste Achsen pro Produktfamilie, das andere baut auf flexible Attribute, das dritte arbeitet mit Master-Slave-Beziehungen zwischen Artikeln. Was im alten System „Pullover, Größe M, Farbe blau“ als zwei Achsen war, ist im neuen System vielleicht ein Master-Artikel „Pullover“ mit fünf Slave-Artikeln für Größen und drei Color-Tags. Der Datenwert ist der gleiche, die Struktur dahinter nicht.

Folge: Pro Produkt-Familie muss die Varianten-Übertragung geprüft werden. Bei einigen Familien klappt das automatisch, bei anderen braucht es manuelle Anpassung. Ohne Stichproben-Prüfung pro Produktfamilie entstehen schiefe Sortiments-Bilder, die im Frontend sichtbar werden.

Preisgruppen und Kundengruppen

Klassische deutsche Shop-Systeme haben starke B2B-Funktionen, dazu gehören Kundengruppen mit eigenen Preisen, Rabatt-Staffeln, Versandkonditionen. Auch hier definiert jedes System die Mechanik leicht anders. Was im alten System eine Preisliste pro Kundengruppe war, ist im neuen System ein Rabatt-Set pro Kundengruppe — oder ein eigener Sortiments-Klon mit Sonderpreisen.

Wer B2B-Preise migriert, muss die Mechanik zuerst verstehen, dann die Daten in die neue Logik übertragen. Pauschaler Import scheitert hier fast immer — die Mechanik-Definition braucht Konfigurations-Arbeit pro Kundengruppe.

Inhalts-Blöcke und Layouts

Die meisten klassischen Systeme haben einen Content-Manager, in dem über Jahre Inhalts-Seiten, Banner, Werbe-Blöcke gepflegt wurden. Diese Inhalte sind kaum migrationsfähig — sie sind im alten System als HTML-Schnipsel oder als System-spezifische Module gespeichert, das neue System hat einen anderen Content-Manager.

Pragmatischer Pfad: Inhalts-Seiten werden im Migrations-Projekt komplett neu aufgesetzt. Das ist Aufwand, aber gleichzeitig die Chance, alte Inhalte zu entrümpeln und das Branding zu aktualisieren. Wer 80 Inhalts-Seiten hatte, von denen 30 nicht mehr relevant sind, baut im neuen System 50 frische Seiten — keine Migration der toten 30.

Drittmodule und Anbindungen

Module für Warenwirtschafts-Sync, Versand-Anbindung, Zahlungs-Dienste sind im alten System spezifisch entwickelt. Im neuen System gibt es entweder ein vergleichbares Standard-Modul, ein anderes Drittmodul oder eine eigene API-Anbindung. Pauschale Annahme „funktioniert dann genauso“ ist selten zutreffend.

Pro Anbindung muss geklärt werden:

• Welche Funktionen brauchen wir wirklich (was war im alten Modul nice-to-have)?
• Was bietet das neue System im Standard, was muss extern angebunden werden?
• Welche Konditionen mit den Dienstleistern (Zahlungs-Anbieter, Versand-Layer, Lager-Software) müssen neu verhandelt werden?
• Wie testen wir die neue Anbindung vor dem Cut-over?

SEO-Pfade und URL-Strukturen

Auch zwischen klassischen Systemen ist die URL-Struktur fast nie identisch. Produkte sind im einen System unter `/produkt/artikelnummer`, im anderen unter `/shop/kategorie/slug`. Kategorien sind im einen System mit eigener Sub-Domain, im anderen als Pfad-Segmente.

Folge: Vollständiger URL-Plan vor der Migration. Pro alter URL die neue URL festlegen, 301-Weiterleitungen einrichten, testen. Diese Disziplin ist die gleiche wie beim SaaS-zu-Eigen-Wechsel — und genauso wichtig.

Modernisierungs-Chancen im Migrations-Anlass

Migration ist die seltene Gelegenheit, gleichzeitig zu modernisieren. Wer den Anlass nur als 1:1-Übertrag nutzt, verschenkt den größten Teil des Mehrwerts. Vier typische Modernisierungs-Disziplinen:

• Sortiments-Aufräumung. Welche Artikel haben in den letzten 12 Monaten null oder eine Bestellung gehabt? Diese kommen nicht mit. Welche Kategorien haben kein eigenständiges Profil? Werden zusammengelegt. Welche Beschreibungen sind über 3 Jahre alt? Werden in Stichproben überarbeitet.
• Performance-Reset. Im neuen System wird Performance von Anfang an als Pflicht-Disziplin eingebaut — Bild-Optimierung, Lazy Loading, Caching-Strategie, CDN-Anbindung. Im alten System wäre das eine Nachrüstung gewesen, die viel Arbeit für wenig Gewinn macht.
• Tracking-Hygiene. Welche Tracking-Tools haben sich über die Jahre angesammelt, welche werden noch genutzt? Welche brauchen DSGVO-Einwilligung, welche nicht? Welche können raus? Migration ist der saubere Schnitt — alte Tracking-Schulden bleiben im alten System.
• Mobile-First-Konzeption. Wenn der alte Shop noch Desktop-zuerst gebaut war (was bei älteren Setups oft der Fall ist), wird der neue Shop Mobile-First konzipiert — und der Mobile-Anteil im Verkauf hebt sich entsprechend.

Der Migrations-Ablauf zwischen klassischen Systemen

Phase 1: Audit und Plan (3 bis 6 Wochen)

• Vollständiger Daten-Audit: was haben wir, wie ist es strukturiert, was kommt mit.
• Sortiments-Audit: Modernisierungs-Reset, was bleibt, was fliegt.
• URL-Plan komplett.
• Modul-Liste: was wird neu, was wird ersetzt, was wird gestrichen.
• Architektur-Entscheidungen neuer Shop.

Phase 2: Aufbau (6 bis 16 Wochen)

• Neuer Shop wird parallel aufgebaut.
• Stammdaten-Migration in Wellen, mit Prüfung pro Welle.
• Inhalts-Aufbau (neu, nicht migriert).
• Drittmodule und Anbindungen neu konfiguriert und getestet.
• Design-Anpassungen und Branding.
• Funktions-Tests in mehreren Wellen.

Phase 3: Cut-over (1 Tag bis 1 Woche)

• Bestell-Stopp 24 bis 48 Stunden.
• Letzte Bestellungen abarbeiten, Bestand-Stand übertragen, Kunden-Stand finalisieren.
• Domain-Umstellung und 301-Weiterleitungen aktivieren.
• Test der Bestell-Strecke mit Probe-Bestellungen.
• Bestell-Annahme öffnen.

Phase 4: Nachlauf (6 bis 12 Wochen)

• Such-Sichtbarkeit beobachten.
• Kunden-Support für Passwort-Reset und Konto-Wiederherstellung.
• Lücken-Schluss in Inhalten und Sortiment.
• Alter Shop bleibt als Schatten-Kopie für 8 Wochen.

Die Phasen sind länger als bei einer SaaS-zu-Eigen-Migration, weil mehr Sonder-Konfigurationen zu prüfen sind und die Inhalts-Seiten oft neu aufgebaut werden müssen. Dafür ist das technische Risiko geringer — beide Systeme kennen ihre Disziplinen.

Die acht typischen Brüche zwischen klassischen Systemen

1. Varianten-Logik passt nicht. Pro Produktfamilie prüfen, manuell nachpflegen.
2. Preisgruppen-Mechanik ist anders. Konfigurations-Arbeit pro Kundengruppe.
3. Content-Blöcke nicht migrierbar. Inhalts-Seiten werden neu gebaut.
4. Drittmodule nicht 1:1 übertragbar. Pro Anbindung Klärung und Neu-Konfiguration.
5. URL-Pfade unterschiedlich. Vollständiger 301-Plan vor Cut-over.
6. SEO-Metadaten verloren. Title, Description, Schema.org explizit übertragen.
7. Bewertungs-Format inkompatibel. Bewertungs-Übertrag prüfen, ggf. Drittdienst nutzen.
8. Tracking-Schulden bleiben kleben. Migration als Hygiene-Anlass nutzen.

Was Hannes daraus macht

Wir begleiten Migrationen zwischen klassischen Shop-Systemen mit einem auf den Anlass abgestimmten Vorgehen:

• Pre-Migration-Audit mit Fokus auf Sonder-Konfigurationen (Varianten, Preisgruppen, Anbindungen).
• Modernisierungs-Plan parallel zum Migrations-Plan — der Inhaber entscheidet, was bleibt, was fällt, was neu aufgesetzt wird.
• URL-Mapping vollständig vor Aufbau, 301-Weiterleitungs-Plan als Liefer-Artefakt.
• Stammdaten-Migration in Wellen, Stichproben-Prüfung pro Welle.
• Inhalts-Seiten als Neu-Aufbau, keine 1:1-Übertragung.
• Drittmodul-Neu-Konfiguration mit Test-Strecke vor Cut-over.
• Cut-over an einem ruhigen Termin, mit Test-Bestell-Strecke vor Bestell-Öffnung.
• 8 Wochen Nachlauf mit Such-Sichtbarkeits-Beobachtung und Schatten-Kopie alter Shop.

Festpreis nach Audit. Migration zwischen klassischen Systemen ist anspruchsvoller als sie aussieht — und gleichzeitig die beste Gelegenheit für eine echte Modernisierung. Wer sie als 1:1-Übertrag plant, baut den alten Shop in einer neuen Engine nach. Wer sie als Modernisierungs-Anlass plant, hat hinterher einen Shop, der wirklich besser ist als der alte — nicht nur in einer anderen Plattform-Welt.