Eine ERP-Datenmigration im E-Commerce ist Operation am offenen Herzen: Während Daten umziehen, läuft das Tagesgeschäft 24/7 weiter. Dieser Guide zeigt, welche Daten kritisch sind, wie der Ablauf in sechs Phasen funktioniert, welche Strategie wann passt und wie Sie die teuersten Fehler vermeiden.
Ein ERP-Wechsel greift tief in die Geschäftsprozesse eines Onlinehändlers ein und erfordert höchste Präzision. Während im Hintergrund Datenbanken umziehen, Mapping-Tabellen geschrieben und Schnittstellen neu verknüpft werden, läuft das Tagesgeschäft strikt weiter. Bestellungen kommen über den Onlineshop herein, Amazon fordert taktende Bestandsupdates, und im Lager warten Retouren auf ihre Verbuchung. In diesem 24/7-Umfeld ist die ERP Datenmigration weit mehr als ein technischer IT-Prozess. Sie ist das Fundament, auf dem Ihr zukünftiges Wachstum steht.
Ein fehlerhafter Datenimport führt im E-Commerce unmittelbar zu Überverkäufen, stornierten Aufträgen und schlechten Marktplatz-Rankings. Wer historische Retourenquoten oder komplexe Variantenstrukturen verliert, startet im neuen System effektiv bei null. Als erfahrene Plattform für den Multichannel-Vertrieb weiß PlentyONE: Eine gut geplante Migration schützt Ihr laufendes Geschäft und macht Ihre Dateninfrastruktur fit für die Skalierung.
Eine ERP-Datenmigration ist im Kern der systematische Prozess, bei dem Unternehmensdaten aus einem oder mehreren Altsystemen (Legacy-Systemen) extrahiert, bereinigt, transformiert und in ein neues Enterprise-Resource-Planning-System geladen werden. Sie stellt sicher, dass das neue System vom ersten Tag des Produktivbetriebs an mit verlässlichen, korrekten und vollständigen Informationen arbeitet. Im E-Commerce umfasst dies neben klassischen Finanz- und Stammdaten zwingend auch kanalspezifische Informationen wie Marktplatz-Listings, Multichannel-Bestände und laufende Fulfillment-Prozesse.
Oft werden Begriffe in diesem Kontext synonym verwendet, obwohl sie unterschiedliche Phasen beschreiben. Die ERP-Migration bezeichnet das gesamte Projekt, von der Softwareauswahl über die Prozessneugestaltung bis zum Go-Live. Die ERP-Datenmigration (oder Datenübernahme ERP-System) ist ein spezifisches, hochkritisches Teilprojekt innerhalb dieses Rahmens. Die reine ERP Altdaten Übernahme bezieht sich oft nur auf das Archivieren historischer Datensätze, die für Compliance-Gründe aufbewahrt, aber operativ nicht mehr genutzt werden.
Warum ist dieser Vorgang im Onlinehandel so viel komplexer als in der klassischen Fertigungsindustrie?
Ein produzierendes Unternehmen hat oft feste Lieferanten, überschaubare Kundenstämme und planbare Produktionszyklen. Im Multichannel-E-Commerce hingegen ändern sich Daten im Millisekundentakt. Wenn Sie ein neues ERP-System einführen, müssen Sie sicherstellen, dass ein Artikel, der auf Amazon, eBay, Zalando und im eigenen Shop verkauft wird, exakt über alle Kanäle hinweg gemappt ist. Die Bestände müssen über verschiedene Lagerorte (inklusive FBA oder externen 3PL-Dienstleistern) synchronisiert werden.
Zudem spielen steuerrechtliche Logiken eine enorme Rolle. Die korrekte Übernahme von OSS- (One-Stop-Shop) und IOSS-Steuerregeln für den grenzüberschreitenden Versand entscheidet darüber, ob Ihre Rechnungen im neuen System rechtskonform erstellt werden. Die ERP-Datenmigration ist daher keine reine IT-Aufgabe, sondern erfordert tiefes operatives Verständnis für E-Commerce-Prozesse.
Es ist Black Friday. Ihr neues ERP-System ist seit zwei Tagen live. Plötzlich stellen Sie fest, dass die Varianten-Bilder für Ihren Bestseller auf OTTO fehlen und die Versandregeln für Sperrgut nicht greifen. Solche Szenarien entstehen, wenn bei der Datenmigration nicht alle E-Commerce-spezifischen Datenkategorien berücksichtigt wurden.
Die zu migrierenden Daten lassen sich grob in fünf Kategorien einteilen. Im Onlinehandel weisen diese spezifische Ausprägungen auf, die bei der Planung zwingend beachtet werden müssen.
Datenkategorie |
Beispiele im Multichannel-Handel |
Typisches Volumen |
Migrationspriorität |
|---|---|---|---|
Stammdaten |
Artikel (inkl. Varianten, EAN, Attribute), Kunden (B2C/B2B), Lieferanten, Kontenplan |
10.000–500.000 Datensätze |
Kritisch (Muss) |
Transaktionsdaten |
Offene Bestellungen, schwebende Retouren, unbezahlte Rechnungen |
50.000–5.000.000 Datensätze |
Kritisch (Muss) |
Konfigurationsdaten |
Steuerkennzeichen (OSS/IOSS), Versandprofile, Zahlungsbedingungen |
100–5.000 Einstellungen |
Kritisch (Muss) |
Historische Daten |
Abgeschlossene Aufträge der letzten 3 Jahre, alte Hauptbucheinträge |
1 Mio.–100 Mio. Datensätze |
Optional / Selektiv |
Unstrukturierte Daten |
Produktbilder, PIM-Medien, PDF-Rechnungen, Kundenservice-Notizen |
10.000–1 Mio. Dateien |
Selektiv |
Die Artikelstammdaten sind das Herzstück. Hier reicht es nicht, nur Artikelnummer und Preis zu übertragen. Ein modernes System benötigt Parent-Child-Beziehungen für Varianten (z. B. T-Shirt in Farbe/Größe), ausführliche Produktbeschreibungen in mehreren Sprachen, Größentabellen, Zolltarifnummern und Attribute. Auch die Kundenstammdaten bergen Tücken. Ein B2B-Kunde hat oft abweichende Rechnungs- und dutzende Lieferadressen, die präzise in die neue Warenwirtschaft überführt werden müssen.
Wenn Sie Bestandsdaten in das neue ERP übertragen, müssen die physischen Bestände exakt abgebildet werden. Bestand pro Lager, pro Lagerort (Regal/Fach), pro Charge und Mindesthaltbarkeitsdatum (MHD). Reservierte Bestände für bereits eingegangene, aber noch nicht versendete Aufträge müssen bei der Migration sauber von frei verfügbaren Beständen getrennt werden, um Überverkäufe auf den Marktplätzen zu verhindern.
Dies ist der häufigste Stolperstein für Onlinehändler. Jeder Marktplatz nutzt eigene Identifikatoren. Amazon nutzt die ASIN, eBay die ItemID, Kaufland eigene Listing-IDs. Wenn Sie diese Verknüpfungen (Mappings) nicht in das neue ERP-System migrieren, verliert das System die Verbindung zu den aktiven Angeboten. Bestände werden nicht aktualisiert, und eintreffende Bestellungen können keinem Artikel zugeordnet werden.
Der Cutover-Zeitpunkt schneidet mitten durch laufende Prozesse. Eine Bestellung wurde bezahlt, aber noch nicht versandt. Eine andere wurde teilgeliefert. Ein Kunde hat eine RMA (Return Merchandise Authorization) angefordert, das Paket ist aber noch auf dem Postweg. Diese „fliegenden" Transaktionsdaten müssen mit ihrem exakten Status migriert werden. Gleichzeitig müssen die Referenznummern der Payment-Provider (PayPal, Klarna, Stripe) erhalten bleiben, damit spätere Rückerstattungen (Refunds) im neuen System technisch noch durchgeführt werden können.
Damit eine Migration gelingt, braucht es einen strukturierten Prozess, der keinen Raum für Zufälle lässt. Besonders im E-Commerce, wo Stillstand direkten Umsatzverlust bedeutet, muss der Ablauf minutiös geplant werden. Der Standard-Prozess gliedert sich in sechs aufeinanderfolgende Phasen.
Phase |
Beschreibung der Aktivität |
Typische Dauer |
|---|---|---|
1. Analyse & Bewertung |
Sichtung der Altdaten, Definition des Scopes (Was wird migriert?), Identifikation von Datenmüll. |
4–8 Wochen |
2. Datenbereinigung |
Deduplizierung, Korrektur fehlerhafter Datensätze im Altsystem. |
8–16 Wochen |
3. Mapping & ETL |
Definition der Zielfelder, Aufbau der Extract-Transform-Load-(ETL)-Pipelines. |
6–12 Wochen |
4. Test-Migrationen |
Iterative Probeläufe (meist 4–6 Zyklen) in einer Staging-Umgebung. |
8–12 Wochen |
5. Cutover & Go-Live |
Der eigentliche Wechsel am Stichtag inklusive Shop-Freeze und Delta-Import. |
1–3 Tage (Wochenende) |
6. Hypercare |
Intensive Überwachung, Reconciliation (Abgleich) und Fehlerbehebung nach dem Live-Gang. |
4–8 Wochen |
Bevor Sie Daten in das neue ERP übertragen, müssen Sie wissen, was Sie besitzen. Welche Datenstrukturen erfordern die Marktplatz-Integrationen? Welche historischen Daten werden wirklich noch operativ benötigt, und welche können in ein Data Warehouse archiviert werden?
Die Regel lautet: Nehmen Sie keinen Ballast mit.
Dies ist die arbeitsintensivste Phase. Dubletten bei Kundenadressen müssen zusammengeführt, fehlende EANs ergänzt und veraltete Artikel auf inaktiv gesetzt werden. Laut Branchenstudien benötigen 20 bis 40 Prozent der Stammdaten vor einer Migration eine Bereinigung. Tun Sie dies zwingend im alten System, bevor der Export beginnt.
ETL steht für Extract, Transform, Load. Hier wird definiert, welches Feld aus dem Altsystem in welches Feld des neuen ERPs fließt. Ein klassisches Problem im E-Commerce. Das alte System hatte nur ein Feld für „Straße und Hausnummer", das neue System erfordert getrennte Felder für die Versandlogistik (DHL, DPD). Solche Transformationen werden in dieser Phase programmiert.
Man testet nicht am offenen Herzen. In der Regel werden 4 bis 6 Probeläufe in einer gesicherten Sandbox-Umgebung durchgeführt. Hier prüfen die Key-User aus dem Kundenservice, Lager und Buchhaltung, ob die migrierten Daten für ihre täglichen Prozesse ausreichen. Stimmen die Eröffnungssalden? Sind die Stücklisten für Bundles korrekt angelegt?
Der kritische Moment. Im 24/7-Onlinehandel gibt es keinen echten Feierabend. Daher wird meist ein Wochenende gewählt. Es wird ein „Freeze" verhängt: Keine Artikeländerungen mehr, keine neuen Marktplatz-Listings. Die Systeme werden gestoppt, die finalen Delta-Daten (die letzten Bestellungen der letzten Stunden) werden migriert, die API-Verbindungen zu Amazon und Co. werden vom alten auf das neue System umgeschaltet.
Nach dem Go-Live beginnt die Hypercare-Phase. Ein dediziertes Team überwacht die ersten Zahlungseingänge, die ersten Pick- & Pack-Prozesse im Lager und den ersten DATEV-Export. Bei der Reconciliation (dem Abgleich) wird final verifiziert. Entspricht die Summe der offenen Posten im neuen System exakt der Summe aus dem Altsystem?
Während traditionelle ERP-Anbieter in der Fertigung oft auf jahrelange Phasen-Modelle setzen, ticken die Uhren im digitalen Handel anders. Die Wahl der richtigen Migrationsstrategie hängt massiv von Ihrem Bestellvolumen, der Anzahl Ihrer Vertriebskanäle und Ihrer Risikobereitschaft ab.
Strategie |
Funktionsweise |
Vorteile |
Nachteile |
Eignung im E-Commerce |
|---|---|---|---|---|
Big Bang |
Kompletter Wechsel aller Module und Daten an einem einzigen Stichtag. |
Klarer Schnitt, keine doppelten Schnittstellenkosten, schnelles ROI. |
Hohes Risiko bei Ausfällen, enormer Druck am Cutover-Wochenende. |
Ideal für Single-Brand-Händler oder KMU mit überschaubarer Komplexität. |
Phased (Phasenweise) |
Migration nach Modulen (z. B. erst PIM, dann WMS, dann FiBu) oder nach Ländern/Brands. |
Kontrollierbares Risiko, Lerneffekte von Phase zu Phase. |
Monatelanger Aufbau temporärer Schnittstellen zwischen Alt- und Neusystem. |
Gut für Enterprise-Händler mit mehreren getrennten Marken oder Ländershops. |
Parallelbetrieb |
Beide Systeme laufen wochenlang zeitgleich, alle Daten werden doppelt gepflegt. |
Maximale Sicherheit, ständiger Soll-Ist-Abgleich möglich. |
Doppelte Datenpflege, hohe Kosten; im E-Commerce aufgrund von Echtzeit-Beständen fast unmöglich. |
Nur für extrem regulierte Branchen (z. B. Pharma); im E-Commerce unüblich. |
Hybrid |
Stammdaten werden frühzeitig migriert, Transaktionsdaten folgen per Big Bang. |
Verbindet Sicherheit mit Praktikabilität. |
Erfordert exaktes Timing beim Einfrieren der Stammdaten. |
Der De-facto-Standard für den gehobenen DACH-Mittelstand. |
Für Multichannel-Händler scheidet ein echter Parallelbetrieb meist aus. Wenn eine Bestellung über OTTO eingeht, müsste der Bestand in beiden Systemen in Echtzeit gesenkt werden, um Überverkäufe zu vermeiden. Das erfordert eine Synchronisation zwischen Alt- und Neusystem, die technisch extrem fehleranfällig ist.
Daher setzen die meisten E-Commerce-Unternehmen auf einen hybriden Big-Bang-Ansatz. Die Artikel-, Lieferanten- und Kundenstammdaten werden Wochen vor dem Go-Live migriert und kontinuierlich über Delta-Updates synchron gehalten. Am eigentlichen Cutover-Wochenende werden dann „nur" noch die Bestände, offenen Aufträge und aktuellen Salden übertragen. Das minimiert die Downtime des Onlineshops auf wenige Stunden.
Laut einer Studie verfehlen 50 bis 70 Prozent aller ERP-Migrationen ihre ursprünglichen Budget- oder Zeitziele. Der Hauptgrund ist fast nie die Software selbst, sondern der fehlerhafte Umgang mit den historischen und operativen Daten. Wenn Sie eine Datenübernahme in ein neues ERP planen, sollten Sie folgende Fehler zwingend vermeiden:
Faustregel zur Datenqualität: Die Qualität Ihrer Stammdaten verantwortet 30 bis 50 Prozent des gesamten Projektaufwands. Beginnen Sie mit der Datenqualitätsbewertung mindestens 6 bis 12 Wochen bevor das eigentliche Implementierungsprojekt startet.
Ein Modehändler aus München mit 12.000 SKUs und drei angebundenen Marktplätzen stand vor der Herausforderung, sein Altsystem abzulösen. Durch eine strikte Methodik gelang der Wechsel ohne eine einzige stornierte Bestellung. Die folgenden Best Practices aus der operativen E-Commerce-Praxis machen den Unterschied zwischen einer holprigen und einer lautlosen Migration.
Daten brauchen Verantwortliche. Definieren Sie für jede Datenkategorie einen „Data Owner". Der Head of E-Commerce verantwortet die PIM-Daten (Bilder, Texte, Attribute), der Head of Finance die Debitoren/Kreditoren, der Warehouse Manager die Lagerplätze. Nur diese Personen dürfen in der Vorbereitungsphase Freigaben für das Mapping erteilen.
Migrieren Sie niemals direkt von Datenbank A nach Datenbank B. Nutzen Sie eine Staging-Area (einen Zwischenspeicher). Hier werden die rohen CSV- oder SQL-Exporte aus dem Altsystem abgelegt, per Skript transformiert und erst dann in das neue ERP-System via REST API importiert. Das schützt das Zielsystem vor korrupten Datensätzen.
Vertrauen ist gut, Kontrolle ist Pflicht. Eröffnungssalden müssen auf den Cent genau stimmen. Bauen Sie automatisierte Abgleich-Routinen. Wenn das alte System 1.452 offene Bestellungen mit einem Warenwert von 84.500 Euro ausweist, muss das neue System exakt diese Zahlen nach dem Import widerspiegeln.
Das ERP fungiert im E-Commerce als zentraler Knotenpunkt für Daten, Prozesse und Systemintegrationen. Die Migration der Daten muss Hand in Hand mit dem Umschalten der Schnittstellen gehen.
Ein Cutover-Wochenende erfordert oft 60 bis 120 Stunden Schichtarbeit des IT- und Operations-Teams. Definieren Sie klare Meilensteine. Wenn am Sonntag um 14:00 Uhr die Bestandsmigration fehlschlägt, muss die Entscheidung fallen. Fixen wir das Problem oder rollen wir das Backup zurück und starten am Montag wieder mit dem Altsystem? Ein harter Schnitt rettet im Zweifel das Tagesgeschäft.
[Jetzt kostenlose Demo buchen]
Die Anforderungen an Datenqualität haben sich in den letzten Jahren drastisch erhöht. Marktplätze strafen Händler für fehlerhafte Produktdaten sofort ab. Dementsprechend ist die ERP-Datenmigration kein Wochenendprojekt mehr. Ein komplettes ERP-Projekt im Mittelstand dauert von der Initiierung bis zum stabilen Betrieb realistisch betrachtet 18 bis 36 Monate. Die Datenmigration als Teilprojekt nimmt davon je nach Komplexität zwei bis vierzehn Monate ein.
Budget-Überschreitungen sind in der Branche keine Seltenheit, in Einzelfällen erreichen sie sogar das Mehrfache des ursprünglich geplanten Budgets. Sie entstehen fast immer, weil die Aufwände für die Datenbereinigung (Data Cleansing) vorab nicht budgetiert wurden.
Unternehmensgröße (E-Commerce) |
GMV / Bestellvolumen |
Dauer der Datenmigration (Phase 1–6) |
Typische Kosten (nur Daten-Stream) |
|---|---|---|---|
SMB (Kleinunternehmen) |
< 3 Mio. € / < 500 Orders pro Tag |
2–4 Monate |
10.000 € – 25.000 € |
Mid-Market (Mittelstand) |
3–15 Mio. € / bis 2.000 Orders pro Tag |
4–8 Monate |
30.000 € – 80.000 € |
Enterprise (Großhändler) |
> 15 Mio. € / Multichannel international |
6–14 Monate |
100.000 € – 250.000 €+ |
Hinweis: Diese Kosten umfassen interne Personalaufwände, externe Berater, ETL-Tools und eventuelle Agenturleistungen speziell für den Daten-Stream, nicht die gesamten ERP-Lizenzkosten.
Allein die externe Unterstützung für eine professionelle Datenbereinigung schlägt oft mit 15.000 bis 40.000 Euro zu Buche. Doch dieses Geld ist hervorragend investiert. Bedenken Sie: Unternehmen wechseln im Schnitt nur alle 10 Jahre ihr ERP-System. Die Daten, die Sie heute bereinigen, bilden das Fundament für Ihre Umsätze der nächsten Dekade.
Multichannel-Handel funktioniert dann verlässlich, wenn alle Kanäle aus einer einzigen Datenquelle gespeist werden. Wenn Sie von einem fragmentierten Setup (z. B. getrenntes PIM, WMS und CRM) oder einem veralteten Legacy-System auf PlentyONE wechseln, profitieren Sie von einer Architektur, die nativ für den E-Commerce entwickelt wurde.
Als umfassende Plattform für Multichannel-Seller bietet PlentyONE spezifische Werkzeuge, um die Altdaten-Übernahme sicher und effizient zu gestalten:
Mit PlentyONE entscheiden Sie sich nicht nur für eine Software, sondern für einen operativen Partner, der versteht, dass im E-Commerce jede Sekunde zählt.
Schlechte Datenqualität ist das größte Risiko bei jedem Systemwechsel. Ein neues, noch so leistungsstarkes ERP-System kann seine Stärken nicht ausspielen, wenn es mit unvollständigen Artikelstammdaten, fehlerhaften Marktplatz-Mappings oder abweichenden Beständen gefüttert wird. Die ERP-Datenmigration ist daher keine lästige IT-Pflichtaufgabe, sondern eine strategische Chance. Sie zwingt Sie dazu, Altlasten über Bord zu werfen, Prozesse zu hinterfragen und eine saubere Datenbasis für künftiges Wachstum im Multichannel-Handel zu schaffen. Wer hier Zeit und Budget intelligent investiert, schützt sein Tagesgeschäft und sichert sich einen reibungslosen Go-Live.
[Jetzt PlentyONE kostenlos testen oder eine persönliche Demo buchen]
Was passiert, wenn ein Kunde nach der Umstellung eine alte Rechnung anfordert? Solche operativen Fragen begegnen uns täglich. Hier finden Sie die Antworten auf die häufigsten Fragen rund um die Migration von ERP-Daten.
Eine ERP-Migration ist das ganzheitliche Projekt des Wechsels von einem alten auf ein neues Enterprise-Resource-Planning-System. Sie umfasst die Softwareauswahl, die Neugestaltung von Geschäftsprozessen, die Schulung der Mitarbeiter, die Einrichtung von Schnittstellen und schließlich den technischen Wechsel. Die Datenmigration ist dabei ein essenzielles Teilprojekt.
Darunter versteht man den technischen und prozessualen Vorgang, bei dem Unternehmensdaten (Stamm-, Bewegungs- und Konfigurationsdaten) aus einem Legacy-System exportiert, bereinigt, transformiert und in das neue ERP-System geladen werden. Ziel ist es, dass das neue System sofort mit validen Daten arbeitsfähig ist.
Der Prozess erfolgt klassischerweise über eine ETL-Strecke (Extract, Transform, Load). Daten werden exportiert (meist als CSV, XML oder via API), in einer Staging-Umgebung bereinigt und auf die Zielfelder des neuen Systems gemappt (Transform), bevor sie final importiert werden (Load). Im E-Commerce erfordert dies mehrere Testläufe und einen koordinierten Cutover.
ERP-Daten umfassen alle Informationen, die zur Steuerung eines Unternehmens nötig sind. Dazu gehören Stammdaten (Artikel, Kunden, Lieferanten), Transaktionsdaten (Bestellungen, Rechnungen, Retouren), Bestandsdaten (Lagerorte, Chargen) sowie Konfigurationsdaten (Steuerregeln, Zahlungsbedingungen).
Die reine Datenmigration dauert je nach Unternehmensgröße und Datenqualität zwischen 2 und 14 Monaten. Die kritischste und zeitaufwendigste Phase ist dabei die Datenbereinigung im Vorfeld, die oft 8 bis 16 Wochen in Anspruch nimmt, bevor der erste Test-Import überhaupt starten kann.
Die Kosten variieren stark nach Projektumfang. Kleine Händler sollten für den Daten-Stream (Bereinigung, Mapping, Import-Support) mit 10.000 bis 25.000 Euro rechnen. Im gehobenen Mittelstand liegen die Kosten für externe Dienstleister, Tools und Personalaufwand oft zwischen 30.000 und 80.000 Euro.