Čo sa naozaj stane s dátami pri migrácii e-shopu

Otázka, ktorú na prvom hovore dostaneme skoro vždy, znie: prenesú sa nám staré objednávky? Odpoveď je áno a je nudná. Zaujímavé je to, na čo sa nikto nepýta.

Migrácia je totiž audit vašich dát, ktorý ste si neobjednali. Produkty, ktoré roky fungovali, sa zrazu ukážu ako zle namodelované. Parameter, ktorý na starom e-shope nikomu neprekážal, sa po prenose rozsype na tristo hodnôt. A veci, ktoré ste považovali za varianty, sa ukážu ako tristo samostatných produktov, ktoré o sebe nevedia.

Tento článok je o tom, čo sa s dátami reálne deje — z migrácií, ktoré sme odviedli, nie z letáku.

Čas čítania: 10 min | Aktualizované: september 2026

Rýchla odpoveď, ak nemáte 10 minút

• Prenesie sa takmer všetko — produkty, varianty, parametre, zákazníci, história objednávok. Zmigrovali sme e-shop so 40-tisíc objednávkami aj s históriou, takže si zákazníci po prechode otvorili staré objednávky.
• Problém nie je prenos, ale model. Najviac hodín na migrácii nezoberie import, ale to, že dáta boli roky vedené inak, než majú byť.
• Nie všetku históriu sa oplatí brať. Pri stovkách tisíc objednávok býva rozumnejšie archivovať ich mimo novej platformy.
• Metriky začínajú od nuly. Retenciu a podobné čísla budete v novom systéme sledovať od spustenia, nie spätne.
• Analýza pred ponukou nie je zdržanie. Je to jediný spôsob, ako zistiť, čo sa z pôvodnej platformy vôbec dá dostať.

Obsah článku

1. Čo sa prenesie
2. Skutočný problém: ako sú dáta namodelované
3. História objednávok: koľko jej brať
4. Zákazníci naprieč viacerými e-shopmi
5. Čo sa pokazí potichu
6. Čo spraviť pred migráciou
7. Často kladené otázky

1. Čo sa prenesie

Produkty s variantmi a parametrami, popisy, obrázky, kategórie, zákaznícke účty, história objednávok, staré adresy s presmerovaniami. Pri e-shope so 40-tisíc objednávkami to prebehlo vrátane histórie — zákazníci si po prechode vedeli otvoriť aj staré objednávky.

Dve veci, ktoré sa pýtajú zvlášť často:

• Recenzie. Pýtajú sa na ne klienti s dlhoročnou zbierkou hodnotení a je to oprávnené — sú to dáta, ktoré priamo predávajú. Či a ako sa prenesú, závisí od pôvodnej platformy, preto to patrí do analýzy pred ponukou, nie do prísľubu na hovore.
• Vernostné body. Prenášajú sa cez API a raz nám to ukázalo, aké tenké to vie byť: import nebral nulu ako platnú hodnotu, takže zákazníkom, ktorí mali mať nula bodov, ostalo pole prázdne. Nahlásili sme to a platforma to opravila. Také veci sa nedajú predvídať, dajú sa len odchytiť kontrolou po importe.

2. Skutočný problém: ako sú dáta namodelované

Toto je jadro celého článku. Import je strojová práca. Hodiny zožerie to, že dáta na starej platforme opisujú realitu inak, než by mali.

Samostatné produkty, ktoré mali byť varianty

Najčastejší prípad. Reťazec s odevami mal každú farbu toho istého kusu vedenú ako samostatný produkt. Jeho vlastnými slovami:

„My budeme musieť pre každý produkt pred migráciou dať nejaký párovací znak, že toto je vlastne materský produkt a toto sú dcérske produkty."

To isté sme videli pri baleniach — rôzne hmotnosti toho istého tovaru ako samostatné položky namiesto variantov. A pri vôňach, kde vzorka a plná fľaška patria k sebe.

Je to práca, ktorú za vás nikto neurobí, lebo ktoré produkty patria k sebe, viete len vy. Zároveň je to najlepšia investícia celej migrácie: bez nej si prenesiete neporiadok do nového systému aj s tým, že sa v ňom nedá filtrovať.

Počet položiek, ktorý klame

Veľkoobchod so spojovacím materiálom mal v ERP viac ako 50-tisíc položiek. Znie to ako obrovská migrácia. Po prezretí ich bolo reálne 400 až 500 unikátnych produktov, z ktorých sa odvodzovali tisíce rozmerových variantov s rovnakou fotkou a iným rozmerom.

Rozdiel medzi tými dvoma číslami je rozdiel medzi projektom na mesiace a projektom na týždne. Preto sa cena migrácie nedá povedať z počtu riadkov v exporte.

Parametre, ktoré sa po prenose rozsypú

Pri migrácii zo staršej platformy sa parameter s viacerými hodnotami — chuťový profil kávy — preniesol ako jedna spojená textová hodnota namiesto samostatných hodnôt. Výsledok: vyše 350 rôznych „variantov" a 369 chuťových profilov, hoci reálne unikátnych hodnôt malo byť okolo päťdesiat. Produkty sa podľa nich nedali poriadne filtrovať.

Opačný prípad: klient mal v ERP jednu vlastnosť — vhodnosť použitia — namodelovanú ako desať samostatných parametrov, z ktorých mal každý produkt vyplnený spravidla jeden. Opravovať to na strane klienta by trvalo týždne, tak sa tých desať hodnôt zlúčilo do jedného parametra už v integračnej vrstve.

Po migrácii si jeden klient parametre zjednotil sám: skonsolidoval približne 42 parametrov so 150 až 200 hodnotami, z ktorých veľká časť boli duplicity. Potom si štruktúru zamkol a ďalej ju nemenil — inak sa chaos vráti.

3. História objednávok: koľko jej brať

Automatická odpoveď býva „všetko". Nie vždy je správna.

Pri jednej skupine e-shopov bolo na starej platforme odhadom 200 až 300-tisíc historických objednávok. Rozhodli sa ich kompletne nemigrovať a namiesto toho archivovať mimo novej platformy, aby sa dáta nestratili a zároveň nezaťažovali nový systém.

Pre predstavu o rozsahu inde v tej istej skupine: hlavný e-shop mal 120 až 150-tisíc objednávok, druhý najväčší 85-tisíc. Posledná dávka reálneho importu mala okolo 75-tisíc objednávok a spracovanie trvalo približne 12 hodín. To nie je problém, len to treba mať v pláne prepnutia — podrobne v článku Deň prepnutia.

Čo si treba uvedomiť o metrikách

Aj keď históriu prenesiete, nebudete mať historické dáta v takej kvalite a rozsahu, ako vám ich nový systém poskytne od spustenia. Retenciu a podobné metriky začnete sledovať od nuly.

Mimochodom, veľa e-shopov ich nesleduje ani dnes. Jedna klientka má dáta o zákazníkoch od roku 2010 a napriek tomu:

„Ja si viem kliknúť na jedného zákazníka… ale ak by som si chcela spraviť sumárnu retenciu, tak toto nevieme."

Ak ste na tom podobne, strata histórie vás bolí menej, než si myslíte — a zisk z toho, že metriky konečne budete mať, je väčší. Ktoré čísla to sú, rozoberáme v článku Čísla, ktoré váš e-shop musí poznať.

4. Zákazníci naprieč viacerými e-shopmi

Pri migrácii skupiny e-shopov bolo treba preniesť zhruba 30-tisíc zákazníkov naprieč všetkými obchodmi. Približne dvesto z nich nakupovalo vo viacerých e-shopoch tej istej skupiny.

Pri importe sa im objednávky spárovali podľa e-mailovej adresy do jedného účtu a zákazníci s viacerými doručovacími adresami si všetky adresy zachovali v profile. To je detail, ktorý si nikto nevšimne, keď funguje, a ktorý narobí veľa zlej krvi, keď nefunguje.

Pri menších počtoch sa oplatí opak: klient s 25 B2B zákazníkmi so zvýhodnenými cenníkmi ich preniesol ručne. Automatizovať prenos dvadsiatich piatich záznamov je drahšie než ich prepísať.

To isté platí o produktoch. Pri e-shope s piatimi kategóriami a päťdesiatimi položkami by naprogramovanie automatického sťahovania obsahu vyšlo približne na to isté, čo ručné zadanie — takže sa zadávali ručne.

5. Čo sa pokazí potichu

Toto je zoznam vecí, ktoré po migrácii nespadnú. Fungujú ďalej a mesiace nikto nevie, že sú zle.

• Feed a meranie si prestanú rozumieť. Po jednej migrácii spadol katalógový match rate na Facebooku prakticky na nulu — feed posielal iné ID produktu a cenu s DPH, kým sledovanie nákupov posielalo iné ID a cenu bez DPH. E-shop pritom predával ďalej. Píšeme o tom v článku Feedy pre Google, Heureku a Metu.
• Dvojité odpočítanie skladu. Pri napojení na externý sklad alebo CRM hrozí, že objednávka zníži zásobu v e-shope a potom ešte raz v druhom systéme pri spätnom zaevidovaní.
• Dve faktúry s rovnakým číslom. Keď niekto v externom systéme ručne upraví objednávku, ku ktorej už z e-shopu odišla faktúra, vznikne druhá faktúra s rovnakým číslom a iným obsahom.
• Číselný rad, ktorý sa prekrýva. Pri zakladaní nového satelitu treba ručne posunúť počiatočné číslo objednávok a faktúr, aby nekolidovalo s existujúcimi.
• Ceny sa pri novej mene neprepočítajú. Import katalógu v eurách do satelitu s českou korunou menu neprepočíta — pre každú menovú a jazykovú kombináciu treba samostatný satelit a vlastný import. Súvisiace je v článku E-shop pre viac krajín.
• Drobnosti, ktoré nájde len kontrola. Po spustení automatickej synchronizácie sa raz dodatočne založili tri produkty navyše (nechali sa neaktívne) a pri štyroch nesedela hmotnosť — musela sa dohľadať a opraviť ručne.

Spoločný menovateľ: ani jedna z týchto porúch sa neohlási. Preto po migrácii nestačí pozrieť, či e-shop beží.

6. Čo spraviť pred migráciou

1. Označte, ktoré produkty patria k sebe. Ak vediete farby, veľkosti alebo balenia ako samostatné položky, doplňte párovací identifikátor. Toto je najväčší kus práce a spraviť ho viete len vy.
2. Zistite skutočný počet unikátnych produktov. Nie počet riadkov v exporte. Rozdiel býva rádový.
3. Prejdite parametre a ich hodnoty. Duplicity a preklepy zlúčte teraz — po migrácii sa to robí horšie.
4. Rozhodnite, koľko histórie idete brať. A ak časť nie, dohodnite, kam sa archivuje.
5. Vypýtajte si analýzu pôvodného e-shopu pred cenovou ponukou. Čo sa z platformy dá dostať a v akom stave, sa inak zistí až pri importe — teda po podpise. Koľko to stojí, rozoberáme v článku Koľko stojí migrácia e-shopu.
6. Zrátajte API limity, ak napájate ďalšie systémy. Na Upgates sú základné limity 100 requestov za hodinu, 1 500 za deň, najviac tri súbežné požiadavky a po 100 položiek v dávke; základný balík API stojí rádovo jednotky eur mesačne a limity sa dajú navýšiť. Aktuálne podmienky si overte, menia sa.

7. Často kladené otázky

Prenesú sa pri migrácii staré objednávky?

Áno. Zmigrovali sme e-shop so 40-tisíc objednávkami vrátane histórie, takže si zákazníci po prechode vedeli otvoriť aj staré objednávky. Pri stovkách tisíc objednávok sa ale oplatí zvážiť, či časť neuložiť do archívu mimo platformy — import takého objemu trvá hodiny a nový systém zaťažuje zbytočne.

Prenesú sa zákaznícke recenzie?

Závisí od pôvodnej platformy a od toho, ako sú uložené. Je to jedna z vecí, ktoré sa dajú povedať až po analýze pôvodného e-shopu — preto na ňu na prvom hovore nedostanete tvrdé áno.

Budem mať po migrácii svoje metriky?

Od spustenia áno, spätne v obmedzenej miere. Aj keď sa história objednávok prenesie, dáta v novom systéme nebudú mať rovnakú kvalitu a rozsah ako tie, ktoré začne zbierať sám. Retenciu a podobné metriky preto počítajte od nuly.

Koľko trvá import veľkého e-shopu?

Samotné spracovanie dávky 75-tisíc objednávok nám trvalo približne 12 hodín. Nie je to problém, len to musí byť v pláne prepnutia — a preto sa migrácia nerobí v piatok večer.

Musím si dáta upratať pred migráciou, alebo to spraví agentúra?

Technickú časť spraví agentúra. Rozhodnutia nie. Ktoré samostatné produkty sú v skutočnosti varianty toho istého tovaru a ktoré parametre znamenajú to isté, viete len vy — a bez toho sa neporiadok prenesie do nového systému nedotknutý.

Záver

Jedna klientka to pomenovala presnejšie než ktorýkoľvek náš dokument. Chcela, aby nový systém bol:

„…ten zdroj pravdy."

To je celý zmysel migrácie dát. Nie preniesť riadky z jednej databázy do druhej, ale skončiť so stavom, keď ten istý produkt existuje v troch systémoch trikrát inak a nikto nevie, ktorá verzia platí.

Preniesť sa dá takmer všetko. Otázka je, čo z toho chcete preniesť tak, ako to je teraz.

Ak si chcete nechať pozrieť, v akom stave vaše dáta sú, napíšte nám.

Mohlo by vás zaujímať

• Migrácia e-shopu: kompletný sprievodca
• Deň prepnutia: ako prebieha migrácia bez odstávky
• Koľko stojí migrácia e-shopu
• Prepojenie e-shopu s ERP