Von OXID zu JTL-Shop wechseln: Daten, SEO und Prozesse sicher migrieren

Warum Unternehmen von OXID zu JTL-Shop wechseln

Der Systemwechsel sollte ein konkretes technisches oder betriebliches Ziel verfolgen.

Typische Gründe sind:

• JTL-Wawi soll künftig das zentrale Warenwirtschaftssystem bilden.
• Artikel, Preise und Bestände sollen ohne zusätzliche Zwischenlösung gepflegt werden.
• Marktplätze und Onlineshop sollen aus einem gemeinsamen System gesteuert werden.
• Die bestehende OXID-Version ist technisch veraltet oder schwer wartbar.
• Individuelle Anpassungen erschweren Updates.
• Shop, Lager, Versand und Auftragsbearbeitung sollen enger miteinander verbunden werden.
• bestehende Prozesse sollen vereinheitlicht und automatisiert werden
• die technische Betreuung soll langfristig einfacher werden

Der Wechsel lohnt sich besonders, wenn nicht nur ein neues Frontend gesucht wird, sondern eine einheitliche E-Commerce-Umgebung aus JTL-Wawi, JTL-Shop und weiteren JTL-Komponenten entstehen soll.

OXID und JTL-Shop verfolgen unterschiedliche Systemansätze

Bei einer Migration werden nicht einfach zwei identische Datenmodelle miteinander verbunden.

Deshalb reicht es nicht, OXID-Daten direkt in die Datenbank des neuen Shops zu kopieren. Die Informationen müssen so aufbereitet werden, dass sie dauerhaft über JTL-Wawi gepflegt und zuverlässig an JTL-Shop übertragen werden können.

Das Zielsystem vor der Datenmigration aufbauen

Vor dem ersten Import muss feststehen, wie JTL-Wawi und JTL-Shop künftig genutzt werden.

Zu klären sind:

• Welche JTL-Wawi-Version wird eingesetzt?
• Welche JTL-Shop-Version und welches Template werden verwendet?
• Welche Lager und Bestände werden geführt?
• Welche Kundengruppen werden benötigt?
• Welche Preislisten und Staffelpreise gelten?
• Welche Sprachen und Währungen werden benötigt?
• Welche Marktplätze werden angebunden?
• Welche Versand- und Zahlungsprozesse sollen künftig gelten?

Die Seite JTL-Shop-Erstellung mit Wawi-Anbindung beschreibt den Aufbau einer gemeinsamen technischen Grundlage.

Mit einer vollständigen OXID-Bestandsaufnahme beginnen

Vor der Migration muss bekannt sein, welche Daten und Funktionen im alten Shop tatsächlich vorhanden sind.

Erfasst werden sollten:

• Anzahl aktiver und inaktiver Artikel
• Varianten und Eltern-Kind-Strukturen
• Kategorien und Artikelzuordnungen
• Hersteller und Lieferanten
• Attribute und Auswahllisten
• Preise und Preisgruppen
• Produktbilder und weitere Mediendateien
• Kunden und Bestellungen
• Inhaltsseiten
• SEO-Titel und Beschreibungen
• aktuelle URLs und Weiterleitungen
• installierte Module und individuelle Anpassungen

Zusätzlich sollte dokumentiert werden, welche Informationen tatsächlich noch genutzt werden und welche nur als historische Altlast im System liegen.

Aktive und inaktive Daten unterscheiden

Nicht jeder im OXID-Backend vorhandene Artikel muss in das neue System übernommen werden.

Getrennt bewertet werden sollten:

• aktuell verkaufte Artikel
• vorübergehend nicht verfügbare Artikel
• dauerhaft ausgelistete Produkte
• historische Varianten
• alte Testartikel
• Dubletten
• Produkte ohne Bilder oder vollständige Daten

Eine vollständige ungeprüfte Übernahme verlagert bestehende Datenprobleme lediglich in JTL-Wawi und JTL-Shop.

Artikelnummern als zentrale Zuordnung verwenden

Für die Migration wird ein eindeutiger und dauerhaft stabiler Identifikator benötigt.

In vielen Projekten eignet sich die Artikelnummer als zentrale Verbindung zwischen:

• OXID-Artikeldaten
• JTL-Wawi-Import
• Bildern
• Kategoriezuordnungen
• Preisen
• Beständen
• Weiterleitungen
• externen Lieferantendaten

Vor dem Import muss geprüft werden, ob Artikelnummern eindeutig, vollständig und konsistent formatiert sind.

EAN, Herstellerartikelnummer und interne IDs nicht verwechseln

Unterschiedliche Kennungen erfüllen unterschiedliche Aufgaben.

Zu unterscheiden sind:

• interne OXID-Datenbank-ID
• Artikelnummer
• EAN oder GTIN
• Herstellerartikelnummer
• Lieferantenartikelnummer

Eine interne OXID-ID sollte normalerweise nicht zur langfristigen führenden Artikelkennung in JTL-Wawi werden. Sie kann jedoch während der Migration für Zuordnungen hilfreich sein.

Artikeldaten aus OXID exportieren

Je nach OXID-Version und Datenstruktur können Informationen über Datenbankexporte, vorhandene Schnittstellen oder individuell erstellte Exporte bereitgestellt werden.

Typische Artikelfelder sind:

• Artikelnummer
• Produktname
• Kurzbeschreibung
• Langbeschreibung
• Preis
• Steuersatz
• Gewicht
• EAN
• Hersteller
• Lieferant
• Bestand
• Lieferzeit
• Status
• SEO-Daten

Der Export sollte zunächst vollständig und unverändert archiviert werden. Die eigentliche Bereinigung und Umwandlung erfolgt anschließend in einer separaten Arbeitsdatei.

Originalexport und Importdatei getrennt aufbewahren

Die Quelldaten sollten jederzeit unverändert nachvollziehbar bleiben.

Sinnvoll ist eine Trennung in:

• unveränderten OXID-Rohdatenexport
• bereinigte Arbeitsdatei
• fertige JTL-Importdatei
• Fehler- und Änderungsprotokoll

Dadurch lässt sich später erkennen, ob ein Wert bereits in OXID falsch war oder während der Aufbereitung verändert wurde.

Kategorien nicht ungeprüft übernehmen

Eine historisch gewachsene OXID-Kategoriestruktur ist nicht automatisch die beste Struktur für den neuen JTL-Shop.

Kategorien sollten geprüft werden auf:

• veraltete oder leere Bereiche
• Dubletten
• uneinheitliche Benennung
• zu tiefe Verschachtelung
• fehlende kaufentscheidende Unterteilung
• interne Verwaltungsbegriffe
• SEO-relevante bestehende Landingpages

Eine neue Struktur sollte Bedienung, Sortimentslogik, Filter und bestehende Rankings gemeinsam berücksichtigen.

Mehrfachzuordnungen von Artikeln erhalten

Ein Artikel kann in OXID mehreren Kategorien zugeordnet sein.

Beim Export muss deshalb nicht nur eine Hauptkategorie berücksichtigt werden. Benötigt wird eine vollständige Zuordnung:

• Artikelnummer
• Kategorie-ID oder eindeutiger Kategoriepfad
• gegebenenfalls Priorität oder Hauptkategorie
• vollständige Pfadhierarchie

Ohne diese Zuordnung können Artikel im neuen Shop in falschen oder zu wenigen Kategorien erscheinen.

Varianten vollständig analysieren

Varianten gehören zu den anspruchsvollsten Bereichen einer Shopmigration.

Zu prüfen sind:

• Eltern- und Kindartikel
• Variationsnamen
• Variationswerte
• eigene Artikelnummern
• eigene EANs
• abweichende Preise
• Bestände
• variantenabhängige Bilder
• unvollständige oder inaktive Kinder

Die OXID-Struktur muss in eine JTL-Wawi-kompatible Vater-Kind-Struktur umgewandelt werden. Dabei dürfen keine eindeutigen Kindartikelkennungen verloren gehen.

Variationen und Merkmale voneinander trennen

Nicht jede Produkteigenschaft sollte als Variante aufgebaut werden.

Eine Variation beeinflusst typischerweise die konkret bestellbare Ausführung, beispielsweise:

• Größe
• Farbe
• Länge
• Ausführung

Merkmale beschreiben dagegen Produkte und können für Filter verwendet werden. Dazu gehören beispielsweise Material, Einsatzzweck oder technische Eigenschaften.

Eine saubere Trennung verbessert Bedienung, Datenpflege und spätere Marktplatzzuordnungen.

OXID-Attribute in JTL-Datenstrukturen überführen

Attribute aus OXID können im Zielsystem unterschiedliche Aufgaben übernehmen.

Abhängig vom Zweck können sie in JTL-Wawi als folgende Strukturen gepflegt werden:

• Merkmale
• Funktionsattribute
• Artikelattribute
• Eigene Felder
• Bestandteile der Beschreibung

Die Zuordnung sollte nach der späteren Verwendung erfolgen und nicht allein nach dem ursprünglichen OXID-Feldnamen.

Merkmale für Filter strukturieren

Filter funktionieren nur mit einheitlichen und sauber getrennten Werten.

Vor dem Import sollten vereinheitlicht werden:

• Schreibweisen
• Einheiten
• Groß- und Kleinschreibung
• Mehrfachwerte
• leere Werte
• Synonyme

Werte wie „schwarz“, „Schwarz“ und „black“ sollten nicht ungeprüft als drei unterschiedliche Filterwerte übernommen werden.

Produktbeschreibungen und HTML bereinigen

OXID-Beschreibungen können alte Formatierungen, Tabellen, Inline-Stile und Modulreste enthalten.

Geprüft werden sollten:

• veraltete HTML-Elemente
• Inline-CSS
• absolute Bildpfade
• interne OXID-Links
• nicht mehr vorhandene Downloads
• Zeichensatzfehler
• eingebettete Skripte
• doppelte Überschriften

Inhalte sollten so bereinigt werden, dass sie im neuen JTL-Shop responsiv, verständlich und langfristig wartbar bleiben.

Absolute interne Links durch relative Pfade ersetzen

Interne Links in Produkt- und Kategorietexten dürfen nach dem Domain- oder Strukturwechsel nicht auf alte OXID-Seiten verweisen.

Geprüft werden müssen:

• Links zu Kategorien
• Links zu Produkten
• Links zu Ratgebern
• Bildpfade
• Downloads
• sprachabhängige Links

Für interne Verlinkungen sollten relative URLs verwendet werden, damit Domain- und Umgebungswechsel leichter kontrollierbar bleiben.

Produktbilder vollständig übernehmen

Bilder liegen häufig nicht vollständig im Datenbankexport vor.

Für eine vollständige Migration werden je nach OXID-Struktur benötigt:

• Originalbilder
• weitere Produktbilder
• variantenabhängige Bilder
• Kategorie- und Markenbilder
• Downloads und Datenblätter
• eindeutige Zuordnung zum Artikel

Häufig ist dafür ein vollständiger FTP- oder Serverzugriff erforderlich. Ein Export aus dem Backend enthält nicht zwingend alle Originaldateien.

Bildzuordnungen systematisch erstellen

Dateinamen allein reichen nicht immer für eine sichere Artikelzuordnung.

Eine Bildliste kann enthalten:

• Artikelnummer
• Bildposition
• ursprünglicher Dateiname
• Quellpfad
• Zielpfad oder Importdatei
• Variantenbezug
• Status der Datei

Fehlende Dateien sollten vor dem Import erkannt und separat dokumentiert werden.

Preise und Kundengruppen migrieren

OXID kann unterschiedliche Preislogiken und Benutzergruppen enthalten.

Zu prüfen sind:

• Standardverkaufspreise
• Brutto- und Nettopreise
• Kundengruppenpreise
• Staffelpreise
• Aktionspreise
• variantenabhängige Preise
• länderspezifische Steuern
• Währungen

Nicht jede alte Preisregel sollte unverändert übernommen werden. Die künftige Preisverwaltung in JTL-Wawi muss verständlich und dauerhaft pflegbar bleiben.

Preisvergleich vor und nach dem Import

Preisabweichungen müssen vor dem Go-live erkannt werden.

Verglichen werden sollten repräsentative Fälle:

• normaler Artikel
• Artikel mit Sonderpreis
• Variantenartikel
• Staffelpreis
• Geschäftskundenpreis
• unterschiedliche Steuerfälle

Besonders bei Netto- und Bruttopreisen müssen Rundung und Steuerberechnung kontrolliert werden.

Bestände und Lieferzeiten neu definieren

Künftig sollte JTL-Wawi die führende Quelle für verfügbare Bestände bilden.

Vor dem Start muss geklärt werden:

• Welcher OXID-Bestand ist aktuell?
• Gibt es mehrere Lager?
• Werden Lieferantenbestände einbezogen?
• Welche Überverkäufe sind erlaubt?
• Wie werden Beschaffungsartikel behandelt?
• Welche Lieferzeiten gelten?

Ein historischer Shopbestand sollte nicht ungeprüft in JTL-Wawi übernommen werden, wenn parallel andere Verkaufskanäle oder manuelle Lagerbewegungen bestehen.

Hersteller und Lieferanten getrennt behandeln

Hersteller und Lieferant erfüllen unterschiedliche Funktionen.

Der Hersteller kann im Shop sichtbar sein und für Marken- oder Filterseiten genutzt werden. Der Lieferant ist dagegen häufig für Einkauf, Beschaffung und interne Prozesse relevant.

Beim Import sollte deshalb geprüft werden:

• Ist der Hersteller eindeutig?
• Existieren doppelte Schreibweisen?
• Ist der Lieferant noch aktiv?
• Welche Lieferantenartikelnummer gilt?
• Welche Einkaufspreise werden übernommen?

Kundenmigration bewusst entscheiden

Nicht jedes Projekt benötigt die Übernahme aller historischen Kundenkonten.

Für eine Kundenmigration sprechen:

• viele aktive Stammkunden
• B2B-Kunden mit individuellen Konditionen
• gespeicherte Adressen und Kundengruppen
• geschäftlich notwendige Kundenkennungen

Gegen eine vollständige Übernahme können sprechen:

• sehr alte oder inaktive Konten
• unvollständige Einwilligungs- und Datenschutzlage
• nicht übertragbare Passwörter
• hoher Bereinigungsaufwand
• fehlender betrieblicher Nutzen

Passwörter lassen sich häufig nicht direkt übertragen

Passwortspeicherung und Verschlüsselungsverfahren unterscheiden sich zwischen Systemen.

Mögliche Vorgehensweisen sind:

• Kundenkonto übernehmen und neues Passwort anfordern
• nur aktive B2B-Konten übertragen
• Konten nicht migrieren und Neuregistrierung ermöglichen
• individuelle technische Prüfung der vorhandenen Passwortstruktur

Kundenkommunikation und Datenschutz müssen bei dieser Entscheidung berücksichtigt werden.

Bestellungen nur bei tatsächlichem Bedarf übernehmen

Historische Bestellungen gehören zu den komplexesten Datenbereichen.

Eine vollständige Übernahme kann erforderlich sein, wenn:

• Kunden ihre Historie im neuen Konto sehen sollen
• laufende Aufträge noch bearbeitet werden müssen
• Retouren und Gewährleistung auf alten Bestellungen basieren
• interne Auswertungen im neuen System benötigt werden

Häufig ist es wirtschaftlicher, alte OXID-Bestellungen revisionssicher im bisherigen System oder in einem Exportarchiv aufzubewahren und nur offene Vorgänge gezielt zu übernehmen.

Historie und operative Daten unterscheiden

Nicht jede historische Information muss im neuen System aktiv weiterverarbeitet werden.

Eine mögliche Aufteilung ist:

• offene Aufträge werden operativ übernommen
• aktive Kunden werden migriert
• alte Bestellungen bleiben im Archiv zugänglich
• relevante Belege werden separat gesichert

Inhaltsseiten und rechtliche Texte übernehmen

Neben Produktdaten besitzt OXID häufig zahlreiche CMS- und Informationsseiten.

Dazu gehören:

• Über uns
• Kontakt
• Versandinformationen
• Zahlungsarten
• FAQ
• Ratgeber
• Datenschutz
• AGB
• Widerrufsbelehrung
• Impressum

Inhalte sollten nicht nur kopiert, sondern auf Aktualität, interne Links, Überschriftenstruktur und rechtliche Gültigkeit geprüft werden.

Individuelle OXID-Module analysieren

Funktionen aus OXID lassen sich nicht automatisch durch den Datenimport übertragen.

Für jedes Modul sollte geklärt werden:

• Welche Aufgabe erfüllt es?
• Wird die Funktion noch benötigt?
• Gibt es eine JTL-Shop-Standardfunktion?
• Existiert ein passendes Plugin?
• Ist eine individuelle Entwicklung notwendig?
• Welche Daten des Moduls müssen übernommen werden?

Einen Überblick über mögliche Erweiterungen bietet die Seite Plugins und Erweiterungen.

Versandarten neu aufbauen

Versandregeln aus OXID müssen für JTL-Shop neu konfiguriert und getestet werden.

Zu berücksichtigen sind:

• Lieferländer
• Versandklassen
• Gewicht
• Warenwert
• Sperrgut
• Spedition
• kostenloser Versand
• Kundengruppen
• Versanddienstleister

Die Konfiguration muss mit den tatsächlichen Versandprozessen in JTL-Wawi, Versandsoftware und Lager übereinstimmen.

Zahlungsarten neu anbinden und testen

Zahlungsintegrationen können nicht durch eine reine Datenmigration übernommen werden.

Für jede Zahlungsart müssen geklärt werden:

• neuer Händlerzugang
• Plugin oder Standardintegration
• Testmodus
• Statusübertragung
• Rückleitung in den Shop
• Zuordnung in JTL-Wawi
• Storno und Erstattung

Vor dem Go-live sind vollständige Testbestellungen mit allen wichtigen Zahlungsarten erforderlich.

SEO-Daten vollständig erfassen

Bestehende Rankings und indexierte URLs dürfen bei einem Systemwechsel nicht dem Zufall überlassen werden.

Erfasst werden sollten:

• Produkt-URLs
• Kategorie-URLs
• Marken- und Herstellerseiten
• Ratgeber und Inhaltsseiten
• Meta-Titel
• Meta-Beschreibungen
• Canonical-Angaben
• indexierte Filter- und Suchseiten
• bestehende Weiterleitungen

Die Seite SEO-Migration beschreibt die notwendigen Schritte für einen kontrollierten URL- und Systemwechsel.

Alte und neue URLs systematisch zuordnen

Für jede wichtige alte URL wird ein passendes neues Ziel benötigt.

Die Zuordnung sollte möglichst erfolgen:

• altes Produkt zu neuem Produkt
• alte Kategorie zu entsprechender neuer Kategorie
• entferntes Produkt zu passender Alternative oder Kategorie
• alter Ratgeber zu neuem oder überarbeitetem Inhalt
• veraltete Seite zu fachlich geeignetem Ziel

Pauschale Weiterleitungen aller alten URLs auf die Startseite sind fachlich und aus SEO-Sicht ungeeignet.

Bestehende Weiterleitungen aus OXID berücksichtigen

Viele ältere Shops besitzen bereits Weiterleitungsketten aus früheren URL-Änderungen.

Diese sollten:

• vollständig exportiert
• auf aktuelle Nutzung geprüft
• mit neuen Ziel-URLs zusammengeführt
• von Weiterleitungsketten bereinigt
• auf Schleifen kontrolliert werden

Idealerweise führt jede relevante alte URL direkt auf das endgültige neue Ziel.

Meta-Daten nicht ungeprüft übernehmen

Bestehende Titel und Beschreibungen können wertvoll sein, müssen aber auf Aktualität und Qualität geprüft werden.

Problematisch sind:

• doppelte Meta-Titel
• veraltete Marken- oder Produktnamen
• abgeschnittene Beschreibungen
• interne Systembegriffe
• fehlende Meta-Daten
• automatisch erzeugte unverständliche Texte

Die Seite JTL-Shop-SEO zeigt, wie technische und inhaltliche Optimierung im neuen Shop zusammengeführt werden.

Interne Verlinkung im neuen Shop prüfen

Navigation und Weiterleitungen allein reichen nicht aus.

Kontrolliert werden müssen auch:

• Links in Produktbeschreibungen
• Links in Kategorietexten
• Ratgeberverlinkungen
• Footerlinks
• Herstellerseiten
• Downloads
• Bilder mit alten Pfaden

Alle internen Verlinkungen sollten auf die endgültigen relativen URLs des neuen Shops zeigen.

Sitemap und Indexierung vorbereiten

Suchmaschinen benötigen nach dem Go-live klare Signale zur neuen Struktur.

Zu prüfen sind:

• XML-Sitemap
• Robots-Einstellungen
• Canonical-Tags
• sprachabhängige URLs
• noindex-Einstellungen
• Testumgebung darf nicht indexiert werden
• Produkt- und Kategorieverfügbarkeit

Die technische Grundlage sollte vor dem Domainwechsel vollständig getestet werden.

Testimporte in mehreren Stufen durchführen

Ein vollständiger Massenimport sollte nicht der erste praktische Test sein.

Eine sinnvolle Reihenfolge ist:

1. wenige einfache Artikel importieren
2. Variantenartikel ergänzen
3. Kategorien und Mehrfachzuordnungen testen
4. Merkmale und Attribute prüfen
5. Bilder importieren
6. Preise und Kundengruppen testen
7. anschließend den vollständigen Datenbestand importieren

Nach jeder Stufe werden Struktur, Darstellung und Daten in JTL-Wawi und JTL-Shop kontrolliert.

Repräsentative Testartikel auswählen

Testdaten müssen die tatsächliche Vielfalt des Sortiments abbilden.

Enthalten sein sollten:

• einfacher Artikel
• Variantenartikel
• Artikel mit vielen Bildern
• Artikel mit Staffelpreis
• Artikel mit Sonderpreis
• Artikel mit mehreren Kategorien
• Artikel mit vielen Merkmalen
• inaktiver oder auslaufender Artikel

Daten nach dem Import systematisch vergleichen

Eine reine Sichtkontrolle einzelner Produktseiten reicht nicht aus.

Verglichen werden sollten:

• Anzahl der Artikel
• Anzahl aktiver Artikel
• Variantenanzahl
• Kategoriezuordnungen
• Hersteller
• Merkmalswerte
• Bilder pro Artikel
• Preise
• Bestände
• fehlende Pflichtfelder

Abweichungen sollten in einem Fehlerprotokoll dokumentiert und vor dem endgültigen Import korrigiert werden.

Importfehler nicht manuell im neuen System verstecken

Einzelne Korrekturen direkt in JTL-Wawi können während der Testphase notwendig sein, dürfen aber nicht die eigentliche Importlogik ersetzen.

Andernfalls treten dieselben Fehler beim nächsten vollständigen Import erneut auf. Korrekturen sollten möglichst in:

• der Aufbereitungsdatei
• dem Importskript
• der Feldzuordnung
• der zugrunde liegenden Regel

vorgenommen und anschließend reproduzierbar getestet werden.

Delta-Migration vor dem Go-live planen

Zwischen dem ersten vollständigen Export und dem tatsächlichen Wechsel verändert sich der alte Shop weiter.

Neu entstehen können:

• Bestellungen
• Kunden
• Bestandsänderungen
• Preisanpassungen
• neue Artikel
• geänderte Beschreibungen

Für den Go-live muss feststehen, welche Daten erneut exportiert und in welcher Reihenfolge aktualisiert werden.

Bearbeitungsstopp für kritische Daten festlegen

Während der letzten Migration dürfen nicht beide Systeme parallel dieselben Daten verändern.

Abhängig vom Projekt kann ein zeitlich begrenzter Stopp notwendig sein für:

• Artikelpflege
• Preisänderungen
• Kategorieänderungen
• Kundenregistrierungen
• Bestellungen

Dauer und Umfang sollten so klein wie möglich bleiben und vorab mit allen Beteiligten abgestimmt werden.

Den Go-live als eigenes Projekt planen

Der Domainwechsel ist nur ein Teil des eigentlichen Umschaltprozesses.

Ein Go-live-Plan kann enthalten:

1. abschließendes Backup von OXID
2. letzter Datenexport
3. Delta-Import in JTL-Wawi
4. Shopabgleich
5. Aktivierung von Zahlungs- und Versanddiensten
6. Einspielen der Weiterleitungen
7. Domain- oder DNS-Umschaltung
8. vollständige Testbestellung
9. Kontrolle von Protokollen und Schnittstellen

Der allgemeine Projektablauf zeigt, wie Analyse, Umsetzung, Test und Go-live miteinander verbunden werden.

Rückfallplan vorbereiten

Vor dem Wechsel muss feststehen, wie bei einem kritischen Problem reagiert wird.

Benötigt werden:

• vollständige Sicherung des OXID-Shops
• Sicherung der neuen JTL-Umgebung
• Dokumentation der DNS- und Serveränderungen
• Verantwortliche Ansprechpartner
• Entscheidungskriterien für einen Rückfall
• Umgang mit zwischenzeitlich eingegangenen Bestellungen

Ein Rückfall ist nach bereits erfolgten Bestellungen nicht nur eine technische, sondern auch eine operative Entscheidung.

Vollständige Testbestellungen durchführen

Vor und unmittelbar nach dem Go-live müssen reale Bestellabläufe geprüft werden.

Testfälle sollten umfassen:

• Gastbestellung
• registrierter Kunde
• Privat- und Geschäftskunde
• verschiedene Zahlungsarten
• verschiedene Versandarten
• Inlands- und Auslandsbestellung
• Gutschein oder Rabatt
• Variantenartikel
• Bestellübernahme in JTL-Wawi
• Zahlungs- und Versandstatus

E-Mails und Dokumente kontrollieren

Ein technisch abgeschlossener Auftrag kann weiterhin fehlerhafte Kommunikation erzeugen.

Geprüft werden sollten:

• Bestellbestätigung
• Zahlungsinformation
• Versandbestätigung
• Absender und SMTP-Einstellungen
• Links in den E-Mails
• mehrsprachige Vorlagen
• Rechnungen und weitere Belege

Nach dem Go-live engmaschig kontrollieren

Die ersten realen Bestellungen und Suchmaschinenzugriffe benötigen besondere Aufmerksamkeit.

Kontrolliert werden sollten:

• Bestelleingang in JTL-Wawi
• Zahlungsstatus
• Versandberechnung
• Fehlerprotokolle
• 404-Aufrufe
• Weiterleitungen
• Indexierung
• Performance
• Kundenanfragen
• Bestandsabgleich

Eine laufende technische Betreuung kann über JTL-Support und Betreuung organisiert werden.

404-Fehler nach der Migration auswerten

Trotz sorgfältiger URL-Liste können weitere alte Pfade aufgerufen werden.

Ursachen sind beispielsweise:

• alte externe Links
• historische Produkt-URLs
• Links aus Newslettern
• nicht erfasste Sprachversionen
• alte Bild- oder Downloadpfade
• interne OXID-Verlinkungen

Relevante Fehler sollten nachträglich mit passenden Weiterleitungen geschlossen werden.

SEO-Entwicklung nach dem Wechsel beobachten

Sichtbarkeit und Indexierung können sich nach einer Migration vorübergehend verändern.

Beobachtet werden sollten:

• indexierte Seiten
• 404-Fehler
• Weiterleitungsprobleme
• Ranking wichtiger Kategorien und Produkte
• organische Zugriffe
• Canonical- und Sitemap-Fehler
• ausgeschlossene Seiten

Nicht jede kurzfristige Schwankung bedeutet einen dauerhaften Verlust. Technische Fehler und falsche Zuordnungen müssen jedoch schnell erkannt werden.

Den alten OXID-Shop nicht sofort löschen

Das bisherige System bleibt nach dem Go-live eine wichtige Referenz.

Es kann benötigt werden für:

• historische Bestellungen
• alte Rechnungen und Belege
• Vergleich von Produktdaten
• Nachweis früherer Inhalte
• fehlende Bilder oder Downloads
• Support- und Reklamationsfälle

Der alte Shop kann zunächst geschützt und nicht öffentlich erreichbar archiviert werden.

Typische Fehler bei einer OXID-zu-JTL-Migration

Viele Probleme entstehen durch eine zu enge Betrachtung des Projekts als reinen Artikeldatenimport.

Eine sinnvolle Reihenfolge für den Wechsel

Die Migration wird sicherer, wenn Daten, Technik und Prozesse schrittweise vorbereitet werden.

Welche Unterlagen für eine erste Migrationsanalyse benötigt werden

Eine belastbare Einschätzung benötigt technische und fachliche Informationen.

Hilfreich sind:

• OXID-Version
• Datenbankzugriff oder vollständiger Datenbankexport
• FTP- oder Serverzugriff für Bilder
• Liste installierter Module
• Anzahl Artikel und Varianten
• Anzahl Kategorien
• gewünschter Umfang von Kunden und Bestellungen
• aktive Sprachen und Währungen
• Versand- und Zahlungsarten
• Liste der bestehenden Domains und URLs
• geplante JTL-Komponenten

Wie Faymax Consulting eine OXID-Migration umsetzt

Faymax Consulting betrachtet Datenmigration, JTL-Aufbau, Prozesse und SEO als zusammenhängendes Projekt.

Die Leistungen können umfassen:

• Analyse von OXID-Datenbank und Dateistruktur
• Bestandsaufnahme von Artikeln, Kategorien und Varianten
• Bereinigung und Aufbereitung der Produktdaten
• Planung der JTL-Wawi-Struktur
• Import von Artikeln, Preisen und Merkmalen
• Übernahme und Zuordnung von Bildern
• Einrichtung von JTL-Shop und Shopabgleich
• Aufbau von Versand- und Zahlungsarten
• Erstellung und Prüfung von Weiterleitungen
• Testbestellungen und Go-live-Begleitung
• Kontrolle nach dem Systemwechsel

Bestehende OXID-Sonderfunktionen werden einzeln bewertet. Nur tatsächlich benötigte Prozesse werden im neuen System über Standardfunktionen, vorhandene Plugins oder individuelle Erweiterungen nachgebildet.

Weitere Informationen zu unterstützten Shopsystemen finden Sie unter Shopsysteme.

Häufige Fragen zum Wechsel von OXID zu JTL-Shop