Flytting av en nettbutikk ser ut som en teknisk oppgave: produktene, ordrene og bildene skal over, betalingsmetodene skal kobles til, viderekoblinger skal settes opp – og så kan det nye systemet lanseres. Når det gjelder kundedata, handler det imidlertid om langt mer enn enkel datakopiering. Databasen i en nettbutikk i drift kan inneholde navn, e-postadresser, telefonnumre, faktura- og leveringsadresser, ordrehistorikk, markedsføringssamtykker, brukerkontoer og autentiseringsdata. For en større nettbutikk kan det bety datamengder i hundretusen- eller til og med millionklassen.
Er flyttingen av disse dårlig organisert, kan det ikke bare oppstå en teknisk feil, men også et personvernbrudd – noe ingen ønsker seg.
Fra et GDPR-perspektiv er det dessuten ikke bare den nye nettbutikkens virkemåte som teller. Selve eksporten, overføringen, den midlertidige lagringen, importen og slettingen av de gamle kopiene er også behandlingsaktiviteter.
GDPR gjelder også under migreringen av nettbutikken
Det finnes en grunnsetning om at GDPRs behandlingsbegrep er bevisst bredt. Det er ikke bare behandling når en nettbutikk viser en kundes navn eller lagrer en ordre – behandling skjer også når databasen kopieres ut av det gamle systemet, lastes opp på en migreringsserver, overleveres til en utvikler, når datastrukturen omformes eller dataene lastes inn i det nye systemet. Av dette følger en viktig praktisk regel: nettbutikkeieren kan ikke behandle migreringen som om den utelukkende var IT-leverandørens sak.
Hvis det er forhandleren som bestemmer hvilke kundedata som behandles og til hvilket formål, er det som regel fortsatt han som er behandlingsansvarlig. Utvikleren, hostingselskapet eller plattformleverandøren som gjennomfører flyttingen, deltar derimot vanligvis i prosessen som databehandler.
Ifølge Det europeiske personvernrådets retningslinjer skal forholdet mellom behandlingsansvarlig og databehandler reguleres av en egnet databehandleravtale. Den skal blant annet regulere behandlingens gjenstand, varighet og formål, de berørte datakategoriene, informasjonssikkerhetsforpliktelsene og vilkårene for bruk av underdatabehandlere.
Migreringsrisikoen er høyst reell
Også i Ungarn har det allerede vært en tilsynssak hos datatilsynsmyndigheten som gjaldt nettopp flytting av en kundedatabase.
NAIH undersøkte i en sak offentliggjort i 2025 en hendelse der en database inneholdt omtrent 3,6 millioner personopplysninger om i størrelsesorden 900 000 berørte. Problemet skyldtes ikke at noen importerte feil data. Brannmurkonfigurasjonen på en server startet med feil innstillinger etter en omstart og tillot i en periode nettverkstilgang som ikke skulle ha eksistert. Feiltilstanden varte i flere dager, og det skjedde også uautoriserte dataoppslag; navn, e-postadresser, telefonnumre, bostedsadresser og kontonumre var blant de berørte opplysningene.
Trengs det nytt samtykke fordi vi flytter til en ny nettbutikkmotor?
Som regel ikke. Hvis en virksomhet for eksempel bytter fra ett nettbutikksystem til et annet, endres ikke behandlingsgrunnlaget for kundedataene automatisk. Opplysningene fra en tidligere bestilling behandler nettbutikken for eksempel ikke fordi kunden har samtykket, men fordi de i det aktuelle tilfellet trengs for å oppfylle avtalen eller en rettslig forpliktelse. Byttet av teknologisk system gjør derfor ikke i seg selv et nytt samtykke nødvendig.
Det stiller seg annerledes hvis selve behandlingen endres sammen med plattformbyttet. For eksempel hvis det nye systemet begynner med en profilering som ikke fantes i det gamle, eller hvis kundedataene tas i bruk av en ny virksomhet til egne formål. Da snakker vi ikke lenger om en enkel teknisk migrering. Behandlingsgrunnlaget, behandlingsformålene og informasjonen til de registrerte må da vurderes på nytt.
Poenget er altså ikke om navnet på nettbutikkmotoren er endret. Spørsmålet er om innholdet i behandlingen er endret.
Det er ikke sikkert at alt må flyttes
Før migreringen bør du stille et tilsynelatende enkelt spørsmål: Trenger du virkelig alle dataene som finnes i det gamle systemet?
I praksis vokser databasen i mange nettbutikker gjennom årene. Underveis kommer det også inn data det ikke lenger er behov for; gamle midlertidige adresser, utdaterte tekniske logger, felter fra funksjoner som for lengst er avviklet, halvferdige importer eller markedsføringsinformasjon der behandlingsformålet for lengst har opphørt, kan bli liggende igjen.
Å overføre alt dette automatisk er ikke god praksis. Av GDPRs prinsipp om dataminimering følger at du bare bør ta med personopplysninger som det faktisk er behov for også i det nye systemet. Derfor bør flyttingen starte med en datainventering.
Se på hvilke data dagens nettbutikk lagrer i kundekontoene, hva ordrene inneholder, hvilke tekniske loggdata som finnes, hvilke markedsføringssamtykker som er knyttet til kundene, og hvilken autentiseringsinformasjon som ligger i databasen. Det neste spørsmålet er så bare hva av dette som kan tas med over i det nye systemet.
Også markedsføringssamtykket må flyttes – ikke bare e-postadressen
Nyhetsbrevdatabasen kan skape spesielt mange problemer. For en nettbutikk er det i seg selv ikke nok at den aktuelle kunden har en «påmeldt»-markering i det nye systemet. I gitte tilfeller må du også kunne dokumentere når og under hvilke omstendigheter samtykket ble gitt. Et godt ført system lagrer derfor ikke bare e-postadressen. Tidspunktet for samtykket, kilden og annen informasjon som senere kan bidra til å dokumentere lovligheten, kan bevares.
Det samme gjelder avmeldinger. Det kan oppstå en særdeles pinlig situasjon hvis en del av de tidligere avmeldte kundene etter nettbutikkens flytting igjen begynner å motta markedsføringsbrev fordi bare de aktive e-postadressene ble overført til det nye systemet – men ikke sperrene.
Ved migreringen er altså informasjonen «ønsker ikke markedsføring» minst like viktig som selve adressen.
Passordet er ikke et felt som bare kan kopieres over
Et av de mest sensitive tekniske spørsmålene ved nettbutikkflytting er håndteringen av brukerpassordene.
I et moderne system skal passordet ikke lagres i lesbar form. Ideelt sett kan ikke engang nettbutikkens driftsansvarlige si hvilket passord en gitt bruker benytter. Systemet lagrer i stedet en passordhash. Når brukeren logger inn, lages det med samme matematiske metode en kontrollerbar verdi av det oppgitte passordet, som kan sammenlignes med den som er lagret i databasen. Det kan ved første øyekast virke som en teknisk detalj, men ved migrering er det helt avgjørende.
Hvis noen sier «vi eksporterer de gamle passordene og laster dem inn i den nye nettbutikken», bør du mistenke en misforståelse – for snakker vi om faktiske, lesbare passord, er det et alvorlig sikkerhetsproblem!
Ikke alle passordhasher kan overføres problemfritt
Idealtilfellet er at det nye systemet kan håndtere passordhash-formatet den gamle nettbutikken brukte. Da kan selve hashen migreres, og kunden kan logge inn med samme passord etter flyttingen. Det krever at du kjenner det gamle systemets virkemåte i detalj.
Støtter den nye plattformen ikke det gamle systemet, kan hashene som regel ikke bare «konverteres». Hele poenget med dem er jo nettopp at det opprinnelige passordet ikke skal kunne gjenskapes.
I slike tilfeller er det ofte en renere og tryggere løsning å flytte kundekontoene slik at brukeren bes om å tilbakestille passordet ved første innlogging. Fra et brukeropplevelsesperspektiv er det ikke perfekt, men sikkerhetsmessig er det en bedre beslutning enn å holde liv i en utdatert passordløsning i årevis bare for å slippe å be om et nytt passord.
Selv om det som står her, kan virke skremmende, kan migrering mellom nettbutikksystemer gjennomføres trygt etter en skikkelig kartlegging; be Sellvio-teamet om hjelp hvis du skulle være i tvil om noe!