21/9/2026

Producten, klanten en bestellingen migreren zonder ongemerkt gegevens te verliezen

Producten, varianten, klanten en bestellingen migreren vanuit Shopify, WooCommerce, PrestaShop, Wix, BigCommerce of Shopware, zonder dat gegevens ongemerkt verdwijnen.

Van e-commerceplatform wisselen is meer dan een paar producten van de ene webshop naar de andere verplaatsen. Elk platform, of het nu Shopify, WooCommerce, PrestaShop, Wix, BigCommerce of Shopware is, organiseert varianten, attributen, categorieën, prijzen, voorraden, afbeeldingen, klanten en bestellingen op zijn eigen manier.

En daar zit de valkuil: een migratie kan geslaagd lijken, terwijl ze onderweg ongemerkt een deel van de catalogus heeft laten liggen. Geen foutmelding, geen waarschuwing. Alleen onvolledige producten, kapotte filters of verdwenen varianten, zonder dat iemand het de eerste weken opmerkt.

Deze gids legt uit waarom dat gebeurt, hoe u het voorkomt en waarom Eloshon Converter specifiek voor dit probleem is ontworpen: nooit een gegeven verliezen zonder het te melden.

Schema: Shopify, WooCommerce, PrestaShop, Wix, BigCommerce en Shopware verbonden met Eloshon Converter als centrale conversie-engine
Eloshon Converter leest zes platforms en schrijft importbestanden voor vier ervan: Shopify, WooCommerce, Wix en BigCommerce. Merken en logo's zijn eigendom van hun respectieve houders; Eloshon is geen partner van deze platforms en is er niet aan verbonden.

Waarom gegevens verloren gaan bij een platformwissel

Als u nog nooit een webshop hebt beheerd, is dit het basisprincipe: een productcatalogus wordt meestal verplaatst als CSV-bestand (een gegevenstabel, een beetje zoals een vereenvoudigd Excel-bestand) dat u uit het ene platform exporteert en in het andere importeert.

Het probleem is dat dat bestand slechts een platte tabel is. Het zegt niets over hoe elk platform de gegevens erin begrijpt. Een concreet voorbeeld maakt dat duidelijk.

Een T-shirt bestaat in 3 kleuren en 4 maten. In WooCommerce worden die gegevens opgeslagen als « attributen », gekoppeld aan technische kolommen zoals attribute_pa_color. In Shopify heet hetzelfde begrip een « variantoptie », met een strikte technische limiet: 3 opties en 100 varianten per product (2048 voor de recentste catalogi via een aparte API, maar ook dan geldt een limiet). In Shopware kan een product alleen aan het laagste categorieniveau worden gekoppeld: hangt het aan een tussenliggende categorie, dan wordt het onzichtbaar in de webshop, zonder enige foutmelding.

Een eenvoudige mapping « bronkolom → doelkolom » kan die regels niet raden. Evenmin kan ze raden dat Shopify een variant als volledig nieuw beschouwt wanneer u een optiewaarde hernoemt (bijvoorbeeld « Maat: XL » wordt « Maat: X-Large »). Het platform verwijdert dan ongemerkt de oude variant en de voorraad ervan, ook al is de referentie (SKU) niet veranderd. Dat is geen hypothese: het is een gedocumenteerd geval dat meermaals is gemeld in de officiële Shopify-community, bij catalogi van meer dan 1.500 referenties.

Andere valkuilen komen steeds terug, allemaal gedocumenteerd op de helpforums van de platforms zelf:

  • Dynamische collecties (op basis van automatische regels) die na de migratie weer vaste categorieën worden. Het gegeven bestaat nog, maar het gedrag is veranderd zonder dat iemand daar uitdrukkelijk voor heeft gekozen.
  • Attribuutnamen die niet in het Engels zijn geschreven (accenten, Arabische of Aziatische tekens) en daardoor de automatische koppeling van varianten breken.
  • Categorieën die meer dan 8 niveaus diep genest zijn en in BigCommerce abrupt op het hoofdniveau belanden.
  • Een andere bronvaluta dan de euro, waardoor een volledige import in Shopware ongemerkt mislukt: de tool meldt een succes, maar er is geen enkel product echt aangemaakt.
  • Externe leveranciersbestanden (zoals een BigBuy-export) die worden geweigerd door een eenvoudig probleem met een kolomkop of slecht geëscapete aanhalingstekens. Of erger: ze worden geaccepteerd, met prijzen die door een conversiefout vermenigvuldigd zijn.

Geen van deze gevallen is onvermijdelijk. Maar geen enkel geval valt op te sporen door simpelweg kolommen te kopiëren en te plakken. U moet begrijpen wat elk gegeven voorstelt, niet alleen hoe het heet.

De methode van Eloshon Converter: converteren, behouden, melden

Dat is het kernprincipe van Eloshon Converter: elk gegeven dat de tool in een catalogus tegenkomt, wordt nooit blind gekopieerd of zomaar weggelaten. De tool volgt altijd een van deze drie wegen.

Weg Wat er gebeurt Voorbeeld
Geconverteerd Er bestaat een rechtstreeks equivalent in het doelplatform Een prijs, een SKU, een hoofdafbeelding
Behouden Geen rechtstreeks equivalent, maar het gegeven blijft bewaard in een andere bruikbare vorm (vaak een metafield) Een technisch kenmerk zonder eigen veld (garantie, materiaal, energieklasse)
Gemeld Geen betrouwbare conversie mogelijk: de gebruiker wordt gewaarschuwd in plaats van dat het gegeven verdwijnt Meerdere kolommen die allemaal de kleur van een product lijken aan te duiden

Concreet: als een WooCommerce-bestand tegelijk Color, attribute_pa_color en option_1 bevat, past een klassieke converter een vaste regel toe, ook als die zich bij een slecht opgeschoonde catalogus vergist. Eloshon Converter herkent dat meerdere kolommen om dezelfde variantinformatie concurreren en stelt de vraag in plaats van te gokken: « Welke kolom stelt echt de kleur voor? »

Dat is het verschil tussen een migratie die gelukt lijkt en een migratie waarvan u precies weet wat er is overgezet, omgezet of achtergelaten.

Wat Eloshon Converter ondersteunt

  • Producten en varianten, ook complexe combinaties (kleur + inhoud op hetzelfde product: een veelvoorkomend geval in cosmetica, dat op de Shopify-forums vragen oproept bij een migratie vanuit PrestaShop).
  • Prijzen, voorraden en staffels: met onderscheid tussen prijs excl. btw, prijs incl. btw, actieprijs en staffelprijs, in plaats van alles terug te brengen tot één kolom price.
  • Afbeeldingen: waar mogelijk blijft de koppeling tussen een specifieke afbeelding en een variant (kleur, uitvoering) behouden, niet alleen een algemene galerij.
  • Categorieën en hiërarchieën, ook wanneer het bronplatform categoriekoppelingen toelaat die het doelplatform weigert, of wanneer het doelplatform de diepte beperkt (BigCommerce).
  • Productidentificatoren (EAN, GTIN, UPC, ISBN): een veld dat verschillende migratietools standaard niet meenemen, waardoor u het achteraf vaak handmatig moet instellen.
  • Vertalingen en meertalige webshops.
  • Metadata en aangepaste velden.
  • Bestellingen en klanten, met twee bijzondere aandachtspunten.

Marketingtoestemming is niet standaard overdraagbaar

Een klant die in de bronwebshop heeft ingestemd met marketingmails, heeft die toestemming niet automatisch gegeven voor de nieuwe webshop. Een veld « toestemming: ja » in het bronbestand volstaat niet om dat gegeven in een nieuwe context te hergebruiken. Eloshon Converter behandelt dit veld als een apart gegeven, dat een uitdrukkelijke beslissing vraagt in plaats van een simpele kopie.

Nummering van bestellingen en facturen

Een reëel en gedocumenteerd voorbeeld: in BigCommerce zijn bestelnummers oplopend en kan het oorspronkelijke nummer bij een migratie technisch niet behouden blijven. Dat punt raakt rechtstreeks aan de boekhoudkundige verplichtingen rond factuurnummering. Voor een onderneming die een doorlopende factuurreeks moet aanhouden, mag een migratie die reeks nooit willekeurig herschrijven, en ook geen gaten of dubbele nummers veroorzaken. Eloshon Converter maakt een duidelijk onderscheid tussen het overnemen van de bestelgeschiedenis en de nummering van nieuwe facturen, rekening houdend met de verplichtingen die in de jurisdictie van de onderneming gelden.

Waarom Shopify, WooCommerce, PrestaShop, Wix, BigCommerce en Shopware niet kolom per kolom te vergelijken zijn

Elk platform heeft zijn eigen interne regels, die vaak onzichtbaar blijven tot u er tegenaan loopt:

Platform Concrete technische beperking
Shopify Standaard 3 opties en 100 varianten per product (tot 2048 via een aparte API; let bij grote catalogi op de dagelijkse aanmaaklimiet)
WooCommerce Globale attributen, lokale attributen en aangepaste velden (ACF) bestaan naast elkaar zonder strikte hiërarchie; de variatiesleutels moeten exact als slug in het verwachte formaat staan, anders herkent de frontend de variaties niet meer
PrestaShop Combinaties van kenmerken (kleur + inhoud op dezelfde productpagina) en een EAN/GTIN-veld dat bij standaardmigraties vaak ontbreekt
Wix Klantwachtwoorden nooit overdraagbaar (net als overal elders), galerij bij import beperkt tot 19 afbeeldingen per product
BigCommerce Categoriediepte beperkt tot 8 niveaus, oplopende bestelnummering die niet te herschrijven is
Shopware Producten moeten aan het laagste categorieniveau gekoppeld zijn; gevoelig voor valuta en speciale tekens bij import

Geen van deze beperkingen is een fout van het doelplatform: het zijn gewoon andere regels. Het probleem ontstaat wanneer ze genegeerd worden.

Concrete gevallen per migratierichting

WooCommerce → Shopify. Het bronbestand bevat taxonomieën en attributen (pa_heel-height, pa_brand, product_cat). Zonder expliciete mapping naar Shopify-metafields komen die gegevens nergens bruikbaar terecht: ze zijn er wel, maar onzichtbaar voor de productfilters. Eloshon Converter herkent die relaties vóór de export in plaats van achteraf.

Shopify → WooCommerce. De « slimme » collecties van Shopify (op basis van automatische regels, bijvoorbeeld « alle producten met de tag zomer ») worden vaste categorieën in WooCommerce. Het gegeven is er wel, maar het dynamische gedrag verdwijnt: een typisch voorbeeld van « behouden, maar omgezet ».

PrestaShop → Shopify. Een reëel, gedocumenteerd geval met een cosmeticacatalogus van 900 referenties: op één productpagina combineren de producten kleur en inhoud. Het EAN-veld, dat bij standaardmigraties vaak ontbreekt, moet uitdrukkelijk worden opgevraagd. In een reëel geval zonder 301-redirects (de regels die een oude URL automatisch naar de nieuwe doorsturen) bleef het verkeer gestaag dalen, en dat was maanden na de migratie nog moeilijk te verklaren.

Wix → Shopify of WooCommerce. ERP-, CRM- en vervoerdersintegraties, die bij Wix vaak beperkt zijn, moeten opnieuw worden opgebouwd in plaats van ongewijzigd te worden overgezet. Afbeeldingen in blogartikelen gaan zelden mee met de tekst.

BigCommerce → Shopify of WooCommerce. Complexe productopties (B2B-catalogus met tienduizenden referenties) laten zich niet 1:1 mappen op de 3 standaardopties van Shopify. In een reëel, gedocumenteerd geval moest een product met 5 opties en 1708 varianten volledig worden geherstructureerd tot een compatibel model.

Shopware → Shopify of WooCommerce. De categoriekoppelingen die uit Shopware worden gelezen, worden opnieuw opgebouwd volgens de regels van het doelplatform. Een product dat niet gekoppeld kan worden, wordt in het rapport gemeld in plaats van ongemerkt uit de webshop te verdwijnen.

Geen nette export? Eloshon Scraper neemt het over

Niet elke migratie vertrekt van een nette export. Een concurrent, een leverancier of een oude webshop zonder beheerderstoegang levert vaak geen bruikbaar bestand, alleen een openbare website die u pagina per pagina moet doorlopen.

Eloshon Scraper zet die openbare informatie om in gestructureerde gegevens, die Eloshon Converter vervolgens kan aanpassen aan het doelplatform:

Schema in vijf stappen: openbare e-commercesite zonder export, Eloshon Scraper, gestructureerde gegevens in CSV of JSON, Eloshon Converter, doelplatform
Openbare site zonder export → Eloshon Scraper → gestructureerde gegevens (CSV/JSON) → Eloshon Converter → importbestanden voor Shopify, WooCommerce, Wix of BigCommerce.

Precies dit soort problemen ondervinden bedrijven die met externe leveranciersfeeds werken (dropshipping, groothandels): een CSV-export die ongewijzigd binnenkomt, kan worden geweigerd door een eenvoudig probleem met een kolomkop. Of erger: hij wordt geïmporteerd met verkeerd omgerekende prijzen, zonder dat iemand het merkt voordat klanten erover klagen. Het duo Scraper + Converter dekt dit geval van begin tot eind: extraheren, structureren, controleren, converteren.

Let op: de merken of sites die in deze context als voorbeeld worden genoemd, zijn geen klanten of partners van Eloshon. Ze illustreren alleen de technische mogelijkheden van scraping. Het gebruik van de opgehaalde gegevens moet altijd de toegangsvoorwaarden van de betrokken site en de geldende regelgeving respecteren.

Voor wie

Webshopeigenaars die van platform wisselen, een bestaande catalogus overnemen of een nieuw verkoopkanaal voorbereiden.

E-commercebureaus die migraties voor klanten begeleiden, heterogene catalogi opschonen of bestanden uit meerdere bronnen zonder documentatie verwerken.

Waarom niet gewoon een CSV-mapping

Twee bestanden kunnen allebei de kolommen name, price, sku en category bevatten en toch totaal verschillende commerciële modellen voorstellen. CSV is maar een transportformaat. De echte vraag is: wat betekent elk gegeven, en waarmee is het verbonden?

Het is die laag van begrip, en niet alleen van overeenstemming, waardoor Eloshon Converter varianten, attributen, categorieën, prijzen, afbeeldingen, voorraden, vertalingen en bestellingen correct kan verwerken, zonder ooit informatie te laten verdwijnen zonder het te melden.

Samengevat

Een geslaagde migratie meet u niet aan het aantal regels dat in het doelbestand is aangekomen. U meet ze aan de antwoorden op precieze vragen: welke varianten zijn herkend, welke afbeeldingen hebben hun koppelingen behouden, welke gegevens hadden geen equivalent, en welke vragen een menselijke beslissing.

Eloshon Converter, en Eloshon Scraper voor gevallen zonder nette export, zijn ontworpen zodat die vragen altijd een antwoord krijgen, in plaats van verborgen te blijven achter een knop « Importeren ».

Voor het praktische verloop van een migratie (export, tussenformaat, ondersteunde richtingen, 301-redirects), zie ook Hoe migreert u een Shopify-, WooCommerce-, Wix-, BigCommerce- of PrestaShop-webshop?