Het voorbereiden van historische bestelgegevens is een beslissende stap bij de migratie naar Shopware. Deze gids legt uit hoe wordt beoordeeld welke eerdere bestellingen moeten worden geïmporteerd en benadrukt beproefde werkwijzen, zoals het opnemen van de data van de laatste twee tot drie jaar, om de continuïteit van actieve klantrelaties en het analytische nut te waarborgen. solution25 laat zien hoe een zorgvuldige dataselectie en datavoorbereiding de operationele consistentie en business intelligence na de migratie ondersteunen.
Kostenlose 15-minütige Erstberatung direkt mit unseren Experten.
Deze gids maakt deel uit van ons overzicht Shopware-migratie: daar vindt u verloop, duur en kosten van een overstap naar Shopware 6 en alle overige gidsen.
In de snelle e-commerceomgeving van vandaag zijn data meer dan louter informatie: ze vormen de basis voor business intelligence, gepersonaliseerde gebruikerservaringen, klantenservice, belastingconformiteit en operationele continuïteit. Wanneer een bedrijf van het ene e-commerceplatform naar het andere overstapt, of het nu gaat om Shopware 5 naar Shopware 6, Magento naar Shopware, WooCommerce naar een maatwerkoplossing of een oud ERP-systeem, wordt het voorbereiden van de historische bestelgegevens een beslissende stap.
Historische bestellingen bevatten een schat aan transactionele inzichten: wie heeft wat wanneer gekocht, tegen welke prijs, vanuit welke regio, onder welke belastingcategorie en met welke kortingen of acties. Deze data zijn nauw verbonden met klantstamgegevens, magazijnbeheer, belastingrapporten, terugbetalingen, verzenddocumentatie en prestatieanalyses. Het verlies of de onjuiste weergave van deze informatie tijdens de migratie kan juridische problemen, ontevreden klanten, foutieve rapportages of zelfs boekhoudfouten veroorzaken.
Kortom: bestelhistorie is niet zomaar “oude data”, maar een essentieel onderdeel van het DNA van uw bedrijf.
Helaas zijn historische data vaak rommelig, inconsistent en verspreid over verschillende bronnen, zoals oude databases, csv-exports of ERP-koppelingen. Het voorbereiden van deze data voor de migratie vraagt om zorgvuldige planning, gestructureerde reiniging, toewijzing aan het schema van het nieuwe platform en validatie, om nog te zwijgen van naleving van de privacywetgeving en een mogelijke herstructurering om het Shopware 6-bestelmodel met meerdere entiteiten weer te geven.
Deze gids leidt u gestructureerd en praktisch door dit proces. Of u de migratie nu intern uitvoert of met een extern bureau werkt: met deze stappen verplaatst u niet alleen data, maar migreert u bruikbare, betrouwbare en regelconforme datasets.
Aan het einde van deze gids weet u:
Daarnaast behandelen we veelvoorkomende fouten, tips voor het omgaan met klantrelaties, terugbetalingen of gastbestellingen, en tools en scripts die delen van de workflow kunnen automatiseren.
Deze documentatie gaat ervan uit dat technische middelen beschikbaar zijn: ontwikkelaars, databasebeheerders of migratiepartners. Ze bevat echter ook contextuele aanwijzingen voor projectmanagers, e-commerceverantwoordelijken en rollen voor datagovernance, zodat zij het proces kunnen volgen.
We beginnen met te begrijpen waarom historische bestellingen zowel operationeel als strategisch belangrijk zijn.
Bij de planning van een migratie of een platformwissel overwegen veel bedrijven oude bestellingen om redenen van tijd of eenvoud niet over te nemen. Dat kan echter aanzienlijke lacunes veroorzaken in de bedrijfsvoering, de klantenservice en de bedrijfscontinuïteit op lange termijn. Historische bestellingen zijn niet alleen een logboek van eerdere activiteiten: ze vormen de basis voor financiële, juridische, analytische en klantgerichte processen.
Dit zijn de belangrijkste redenen waarom historische bestellingen moeten worden bewaard en correct geïmporteerd:
Overheden en belastingdiensten eisen in de meeste regio’s dat transactiedata meerdere jaren worden bewaard (doorgaans 5 tot 10 jaar, afhankelijk van de jurisdictie). Deze data kunnen worden gecontroleerd bij:
Het ontbreken van correcte en tijdige registraties kan leiden tot boetes of juridische problemen. Pdf’s of spreadsheetexports alleen volstaan vaak niet: geïntegreerde, doorzoekbare data zijn nodig voor geautomatiseerde controles.
Support- en verkoopteams hebben snel toegang nodig tot klanthistorie bij:
Zonder historische bestellingen in het nieuwe systeem moeten medewerkers tussen systemen schakelen of de it-afdeling om toegang tot oude data vragen. Dat bemoeilijkt de service voor medewerkers en klanten.
Stelt u zich voor dat u een trouwe klant moet zeggen: “Helaas hebben wij geen toegang meer tot uw eerdere bestellingen.” Dat schaadt het merkvertrouwen op een vermijdbare manier.
Historische bestellingen zijn de basis van moderne analyses, met name om te begrijpen:
Ontbreken historische bestellingen, dan ontstaan er lacunes in segmentatie en personalisatie in tools zoals Google Analytics, Metabase of BI-dashboards. Dat schaadt programma’s voor klantbinding, slimme aanbevelingen en marketingautomatisering.
Biedt u loyaliteitspunten, kortingen of exclusieve niveaus op basis van eerdere bestellingen, dan is de overname van historische aankopen onmisbaar. U moet:
Ontbrekende data kunnen leiden tot verontwaardigde vaste klanten en de waarde van uw programma verminderen.
Om te begrijpen welke producten in de loop der tijd goed lopen, hebt u historische verkoopdata nodig. Deze ondersteunen:
Bovendien zijn verkoopdata vaak gekoppeld aan SKU-prestatiebeoordelingen of leveranciersovereenkomsten: het verlies van deze historie kan toekomstige onderhandelingen en herbestellingen bemoeilijken.
Historische bestelgegevens stromen vaak naar de volgende systemen:
Zonder overname van de historie kunnen deze systemen uitvallen, inconsistent worden of onvolledige data tonen, met tijdrovende correcties of gedeeltelijke synchronisaties als gevolg.
Voordat de technische werkzaamheden beginnen, zoals data-export, scripts schrijven of bestanden formatteren, moet u de omvang van de historische bestellingen die u wilt migreren duidelijk definiëren. Deze fase is beslissend om de datakwaliteit te behouden, fouten te minimaliseren en onnodige inspanning door de import van irrelevante of inconsistente records te vermijden.
Niet alle historische data zijn even waardevol. Elke afzonderlijke transactie van de afgelopen 10 jaar migreren klinkt weliswaar grondig, maar leidt vaak tot opgeblazen databases, langere importtijden en complexere vervolgprocessen. Anderzijds kan een te geringe migratie leiden tot verlies van bedrijfscontext, defecte analyses of compliancelacunes.
Met de volgende filters moet u rekening houden bij het voorbereiden van de dataset:
Hoever moet de historie teruggaan?
Best practice: importeer minimaal de laatste 2 tot 3 jaar om actieve klantrelaties en basisanalyses te dekken. Oudere data kunnen worden gearchiveerd of in een alleen-lezenmodus worden bewaard.
Aandachtspunten:
Welke bestellingen moeten worden opgenomen?
Tip: richt u op bestellingen met geldige betaal- en leveringsgegevens. Geannuleerde of mislukte bestellingen moeten worden gearchiveerd, tenzij ze relevant zijn voor analyses of fraudedetectie.
Shopware 6 vereist voor elke bestelling een geldig order_customer-record. Als uw oude systeem gasten en geregistreerde klanten door elkaar gebruikt, moet u deze datastructuur vóór de import uniformeren.
Aanbeveling: migreer beide typen, maar maak onderscheid via klantgroepen of metadata.
Regionale verschillen in belastingen, verzending en betaalmethoden vragen vaak om segmentatie om de transformatiescripts te vereenvoudigen.
Voorbeeld: als u uw Shopware 6-webshop eerst alleen in Duitsland lanceert, kunt u oudere bestellingen uit de VS of het Verenigd Koninkrijk buiten beschouwing laten.
source_system, imported_at of import_batch_id voor latere naspeurbaarheid.Deze gestructureerde aanpak vergemakkelijkt terugzettingen, foutopsporing en het isoleren van problematische records bij tests.
Voordat de technische werkzaamheden beginnen, zoals data-export, scripts schrijven of bestanden formatteren, moet u de omvang van de historische bestellingen die u wilt migreren duidelijk definiëren. Deze fase is beslissend om de datakwaliteit te behouden, fouten te minimaliseren en onnodige inspanning door de import van irrelevante of inconsistente records te vermijden.
Niet alle historische data zijn even waardevol. Elke afzonderlijke transactie van de afgelopen 10 jaar migreren klinkt weliswaar grondig, maar leidt vaak tot opgeblazen databases, langere importtijden en complexere vervolgprocessen. Anderzijds kan een te geringe migratie leiden tot verlies van bedrijfscontext, defecte analyses of compliancelacunes.
Met de volgende filters moet u rekening houden bij het voorbereiden van de dataset:
| Dimensie | Vragen / opties | Opmerkingen / tips |
|---|---|---|
| Periode |
Laatste 6 maanden 1 jaar 3 jaar Alle beschikbare data |
Minimaal 2 tot 3 jaar aanbevolen. Oudere data archiveren of alleen-lezen bewaren. Let op de wettelijke bewaartermijnen. Afweging tussen datavolume en systeemprestaties. |
| Bestelsoorten |
Afgeronde bestellingen Geannuleerde of mislukte transacties Terugbetaalde bestellingen Verlaten winkelwagens of voorbestellingen |
Focus op geldige betaal- en leveringsgegevens. Archivering van geannuleerde bestellingen, behalve wanneer relevant voor analyse. |
| Klanttypen |
Gastbestellingen Geregistreerde klanten Mogelijke vertekening door anonieme bestellingen |
Shopware 6 vereist een geldig order_customer-record.Uniforme datastructuur vóór de import vereist. Aanbeveling: beide typen migreren, maar onderscheiden. |
| Geografische filters |
Binnenlandse bestellingen Internationale bestellingen B2B of B2C Meertalige / multivalutabestellingen |
Let op verschillen in belasting, verzending en betaling. Segmentatie vereenvoudigt scripts. Voorbeeld: aanvankelijk focus op Duitsland. |
source_system, imported_at of import_batch_id voor latere naspeurbaarheid.Deze gestructureerde aanpak vergemakkelijkt terugzettingen, foutopsporing en het isoleren van problematische records bij tests.
s_order, s_order_details, s_user en s_order_documents.SELECT o.id, o.ordernumber, o.invoice_amount, u.email, d.articleID, d.quantity
FROM s_order o
JOIN s_order_details d ON o.id = d.orderID
JOIN s_user u ON o.userID = u.id;
sales_order, sales_order_item, customer_entity en andere raadplegen.wp_posts, wp_postmeta en wp_woocommerce_order_items.| Type | Beschrijving |
|---|---|
| Bestelkoppen | Bestel-ID, status, totalen, valuta, datum, verkoopkanaal |
| Orderregels | Product-ID’s/SKU’s, aantal, eenheidsprijs, belastingtarief, korting |
| Klanten | Naam, e-mailadres, klantgroep, factuur-/leveringsadres |
| Verzending | Methode, trackingnummer, vervoerder, leveringsdatum |
| Transacties | Betaalmethode, transactie-ID, status, terugbetaald bedrag |
| Facturen | Factuurnummer, factuurdatum, pdf-referentie (indien aanwezig) |
Optioneel, maar nuttig:
Na het exporteren van de ruwe data volgt als volgende stap de reiniging en validatie, voordat u de data aan het Shopware 6-schema toewijst. Daar gaat het volgende onderdeel over.
De export van uw historische bestelgegevens is slechts het begin: wat u nu hebt, is vaak rommelig, onvolledig of inconsistent gestructureerd. Het reinigen en valideren van deze data is beslissend om importfouten te vermijden, dataverlies te voorkomen en op lange termijn nauwkeurigheid in uw rapporten in het nieuwe Shopware 6-systeem te waarborgen.
Als uw data niet goed zijn gereinigd, dreigen:
De meeste exports, vooral uit oudere of eigen systemen, bevatten problemen zoals:
order_id + datum + email.order_items en orders de 1:n-integriteit. Alle “verweesde” bestellingen moeten worden gemarkeerd.anonymous@example.com voor gasten).| Tool | Toepassing |
|---|---|
| Excel / LibreOffice | Visuele herkenning van duplicaten, nulwaarden, opmaak |
| Python (Pandas) | Automatisering van transformaties, validaties |
| PHP- of Node.js-scripts | Verwerking van grote JSON-/csv-datasets |
| Shopware API-testtools | Controle van de importacceptatie (Postman, cURL) |
| OpenRefine | Diepgaande datareiniging en tekstclustering |
Bewaar altijd:
Dat maakt naspeurbaarheid, terugzetting en foutherstel mogelijk als er na de deployment problemen optreden.
Nadat uw historische bestelgegevens zijn gereinigd en gevalideerd, moeten ze zo worden gestructureerd dat ze overeenkomen met het schema van het doelplatform, in dit geval Shopware 6. In tegenstelling tot oude systemen, die vaak op monolithische tabellen zijn gebaseerd, gebruikt Shopware 6 een modulaire, op entiteiten gebaseerde architectuur voor bestellingen. Die modulariteit biedt grote flexibiliteit en schaalbaarheid, maar betekent ook dat uw importbestanden zich moeten houden aan strikte relationele regels en entiteitsscheiding.
| Entiteit | Doel |
|---|---|
| order | Hoofdbestelling met totalen, status en metadata |
| order_line_item | Afzonderlijke producten of aangepaste orderregels |
| order_customer | Klantsnapshot op het moment van de bestelling |
| order_transaction | Betalingsinformatie (methode, status, transactie-ID) |
| order_delivery | Verzendgegevens, tracking en verzendmethode |
| order_address | Factuur- en leveringsadressen bij de bestelling |
order_id of order_number.order_line_item.csv kan het volgende bevatten:
| order_id | product_id | label | quantity | total_price |
|---|---|---|---|---|
| abc123 | prod567 | Blue T-Shirt | 2 | 39,98 |
order_customer.csv kan het volgende bevatten:
| order_id | first_name | last_name | customer_number | |
|---|---|---|---|---|
| abc123 | john@example.com | John | Doe | CUST-001 |
Als u de Sync API of Admin API gebruikt, moet de payload voor elke bestelling er ongeveer als volgt uitzien (vereenvoudigd):
{
"order": {
"orderNumber": "10001",
"salesChannelId": "...",
"currencyId": "...",
"orderCustomer": { ... },
"transactions": [ ... ],
"deliveries": [ ... ],
"lineItems": [ ... ],
"addresses": [ ... ]
}
}
Door uw data correct in afzonderlijke, relationele entiteiten te structureren, legt u de basis voor een naadloze import in Shopware 6. Zo blijven alle relaties behouden en werken rapportage- en klantenserviceprocessen zoals verwacht.
Veldnamen en datatypen kunnen per systeem verschillen. Maak een toewijzingstabel zoals deze:
| Oud veld (Magento) | Nieuw veld (Shopware) | Transformatieopmerkingen |
|---|---|---|
| customer_email | order_customer.email | Converteren naar kleine letters |
| status | order.state_id | Shopware-state-UUID’s gebruiken |
| shipping_address | order_address | Structuur afvlakken indien genest |
Het louter migreren van ruwe bestelgegevens is vaak niet genoeg om de operationele waarde die uw bedrijf in de loop der tijd heeft opgebouwd volledig te behouden. Bestellingen bestaan niet geïsoleerd: ze zijn ingebed in grotere bedrijfsprocessen, marketingstrategieën en customer journeys. Om het nut van uw historische bestelgegevens te maximaliseren, kunt u ze verrijken met contextuele informatie die slimmere beslissingen en een soepele bedrijfscontinuïteit na de migratie ondersteunt.
utm_source, utm_medium, utm_campaign). Zo kunt u de historische marketingeffectiviteit ook na de migratie analyseren.Door deze contextuele lagen in uw migratie van historische bestelgegevens op te nemen, zorgt u ervoor dat Shopware 6 niet alleen uw data opslaat, maar ook de benodigde business intelligence en operationele inzichten biedt voor duurzaam succes na de migratie.
De migratie van historische bestelgegevens gaat niet alleen over de bestellingen zelf: het is even belangrijk de klantgegevens correct te verwerken. Shopware 6 dwingt een strikte relatie af tussen bestellingen en klanten: elke bestelling moet aan een geldige order_customer-entiteit zijn gekoppeld. Dit levert bijzondere uitdagingen op wanneer zowel geregistreerde klantaccounts als gastbestellingen moeten worden meegenomen.
Beslis of u:
Dit kan afzonderlijke API-endpoints of datalagen vereisen. Sommige webshops importeren bestellingen ter vereenvoudiging zonder deze data; anderen beschouwen ze als kritiek.
order_customer-entiteit is gekoppeld, ook bij gastbestellingen.Deze klanten dienen alleen als referentie voor de bestelling.
order_customer-referenties. Ontbrekende of foutieve klantkoppelingen leiden tot een importfout.Een zorgvuldige afhandeling van klantaccounts en gastbestellingen garandeert dat uw historische bestellingen in Shopware 6 doorzoekbaar, gekoppeld en bruikbaar blijven, zowel in de backend als in de Storefront. Zo blijven zowel operationele processen als klantervaringen behouden.
De import van historische bestelgegevens is een complex proces met veel afhankelijkheden en relaties. De volledige dataset in één keer importeren is riskant en kan leiden tot moeilijk te diagnosticeren fouten, datacorruptie of systeeminstabiliteit.
Om deze risico’s te minimaliseren, is een rigoureuze test- en validatiefase onmisbaar. Dit onderdeel leidt u door beproefde werkwijzen voor incrementeel testen en het controleren van de geïmporteerde bestelgegevens in Shopware 6.
Behandel fouten een voor een en corrigeer data of importlogica.
Start de volledige import pas wanneer testimports foutloos zijn en de datakwaliteit is bevestigd. Zo zorgt u voor een soepele eindimport met minimale verstoringen.
Historische bestelgegevens bevatten gevoelige informatie zoals:
Zorg ervoor dat:
Aanbevolen tools:
Voorbeeld: een Python-script voor het omzetten van WooCommerce-bestellingen naar het Shopware-formaat.
Vraag: wat gebeurt er als ik bestellingen niet importeer?
Antwoord: u verliest klanthistorie en diepgang in rapporten, en loopt juridische risico’s bij de belastingdocumentatie.
Vraag: kan ik bestellingen zonder producten importeren?
Antwoord: nee. Shopware vereist geldige productreferenties (SKU’s, ID’s of UUID’s).
Vraag: wat als sommige velden ontbreken of onbekend zijn?
Antwoord: gebruik placeholderwaarden of standaarddata, maar doorbreek daarbij de referentiële integriteit niet.
Het voorbereiden van uw historische bestelgegevens is geen eenvoudige taak van kopiëren & plakken. Het vraagt om:
Maar het loont: uw bestelhistorie is een waardevolle asset voor business intelligence, klantenservice en juridische compliance.
Neem de tijd voor een zorgvuldige voorbereiding, zodat u de migratie naar uw nieuwe platform met vertrouwen en duidelijkheid kunt starten.