Selidba web shopa deluje kao tehnički zadatak: treba preneti proizvode, porudžbine, slike, povezati načine plaćanja, podesiti preusmeravanja, i novi sistem može da krene — kod podataka kupaca, međutim, reč je o mnogo više od prostog kopiranja podataka. U bazi funkcionalne online prodavnice mogu se nalaziti imena, e-mail adrese, brojevi telefona, adrese za fakturisanje i dostavu, istorija porudžbina, marketinške saglasnosti, korisnički nalozi i podaci za autentifikaciju. Kod veće prodavnice to može značiti stotine hiljada ili čak milione podataka.
Ako je njihova selidba loše organizovana, ne može se desiti samo tehnička greška, već i incident u vezi sa zaštitom podataka, što niko ne želi.
Sa aspekta GDPR-a, uz to, nije bitno samo kako će novi web shop raditi. I sam izvoz, prenos, privremeno čuvanje, uvoz i brisanje starih kopija predstavljaju radnje obrade podataka.
GDPR važi i tokom migracije web shopa
Postoji osnovna teza po kojoj je pojam obrade podataka u GDPR-u namerno širok. Obradom podataka ne smatra se samo kada web shop prikaže ime kupca ili sačuva njegovu porudžbinu; obrada podataka se dešava i kada se baza kopira iz starog sistema, otpremi na migracioni server, preda programeru, kada se transformiše struktura podataka ili kada se podaci učitaju u novi sistem. Iz toga sledi važno praktično pravilo: vlasnik web shopa ne sme da tretira migraciju kao da je ona isključivo stvar IT provajdera.
Ako trgovac određuje koje podatke kupaca i u koju svrhu obrađuje, po pravilu je i dalje on rukovalac podataka. Programer koji obavlja selidbu, hosting kompanija ili provajder platforme obično učestvuju u procesu kao obrađivači podataka.
Prema smernicama Evropskog odbora za zaštitu podataka, odnos rukovaoca i obrađivača mora urediti odgovarajući ugovor o obradi podataka. U njemu, između ostalog, treba urediti predmet, trajanje i svrhu obrade, kategorije podataka na koje se odnosi, obaveze u pogledu bezbednosti podataka i uslove angažovanja pod-obrađivača.
Migracioni rizik je i te kako stvaran
I u Mađarskoj je već bilo postupka organa za zaštitu podataka koji se odnosio upravo na selidbu baze podataka klijenata.
NAIH je u predmetu objavljenom 2025. godine ispitivao incident gde je baza sadržala približno 3,6 miliona ličnih podataka oko 900 hiljada lica. Problem nije nastao iz toga što je neko uvezao pogrešne podatke. Firewall podešavanje jednog servera nakon restarta pokrenulo se sa neodgovarajućom konfiguracijom, i jedno vreme je omogućavalo mrežni pristup koji nije smeo da postoji. Neispravno stanje trajalo je više dana, a došlo je i do neovlašćenog preuzimanja podataka; pogođeni su bili i imena, e-mail adrese, brojevi telefona, kućne adrese i brojevi bankovnih računa.
Da li je potrebna nova saglasnost zato što prelazimo na novi webshop sistem?
Po pravilu ne. Ako preduzeće, na primer, pređe sa jednog webshop sistema na drugi, time se pravni osnov obrade podataka kupaca ne menja automatski. Podatke ranije porudžbine web shop, na primer, ne obrađuje zato što je klijent dao saglasnost, već su u datom slučaju potrebni za ispunjenje ugovora ili neke pravne obaveze. Zamena tehnološkog sistema sama po sebi još ne čini neophodnim pribavljanje nove saglasnosti.
Drugačija je situacija ako se zajedno sa promenom platforme menja i sama obrada podataka. Na primer, novi sistem počne da vrši profilisanje koje u prethodnom nije postojalo, ili podatke klijenata novo preduzeće počne da koristi u sopstvene svrhe. Tada više ne govorimo o prostoj tehničkoj migraciji. Ponovo treba ispitati pravni osnov, svrhe obrade podataka i informisanje lica na koja se podaci odnose.
Suština, dakle, nije u tome da li se promenilo ime webshop sistema. Pitanje je da li se promenio sadržaj obrade podataka.
Nije sigurno da sve treba preseliti
Pre migracije vredi postaviti naizgled jednostavno pitanje: da li su zaista potrebni svi podaci koji se nalaze u starom sistemu?
U praksi baza mnogih online prodavnica raste godinama. U međuvremenu u nju dospevaju i podaci koji više nisu potrebni; mogu ostati stare privremene adrese, zastareli tehnički logovi, polja ranije ukinutih funkcija, napola završeni uvozi ili upravo marketinške informacije čija je svrha obrade odavno prestala.
Njihovo automatsko prenošenje nije dobra praksa. Iz GDPR principa minimizacije podataka sledi da vredi dalje nositi samo one lične podatke koji su i u novom sistemu zaista potrebni. Zato je selidbu celishodno početi inventarom podataka.
Treba pogledati koje podatke trenutni web shop čuva u korisničkim nalozima, šta sadrže porudžbine, kakvi tehnički log podaci postoje, kakve su marketinške saglasnosti vezane za klijente, odnosno kakve se informacije za autentifikaciju nalaze u bazi. Sledeće pitanje je već samo šta od toga može preći u novi sistem.
I marketinšku saglasnost treba preseliti, ne samo e-mail adresu
Posebno mnogo problema može izazvati baza njuzletera. Za web shop je samo po sebi malo da u novom sistemu kod datog klijenta stoji oznaka „prijavljen”. U datom slučaju mora se moći dokazati i kada i pod kojim okolnostima je saglasnost data. Dobro vođen sistem zato ne čuva samo e-mail adresu. Mogu se sačuvati vreme saglasnosti, njen izvor i druge informacije koje kasnije mogu pomoći u dokazivanju njene zakonitosti.
Isto važi i za odjavu. Izrazito neprijatna situacija može nastati ako nakon selidbe web shopa deo ranije odjavljenih klijenata ponovo počne da dobija poruke u marketinške svrhe zato što su u novi sistem prešle samo aktivne e-mail adrese, a zabrane nisu.
Kod migracije je, dakle, informacija „ne želi marketing” najmanje jednako važna kao i sama adresa.
Lozinka nije polje koje se može prosto prekopirati
Jedno od najosetljivijih tehničkih pitanja selidbi web shopova jeste rukovanje korisničkim lozinkama.
U savremenom sistemu lozinka se ne sme čuvati u čitljivom obliku. U idealnom slučaju ni sam operater web shopa ne može da kaže koju lozinku koristi određeni korisnik. Sistem umesto toga čuva hash lozinke. Kada se korisnik prijavi, od unete lozinke se istim matematičkim postupkom pravi proverljiva vrednost, koja se može uporediti sa onom sačuvanom u bazi. Ovo na prvi pogled može delovati kao tehnički detalj, ali je kod migracije od presudnog značaja.
Ako neko kaže „izvezimo stare lozinke, pa ih učitajmo u novi web shop”, možemo posumnjati na nesporazum — jer ako govorimo o stvarnim, čitljivim lozinkama, to predstavlja ozbiljan bezbednosni problem!
Ne može se svaki hash lozinke preneti bez problema
Idealan slučaj je kada novi sistem ume da radi sa formatom hash-a lozinki koji je koristio stari web shop. Tada se može migrirati sam hash, i kupac se nakon selidbe može prijaviti istom lozinkom. Za to je potrebno tačno poznavati rad prethodnog sistema.
Ako nova platforma ne podržava stari sistem, hash-evi se po pravilu ne mogu prosto „konvertovati”. Upravo je u tome suština — da se originalna lozinka ne može rekonstruisati.
U takvom slučaju je često čistije i bezbednije rešenje preseliti korisničke naloge tako da pri prvoj prijavi od korisnika zatražimo resetovanje lozinke. Sa aspekta korisničkog iskustva to nije savršeno, ali je sa bezbednosne strane bolja odluka nego godinama održavati u životu zastarelo rešenje za rukovanje lozinkama samo da ne bismo morali da tražimo novu lozinku.
Iako ovde opisano može delovati zastrašujuće, migracija između webshop sistema se nakon odgovarajućeg mapiranja može bezbedno obaviti; zatražite pomoć Sellvio tima ako se pojavi bilo kakva nedoumica!