Migracija web shopa treba da se vodi kao kontrolisan prenos podataka, funkcionalnosti i URL strukture, a ne kao obično postavljanje novog dizajna. Pre puštanja nove prodavnice potrebno je mapirati katalog, kupce, porudžbine, načine plaćanja, dostavu, integracije i postojeće organske URL-ove. Tek tada se može odlučiti šta se prenosi bez izmene, šta se prilagođava novoj platformi, a šta se namerno napušta.
Najveći rizici nisu samo tehnički. Nedostajući proizvodi, pogrešne cene, izgubljena istorija porudžbina, nevažeći linkovi i pogrešno postavljeni redirekti mogu istovremeno da otežaju rad podrške, zbune kupce i smanje vidljivost u pretrazi. Zato migracija treba da ima jasan plan, rezervnu kopiju, testno okruženje, kontrolisano prebacivanje i listu provera nakon objave. Ako tek birate rešenje ili obim nove prodavnice, korisno je da proces sagledate u okviru usluge izrade web shopa, gde se migracija planira zajedno sa arhitekturom i poslovnim zahtevima.
Šta sve obuhvata migracija web shopa
Termin migracija može označavati nekoliko različitih scenarija. Nije isto da li se menja samo platforma, domen, struktura URL-ova, hosting ili kompletan poslovni sistem. Pre procene posla treba precizno definisati promene:
- Platformska migracija: prelazak sa jednog ecommerce sistema na drugi, uz promenu modela podataka i administracije.
- Redizajn bez promene platforme: često je jednostavniji, ali i dalje može menjati URL-ove, filtriranje, checkout i način učitavanja sadržaja.
- Promena domena: zahteva prenos signala sa starih URL-ova na novu adresu i posebnu proveru Search Console svojstava.
- Promena URL strukture: kategorije, proizvodi, blog i slike mogu dobiti nove adrese čak i kada domen ostane isti.
- Spajanje ili razdvajanje prodavnica: više kataloga ili tržišta može se objediniti, odnosno jedan shop može biti podeljen po zemljama ili brendovima.
Ove promene se mogu kombinovati, ali svaka dodatna promena povećava broj veza koje treba proveriti. Na primer, promena platforme, domena i strukture kategorija u jednom koraku otežava utvrđivanje uzroka problema. Kada postoji izbor, korisno je smanjiti broj promenljivih ili barem za svaku od njih napraviti zaseban plan i evidenciju.
Prva faza: inventar postojećeg shopa
Pre izrade nove prodavnice treba napraviti inventar starog sistema. On nije samo spisak proizvoda. Potrebno je obuhvatiti sve što ima poslovnu, korisničku ili SEO vrednost:
- proizvode, varijante, SKU oznake, kategorije, brendove i atribute;
- naslove, opise, meta podatke, fotografije, alt tekstove i dokumentaciju;
- cene, akcijske cene, poreska pravila i stanje zaliha;
- naloge kupaca, adrese, saglasnosti i statuse naloga;
- porudžbine, stavke, iznose, status plaćanja, status isporuke i refundacije;
- statičke stranice, blog tekstove, vodiče i stranice za podršku;
- URL-ove koji dobijaju organski saobraćaj ili imaju spoljne linkove;
- integracije za plaćanje, dostavu, ERP, CRM, newsletter, analitiku i oglašavanje;
- promotivne kodove, pravila dostave, email obaveštenja i korisničke tokove.
Izvoz podataka treba sačuvati u izvornom obliku pre čišćenja. Tako se kasnije može utvrditi da li je greška nastala u starom sistemu, mapiranju ili uvozu. Za katalog je korisno imati jedinstveni identifikator proizvoda, najčešće SKU ili interni ID. Naziv proizvoda nije pouzdan ključ jer se može promeniti, ponoviti ili sadržati različito formatirane karaktere.
Mapiranje podataka: šta se prenosi, menja ili ne prenosi
Svako polje iz starog sistema treba povezati sa odgovarajućim poljem u novom. Jednostavna tabela za mapiranje može sadržati kolone: izvorno polje, ciljano polje, format, obaveznost, pravilo transformacije i način provere.
| Oblast | Primer odluke | Kontrola |
|---|---|---|
| Katalog | SKU ostaje isti, a kategorije se preslikavaju na novu taksonomiju | Broj proizvoda, varijanti i kategorija; uzorak pojedinačnih artikala |
| Kupci | Nalozi se prenose, ali se lozinke ne kopiraju ako formati nisu kompatibilni | Test aktivacije naloga i provera zaštite podataka |
| Porudžbine | Istorija ostaje dostupna za podršku, dok se statusi prilagođavaju novom modelu | Uzorak porudžbina sa različitim načinima plaćanja i statusima |
| URL-ovi | Stare adrese se povezuju sa najrelevantnijim novim adresama | Test svake grupe redirekcija i provera odredišnog sadržaja |
Posebnu pažnju zahtevaju statusi porudžbine. Jedan sistem može razlikovati „plaćeno“, „obrađuje se“, „poslato“, „isporučeno“, „otkazano“ i „refundirano“, dok drugi koristi drugačiji model. Ne treba ih spajati samo zato što zvuče slično. Status utiče na rad skladišta, obaveštavanje kupca, izveštaje i refund workflow. Za detaljnije modelovanje korisno je pročitati vodič kako modelovati status porudžbine kod povraćaja robe i refundacije.
Kako preneti katalog bez gubitka komercijalnih podataka
Katalog se obično prenosi uvoznim fajlom ili kroz integraciju između sistema. Bez obzira na tehniku, prvo treba testirati mali uzorak, a tek zatim raditi masovni uvoz. Uzorak treba da sadrži jednostavan proizvod, proizvod sa varijantama, proizvod sa više slika, artikl na akciji, proizvod bez zalihe i proizvod sa specifičnim atributima.
Proverite najmanje sledeće:
- da svaki proizvod ima tačan SKU i da se varijante ne pretvaraju u duplikate;
- da su glavna slika, galerija, opis i dokumenti povezani sa pravim artiklom;
- da decimalni separator, valuta, porez i format cene odgovaraju novom sistemu;
- da se stanje zaliha prenosi sa dogovorenim pravilom i datumom preseka;
- da kategorije, brendovi i atributi imaju smislen odnos prema navigaciji;
- da nedostajući ili ugašeni proizvodi imaju definisanu destinaciju, umesto nasumičnog preusmeravanja.
Ne treba automatski preneti sve stare atribute. Ako su ranije korišćeni samo kao neuređene oznake, njihov direktan uvoz može napraviti mnogo nejasnih filtera i URL kombinacija. Pre toga definišite koji atribut služi za izbor proizvoda, koji je samo informativan, a koji treba ukloniti.
To je naročito važno kod velikih kataloga. Nepravilno generisane filtrirane stranice mogu stvarati duplikate i otežati indeksiranje. Pravila za ovu oblast objašnjena su u tekstu Filteri i faceted navigation: kako izbeći UX i SEO probleme.
Kupci, nalozi i zaštita podataka
Podaci o kupcima zahtevaju drugačiji tretman od javnog kataloga. Pre migracije treba definisati koje informacije su zaista potrebne za nastavak poslovanja, ko ima pristup izvozu i koliko dugo se čuvaju radne kopije. Fajlovi sa imenima, adresama, telefonima ili istorijom kupovine ne treba da se razmenjuju neformalno niti ostavljaju u otvorenim testnim okruženjima.
Najčešći tehnički problem je prenos lozinki. Lozinke su u starom sistemu uskladištene u formatu koji nova platforma možda ne može da koristi. U tom slučaju bezbednije rešenje može biti aktivacija naloga ili postavljanje nove lozinke kroz kontrolisan proces, umesto pokušaja konverzije nekompatibilnih zapisa. Kupac mora jasno da dobije uputstvo šta se promenilo i kako da pristupi nalogu.
Pre prenosa napravite odluke za:
- duplikate kupaca sa različitim email adresama ili adresama za dostavu;
- neaktivne i poslovne naloge;
- istoriju saglasnosti i pretplate na marketinške poruke;
- adrese koje pripadaju završenim porudžbinama, ali nisu više aktivne;
- pristup zaposlenih, korisničke uloge i administratorske naloge.
Ovo nije zamena za pravnu procenu usklađenosti. Pre obrade podataka proverite interne procedure, ugovore sa dobavljačima i obaveze koje važe za vaše tržište i poslovni model.
Porudžbine, plaćanje i operativni kontinuitet
Istorija porudžbina može biti potrebna podršci, računovodstvu, logistici i samom kupcu. Zato se pre migracije mora odlučiti da li će se porudžbine preneti kao potpuno aktivni zapisi, kao arhiva za čitanje ili u drugom obliku. Ne treba mešati stare i nove statuse bez jasnog pravila, posebno ako su u toku isporuke, povraćaji ili neuspešna plaćanja.
Napravite presek podataka u dogovoreno vreme i evidentirajte porudžbine koje su nastale između izvoza i konačnog prebacivanja. Ako stari shop ostane dostupan tokom rada, potrebno je definisati kako se sprečava da nova porudžbina bude zabeležena u jednom sistemu, a da ne bude preneta u drugi.
Checkout proverite kao stvarni kupac, ali i iz perspektive administracije. Test obuhvata izbor proizvoda, primenu kupona, dostavu, porez, plaćanje, email potvrdu, promenu statusa i refundaciju. Za kartična plaćanja koristite testni režim kada ga provajder podržava. Proverite i webhooks ili druge povratne poruke koje menjaju status porudžbine; uspešno učitavanje stranice za plaćanje samo po sebi ne potvrđuje da je ceo tok ispravan.
Ako shop posluje na više tržišta, valuta, jezici, formati adresa i pravila dostave moraju biti deo plana od početka. Dodatne praktične odluke opisane su u vodiču Multi-currency i lokalizacija web shopa za više tržišta. Ako novi checkout menja obavezna polja ili način kupovine bez naloga, proverite i pristup guest checkout toku.
SEO migracija: kako sačuvati postojeću vidljivost
SEO deo migracije počinje popisom starih URL-ova, a ne tek nakon objave novog shopa. U popis uključite proizvode, kategorije, brendove, informativne stranice, blog, slike i druge URL-ove koji imaju organske posete ili spoljne linkove. Kao izvore možete kombinovati crawl, server logove, analitiku, Search Console i internu bazu sadržaja. Nijedan izvor sam po sebi ne mora obuhvatiti sve važne adrese.
Za svaki važan stari URL definišite jednu od odluka:
- ostaje isti;
- dobija novu, ekvivalentnu adresu;
- spaja se sa relevantnijom stranicom;
- uklanja se jer nema zamenu i ne treba da bude dostupna;
- privremeno se zadržava dok traje poslovna ili tehnička tranzicija.
Kada se sadržaj seli na novu adresu, redirekcija treba da vodi direktno na najbliži ekvivalent, a ne automatski na početnu stranicu. Lanac redirekcija otežava dijagnostiku i može usporiti korisnički tok. Google u dokumentaciji o promeni URL-ova preporučuje mapiranje starih i novih adresa, postavljanje trajnih redirekcija i ažuriranje internih linkova.
Proverite i sledeće elemente:
- canonical oznake na proizvodima, kategorijama i paginaciji;
- interno linkovanje iz menija, breadcrumbs navigacije, sadržaja i sitemap-a;
- XML sitemap koji sadrži samo relevantne, indeksabilne URL-ove;
- robots.txt i eventualne noindex direktive;
- hreflang, ako shop ima više jezičkih ili regionalnih verzija;
- strukturirane podatke, ali bez očekivanja da će njihov prikaz biti garantovan;
- statusne kodove, mobilnu verziju, slike i brzinu učitavanja.
SEO migracija nije samo očuvanje starih URL-ova. Ako se usput menjaju nazivi kategorija, sadržaj ili način filtriranja, treba odvojeno proceniti da li se time poboljšava ili slabi korisnička i pretraživačka logika. Za širi tehnički plan možete koristiti i stranicu SEO migracija sajta, ali konkretne odluke za web shop treba vezati za katalog, checkout i poslovne tokove.
Testno okruženje i plan puštanja
Nova prodavnica treba da bude testirana pre promene DNS-a ili javnog preusmeravanja saobraćaja. Testno okruženje ne sme biti dostupno pretraživačima kao da je produkcija. Istovremeno, zabrana indeksiranja ne zamenjuje kontrolu pristupa, naročito kada se u okruženju nalaze realni podaci.
Testiranje organizujte po scenarijima, a ne samo po stranicama. Minimalni set može da izgleda ovako:
- pronaći proizvod kroz meni, pretragu i kategoriju;
- izabrati varijantu i dodati je u korpu;
- izmeniti količinu, ukloniti artikl i primeniti kupon;
- završiti kupovinu sa svakim relevantnim načinom plaćanja i dostave;
- proveriti emailove kupcu i administratoru;
- obraditi otkazivanje, povraćaj i promenu statusa;
- prijaviti se kao postojeći kupac i aktivirati novi nalog ako je potrebno;
- otvoriti stare URL-ove i proveriti njihove redirekcije;
- testirati mobilni prikaz, pretragu, filtre i poruke o grešci.
Pre objave pripremite plan vraćanja na prethodnu verziju. On treba da navede ko donosi odluku, šta se vraća, kako se obrađuju porudžbine nastale nakon prebacivanja i kako se čuvaju podaci nastali u međuvremenu. „Imamo backup“ nije dovoljan plan ako nije provereno da se backup može obnoviti i da su poznate njegove granice.
Kontrola nakon migracije
Provera se ne završava kada nova početna stranica proradi. U prvim danima napravite tehnički i poslovni pregled: da li se porudžbine pravilno kreiraju, da li su plaćanja evidentirana, da li zalihe odlaze u pravi sistem, da li korisnici primaju obaveštenja i da li podrška vidi prethodnu istoriju.
Sa SEO strane, proverite najvažnije stare URL-ove, nove sitemap fajlove, canonical oznake, indeksabilnost i greške u crawl-u. Uporedite kategorije stranica, organske landing stranice i upite sa periodom pre migracije, ali nemojte donositi zaključak na osnovu jedne metrike ili jednog dana. Ako se pojavi problem, prvo proverite da li je posledica redirekcije, dostupnosti, promene sadržaja, tehničke zabrane indeksiranja ili normalne promene potražnje.
Vodite listu incidenata sa URL-om, opisom, prioritetom, vlasnikom i statusom. Tako se rešavanje ne pretvara u nasumično menjanje podešavanja. Nakon stabilizacije, dokumentujte konačnu mapu URL-ova, model podataka, integracije, administratorske pristupe i poznata ograničenja novog sistema.
Praktičan redosled odluka
Dobar plan migracije može se svesti na sledeći niz:
- definišite šta se menja i šta mora ostati kompatibilno;
- napravite inventar kataloga, korisnika, porudžbina, URL-ova i integracija;
- sačuvajte izvorne podatke i proverite mogućnost obnove;
- izradite mapu polja, statusa i starih ka novim URL-ovima;
- prenesite mali uzorak i testirajte ga kroz realne scenarije;
- uradite masovni prenos i uskladite razlike nastale tokom rada;
- proverite checkout, plaćanje, dostavu, emailove, SEO i analitiku;
- objavite po planu, pratite incidente i ne menjajte više nepovezanih stvari odjednom.
Ako je postojeći shop mali i ima jednostavan katalog, migracija može biti relativno direktna. Kod velikog kataloga, više tržišta, ERP integracije ili složenih refundacija, najveći posao često nije vizuelni sloj već usklađivanje podataka i operativnih pravila. Sledeći korak je zato izrada konkretnog inventara i matrice odluka: šta se prenosi, gde se mapira, ko proverava i koji je uslov da se pređe na narednu fazu.
Za širi tehnički kontekst — arhitekturu, UX, performanse i održavanje — pogledajte i naš pristup izrada sajta.
