Migratie van Shopware naar Shopify Plus: kosten, doorlooptijd en wat opnieuw gemapt moet worden
Door Robin Laseur
Het zichtbare deel van een migratie van Shopware naar Shopify Plus is een nieuwe storefront. Het lastige deel zit eronder: overgeërfde productrelaties, voorwaarden in de Rule Builder, Shopping Experiences, configuratie van saleskanalen, plugins, B2B-processen en koppelingen met de systemen die de bredere operatie draaien.
Een migratie van Shopware naar Shopify Plus zet de commercedata over die het bedrijf nog nodig heeft, mapt Shopware-specifieke regels en structuren opnieuw, bouwt de storefront opnieuw en koppelt essentiële systemen weer aan. Een volledig traject omvat discovery, doelarchitectuur, data, functionaliteit, koppelingen, SEO, testen, de overstap en stabilisatie na de livegang, in plaats van het project als catalogusimport te behandelen.
Shopware functie voor functie nabouwen is zelden het sterkste doel. Dan neem je historische implementatiekeuzes mee naar een platform met een ander operationeel model. Het betere doel is bedrijfscontinuïteit met minder vermijdbare complexiteit: behoud de functies die klanten en interne teams ondersteunen en geef elke functie de eenvoudigste betrouwbare eigenaar in de Shopify-architectuur.
Hoe verandert de bronversie een Shopware-migratie?
Shopware 5 en Shopware 6 vragen om een verschillende migratiebeoordeling. Shopware 5 is een verouderd platform zonder support met een andere technische basis, terwijl Shopware 6 kan draaien als Community Edition, op een commercieel abonnement, zelf gehost, als PaaS of als SaaS. De bronversie, het deploymentmodel en de functieset bepalen welke data, code en operationele verantwoordelijkheid moeten veranderen.
Shopware stopte in juli 2024 met officiële beveiligingsupdates voor Shopware 5. De eigen migratierichtlijnen voor Shopware 5 maken duidelijk dat Shopware 6 een andere bestemming is en geen gewone versie-update. Voor een bedrijf dat nog op Shopware 5 draait, is de beslissing daarom breder dan de vraag of je moderniseert. Het gaat erom of je opnieuw bouwt op Shopware 6 of de replatforming die toch nodig is gebruikt om over te stappen naar Shopify Plus.
Controleer bij Shopware 6 of de omgeving Community Edition gebruikt of een Rise-, Evolve- of Beyond-abonnement, en of die zelf gehost is, als PaaS of als SaaS draait. Die keuzes veranderen welke commerciële functies, maatwerkcode en verantwoordelijkheden voor infrastructuur binnen de scope vallen.
Controleer deze punten voordat je het project schat:
Hoofd- en subversie van Shopware
Community Edition of huidig commercieel abonnement
Deployment: zelf gehost, PaaS of SaaS
Aantal en doel van de saleskanalen
Architectuur van storefront, headless of eigen frontend
Actieve plugins, apps en maatwerkextensies
Gebruik van Rule Builder en Flow Builder
Shopping Experiences, CMS-extensies en eigen contentblokken
B2B Suite, B2B Components of eigen groothandelsfunctionaliteit
Koppelingen met ERP, PIM, WMS, POS, marktplaatsen en marketing
Wanneer is overstappen van Shopware naar Shopify Plus zinvol?
Overstappen van Shopware naar Shopify Plus is zinvol als infrastructuur, upgrades, plugins en specialistisch development capaciteit opslokken die het bedrijf in commerceverbeteringen wil steken. De case wordt sterker als Shopify het benodigde B2C-, B2B- en multimarktmodel kan ondersteunen met minder platformspecifieke afhankelijkheden en een lagere operationele last over drie jaar.
Shopware blijft een serieuze optie voor Europese commerce in het middensegment en enterprise. Het kan passen bij organisaties die controle over deployment en applicatiearchitectuur waarderen, de regel- en contentmogelijkheden intensief gebruiken en het engineeringmodel hebben om die flexibiliteit goed te beheren. Een migratie hoort niet te beginnen vanuit de aanname dat Shopify Plus vanzelf een upgrade is.
Signalen die een formele beoordeling van een replatforming rechtvaardigen:
Onderhoud verdringt steeds commercieel werk: Een wezenlijk deel van de developmentcapaciteit gaat naar hosting, upgrades, compatibiliteit en het oplossen van bugs.
Routinewijzigingen hangen af van schaarse specialisten: Verbeteringen in merchandising, content of checkout halen niet het tempo dat eCommerce-teams verwachten.
Het eigenaarschap van plugins is onduidelijk: Meerdere extensies overlappen, bevatten bedrijfskritische logica of hebben geen benoemde interne eigenaar.
Saleskanalen zijn in configuratie uit elkaar gegroeid: Verschillen in markt, taal, valuta, prijzen en navigatie zijn moeilijk consequent te beheren.
Het B2B- en D2C-model is veranderd: De huidige setup sluit niet meer aan op hoe klanten, salesteams en backofficesystemen werken.
De TCO over drie jaar past niet meer bij de geleverde waarde: Platform, hosting, development, plugins en interne tijd kosten meer dan de controle die ze opleveren.
De vergelijking van Shopware en Shopify van Flatline behandelt de bredere platformkeuze. Zodra je de migratieroute afbakent, is de nuttigere vraag of het beoogde operationele model genoeg verantwoordelijkheid en afhankelijkheid wegneemt om de overstapkosten te rechtvaardigen.
Wanneer blijven op Shopware de betere keuze kan zijn
Blijven kan de sterkere keuze zijn als de huidige implementatie gezond is, het interne team de flexibiliteit van Shopware productief gebruikt en de roadmap afhangt van controle die rond Shopify veel maatwerkdiensten zou vragen. Een stabiele Shopware 6-omgeving hoort niet te worden vervangen omdat Shopify een eenvoudiger functieverhaal heeft.
Wat moet mee, opnieuw worden gemapt, opnieuw gebouwd of uitgefaseerd?
Elk onderdeel van Shopware hoort een van vier doelbeslissingen te krijgen. Verplaats records die al in het model van Shopify passen. Map structuren of regels opnieuw waarvan de zakelijke betekenis blijft maar de implementatie verandert. Bouw functies opnieuw die een nieuwe eigenaar binnen Shopify nodig hebben. Faseer data, plugins en processen uit die migratie en doorlopende support niet meer rechtvaardigen.
Deze indeling maakt van een technische inventaris een scope waarop je mensen kunt aanspreken. Een spreadsheet met het label ‘migratiedata’ maakt geen onderscheid tussen een actieve commerciële regel en een slapende, of tussen een functie die klanten zien en een extensie die jaren geleden is geïnstalleerd en niet meer wordt gebruikt.
Elke beslissing heeft een zakelijke eigenaar nodig. eCommerce keurt merchandisinggedrag goed, finance de prijs- en btw-logica, operations de order- en fulfilmentstromen en marketing de omgang met toestemming en klantevents. Zo scheid je ook de scope die cruciaal is voor de livegang van verbeteringen die later kunnen volgen.
Hoe map je Shopware-producten en catalogusdata naar Shopify?
Shopware-producten horen naar Shopify te worden gemapt op basis van verkoopbaar gedrag en de eisen van systemen verderop in de keten. Parent-childvarianten, eigenschappen, opties, categorieën, eigen velden, media en beschikbaarheid per kanaal hebben geen automatische één-op-één tegenhangers. Het migratiemodel moet behouden wat klanten kunnen kiezen en wat voorraad-, order- en fulfilmentsystemen moeten ontvangen.
Het productmodel van Shopware onderscheidt hoofdproducten en verkoopbare varianten, met overerving daartussen. De productdocumentatie scheidt ook eigenschappen, die een product beschrijven, van opties die varianten bepalen. Producten kunnen in meerdere hiërarchische categorieën vallen en via geselecteerde saleskanalen worden aangeboden.
Shopify werkt met producten, varianten, collecties, metafields en metaobjects. Een standaardproduct met maat en kleur gaat misschien netjes over. Complexere relaties kunnen een ander model vragen, vooral als een configurator, bundel, eenheidsomrekening, staffelprijs of ERP-bericht van de bronstructuur afhangt.
Bepaal de doelcatalogus voordat je de export omzet
Documenteer actieve producten, varianten, eigenschappen, categorieën, media, eigen velden en beschikbaarheid per markt. Wijs daarna het eigenaarschap na de livegang toe. Het PIM kan eigenaar zijn van verrijking, het ERP van prijs en voorraad en Shopify van het digitale assortiment.
Het aantal producten zegt niets over hoe lastig de mapping is. Een grote catalogus met consistente ID's kan makkelijker zijn dan een kleinere catalogus waarvan de variantopties, eigen velden en ERP-verwijzingen zonder beheer zijn gegroeid.
Representatieve testdata hoort te bevatten:
Een eenvoudig product en een variantfamilie met maximale complexiteit
Producten met overgeërfde en overschreven waarden
Producten die aan meerdere categorieën of saleskanalen zijn toegewezen
Voorbeelden van zichtbaarheid en prijzen per markt
Bundels, sets, configurators of digitale producten, waar gebruikt
Uitlopende producten, vertaalde content en media
De orderregel- en fulfilmentoutput die gekoppelde systemen verwachten
Valideer het resultaat voor de klant en het operationele record samen. Een productpagina kan er goed uitzien terwijl de SKU, btw-klasse, voorraadeenheid of samenstelling van onderdelen die in het ERP binnenkomt niet klopt.
Behandel eigen velden als bedrijfsdata, niet als algemene metadata
Shopware ondersteunt eigen velden op producten, klanten, orders en andere entiteiten. Inventariseer elk veld met type, bron, gebruikers en doel verderop in de keten. Een veld dat alleen door een uitgefaseerde plugin wordt gebruikt, heeft misschien geen bestemming nodig. Een veld dat filters, feeds of fulfilment aanstuurt, heeft een expliciete mapping nodig naar een Shopify-metafield, metaobject of extern systeem.
Hoe map je Rule Builder, acties en automatisering naar Shopify?
Logica uit de Shopware Rule Builder hoort te worden opgedeeld in voorwaarden, effecten en toewijzingspunten voordat je die naar Shopify mapt. Eén regel kan verzending, betaling, acties, geavanceerde prijzen, flows of zichtbaarheid van content beïnvloeden. Het doelsysteem kan afhankelijk van de eis Shopify-configuratie, kortingen, Functions, Markets, Flow, een app of een externe dienst gebruiken.
Het toewijzingsmodel van de Rule Builder van Shopware laat zien waarom een export van regelnamen niet genoeg is. Regels kunnen de beschikbaarheid van betaal- en verzendmethoden beïnvloeden, verzendkosten, acties, kortingen, geavanceerde prijzen, flows en de zichtbaarheid van content. Eén hergebruikte voorwaarde aanpassen kan daardoor meerdere klant- of operationele processen veranderen.
Maak een regelregister met deze velden:
Zet niet standaard elke Shopware-regel om in een eigen Shopify Function. Sommige voorwaarden horen in Markets, catalogi, verzendprofielen, betaalconfiguratie of standaardkortingen. Andere zijn misschien duidelijker in het ERP of de middleware, als dat systeem al eigenaar is van het onderliggende commerciële beleid.
Het sterkste doel is de kleinste set regels die de benodigde uitkomsten oplevert. Het is ook een kans om tegenstrijdigheden op te ruimen. Als twee Shopware-regels via verschillende toewijzingen dezelfde winkelwagen kunnen beïnvloeden, moet discovery de voorrang vastleggen voordat er iets in het doelsysteem wordt gebouwd.
Acties vragen om validatie van het gedrag: voorwaarden, stapelen, kortingscodes, periodes, uitgesloten producten, effecten op verzending, berekening inclusief of exclusief btw en rapportage. De korting in de browser is maar één uitkomst. Finance, analytics en klantenservice hebben na de livegang dezelfde interpretatie nodig.
Hoe map je Shopware-saleskanalen naar Shopify Markets en winkels?
Shopware-saleskanalen horen te worden gemapt op basis van doelgroep, transacties en governance-eisen, niet gekopieerd naar hetzelfde aantal Shopify-winkels. Een saleskanaal kan taal, valuta, btw, betaling, verzending, domeinen en navigatie bepalen. Shopify Markets, catalogi, kanalen en expansion stores verdelen die taken anders, dus elk bronkanaal verdient een beoordeling op basis van het doel.
Shopware definieert saleskanalen als de manier waarop een catalogus een specifieke doelgroep bereikt, waaronder storefronts, headless clients, feeds of applicaties. Elk kanaal kan standaardinstellingen hebben voor taal, valuta, btw, betaling, verzending, domeinen en navigatie.
Met Shopify Markets kun je beschikbaarheid van producten, prijzen, valuta, taal, domeinen, themacontent en de btw-ervaring laten verschillen per regio of klantgroep. Andere kanaaltypen, feeds en aparte winkels kunnen eisen afhandelen die niet in één marktstructuur horen.
Leg per Shopware-saleskanaal vast:
Doelgroep, landen, merk en domein
Juridische entiteit en afwikkeling van betalingen
Taal, valuta, btw en invoerrechten
Eigenaarschap van catalogus, prijzen en voorraad
Betaling, verzending en fulfilment
Navigatie, content en operationeel eigenaarschap
Meerdere storefrontkanalen uit Shopware kunnen opgaan in één Shopify-winkel met Markets. Een kanaal voor een marktplaatsfeed kan een app- of feedkoppeling worden in plaats van een winkel. Aparte juridische entiteiten, merken of sterk verschillende operaties kunnen nog steeds aparte Shopify-winkels rechtvaardigen.
De mapping hoort duplicatie te beperken zonder eisen te centraliseren die eigen eigenaarschap nodig hebben. Een architectuurdiagram helpt, maar de beslissing volgt uit de details van transacties en governance, niet uit een visueel net plaatje.
Wat gebeurt er met Shopping Experiences, thema's en headless storefronts?
Shopping Experiences, thema's en headless frontendcode uit Shopware gaan niet direct mee naar Shopify. Herbruikbare content en designmateriaal kun je migreren, maar lay-outs, CMS-blokken, Twig-templates, koppelingen met de Store API en eigen renderlogica vragen om een nieuwe implementatie. Kies Liquid of headless Shopify op basis van de huidige eisen, niet op basis van de bronarchitectuur.
De Shopping Experiences van Shopware ordenen landingspagina's, winkelpagina's en categorielay-outs met secties, blokken en elementen. Eigen CMS-elementen of extensies kunnen bedrijfsspecifieke redactionele mogelijkheden toevoegen. De content erin kan waardevol blijven, maar de structuur en rendering zijn aan Shopware gebonden.
Maak een inventaris van contentcomponenten in plaats van screenshots te maken en pagina's één voor één na te bouwen. Leg per blok de contentvelden vast, plaatsingen, verschillen per markt, planning, dynamische data, personalisatie, SEO-rol en hoe vaak het wordt gebruikt. Bepaal daarna of het wordt:
Een sectie, blok of standaardpagina in een Shopify-thema
Een component dat wordt aangestuurd door metafields of metaobjects
Een extern CMS, een app of een eigen storefrontfunctie
Uitgefaseerde of samengevoegde content
Deze aanpak behoudt het redactionele systeem, niet alleen hoe het er gepubliceerd uitziet. Marketingteams moeten na de livegang de volgende campagne kunnen maken zonder developers te vragen een hardgecodeerde pagina te kopiëren.
Liquid of headless is een nieuwe beslissing
Een eigen of headless Shopware-storefront maakt headless Shopify niet verplicht. Een Shopify Online Store op basis van een thema kan nog steeds een onderscheidend ontwerp, een herbruikbaar contentsysteem en sterke prestaties ondersteunen, met minder eigenaarschap over infrastructuur en koppelingen.
Headless blijft gerechtvaardigd als geverifieerde eisen aan ervaring, kanalen of organisatie verder gaan dan het themamodel. Voorbeelden zijn een commerce-ervaring die over meerdere applicaties wordt gedeeld, een frontend die als zelfstandig product wordt beheerd of complexe contentorkestratie. Kies het omdat het bedrijf het in de nieuwe situatie nodig heeft, niet omdat het bronteam al in een losgekoppelde frontend heeft geïnvesteerd.
Ook frontendcomponenten hergebruiken vraagt om voorzichtigheid. Een component kan in een overdraagbaar JavaScript-framework zijn geschreven, maar toch afhangen van schema's van de Shopware Store API, sessiecontext, routing en plugingedrag. Hergebruik van code hoort te volgen op een review van afhankelijkheden, niet op een visuele vergelijking.
Hoe beoordeel je plugins en koppelingen?
Shopware-plugins en -koppelingen horen te worden beoordeeld op de zakelijke functie die ze leveren, de data die ze uitwisselen en het gevolg als ze falen. Plugins worden geen Shopify-apps één op één. Sommige eisen worden standaardconfiguratie in Shopify, sommige vragen een app of maatwerkkoppeling en andere horen te verhuizen naar het systeem dat het proces al beheert.
Maak aparte inventarissen voor storefrontplugins en systeemkoppelingen, ook als dezelfde extensie in beide voorkomt. Een reviewwidget en een ERP-connector hebben andere operationele gevolgen, testbehoeften en eigenaarschapsmodellen.
Leg per plugin vast:
Zakelijk doel en benoemde eigenaar
Supportstatus, gelezen en geschreven data en bewijs van actief gebruik
Impact op storefront, checkout, beheer of geplande taken
Afhankelijkheden, contract en exiteisen
Doelbeslissing en acceptatiecriteria
Koppelingen bepalen meestal het kritieke pad
Koppelingen met ERP, PIM, WMS, OMS, CRM, POS, zoeken, btw, betalingen, marktplaatsen en lifecyclemarketing hebben contracten nodig in plaats van labels. ‘Koppel het ERP’ zegt niet welk systeem eigenaar is van product-, voorraad-, prijs-, klant- of orderdata.
Documenteer per stroom de richting, frequentie, volume, omzettingen, ID's, foutafhandeling, afstemming en verwachte serviceniveaus. Ontwerp daarna het Shopify-contract rond de data-eigenaren in de nieuwe situatie. Een migratie kan punt-tot-puntkoppelingen weghalen die middleware dupliceren, maar hoort geen logica in Shopify te centraliseren alleen omdat het commerceplatform nieuw is.
Draai end-to-end tests met realistische uitzonderingen: gedeeltelijke voorraad, geannuleerde orders, prijswijzigingen, retouren, mislukte berichten, dubbele klanten en systemen verderop die niet beschikbaar zijn. Tests van het ideale pad laten niet zien of de operatie kan herstellen als een koppeling faalt.
Hoe map je Shopware B2B naar Shopify Plus?
Shopware B2B hoort te worden gemapt als volledige koperprocessen in plaats van een lijst met functies. Bedrijfsstructuren, rollen, goedkeuringen, bestellijsten, eigen ordernummers, budgetten, catalogi per klant, prijzen en processen met ondersteuning van sales kunnen uit B2B Suite komen, uit B2B Components, plugins of maatwerk. Elk proces heeft een geverifieerde eigenaar nodig in Shopify en in de backoffice.
De huidige B2B Components van Shopware ondersteunen bedrijfsrollen en contactpersonen, goedkeuring van orders, bestellijsten en eigen ordernummers. Oudere omgevingen gebruiken misschien B2B Suite, die volgens Shopware niet meer wordt doorontwikkeld ten gunste van B2B Components, of een eigen combinatie van klantgroepen en extensies.
Shopify ondersteunt bedrijven en bedrijfslocaties, catalogi, betalingsvoorwaarden, aantalregels en staffelprijzen. Shopify Plus voegt directe toewijzing van catalogi aan bedrijven toe en geavanceerde betaalmogelijkheden die op lagere abonnementen niet in dezelfde vorm beschikbaar zijn. Die mogelijkheden vormen een sterke basis, maar bewijzen geen gelijkwaardigheid met elke B2B-implementatie in Shopware.
Breng de volledige aankoopreis in kaart:
Account en identiteit: Wie maakt het bedrijf aan, nodigt contactpersonen uit en beheert de toegang?
Rechten: Welke producten, content en prijzen ziet elke bedrijfslocatie?
Inkoopcontroles: Zijn minimale aantallen, stappen, budgetten, goedkeuring of inkoopordernummers nodig?
Checkout en betaling: Welke voorwaarden, aanbetalingen, btw-regels en betaalmethoden gelden?
Betrokkenheid van sales: Kunnen accountmanagers namens een koper winkelwagens, offertes of orders voorbereiden?
Orderoperatie: Hoe bereiken wijzigingen, nabestellingen, retouren, krediet en fulfilment het ERP?
Shopify hoort alleen eigenaar te zijn van de functies die passen bij zijn rol in de doelarchitectuur. Contractprijzen kunnen in het ERP blijven, terwijl Shopify-catalogi de presentatie bepalen. Goedkeuringslogica heeft misschien een app of workflowlaag nodig. Klantenservice kan in het CRM blijven. Een schone B2B-storefront kan nog steeds van meerdere systemen afhangen, maar elke afhankelijkheid hoort bewust te zijn.
Hoe lang duurt een migratie van Shopware naar Shopify Plus?
Een migratie van Shopware naar Shopify Plus voor een gevestigde operatie plan je meestal in maanden. Een afgebakend B2C-project past misschien in 12 tot 16 weken, terwijl trajecten met meerdere markten, B2B, headless of veel koppelingen vaak 18 tot 28 weken of langer vragen. Discovery moet de bandbreedte bepalen zodra de complexiteit van de bron en de capaciteit voor beslissingen bekend zijn.
De migratierichtlijnen van Shopify voor enterprise uit 2026 noemen 12 tot 16 weken voor migraties met complexe koppelingen, terwijl de bredere richtlijnen voor modernisering sommige enterprise-replatformingtrajecten op zes tot twaalf maanden zetten. Beide kunnen kloppen, omdat de grenzen van projecten verschillen.
Gebruik deze bandbreedtes voor de eerste planning, niet als leveringsbelofte:
Een praktische volgorde omvat:
Audit de omgeving: versie, deployment, producten, regels, content, plugins, koppelingen, SEO en processen.
Keur het doelmodel goed: beslissingen over Shopify-abonnement, Markets, data-eigenaarschap, B2B, storefront en apps.
Bewijs lastige mappings: test representatieve producten, prijzen, klanten, orders en koppelingsevents.
Bouw de werkstromen: werk storefront, data, koppelingen, content en SEO uit volgens gedeelde acceptatiecriteria.
Valideer end-to-end: test accounts, checkout, betaling, btw, orders, fulfilment, service en analytics.
Oefen de overstap: bevestig de laatste synchronisatie, redirects, DNS, criteria voor livegang en wie over een rollback beslist.
Stabiliseer: stem data af en monitor commerce-, zoek- en servicesignalen voordat je gaat optimaliseren.
Wat kost een migratie van Shopware naar Shopify Plus?
De kosten van een migratie van Shopware naar Shopify Plus bestaan uit discovery, dataomzetting, storefrontdevelopment, vervanging van regels en plugins, koppelingen, SEO, testen, de overstap en stabilisatie. Gevestigde projecten vragen meestal een implementatiebudget van vijf cijfers, terwijl trajecten met meerdere markten, B2B of veel koppelingen in de zes cijfers kunnen komen. Een scope per werkstroom is betrouwbaarder dan een schatting per product.
Dit zijn richtinggevende planningsbandbreedtes, geen offerte van Flatline. Het aantal producten beïnvloedt het migratiewerk, maar eigen regels, contentcomponenten, de kanaalstructuur, B2B en koppelingscontracten hebben meestal meer invloed op de totale scope.
De platformkosten van Shopify Plus zijn één post in het doelbudget. Shopify Plus begint momenteel bij € 2.100 per maand voor standaardsetups bij een looptijd van drie jaar, of € 2.250 per maand bij een looptijd van één jaar, met variabele prijzen voor complexere bedrijven of hogere volumes. Bevestig de actuele commerciële voorwaarden voordat je akkoord geeft.
Bouw het migratiebudget op uit deze werkstromen:
Discovery en architectuur: audit van de huidige situatie, eisen, eigenaarschap in de nieuwe situatie, migratiespecificatie, risicoregister en leveringsplan.
Storefront en configuratie: design, thema- of headless implementatie, Markets, checkout, zoeken, navigatie en merchandising.
Data: extractie, opschoning, omzetting, testimports, afstemming en laatste synchronisatie.
Regels en functionaliteit: vervanging van acties, prijzen, verzending, betaling, automatisering, content en maatwerkfuncties.
Koppelingen: ERP, PIM, WMS, OMS, CRM, POS, btw, betalingen, marketing en analytics.
Bescherming van de livegang: SEO, toegankelijkheid, prestaties, QA, acceptatietests, generale repetities van de overstap en monitoring.
Operationele verandering: contentvoorbereiding, training, klantcommunicatie, kosten van parallelle platforms en support na de livegang.
Vergelijk de eenmalige investering met minstens drie jaar huidige en toekomstige beheerkosten. Neem het Shopware-abonnement of de licentie mee, hosting, platformupgrades, developmentsupport, plugins, Shopify-apps, interne tijd en de commerciële kosten van een traag releasemodel. Het TCO-kader voor eCommerce van Flatline helpt bij die bredere berekening.
Hoe bescherm je SEO en de operatie tijdens de overstap?
SEO en de operatie beschermen vraagt om één plan voor de overstap voor URL's, content, data, klanttoegang, orders, voorraad, koppelingen en analytics. Crawl de Shopware-omgeving voordat je de architectuur wijzigt, oefen de laatste synchronisatie en cruciale transacties, valideer redirects op schaal, leg vast wie over livegang en rollback beslist en monitor direct na de overstap van het verkeer de zoek- en operationele signalen.
Shopware kan SEO-URL's per saleskanaal, domein en taal genereren. Dezelfde content kan daardoor meerdere regionale paden, eigen routepatronen of historische aliassen hebben. Bouw een URL-inventaris op uit crawls, sitemaps, analytics, Google Search Console en backlinkdata in plaats van alleen op een database-export te vertrouwen.
Geef elke waardevolle indexeerbare URL een doelbeslissing:
Behoud een gelijkwaardige pagina en zoekintentie
Voeg samen in een sterkere bestemming
Stuur door naar de dichtstbijzijnde relevante vervanger
Faseer alleen uit als er geen nuttige bestemming is
Shopify ondersteunt het in bulk importeren van URL-redirects. Het migratieteam moet nog steeds ketens en lussen voorkomen, de bedoeling per locale behouden, interne links bijwerken en statuscodes valideren. Vergelijk ook canonicals, hreflang, metadata, gestructureerde data, paginering, gefacetteerde navigatie, sitemaps en robots-instructies tussen de platforms.
Het operationele draaiboek moet omvatten:
Freezeperiodes voor content en configuratie
Laatste en delta-synchronisatie van producten, klanten en orders
Leidend systeem voor prijzen en voorraad tijdens de overstap
Toegang tot klantaccounts en communicatie
Tests van betaling, btw, verzending en acties
Berichten voor ERP, PIM, fulfilment en service
Toestemming, analytics en marketingevents
Uitrol van redirects, DNS- en domeinwijzigingen
Criteria voor livegang, escalatieroutes en wie over een rollback beslist
Afstemming en monitoring tijdens de stabilisatie
Klantwachtwoorden vragen om een bewuste overgang. Shopify legt uit dat versleutelde wachtwoorden van een ander platform niet via een klant-CSV kunnen worden geïmporteerd, dus het team moet accountuitnodigingen, klantaccounts zonder wachtwoord of een andere goedgekeurde identiteitsaanpak plannen. De klantenservice hoort de route te kennen voordat klanten ermee te maken krijgen.
Een site die een pagina succesvol laadt, bewijst nog geen bedrijfscontinuïteit. Orders, voorraadupdates, klantevents of regionale redirects kunnen achter een werkende storefront misgaan. Goedkeuring voor de livegang hoort af te hangen van bewijs uit volledige klant- en operationele processen.
Draai je op Shopware 5 en moet je toch al upgraden, dan is kiezen tussen overstappen, herbouwen of blijven de eerste beslissing, want ook een overstap naar Shopware 6 is een herbouw. Komt Shopify Plus als beste uit de bus, dan brengt onze Shopify-migratie de Rule Builder-logica, de saleskanalen en de livegang uit deze gids in kaart.
Veelgestelde vragen
Is migreren vanaf Shopware 5 anders dan vanaf Shopware 6?
Ja. Shopware 5 heeft het einde van de levensduur bereikt en gebruikt een andere technische basis, dus het project omvat vaak een beoordeling van verouderde onderdelen en supportrisico's. De scope bij Shopware 6 hangt af van de editie, het deploymentmodel, saleskanalen, regels, plugins, Shopping Experiences, B2B-functies en koppelingen. Beide vragen om replatforming in plaats van een directe overdracht van code.
Kunnen wachtwoorden van Shopware-klanten naar Shopify worden gemigreerd?
Klantrecords kunnen mee, maar versleutelde wachtwoorden kunnen meestal niet in Shopify worden geïmporteerd. Plan een route voor accountactivering of inloggen zonder wachtwoord, beoordeel waar relevant externe identiteitseisen en bereid scripts voor de klantenservice voor. Test dubbele profielen, opgeslagen adressen, toestemming en communicatie vóór de livegang.
Kan logica uit de Shopware Rule Builder naar Shopify worden gekopieerd?
Niet direct. Exporteer of documenteer per regel de voorwaarden, toewijzingen, prioriteiten en effecten, en map daarna de zakelijke uitkomst naar Shopify Markets, catalogi, kortingen, Functions, Flow, verzend- of betaalconfiguratie, een app of een extern systeem. Gedeelde en tegenstrijdige regels hebben expliciete testcases nodig.
Kunnen Shopware Shopping Experiences naar Shopify worden gemigreerd?
De content en media kunnen worden gemigreerd, maar secties, blokken, elementen en eigen CMS-logica uit Shopware vragen om een nieuwe implementatie. Map herbruikbare componenten naar secties en blokken in een Shopify-thema, metafields, metaobjects, een extern CMS of eigen storefrontcomponenten, zodat redacteuren praktisch kunnen blijven publiceren.
Kunnen Shopware B2B Components naar Shopify Plus?
Veel eisen kunnen worden gemapt naar bedrijven, bedrijfslocaties, catalogi, betalingsvoorwaarden, aantalregels en staffelprijzen in Shopify. Rollen, goedkeuringen, budgetten, offertes, eigen ordernummers, contractprijzen en ERP-processen vragen nog steeds om een beoordeling op procesniveau. Sommige functies hebben misschien een app, koppeling of een ander systeem als eigenaar nodig.
Moet elk Shopware-saleskanaal een Shopify-winkel worden?
Nee. Breng eerst per kanaal de doelgroep, catalogus, valuta, btw, domein, juridische entiteit en operatie in kaart. Meerdere regionale storefronts kunnen opgaan in Shopify Markets, terwijl aparte merken of juridische en operationele modellen extra winkels kunnen rechtvaardigen. Feeds en applicaties kunnen kanalen of koppelingen worden in plaats van winkels.
Kunnen historische Shopware-orders in Shopify worden geïmporteerd?
De scope van historische orders hoort het operationele gebruik te volgen. Klantenservice, retouren, finance, loyaliteit en rapportage hebben mogelijk verschillende diepten van geschiedenis nodig. Sommige orders kunnen in Shopify thuishoren, terwijl oudere records toegankelijk kunnen blijven via een ERP, CRM, datawarehouse of een archief dat aan de regels voldoet.
Is Shopify Plus altijd de juiste vervanger voor Shopware?
Nee. Shopify Plus past bij bedrijven die een beheerde commercekern willen en hun onderscheidende eisen binnen het uitbreidingsmodel kunnen invullen. Shopware kan sterker blijven als controle over deployment, diepgaand platformmaatwerk of de huidige commerciële functies genoeg waarde opleveren om de operationele verantwoordelijkheid te rechtvaardigen.
De belangrijkste punten
Shopware 5 en Shopware 6 vragen om een verschillende beoordeling van de bron. Versie, abonnement en deploymentmodel horen in discovery voordat de inspanning wordt geschat.
Gebruik vier scopebeslissingen: verplaatsen, opnieuw mappen, opnieuw bouwen en uitfaseren. Pas ze toe op data, regels, content, plugins en koppelingen.
Productvarianten, eigenschappen, eigen velden en categorieën vragen om mapping op gedrag, niet alleen om het koppelen van velden.
De Rule Builder kan prijzen, acties, verzending, betaling, automatisering en zichtbaarheid beïnvloeden. Map zowel toewijzingen als regeldefinities.
Shopware-saleskanalen worden niet automatisch Shopify-winkels. Ontwerp Markets en de winkelstructuur rond doelgroep, transacties en governance.
Shopping Experiences en storefrontcode vragen om een nieuwe implementatie, terwijl waardevolle content en redactionele eisen behouden kunnen blijven.
B2B hoort te worden beoordeeld als volledige koper- en backofficeprocessen, niet als checklist met functies.
Een planningshorizon van 12 tot 28 weken past bij veel gevestigde projecten; complexe trajecten kunnen langer duren.
Kosten worden verdedigbaar als data, storefront, regels, koppelingen, SEO en organisatorische verandering apart worden afgebakend.
SEO en operationele continuïteit horen in hetzelfde overstapplan, omdat de storefront live kan lijken terwijl zoek- of backofficeprocessen kapot zijn.
De beslissing om Shopware te verlaten, wordt pas nuttig als het bedrijf kan benoemen wat de nieuwe architectuur eenvoudiger maakt. Een gestructureerde migratie behoudt de commerciële en operationele functies die nog tellen, geeft elke functie een duidelijke eigenaar en laat complexiteit achter die niet meer wordt ondersteund of niet nodig is.
Weet je niet zeker hoe je je Shopware-regels, plugins, saleskanalen en koppelingen naar Shopify Plus mapt? Flatline is Shopify Platinum Partner met praktijkervaring in eCommerce-architectuur, maatwerkdevelopment, ERP-koppelingen en SEO. Neem contact op, dan lopen we de scope van de migratie samen met je door.
Gerelateerde artikelen
