Byta e-handelsplattform utan att tappa order och kunder
Kenneth Lyngshede
Kassan blir långsam under kampanjer. Kundservice letar efter order som borde ha nått affärssystemet. Samtidigt ligger en offert på bordet för att byta e-handelsplattform, med ny design och en lovande tidsplan.
Ni behöver kunna skilja problemen i dagens lösning från riskerna i nästa. Beslutet ska gå att försvara med marginal, fungerande orderflöden och tydligt ansvar efter lanseringen. En teknisk genomgång kan också visa att er nuvarande plattform går att behålla.
Mät nuläget innan ni bestämmer att byta plattform
Börja med att dokumentera var ni tar emot affärer. Det kan vara egen webb, app, kundportal, återförsäljarportal, reservdelsportal, marknadsplats och elektroniskt orderutbyte. Namnge systemet bakom varje kanal och vem som ansvarar för dess data.
Ta sedan fram baslinjer för organisk trafik, indexerade adresser, konverteringsgrad, avbrott i kassan och svarstid. Lägg till ordersynkfel och intäkt per kanal. Bestäm hur varje mått beräknas, så att jämförelsen efter bytet använder samma definitioner.
Lönsamheten behöver ett eget underlag, eftersom marknadens utveckling säger begränsat om vad just ert företag bör investera i. Enligt PostNords E-barometer för första kvartalet 2025 växte e-handeln med 9 procent under kvartalet, medan apotek ökade 24 procent och böcker och media minskade 1 procent.
Ta fram snittorder och täckningsbidrag, returgrad och rabattberoende, kostnad per kundserviceärende och omfattningen av manuell orderhantering. Då ser ni vilka köp som bidrar till resultatet och vilka arbetsmoment självservice kan ta bort.
Dela upp måtten på återköpare, nya kunder och produktkategori. Ett smidigare köpflöde kan ge fler order med svagt täckningsbidrag. En förbättrad offertfunktion kan samtidigt frigöra tid hos säljarna, även när webbens konverteringsgrad står still.
Jämför också offerten med vad ni faktiskt kommer att betala efteråt. Resonemanget om tre poster som saknas i er TCO-kalkyl hjälper er att granska kostnader utanför själva införandet.
En praktisk tumregel är att först undersöka avgränsade fel i befintliga flöden. En teknisk genomgång kan visa vilka delar som behöver stabiliseras och vilka som fungerar.
Det arbetet kräver tillgång till data och en affärsägare som kan fatta beslut. Om plattformen stöder era behov och problemen går att avgränsa kan genomgången vara det bättre första steget. Ett byte blir mer motiverat när centrala affärsregler saknar hållbart stöd.
Byta e-handelsplattform sker i sex faser med grindar
Ett plattformsbyte behöver verifierbara grindar. Varje grind anger vad ni måste veta innan projektet får gå vidare. Projektledaren behöver kunna visa underlaget när affärsägaren godkänner nästa steg.
Svensk Handels E-handelsindikator uppskattade svensk e-handels omsättning till 166 miljarder kronor under 2025 och att 71 procent av svenska konsumenter e-handlade under en genomsnittlig månad. Det ger sammanhang åt risken: avbrott kan träffa kunder som återkommer regelbundet.
Använd följande faser som arbetsmodell. Formulera huvudfrågorna utifrån era egna flöden, men behåll kravet på dokumenterade godkännanden.
Nulägesbilden visar vad som fungerar och vad dagens lösning kostar. Innan nästa fas ska baslinjer för trafik, konvertering och ordersynk vara dokumenterade.
Kravställning och scope anger vilka funktioner och integrationer som måste finnas dag ett. Innan nästa fas ska affärsägaren ha godkänt funktionslistan och prioriteringen.
Datamigreringen anger vilka objekt som flyttas och hur de valideras. Innan nästa fas ska antalet objekt stämma före och efter provmigreringen.
Integrationerna beskriver hur produkter, priser, lager och order synkas. Innan nästa fas ska orderflöden klara timeout utan dubbletter.
Test och pilot visar om lösningen klarar verkliga flöden och undantag. Innan nästa fas ska kritiska fel i kassa och orderflöde vara åtgärdade.
Lansering och uppföljning visar om allt fungerar i produktion. Trafik, order och fel ska jämföras dagligen tills driften är verifierad.
Faserna överlappar ofta i kalendern. Integrationer behöver exempelvis påverka datamodellen tidigt. Testfallen bör skrivas medan ni preciserar kraven, så att varje krav får ett tydligt godkännandekriterium.
En grind öppnas däremot först när underlaget håller. Om kundpriser saknas efter provmigreringen behöver någon rätta orsaken och köra om kontrollen. Beslutet behöver bygga på en ny, godkänd kontroll.
Utse även den som får stoppa lanseringen. Rollen behöver mandat från verksamheten och tillgång till testresultaten. Annars riskerar ett bokat lanseringsdatum att väga tyngre än kvarstående orderfel.
Skriv slutligen vad ett godkännande omfattar. Affärsägaren godkänner affärsreglerna, ekonomifunktionen stämmer av belopp och tekniskt ansvarig verifierar överföringarna. Då slipper ni tolka ett allmänt godkännande när ett fel behöver utredas.
Skriv vad som måste fungera dag ett
Ta en befintlig order och följ den genom verksamheten. Börja med sortiment och produktinformation. Fortsätt genom pris, avtal, lagerbesked, kassa, betalning och frakt tills ordern kan behandlas i affärssystemet.
Ta med inloggning, offert och de portaler ni redan använder. En återförsäljare kan behöva se sitt avtalssortiment. Den som beställer reservdelar kan behöva hitta rätt artikel genom en produktkoppling.
Varje funktion behöver ett beskrivet beteende. Formuleringen kundspecifika priser lämnar mycket öppet. Skriv vilka prislistor som gäller, hur kampanjer påverkar dem och vilket pris kunden ska se vid en ändrad kvantitet.
Vi bygger lösningar med funktionsbibliotekets färdigutvecklade funktioner och integrationer, med fast omfattning och fast pris. Funktionerna finns i tre nivåer: Standard används som den är, Anpassad konfigureras efter er affärslogik och Kundunik isoleras så att den inte påverkar resten vid uppgraderingar.
Vi arbetar med Litium, Optimizely och Magento och är Premium Solution Partner till Litium. I kravbilden behöver kopplingar mot affärssystem som Business Central, Monitor eller Jeeves beskrivas med samma precision som funktionerna kunderna använder. Plattformens namn besvarar ingen fråga om era prisregler.
En lösning kan börja som en innehållswebbplats, en produktwebb eller en komplett kundportal och byggas vidare på samma strukturerade grund med samma integration mot affärssystemet. Det gör prioriteringen viktig: funktioner som behövs för att expediera befintliga affärer får företräde framför önskemål som kan vänta.
Fast pris kräver en godkänd funktionslista och en ansvarig som kan svara under kravarbetet. Nya önskemål efter låst scope behöver bli ett nytt beslut med tydlig kostnadspåverkan. Om affärsreglerna fortfarande ändras kan en avgränsad utredning passa bättre innan ni låser leveransen.
Datamigreringen är där de flesta fel uppstår
En produkt kan se korrekt ut på skärmen och ändå ha fel variantkoppling. Ett kundkonto kan finnas efter importen men sakna rätt behörighet. Kontrollera därför relationer och regler tillsammans med själva antalet poster.
Börja med att inventera produkt-, kund-, order-, pris-, lager- och integrationsdata. Definiera därefter en gemensam datamodell och ett fältmappningsschema. Varje källfält behöver en bestämd plats och betydelse i målsystemet.

Rensa och validera sedan uppgifterna i testmiljön. Genomför en provmigrering med avstämning mot affärssystemet innan ni gör ett begränsat produktionssläpp med parallell övervakning. Kontrollerna måste kunna köras om efter varje ändring av importen.
Produktattribut behöver särskild uppmärksamhet. En benämning kan användas på olika sätt i olika produktgrupper. Arbetet med strukturerade PIM-data hjälper er att reda ut betydelsen innan uppgifterna flyttas.
För produkter och SKU:er ska antalet artikelvarianter och deras relationer stämma, annars tappas varianter och attribut i mappningen. Aktiva prislistor och kundspecifika priser ska stämma, eftersom äldre kundprislistor ofta saknas. Antalet kundkonton och deras behörigheter ska stämma, så att roller inte migreras fel. Orderraderna ska stämma mot affärssystemet så att ordernummer och status finns kvar.
Lagersaldon ska stämma vid övergången, annars publiceras inaktuella saldon. Prioriterade gamla webbadresser ska leda rätt, så att gamla sidor inte ger felsidor. Felkvoten per datatyp ska loggas och godkännas före övergången, så att felaktiga rader inte accepteras utan dokumentation.
Checklistan behöver också omfatta adressmappning, permanenta omdirigeringar, metadata, interna länkar och en återställningsplan. Bevara sökbar orderhistorik för reklamationer och ekonomiska avstämningar. Att en order finns i ett arkiv hjälper begränsat om kundservice inte hittar den.
Bestäm vilka personuppgifter som ska flyttas och varför. Dokumentera också hur uppgifter ska hanteras i det gamla systemet, inklusive radering när de inte ska sparas. Vi behandlar personuppgifter enligt GDPR och tillämplig svensk lag.
Tillgängligheten behöver följa med när innehåll och formulär flyttas. PTS rapport om svenska webbplatsers tillgänglighet beskriver omfattande brister på e-handelswebbplatser. Kontrollera därför tangentbordsanvändning, skärmläsare och felmeddelanden även efter importen.
Ge varje dataobjekt en namngiven ägare. Personen ska granska felkvoten och skriftligt godkänna kvarstående avvikelser före produktionsövergången.
Integrationer och test avgör om ni kan lansera
Produkter, priser, lager och order måste överföras enligt bestämda regler. Ange vilket system som äger varje uppgift och vilka händelser som ska skickas tillbaka. Kundspecifika prislistor och minsta orderkvantitet behöver följa samma regler genom hela köpet.
Testa särskilt vad som händer när affärssystemet svarar sent. Ordern kan redan vara mottagen när webbplatsen försöker igen. Idempotens innebär att omkörningen behandlar samma händelse utan att skapa en dubblett.
Ansvarsfördelningen mellan systemen behöver vara begriplig även för verksamheten. Genomgången av integration mellan e-handel och affärssystem ger stöd för att beskriva flödena och deras felhantering.
Inloggning och kundkonto är godkända när prioriterade kundgrupper ser sina uppgifter och ordrar utan manuell hjälp. Prisberäkningen är godkänd när kassans pris stämmer med affärssystemet i samtliga testfall för kundspecifika priser och kampanjpriser. Lagerstatus är godkänd när reservation, restnotering och delleverans följer överenskomna regler. Orderöverföringen är godkänd när samma order skapas endast en gång vid timeout och omkörning.
Betalning och omdirigeringar är godkända när kritiska kassafel saknas och prioriterade gamla adresser leder rätt. Retur och kreditnota är godkända när kreditnotan skapas korrekt i affärssystemet. Tillgängligheten är godkänd när manuella scenarier med tangentbord, skärmläsare och formulär är godkända utöver automatiska kontroller.
Fortsätt genom undantagen som uppstår när ordern ska levereras. Testa fraktval, ombud, paketboxar och utlandsorder utifrån ert sortiment. En paketbox kan passa ett mindre köp och vara olämplig för industriella reservdelar.
Returflödet behöver samma omsorg. Enligt PostNords E-barometer för andra kvartalet 2025 uppgav 14 procent av svenska e-handelskonsumenter att de returnerat ett onlineköp under den senaste månaden. Följ därför returorsak, återbetalning, fraktdifferens och kreditnota hela vägen tillbaka till affärssystemet.
Belastning och manuella scenarier måste få plats
Använd verkliga order- och returscenarier med kontrollerad hantering av personuppgifter. Belastningstesta med kampanjtoppar och samtidiga batchkörningar i affärssystemet. Ta med delleveranser och restnoteringar, eftersom de påverkar både lagersaldo och kundkommunikation.
Komplettera automatiska kontroller med manuell sökning, filtrering, inloggning, offert, betalning och leveransval. PTS lägesbild av digitala miljöer betonar att automatiska mätningar inte fångar alla problem med begriplighet, språk och informationsstruktur. Låt även kundservice prova de arbetsmoment de ska utföra efter lanseringen.
Inför produktionsövergången behöver ni frysa masterdata och hämta de ändringar som tillkommit sedan provmigreringen. Verifiera omdirigeringslistan och dokumentera godkända undantag för uppgifter som lämnas kvar. Bestäm också vem som jämför trafik, order och fel varje dag.
Ett begränsat släpp ger möjlighet att kontrollera verklig drift innan fler kunder omfattas. Det kräver beredskap för övervakning och ett tydligt beslut om när utrullningen får fortsätta.
Ställ tre frågor till leverantören innan ni skriver under
Tre frågor räcker för att pröva om en offert håller för ett plattformsbyte. Ställ dem skriftligt och begär skriftliga svar, så att de kan kontrolleras mot projektets grindar före signering.
Vilka integrationer, omdirigeringar och migreringsobjekt ingår i fast pris, och vilka delar debiteras löpande? Svaret visar om offerten beskriver det arbete som krävs för en fungerande produktionsövergång.
Be om en skriftlig koppling mellan omfattning och godkännandekriterier. Formuleringen att migrering ingår behöver ange vilka objekt som flyttas och hur avstämningen görs. Samma precision behövs för testmiljö, provkörningar och rättning av importfel.
Vem ansvarar för uppgraderingar av plattform och affärssystem efter go-live, och hur hålls kompatibiliteten när funktioner tillkommer? Svaret visar vem som faktiskt ska utreda och rätta ett brutet flöde.
Ett supportavtal bör konkret ange vem som ansvarar när affärssystemet får en ny version, inom vilken tid ett brutet orderflöde ska åtgärdas och om det arbetet ingår eller faktureras per timme. Ett telefonnummer till supporten och en löpande kontaktväg säger inget om det ansvaret.
Förvaltning och uppgraderingar behöver därför bedömas som en egen avtalsfråga. Glanser Care är ett avtalat ansvar till fast månadskostnad som omfattar versionsuppföljning, kompatibilitet genom uppgraderingar, underhåll av integrationerna mot affärssystemet och buggrättning. Uppgraderingar kräver ingen ny offert.
Vilka data kan ni exportera i ett format som ni själva kan läsa vid ett senare byte, och vad kostar exporten? Svaret visar hur beroende ni blir av leverantörens fortsatta medverkan.
Svaren behöver fungera tillsammans
Exportmöjligheten bör omfatta relationerna mellan uppgifterna. Produktfiler utan variantkopplingar kan kräva omfattande efterarbete. Detsamma gäller orderrader utan koppling till kunder och orderhuvuden.
Om leverantören säger att allt nödvändigt ingår behöver beskedet preciseras. Be om villkor för prioritering av felrättningar och hantering av nya önskemål. Koppla svaren till projektets grindar, så att omfattning och ansvar går att kontrollera före godkännandet.
Bedöm frågorna tillsammans. Ett lågt införandepris kan följas av omfattande förvaltningsarbete, medan en tydlig export ger er bättre handlingsutrymme när verksamheten förändras.
Boka en 72-timmarsanalys innan ni låser omfattningen
Ett beslutsunderlag behöver visa vad som kan behållas och vad som måste ändras. Samla därför er nuvarande lösning, kända fel och viktigaste affärsflöden inför bedömningen.
I den kostnadsfria 72-timmarsanalysen visar ni er webb, e-handel eller portal och avsätter två timmar för ett möte. Inom 72 timmar får ni en tydlig bild av var ni står och vad ett byte till Glanser skulle innebära.
Utfallet landar i ett av tre lägen: lösningen kan stå som den är, den är i grunden bra, eller den behöver byggas om. Ett utlåtande som säger att plattformen kan behållas är ett lika verkligt resultat som en ombyggnad. Ett byte är ett riskprojekt, och ibland är det rätta svaret att lägga budgeten på att stabilisera det ni redan har. Om ett byte är motiverat får ni i stället ett konkret underlag för omfattningen och arbetet fram till lanseringen.
Ta med en order som kräver manuell hjälp till analysen, så blir underlaget konkret från början.

Om Kenneth Lyngshede
Kenneth Lyngshede skriver om strategi, affärsmodeller och erbjudanden. Han har lång erfarenhet av försäljning, förhandling och att bygga upp nya och snabbväxande bolag, och utgår gärna från siffrorna: vad en investering kostar, vad den ger och varför den håller.

Agentic commerce börjar i er produktdata och behörighet
Vad agentic commerce kräver av er produktdata, era priser och era orderregler.
Niclas Frid
Produktkonfigurator i B2B: vad ni bör veta före valet
Produktkonfigurator för B2B: typer, koppling till PIM, ERP och prissättning samt vad implementeringen kräver av er.
Peter Nilsson
Så strukturerar ni produktdata i en PIM-datamodell
PIM data model förklarat: hur produkter, attribut, relationer och kanalbehov hänger ihop, med exempel från svensk handel.
Peter Nilsson