Van maatwerksoftware naar Shopify migreren: hoe behoud je cruciale bedrijfslogica?

Een migratie van maatwerksoftware naar Shopify is zelden een gewone platformmigratie. Bij een standaard e-commerceplatform is meestal bekend hoe producten, klanten, orders, categorieën en extensies zijn opgeslagen. Bij maatwerksoftware kan vrijwel ieder onderdeel anders zijn ingericht. De database, checkout, prijsberekeningen, voorraadlogica en koppelingen zijn vaak speciaal voor één organisatie ontwikkeld.

Dat maakt een maatwerkwebshop waardevol, maar soms ook moeilijk beheersbaar. Belangrijke bedrijfsregels kunnen verspreid staan over broncode, databaseprocedures, cronjobs, integraties en handmatige werkafspraken. Documentatie ontbreekt regelmatig of beschrijft een oudere situatie. De enige persoon die precies wist waarom een bepaalde uitzondering ooit is gebouwd, werkt misschien al jaren ergens anders.

Migreren naar Shopify betekent daarom niet dat de bestaande software wordt gekopieerd. De code van een maatwerkplatform kan niet rechtstreeks in Shopify worden geplaatst. Wat wel kan worden overgezet, zijn data, content en de zakelijke functies achter het maatwerk. Daarbij wordt per proces bepaald of Shopify-standaardfunctionaliteit, een app, Shopify Functions, een koppeling of nieuw maatwerk de beste oplossing vormt.

In deze gids leggen we uit wanneer migreren naar Shopify verstandig is, hoe je verborgen bedrijfslogica ontdekt, welke data kan worden gemigreerd, hoe je koppelingen en SEO beschermt en wat een professioneel migratietraject ongeveer kost.

Wat bedoelen we met maatwerksoftware?

Maatwerksoftware is een webshop of commerceomgeving die geheel of grotendeels voor één organisatie is ontwikkeld. Dat kan een klassieke monolithische applicatie zijn waarin frontend, checkout, beheer en database één geheel vormen. Het kan ook een moderne headless of composable architectuur zijn met afzonderlijke diensten voor productdata, zoeken, prijzen, voorraad en checkout.

Onder maatwerksoftware vallen bijvoorbeeld:

• een webshop die in PHP, .NET, Java, Python, Ruby of Node.js is ontwikkeld;
• een eigen orderportaal dat later tot volwaardige webshop is uitgebreid;
• een commerceomgeving die rond het ERP is gebouwd;
• een headless storefront met een eigen commerce-backend;
• een brancheoplossing die door één leverancier is aangepast;
• een verouderd platform waarvan de kern niet langer wordt ondersteund;
• een combinatie van eigen code, losse databases en externe services;
• een B2B-portaal met klantspecifieke prijzen en bestelprocessen.

Niet iedere maatwerkoplossing is technisch verouderd. Sommige omgevingen zijn uitstekend ontworpen, goed gedocumenteerd en essentieel voor een onderscheidend bedrijfsmodel. Het probleem is dus niet dat software maatwerk bevat. De vraag is of de waarde van dat maatwerk nog opweegt tegen de kosten, risico’s en afhankelijkheden.

Waarom onderzoeken bedrijven een overstap naar Shopify?

Maatwerk begint vaak met een goede reden. Standaardplatformen konden een belangrijk proces niet ondersteunen, de organisatie wilde volledige controle of een ontwikkelaar kon snel iets specifieks bouwen. In de loop van de jaren groeit de oplossing mee. Er komen koppelingen, uitzonderingen, nieuwe landen, betaalmethoden en marketingtools bij.

Op een gegeven moment kan de technische vrijheid veranderen in technische verplichting. Iedere nieuwe browserfunctie, beveiligingsupdate, betaalmethode of wijziging in een externe API vraagt dan om eigen ontwikkeling en onderhoud.

Een migratie naar Shopify wordt vaak onderzocht wanneer:

• de webshop afhankelijk is van enkele developers of één leverancier;
• kennis over de architectuur en bedrijfsregels verdwijnt;
• onderhoud een steeds groter deel van het ontwikkelbudget opslokt;
• hosting, beveiliging, performance en beschikbaarheid veel aandacht vragen;
• releases langzaam of risicovol zijn geworden;
• commerciële teams voor kleine wijzigingen development nodig hebben;
• koppelingen kwetsbaar zijn en onvoldoende logging hebben;
• internationale uitbreiding per land veel maatwerk vraagt;
• de checkout of mobiele ervaring achterblijft;
• het aantrekken van developers voor de gebruikte technologie moeilijk wordt;
• de totale eigendomskosten niet langer in verhouding staan tot de zakelijke waarde.

Shopify neemt hosting en een groot deel van het onderhoud van het kernplatform over. Producten, content, kortingen, markten en campagnes zijn vaak eenvoudiger te beheren. Dat kan de organisatie meer snelheid en voorspelbaarheid geven.

Die voordelen ontstaan echter alleen wanneer Shopify past bij de processen. Een migratie die alle historische uitzonderingen opnieuw als maatwerk bouwt, kan de oude complexiteit simpelweg naar een nieuw adres verhuizen.

Wanneer kun je beter niet naar Shopify migreren?

Shopify is niet automatisch beter dan goed ontworpen maatwerksoftware. Een eigen platform kan een belangrijk concurrentievoordeel vormen wanneer commerceprocessen sterk afwijken van wat gangbare platformen ondersteunen.

Bij de bestaande oplossing blijven of deze moderniseren verdient serieus onderzoek wanneer:

• unieke productconfiguratie de kern van het verdienmodel vormt;
• prijzen tijdens de klantreis door complexe modellen worden berekend;
• extreem lage latency of een bijzondere infrastructuur noodzakelijk is;
• de organisatie volledige controle over database, runtime en releasecyclus nodig heeft;
• de webshop onderdeel is van een breder bedrijfskritisch softwareproduct;
• wetgeving of contracten een specifieke technische architectuur vereisen;
• Shopify-apps en API’s onvoldoende ruimte bieden voor essentiële processen;
• het bestaande platform stabiel, veilig, gedocumenteerd en economisch gezond is;
• de migratie nauwelijks commerciële of operationele verbetering oplevert.

Ook Magento kan in sommige gevallen beter passen. Dat geldt bijvoorbeeld wanneer veel controle over het commerce-datamodel, complexe B2B-processen, vergaand backendmaatwerk of eigenaarschap van de infrastructuur doorslaggevend zijn.

Een eerlijk platformonderzoek kan dus meerdere uitkomsten hebben: de maatwerksoftware gericht verbeteren, bepaalde functies loskoppelen, overstappen naar Shopify, kiezen voor Magento of een hybride architectuur bouwen. De gewenste uitkomst hoort niet vóór de analyse vast te staan.

Het belangrijkste inzicht: migreer functies, niet de oude code

De bestaande broncode is geschreven voor een andere architectuur. Tabellen, services, templates en processen sluiten niet rechtstreeks aan op Shopify. Zelfs wanneer delen van de code technisch herbruikbaar lijken, is dat meestal niet de beste basis voor de nieuwe omgeving.

Beschrijf daarom eerst wat iedere functie zakelijk doet. Bijvoorbeeld:

• “Deze code berekent een staffelkorting voor dealers”;
• “Deze batch synchroniseert iedere nacht voorraden uit drie magazijnen”;
• “Deze regel blokkeert verzending van een product naar bepaalde landen”;
• “Deze configurator maakt een geldige combinatie en stuurt een stuklijst naar het ERP”;
• “Deze accountrol bepaalt welke vestigingen een inkoper mag bestellen.”

Vervolgens wordt per functie een nieuwe oplossing gekozen.

Deze benadering voorkomt een letterlijke herbouw van technische geschiedenis. Het doel is niet om dezelfde software in een ander jasje te maken, maar om een eenvoudiger en beter beheersbaar commercieel fundament te ontwerpen.

Begin met discovery en software-archeologie

Bij maatwerksoftware is een degelijke discoveryfase onmisbaar. Interviews alleen zijn niet genoeg. Gebruikers weten hoe zij de webshop bedienen, maar niet altijd welke automatische processen op de achtergrond draaien. Developers kennen de code, maar mogelijk niet de commerciële reden achter iedere uitzondering.

Onderzoek daarom meerdere bronnen:

• broncode en versiebeheer;
• database, tabellen, relaties en opgeslagen procedures;
• API-documentatie en actuele endpoints;
• cronjobs, queues, webhooks en batchprocessen;
• configuratiebestanden en omgevingsvariabelen;
• hostingarchitectuur en externe services;
• beheeromgeving en gebruikersrollen;
• ERP-, PIM-, WMS-, CRM- en boekhoudsystemen;
• betaal-, verzend- en fraudediensten;
• analytics, advertentietags en consentplatform;
• supporttickets en bekende incidenten;
• handleidingen en interne werkinstructies;
• gesprekken met e-commerce, klantenservice, logistiek, finance en IT.

Analyseer ook werkelijk gebruik. Een functie kan technisch aanwezig zijn maar al jaren niet meer worden gebruikt. Andersom kan een ogenschijnlijk klein script iedere nacht een essentieel bestand voor een logistieke partner genereren.

De uitkomst hoort een actueel overzicht te zijn van data, functies, afhankelijkheden, risico’s en eigenaren. Zonder dat overzicht is een offerte vooral een schatting met nette vormgeving.

Maak verborgen bedrijfslogica zichtbaar

Maatwerksoftware bevat vaak impliciete regels. Ze staan niet in één functioneel ontwerp, maar zijn door de jaren heen verdeeld geraakt over verschillende onderdelen.

Denk aan:

• klantspecifieke prijzen en assortimenten;
• staffels, contractprijzen en minimumafnames;
• productuitsluitingen per land of klantgroep;
• berekeningen op basis van gewicht, volume of materiaal;
• samengestelde producten en stuklijsten;
• voorraadreservering en backorders;
• uitzonderingen voor zakelijke betaalmethoden;
• gedeeltelijke leveringen en meerdere afleveradressen;
• ordergoedkeuring op basis van budget of rol;
• retourregels per productcategorie;
• abonnements- of herhaalbestellingen;
• belastinglogica voor specifieke transacties;
• frauderegels en handmatige controles;
• exports naar productie, fulfilment of finance.

Leg per regel vast wie de eigenaar is, wanneer de regel wordt toegepast, welke data nodig is en wat er gebeurt bij een fout. Beoordeel vervolgens of de regel nog actueel is. Sommige uitzonderingen zijn geen concurrentievoordeel, maar littekens van een probleem dat allang niet meer bestaat.

Een bruikbare functionele matrix bevat minimaal:

Deze matrix wordt later de basis voor scope, acceptatietesten en verantwoordelijkheid na de livegang.

Controleer eigenaarschap en toegang vóór de planning

Een organisatie kan economisch eigenaar zijn van een webshop en toch onvoldoende toegang hebben om deze te migreren. Controleer daarom vroeg wie beschikt over:

• broncode en volledige repositoryhistorie;
• database en recente back-ups;
• beheerdersaccounts;
• hosting, DNS en domeinregistratie;
• API-sleutels en documentatie;
• cloudomgevingen en externe services;
• accounts bij betaalproviders en vervoerders;
• analytics, Tag Manager, Search Console en advertentieplatformen;
• licenties voor afbeeldingen, fonts en externe componenten;
• intellectuele eigendomsrechten op maatwerkcode;
• exportrechten voor klant- en orderdata.

Bespreek ook de medewerking van de huidige leverancier. Kan deze exports maken, databasevelden toelichten en redirects op de oude omgeving activeren? Wat gebeurt er wanneer het contract wordt beëindigd? Een technisch haalbare migratie kan vertragen als toegang pas tijdens de laatste projectmaand wordt geregeld.

Data-eigenaarschap betekent bovendien niet automatisch dat ieder gegeven onbeperkt moet worden meegenomen. Persoonsgegevens, bewaartermijnen en marketingtoestemming vragen om een afzonderlijke beoordeling. Migreer wat operationeel en juridisch nodig is, niet automatisch iedere historische tabel omdat die toevallig bestaat.

Ontwerp eerst het nieuwe datamodel

Bij een maatwerkmigratie is veldmapping onvoldoende. De bestaande database kan entiteiten bevatten die in Shopify anders worden gemodelleerd of helemaal niet bestaan. Ontwerp daarom eerst de gewenste datastructuur.

Breng onder meer in kaart:

• producten, varianten, bundels en configuraties;
• categorieën, collecties en navigatie;
• merken, leveranciers en productfamilies;
• attributen, specificaties en filterwaarden;
• prijzen, valuta, kortingen en klantafspraken;
• voorraadlocaties, reserveringen en levertijden;
• klanten, bedrijven, contactpersonen en vestigingen;
• adressen, voorkeuren en toestemming;
• orders, orderregels, betalingen en refunds;
• fulfilments, retouren en facturen;
• content, downloads en vertalingen;
• relaties met ERP-, PIM- en andere identifiers.

Shopify biedt naast standaardvelden metafields en metaobjects voor gestructureerde aanvullende informatie. Dat maakt veel rijke product- en contentmodellen mogelijk. Toch moet niet ieder databaseveld een metafield worden. Alleen informatie die nodig is voor beheer, storefront, koppelingen, feeds of rapportage hoort in het nieuwe model.

Maak voor ieder veld afspraken over bron, formaat, validatie, synchronisatierichting en eigenaarschap. Wanneer het ERP de prijs beheert en het PIM de producttekst, moet Shopify niet ongemerkt een derde waarheid creëren.

Producten, varianten en configuraties migreren

Productdata kan via CSV, een migratietool of de Shopify Admin API worden geïmporteerd. Shopify noemt deze routes zelf als mogelijkheden bij een overstap en adviseert de migratiemethode af te stemmen op de hoeveelheid en complexiteit van de data.¹

Een eigen productmodel vraagt doorgaans om expliciete mapping van:

• interne product-ID en SKU;
• titels, omschrijvingen en statussen;
• varianten en optiecombinaties;
• verkoopprijzen en vergelijkingsprijzen;
• voorraad en voorraadlocaties;
• categorieën en collecties;
• kenmerken en filters;
• media, documenten en alt-teksten;
• SEO-titels en meta descriptions;
• bundels en samengestelde artikelen;
• cross-sell- en upsellrelaties;
• vertalingen;
• externe ERP- en PIM-ID’s.

Shopify ondersteunt tot 2.048 varianten per product.² Het maximum zegt echter niet of het bestaande productmodel goed past. Een configurator met duizenden theoretische combinaties, berekende prijzen of afhankelijke keuzes moet meestal anders worden ontworpen. Mogelijke oplossingen zijn het opsplitsen van producten, line item properties, een configuratie-app of een externe configurator die een geldige orderregel aan Shopify doorgeeft.

Voer vóór de migratie datacleaning uit. Dubbele SKU’s, vrije tekst in specificatievelden, inconsistente kleuren en ontbrekende relaties worden door een nieuw platform niet vanzelf beter. Slechte brondata wordt vooral sneller en fraaier zichtbaar.

Klanten en accounts

Klantprofielen, adressen, tags en bepaalde aanvullende gegevens kunnen worden gemigreerd. Controleer daarbij dubbele accounts, ongeldige e-mailadressen, bedrijfsrelaties, segmenten en marketingtoestemming.

Wachtwoorden vormen een apart onderdeel. Shopify vermeldt dat klantwachtwoorden vanwege externe versleuteling niet via een customer CSV vanuit een andere webshop kunnen worden gemigreerd.³ Bij klassieke accounts moeten klanten daarom een nieuw wachtwoord instellen. De nieuwere Shopify-klantaccounts werken met een eenmalige verificatiecode per e-mail en hebben geen wachtwoord nodig.⁴

Bereid de overgang communicatief voor:

• leg uit waarom klanten opnieuw moeten inloggen of activeren;
• verstuur geen activatieverzoek voordat de omgeving gereed is;
• voorkom dat meerdere campagnes elkaar overlappen;
• test accountmails in alle talen;
• maak klantenservice bekend met de nieuwe procedure;
• monitor mislukte aanmeldingen na livegang.

Voor B2B is een eenvoudige customer-import vaak onvoldoende. Bedrijven, locaties, contactpersonen, rollen, betaalvoorwaarden, catalogi en orderrechten moeten als samenhangend model worden ontworpen.

Orderhistorie, facturen en serviceprocessen

Historische orders kunnen via een migratie-app of API worden overgezet, maar bepaal eerst waarom de geschiedenis in Shopify nodig is. Klantenservice wil misschien eerdere aankopen kunnen vinden, klanten willen orders terugzien in hun account en marketing wil segmenteren op koopgedrag.

Inventariseer per order:

• klant en afleveradres;
• orderregels en historische productgegevens;
• prijzen, korting, btw en valuta;
• betaalstatus en betaalmethode;
• fulfilment en tracking;
• refunds en retouren;
• opmerkingen en interne labels;
• factuurnummer en documenten;
• externe ERP- en logistieke ID’s.

Niet ieder historisch detail hoeft als actieve Shopify-order beschikbaar te zijn. Een read-only archief kan voor oude jaren praktischer en goedkoper zijn. Maak daarbij duidelijke afspraken over toegang, beveiliging, bewaartermijnen en exportmogelijkheden.

Facturen vragen extra aandacht. Shopify is niet automatisch de boekhoudkundige bron. In veel organisaties maakt het ERP of boekhoudsysteem de officiële factuur. Test daarom de volledige keten van bestelling tot financiële verwerking, inclusief creditnota’s, terugbetalingen en deelzendingen.

ERP-, PIM-, WMS- en andere koppelingen opnieuw ontwerpen

Een bestaande koppeling kan zelden ongewijzigd blijven. De externe systemen mogen hetzelfde zijn, maar endpoints, datamodellen, gebeurtenissen en foutafhandeling veranderen.

Beantwoord per integratie minimaal deze vragen:

• welk systeem is bronhouder van ieder gegeven?
• loopt de synchronisatie realtime, periodiek of handmatig?
• welke richting beweegt de data?
• welke Shopify-objecten en API’s zijn nodig?
• hoe worden identifiers tussen systemen gekoppeld?
• wat gebeurt er bij dubbele of vertraagde berichten?
• hoe worden fouten gelogd en opnieuw aangeboden?
• wie krijgt een melding bij uitval?
• hoe worden API-wijzigingen beheerd?
• welke capaciteit is nodig tijdens piekbelasting?

Voor grotere datasets biedt Shopify asynchrone bulkbewerkingen via de GraphQL Admin API. Daarmee kunnen grote hoeveelheden data worden opgehaald of geïmporteerd zonder iedere mutatie als losse synchrone handeling uit te voeren.⁵ Dat is nuttig bij initiële migraties, maar vervangt geen goed integratieontwerp.

Test niet alleen de ideale route. Simuleer ook time-outs, ongeldige data, dubbele orders, tijdelijk onbereikbare systemen, gedeeltelijke fulfilments en prijsverschillen. Een koppeling is pas betrouwbaar wanneer duidelijk is wat er gebeurt als één systeem een slechte dag heeft.

Hoe vertaal je maatwerk naar Shopify?

Voor iedere functie zijn grofweg vijf routes beschikbaar.

1. Shopify-standaardfunctionaliteit

Gebruik de standaard wanneer deze het proces goed ondersteunt. Dat verlaagt beheerlast en afhankelijkheid. Een historische maatwerkfunctie kan inmiddels gewoon onderdeel zijn van Shopify.

2. Een bestaande app

Een volwassen app kan sneller en goedkoper zijn dan eigen ontwikkeling. Beoordeel functionaliteit, datatoegang, support, prijsmodel, performance, internationale geschiktheid en exitmogelijkheden. Een app is geen detail wanneer een bedrijfskritisch proces ervan afhankelijk wordt.

3. Shopify Functions en extensies

Shopify Functions kunnen backendlogica aanpassen op vastgestelde punten, bijvoorbeeld voor kortingen, checkoutvalidatie, bezorgopties en betaalregels.⁶ Extensies voegen functionaliteit toe aan ondersteunde onderdelen van de storefront, checkout en klantaccounts.

De mogelijkheden verschillen per abonnement en type app. Aanpassingen in de informatie-, verzend- en betaalstappen van de checkout zijn deels voorbehouden aan Shopify Plus. Ook custom apps met Shopify Functions hebben andere beschikbaarheid dan publieke apps.⁷ Onderzoek dit vóór de platformkeuze, niet nadat de checkout al is ontworpen.

4. Een custom app of externe service

Unieke functies kunnen in een custom app of externe service worden gebouwd. Shopify blijft dan het commerceplatform, terwijl specialistische logica buiten de kern draait. Zorg voor monitoring, documentatie, tests en duidelijk eigenaarschap.

5. Het proces vereenvoudigen of verwijderen

Dit is vaak de meest waardevolle route. Een uitzondering die weinig wordt gebruikt maar veel onderhoud vraagt, hoeft niet automatisch terug. Laat de proceseigenaar bewust beslissen in plaats van alle oude software als stilzwijgende eis te behandelen.

Checkout en Shopify Plus vroeg beoordelen

Bij maatwerksoftware is de checkout regelmatig vergaand aangepast. Er kunnen extra stappen, velden, prijsberekeningen, kredietcontroles of afleverkeuzes in zitten. Shopify beschermt de checkoutarchitectuur en biedt extensiepunten, maar geen onbeperkte vrijheid om iedere kernstap te herschrijven.

Maak daarom een checkoutmatrix met:

• verplichte en optionele velden;
• B2C- en B2B-routes;
• validaties;
• betaalmethoden per klant of land;
• bezorgmethoden en uitsluitingen;
• afhalen en meerdere locaties;
• kortingen en promoties;
• belasting- en factuurgegevens;
• ordergoedkeuring;
• tracking en consent;
• post-purchaseprocessen.

Beoordeel per behoefte of deze standaard, via een publieke app, met Functions of alleen binnen Shopify Plus kan worden gerealiseerd. Shopify Plus is niet automatisch nodig vanwege omzet of productaantal. De doorslag hoort te liggen bij concrete functionaliteit, beheer, organisatie en businesscase.

Internationale verkoop opnieuw structureren

Een maatwerkplatform kan per land afzonderlijke domeinen, databases, catalogi of codevarianten gebruiken. Shopify Markets ondersteunt onder meer marktspecifieke talen, prijzen, domeinen en submappen.⁸ Shopify voegt bij gepubliceerde talen automatisch hreflang-verwijzingen toe en neemt deze talen op in sitemaps.⁹

Dat betekent niet dat iedere internationale architectuur in één Shopify-store past. Beoordeel per markt:

• merk en juridische entiteit;
• assortiment en voorraad;
• prijsstrategie en valuta;
• betaal- en verzendmethoden;
• lokale wet- en regelgeving;
• domeinstrategie;
• taal en contentlokalisatie;
• klantenservice en fulfilment;
• ERP- en financiële processen;
• rapportage en teamrechten.

Soms is één store met Markets logisch. In andere gevallen zijn meerdere stores beter, bijvoorbeeld bij afzonderlijke merken, teams, entiteiten of sterk afwijkende catalogi. Ontwerp eerst het operationele model en kies daarna de Shopify-structuur.

B2B-processen vragen meer dan klanttags

Een maatwerk B2B-webshop bevat vaak processen die in een consumentenwebshop nauwelijks voorkomen:

• bedrijven met meerdere locaties;
• inkopers en goedkeurders;
• contractprijzen en assortimenten;
• offertes en conceptorders;
• kredietlimieten en betaaltermijnen;
• bestelreferenties en kostenplaatsen;
• minimale afnames en verpakkingseenheden;
• meerdere afleveradressen;
• snelle herhaalbestellingen;
• vertegenwoordigers die namens klanten bestellen.

Beschrijf niet alleen de zichtbare functies. Leg ook vast waar prijzen vandaan komen, wanneer krediet wordt gecontroleerd, wie een order mag aanpassen en hoe de order in ERP en finance terechtkomt.

Shopify biedt B2B-functionaliteit, maar de precieze mogelijkheden verschillen per abonnement en use case. Complexe B2B-omgevingen kunnen daarnaast apps, integraties of maatwerk nodig hebben. Vergelijk dit eerlijk met Magento of een gemoderniseerde maatwerkoplossing wanneer B2B het hart van de operatie vormt.

Het bestaande ontwerp wordt opnieuw gebouwd

De frontend van maatwerksoftware kan niet rechtstreeks als Shopify-thema worden overgezet. Het visuele ontwerp kan als referentie dienen, maar templates, components en interacties worden binnen de Shopify-architectuur opnieuw ontwikkeld.

Dat is een kans om te verbeteren:

• mobiele navigatie en productvindbaarheid;
• collectie- en zoekervaring;
• filters en specificaties;
• productpagina’s;
• configuratie en variantenkeuze;
• snelheid en toegankelijkheid;
• contentbeheer met herbruikbare sections;
• landingspagina’s voor SEO en campagnes;
• cross-sell, upsell en merchandising;
• meetbaarheid van belangrijke interacties.

Kopieer niet automatisch iedere oude pagina. Gebruik analytics, zoekdata, omzet en gebruikersfeedback om te bepalen wat moet blijven, verbeteren of verdwijnen.

Bescherm SEO-waarde vanaf het begin

SEO mag niet als laatste controlepunt aan een technisch project worden toegevoegd. Nieuwe collecties, templates, contentmodellen en URL’s ontstaan al tijdens strategie en ontwerp.

Maak vóór de bouw een nulmeting van:

• alle indexeerbare URL’s;
• organisch verkeer en omzet per pagina;
• rankings en zoekopdrachten;
• backlinks;
• titles, descriptions en headings;
• canonicals en robotsinstellingen;
• structured data;
• interne links;
• hreflang en internationale varianten;
• XML-sitemaps;
• afbeeldingen en documenten;
• huidige 404- en redirectregels.

Maak daarna een één-op-één redirectmatrix. Iedere waardevolle oude URL krijgt de inhoudelijk beste nieuwe bestemming. Google adviseert bij een siteverhuizing met gewijzigde URL’s permanente server-side redirects te gebruiken, interne links aan te passen en niet veel oude pagina’s naar één irrelevante bestemming zoals de homepage te sturen.¹⁰

Controleer vóór en na livegang:

• statuscodes en redirectketens;
• canonicals;
• indexeerbaarheid;
• robots.txt en sitemap;
• structured data;
• metadata en headings;
• hreflang;
• interne links;
• 404-fouten;
• Search Console-verificatie;
• organische landingspagina’s, omzet en conversies.

Tijdelijke schommelingen zijn mogelijk. Het doel is niet een theoretische garantie op identieke rankings, maar het zorgvuldig overdragen van inhoud, relevantie, links en technische signalen.

Tracking, feeds en marketingtechniek moeten mee

Een nieuwe webshop kan technisch orders verwerken en toch verkeerde marketingdata rapporteren. Inventariseer daarom:

• analytics en e-commerce-events;
• consentmanagement;
• Google Tag Manager;
• advertentiepixels en server-side meting;
• Google Merchant Center en productfeeds;
• affiliate- en marketplacefeeds;
• e-mailmarketing en automatiseringen;
• reviews en loyaliteit;
• calltracking en CRM;
• dashboards en dataplatformen.

Definieer gebeurtenissen en datalayers opnieuw in plaats van oude scripts blind te kopiëren. Test omzet, belasting, verzending, kortingen, valuta, refunds en attributie. Vergelijk tijdens acceptatie dezelfde testorders in Shopify, analytics, advertentieplatformen, ERP en finance.

Welke migratiemethode past?

Shopify onderscheidt handmatige invoer, CSV-import, migratie-apps en API-gebaseerde migratie.¹¹ Bij maatwerksoftware is vaak een combinatie nodig.

CSV

Geschikt voor overzichtelijke producten en klanten met een voorspelbaar veldmodel. Minder geschikt voor complexe relaties, rijke orderhistorie en maatwerkentiteiten. Shopify waarschuwt bovendien dat wijzigingen aan product-CSV’s invloed kunnen hebben op beeldrelaties wanneer de structuur verkeerd wordt behandeld.¹²

Migratie-app

Handig wanneer de bron wordt ondersteund. Voor volledig eigen software is dit minder waarschijnlijk, al kan een generieke database- of feedroute soms bruikbaar zijn.

Maatwerkscripts en API’s

Meestal de belangrijkste route bij complexe maatwerksoftware. Scripts lezen data uit database, exports of API’s, transformeren deze naar het nieuwe model en schrijven ze gecontroleerd naar Shopify.

Archief

Niet alle historische informatie hoeft naar Shopify. Een beveiligd, doorzoekbaar archief kan geschikt zijn voor oude orders, logs en documenten die nog wel raadpleegbaar moeten blijven.

Leg de transformatie vast in herhaalbare scripts. Een handmatig gecorrigeerde proefimport die niet opnieuw kan worden uitgevoerd, is geen robuust migratieproces.

Werk met proefmigraties, vergelijking en een delta-import

De bestaande webshop blijft tijdens het project meestal orders, klanten en wijzigingen verwerken. Eén export aan het begin is daarom niet voldoende.

Een betrouwbaar migratieproces bestaat uit meerdere rondes:

1. Technische proef: test toegang, mapping en API-gedrag met een kleine dataset.
2. Representatieve proef: migreer ingewikkelde producten, klanten, landen en orders.
3. Volledige proefmigratie: laad de complete dataset en meet aantallen, relaties en fouten.
4. Acceptatie: laat proceseigenaren de nieuwe omgeving met echte scenario’s testen.
5. Delta-import: verwerk vlak voor livegang alle wijzigingen sinds de volledige proef.
6. Reconciliatie: vergelijk aantallen, totalen en steekproeven na de definitieve import.

Vergelijk niet alleen recordaantallen. Controleer bijvoorbeeld:

• prijzen en valuta;
• variant-SKU’s;
• media en documenten;
• voorraad per locatie;
• klant-bedrijfrelaties;
• ordertotalen, korting en btw;
• fulfilments en refunds;
• vertalingen;
• collecties en filters;
• externe identifiers.

Maak vooraf duidelijk welke wijzigingen tijdens de cutover tijdelijk worden geblokkeerd. Een korte productfreeze is vaak mogelijk, maar orders stoppen zelden op verzoek van het projectteam.

Test complete bedrijfsprocessen

Technische unit tests zijn belangrijk, maar onvoldoende. De organisatie moet van begin tot eind aantonen dat kritieke processen werken.

Test onder meer:

• zoeken, filteren en configureren;
• B2C- en B2B-inloggen;
• prijzen, promoties en staffels;
• voorraad en levertijden;
• verschillende landen, talen en valuta;
• betalingen, mislukte betalingen en refunds;
• verzending, afhalen en deelzendingen;
• belasting en facturatie;
• ERP-, PIM-, WMS- en CRM-synchronisatie;
• retouren en klantenservice;
• tracking, consent en feeds;
• piekbelasting;
• uitval en herstel van koppelingen;
• rollen en toegangsrechten.

Koppel iedere kritieke bedrijfsregel uit de functionele matrix aan minimaal één acceptatietest. Zo wordt “het lijkt goed te werken” vervangen door aantoonbaar gedrag.

Hoe verloopt een professioneel migratietraject?

1. Strategie en haalbaarheid

We onderzoeken bedrijfsdoelen, organisatie, huidige knelpunten en alternatieven. De uitkomst kan ook zijn dat migreren niet verstandig is.

2. Technische discovery

Broncode, database, processen, integraties, accounts en infrastructuur worden geïnventariseerd. Onzekerheden worden expliciet gemaakt.

3. Functionele gap-analyse

Per bestaande functie bepalen we de zakelijke waarde en de oplossing in Shopify, een extern systeem of een aangepast proces.

4. Doelarchitectuur en datamodel

We ontwerpen systemen, verantwoordelijkheden, synchronisaties, Shopify-structuur en datamapping.

5. UX-design en development

De storefront, templates, themaonderdelen, apps, Functions en custom oplossingen worden ontwikkeld.

6. Integraties en migratiescripts

Koppelingen krijgen mapping, logging, monitoring en foutafhandeling. Herhaalbare scripts verwerken de data.

7. Proefmigratie en acceptatie

Gebruikers testen realistische scenario’s. Afwijkingen worden opgelost voordat de livegang onder tijdsdruk komt.

8. SEO- en marketingmigratie

Redirects, content, metadata, tracking, consent, feeds en campagnes worden voorbereid en gecontroleerd.

9. Cutover en delta-import

Via een gedetailleerd draaiboek worden laatste data, domein, redirects en productie-integraties overgezet.

10. Nazorg en optimalisatie

Na livegang monitoren we orders, koppelingen, foutmeldingen, SEO, tracking, feeds en conversie. Daarna begint structurele doorontwikkeling.

Hoe lang duurt de migratie?

Een overzichtelijke maatwerkwebshop kan ongeveer vier tot zes maanden vragen. Een professionele omgeving met verschillende koppelingen, veel data en internationale verkoop vraagt vaak zes tot negen maanden. Complexe B2B-, configuratie- of enterpriseprojecten kunnen negen tot achttien maanden of langer duren.

De planning wordt vooral beïnvloed door:

• beschikbaarheid van broncode, data en documentatie;
• medewerking van de bestaande leverancier;
• hoeveelheid verborgen bedrijfslogica;
• kwaliteit van product- en klantdata;
• aantal externe systemen en leveranciers;
• internationale en B2B-complexiteit;
• ontwikkeling van custom apps;
• interne besluitvorming;
• beschikbaarheid van proceseigenaren voor testen;
• gewenste livegangsperiode.

Plan eerst discovery en pas daarna een harde livegang. Een datum kiezen voordat duidelijk is wat de software doet, is optimisme met een kalenderuitnodiging.

Belangrijkste risico’s bij een maatwerkmigratie

De scope wordt gebaseerd op schermen

Veel logica draait op de achtergrond. Onderzoek code, database, jobs en integraties, niet alleen wat in de browser zichtbaar is.

De oude webshop wordt letterlijk herbouwd

Daarmee verhuist ook alle historische complexiteit. Beoordeel per functie of deze nog waarde heeft.

De data-export blijkt onvolledig

Vraag vroeg om een representatieve export en test relaties, encodings, media en externe identifiers.

Eén developer bezit alle kennis

Leg kennis vast en betrek meerdere proceseigenaren. Persoonsafhankelijkheid is juist een reden om te migreren.

Shopify-beperkingen worden te laat ontdekt

Onderzoek productmodel, checkout, B2B en integraties vóór het ontwerp definitief wordt.

Koppelingen worden als bijzaak behandeld

Een mooie storefront helpt weinig als prijs, voorraad, fulfilment of facturatie niet klopt.

Er is geen reproduceerbare delta-import

Leg vast welke data tijdens de bouw verandert en hoe deze vlak voor livegang wordt bijgewerkt.

SEO en tracking starten vlak voor livegang

URL’s, content, templates en events worden tijdens het hele project bepaald. SEO en analytics moeten vanaf het begin meedoen.

De oude omgeving wordt te snel uitgezet

Bewaar een gecontroleerde read-only periode en herstelmogelijkheid totdat data, administratie en processen zijn gevalideerd.

Wanneer is de migratie geslaagd?

Een geslaagde migratie levert meer op dan een werkende homepage. Maak vóór de start een nulmeting en beoordeel na livegang onder meer:

• percentage foutloos verwerkte orders;
• juiste prijzen, voorraad, belasting en fulfilment;
• beschikbaarheid en aantal incidenten;
• doorlooptijd van commerciële wijzigingen;
• interne beheertijd;
• afhankelijkheid van schaarse technische kennis;
• conversie per apparaat, markt en klanttype;
• checkoutuitval;
• organische zichtbaarheid en omzet;
• kwaliteit van feeds en tracking;
• integratiefouten en hersteltijd;
• supportvragen van klanten en medewerkers;
• structurele platform- en ontwikkelkosten.

Meet techniek direct en commerciële resultaten over een representatieve periode. Houd rekening met seizoen, campagnes, assortiment en marktverschillen.

Welke vragen stel je aan een migratiebureau?

Stel bij een migratie vanaf maatwerksoftware minimaal deze vragen:

1. Welke migraties vanaf eigen of onbekende software hebben jullie uitgevoerd?
2. Hoe onderzoeken jullie broncode, database en verborgen bedrijfslogica?
3. Welke toegang en documentatie hebben jullie vooraf nodig?
4. Wie voert strategie, UX, development, data, integraties en SEO daadwerkelijk uit?
5. Hoe bepalen jullie of Shopify werkelijk geschikt is?
6. Durven jullie ook een ander platform of behoud van de huidige oplossing te adviseren?
7. Hoe maken jullie een functionele gap-analyse?
8. Hoe wordt bepaald wat standaard, app, Function, koppeling of maatwerk wordt?
9. Welke ervaring hebben jullie met ERP-, PIM-, WMS- en CRM-integraties?
10. Hoe ontwerpen jullie bronhouderschap en synchronisatierichtingen?
11. Hoe worden migratiescripts herhaalbaar en controleerbaar gemaakt?
12. Hoe controleren jullie aantallen, relaties en financiële totalen?
13. Hoe worden klantaccounts en wachtwoorden afgehandeld?
14. Wat gebeurt er met oude orders, facturen en documenten?
15. Hoe beschermen jullie SEO-waarde en bestaande URL’s?
16. Hoe testen jullie checkout, tracking, feeds en consent?
17. Hoe ziet de delta-import en het livegangdraaiboek eruit?
18. Is er een terugvalscenario en hoe lang blijft de oude omgeving beschikbaar?
19. Wie wordt eigenaar van thema, custom apps, code, accounts en documentatie?
20. Hoe worden onzekerheden, scopewijzigingen en nazorg geprijsd?

Een bureau dat na één verkoopgesprek al een vaste prijs en exacte livegang belooft zonder de maatwerksoftware te onderzoeken, beschikt óf over bijzondere helderziendheid óf over een ruim begrip van het woord “scope”.

Van maatwerksoftware naar Shopify migreren met Shopcommerce

Shopcommerce behandelt deze migratie als een combinatie van strategie, softwareanalyse, e-commerceontwikkeling, datamigratie en online groei. Het project begint niet met het kiezen van een thema, maar met het begrijpen van de huidige bedrijfsprocessen en de gewenste organisatie.

Onze specialisten voor strategie, UX-design, Shopify-development, koppelingen, SEO, SEA, productdata en content werken vanuit één plan. Daardoor worden beslissingen niet los van elkaar genomen. Een nieuw productmodel beïnvloedt filters, feeds en SEO. Een aangepaste checkout raakt tracking. Een internationale structuur heeft gevolgen voor content, domeinen, prijzen en ERP.

We adviseren platformneutraal. Shopify kan zeer geschikt zijn wanneer standaardisatie, beheerbaarheid, internationale groei en een beheerd kernplatform belangrijk zijn. Wanneer Magento, modernisering van de bestaande oplossing of een hybride architectuur beter aansluit, moet dat eveneens bespreekbaar zijn.

Als Shopify de juiste richting is, zorgen we dat data, functionaliteit, koppelingen, SEO en marketingtechniek als één migratieprogramma worden behandeld. Zo wordt niet alleen software vervangen, maar ontstaat een platform waarop teams daadwerkelijk sneller en betrouwbaarder kunnen werken.

Conclusie

Van maatwerksoftware naar Shopify migreren kan veel operationele rust en commerciële snelheid opleveren. Shopify neemt een groot deel van hosting en kernplatformonderhoud over en biedt een breed ecosysteem voor storefront, marketing, internationale verkoop en integraties.

De overstap is echter alleen verstandig wanneer Shopify de essentiële bedrijfsprocessen goed kan dragen. Daarvoor moet eerst duidelijk worden welke regels, data en afhankelijkheden in de maatwerksoftware verborgen zitten.

Migreer daarom niet de oude code, maar de waardevolle functies. Gebruik Shopify-standaard waar dat kan, apps en Functions waar dat logisch is, externe systemen voor specialistische verantwoordelijkheden en maatwerk alleen waar het aantoonbaar verschil maakt. Laat verouderde uitzonderingen achter.

Met grondige discovery, een nieuw datamodel, herhaalbare migratiescripts, integratietesten, een complete redirectmatrix en een gecontroleerde delta-import kan de organisatie overstappen zonder cruciale kennis of continuïteit te verliezen.

Veelgestelde vragen over migreren van maatwerksoftware naar Shopify

Kan maatwerksoftware automatisch naar Shopify worden gemigreerd?

Meestal niet volledig. Producten, klanten en andere data kunnen via CSV, API’s of maatwerkscripts worden overgezet. Broncode, databaseprocedures, checkoutlogica en eigen modules kunnen niet rechtstreeks naar Shopify worden gekopieerd. De zakelijke functies moeten opnieuw worden ontworpen.

Kan de bestaande broncode worden hergebruikt?

Soms kunnen losse algoritmen, integratiekennis of frontendcomponenten als referentie dienen, maar de bestaande applicatiecode past doorgaans niet in de Shopify-architectuur. Hergebruik moet per onderdeel technisch en juridisch worden beoordeeld.

Hoe ontdek je wat de maatwerksoftware precies doet?

Door broncode, database, jobs, API’s, configuratie en logs te onderzoeken en dit te combineren met interviews en gebruiksdata. De uitkomst wordt vastgelegd in een functionele matrix met bedrijfsregels, eigenaarschap, nieuwe oplossingen en tests.

Kunnen alle producten en varianten mee?

Meestal kunnen de productgegevens worden gemigreerd. Complexe configuraties, afhankelijke opties of berekende producten passen mogelijk niet rechtstreeks in het standaard productmodel. Dan is een aangepaste structuur, app of externe configurator nodig.

Kunnen klantwachtwoorden worden overgezet?

Nee. Extern versleutelde wachtwoorden kunnen niet via CSV in Shopify worden geïmporteerd. Klanten activeren een nieuw wachtwoord of gebruiken een eenmalige verificatiecode bij de nieuwere klantaccounts.

Kan de volledige orderhistorie worden meegenomen?

Ja, meestal via API’s of migratiescripts. Bepaal vooraf welke statussen, betalingen, fulfilments, refunds, facturen en documenten nodig zijn. Voor oudere informatie kan een beveiligd read-only archief praktischer zijn.

Kunnen bestaande ERP- en PIM-koppelingen blijven werken?

Hetzelfde ERP of PIM kan vaak behouden blijven, maar de koppeling moet vrijwel altijd worden aangepast of opnieuw gebouwd. Shopify gebruikt andere objecten, API’s, events en identificaties dan de maatwerksoftware.

Kan unieke prijs- of checkoutlogica worden behouden?

Vaak wel, maar de oplossing verschilt. Mogelijkheden zijn Shopify-standaardfunctionaliteit, apps, Shopify Functions, Shopify B2B, een custom app of logica in het ERP. Sommige checkoutaanpassingen vereisen Shopify Plus.

Heb je Shopify Plus nodig bij maatwerksoftware?

Niet automatisch. Het productaantal, de omzet of het feit dat de oude webshop maatwerk is, vormt op zichzelf geen reden. Plus wordt relevant wanneer specifieke checkout-, B2B-, organisatie- of integratiemogelijkheden aantoonbare waarde bieden.

Verlies je SEO-posities door de migratie?

Een migratie brengt risico mee, maar verlies is niet vanzelfsprekend. Inventariseer waardevolle URL’s en content, maak één-op-één redirects, behoud relevante signalen en monitor indexatie, verkeer en omzet na livegang.

Hoe voorkom je dat recente orders ontbreken?

Werk met een volledige proefmigratie en een herhaalbare delta-import. Kort voor livegang worden nieuwe of gewijzigde klanten, orders, producten en andere relevante gegevens sinds de vorige migratieronde verwerkt.

Wat kost een migratie van maatwerksoftware naar Shopify?

Een overzichtelijk professioneel traject begint indicatief rond € 50.000 tot € 90.000. Omgevingen met maatwerkdesign, complexe data, ERP-koppelingen en meerdere markten liggen vaak tussen € 90.000 en € 180.000. Grote B2B- of integratie-intensieve projecten kunnen € 180.000 tot € 350.000 of meer kosten.

Hoe lang duurt het traject?

Reken voor een overzichtelijke omgeving op ongeveer vier tot zes maanden. Professionele projecten met koppelingen vragen vaak zes tot negen maanden. Complexe B2B-, configuratie- en enterpriseomgevingen kunnen negen tot achttien maanden of langer duren.

Kan de bestaande webshop tijdens het project online blijven?

Ja. Shopify wordt doorgaans parallel ontwikkeld terwijl de bestaande webshop blijft verkopen. Het livegangdraaiboek bepaalt welke data vlak voor de overstap opnieuw wordt verwerkt en of tijdelijk een beperkte beheerfreeze nodig is.

Wanneer is Shopify niet de beste bestemming?

Wanneer cruciale processen niet goed binnen Shopify en het bijbehorende ecosysteem passen, of wanneer volledige technische controle essentieel is. In zulke gevallen kunnen modernisering van de bestaande software, Magento of een hybride architectuur verstandiger zijn.

Bronnen en verantwoording

De technische platformclaims in deze blog zijn gecontroleerd aan de hand van officiële documentatie van Shopify en Google. De kosten en doorlooptijden zijn indicatieve inschattingen van Shopcommerce op basis van de beschreven projectomvang. Werkelijke prijzen en planningen hangen af van softwarearchitectuur, data, maatwerk, koppelingen, documentatie, markten en beschikbare capaciteit.