Co se doopravdy stane s daty při migraci e-shopu

Otázka, kterou na prvním hovoru dostáváme skoro vždy, zní: přenesou se nám staré objednávky? Odpověď je ano a je nudná. Zajímavé je to, na co se nikdo neptá.

Migrace je totiž audit vašich dat, který jste si neobjednali. Produkty, které roky fungovaly, se najednou ukážou jako špatně namodelované. Parametr, který na starém e-shopu nikomu nevadil, se po přenosu rozsype na tři sta hodnot. A věci, které jste považovali za varianty, se ukážou jako tři sta samostatných produktů, které o sobě nevědí.

Tenhle článek je o tom, co se s daty reálně děje — z migrací, které jsme odvedli, ne z letáku.

Čas čtení: 10 min | Aktualizováno: září 2026

Rychlá odpověď, pokud nemáte 10 minut

• Přenese se téměř všechno — produkty, varianty, parametry, zákazníci, historie objednávek. Zmigrovali jsme e-shop se 40 tisíci objednávkami i s historií, takže si zákazníci po přechodu otevřeli staré objednávky.
• Problém není přenos, ale model. Nejvíc hodin na migraci nezabere import, ale to, že data byla roky vedená jinak, než mají být.
• Ne všechnu historii se vyplatí brát. Při stovkách tisíc objednávek bývá rozumnější archivovat je mimo novou platformu.
• Metriky začínají od nuly. Retenci a podobná čísla budete v novém systému sledovat od spuštění, ne zpětně.
• Analýza před nabídkou není zdržení. Je to jediný způsob, jak zjistit, co se z původní platformy vůbec dá dostat.

Obsah článku

1. Co se přenese
2. Skutečný problém: jak jsou data namodelovaná
3. Historie objednávek: kolik jí brát
4. Zákazníci napříč více e-shopy
5. Co se pokazí potichu
6. Co udělat před migrací
7. Často kladené otázky

1. Co se přenese

Produkty s variantami a parametry, popisy, obrázky, kategorie, zákaznické účty, historie objednávek, staré adresy s přesměrováním. U e-shopu se 40 tisíci objednávkami to proběhlo včetně historie — zákazníci si po přechodu uměli otevřít i staré objednávky.

Dvě věci, na které se ptají obzvlášť často:

• Recenze. Ptají se na ně klienti s dlouholetou sbírkou hodnocení a je to oprávněné — jsou to data, která přímo prodávají. Jestli a jak se přenesou, závisí na původní platformě, a proto to patří do analýzy před nabídkou, ne do slibu na hovoru.
• Věrnostní body. Přenášejí se přes API a jednou nám to ukázalo, jak tenké to umí být: import nebral nulu jako platnou hodnotu, takže zákazníkům, kteří měli mít nula bodů, zůstalo pole prázdné. Nahlásili jsme to a platforma to opravila. Takové věci se nedají předvídat, dají se jen odchytit kontrolou po importu.

2. Skutečný problém: jak jsou data namodelovaná

Tohle je jádro celého článku. Import je strojová práce. Hodiny sežere to, že data na staré platformě popisují realitu jinak, než by měla.

Samostatné produkty, které měly být varianty

Nejčastější případ. Řetězec s oblečením měl každou barvu téhož kusu vedenou jako samostatný produkt. Jeho vlastními slovy:

„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."

Totéž jsme viděli u balení — různé hmotnosti téhož zboží jako samostatné položky místo variant. A u vůní, kde vzorek a plná lahvička patří k sobě.

Je to práce, kterou za vás nikdo neudělá, protože které produkty patří k sobě, víte jen vy. Zároveň je to nejlepší investice celé migrace: bez ní si přenesete nepořádek do nového systému i s tím, že se v něm nedá filtrovat.

Počet položek, který klame

Velkoobchod se spojovacím materiálem měl v ERP přes 50 tisíc položek. Zní to jako obrovská migrace. Po prohlédnutí jich bylo reálně 400 až 500 unikátních produktů, ze kterých se odvozovaly tisíce rozměrových variant se stejnou fotkou a jiným rozměrem.

Rozdíl mezi těmi dvěma čísly je rozdíl mezi projektem na měsíce a projektem na týdny. Proto se cena migrace nedá říct z počtu řádků v exportu.

Parametry, které se po přenosu rozsypou

Při migraci ze starší platformy se parametr s více hodnotami — chuťový profil kávy — přenesl jako jedna spojená textová hodnota místo samostatných hodnot. Výsledek: přes 350 různých „variant" a 369 chuťových profilů, ačkoli reálně unikátních hodnot mělo být kolem padesáti. Produkty se podle nich nedaly pořádně filtrovat.

Opačný případ: klient měl v ERP jednu vlastnost — vhodnost použití — namodelovanou jako deset samostatných parametrů, z nichž měl každý produkt vyplněný zpravidla jeden. Opravovat to na straně klienta by trvalo týdny, tak se těch deset hodnot sloučilo do jednoho parametru už v integrační vrstvě.

Po migraci si jeden klient parametry sjednotil sám: zkonsolidoval přibližně 42 parametrů se 150 až 200 hodnotami, z nichž velká část byly duplicity. Pak si strukturu zamkl a dál ji neměnil — jinak se chaos vrátí.

3. Historie objednávek: kolik jí brát

Automatická odpověď bývá „všechnu". Ne vždy je správná.

U jedné skupiny e-shopů bylo na staré platformě odhadem 200 až 300 tisíc historických objednávek. Rozhodli se je kompletně nemigrovat a místo toho archivovat mimo novou platformu, aby se data neztratila a zároveň nezatěžovala nový systém.

Pro představu o rozsahu jinde v téže skupině: hlavní e-shop měl 120 až 150 tisíc objednávek, druhý největší 85 tisíc. Poslední dávka reálného importu měla kolem 75 tisíc objednávek a zpracování trvalo přibližně 12 hodin. To není problém, jen je potřeba to mít v plánu přepnutí — podrobně v článku Den přepnutí.

Co je potřeba si uvědomit o metrikách

I když historii přenesete, nebudete mít historická data v takové kvalitě a rozsahu, jako vám je nový systém poskytne od spuštění. Retenci a podobné metriky začnete sledovat od nuly.

Mimochodem, spousta e-shopů je nesleduje ani dnes. Jedna klientka má data o zákaznících od roku 2010 a přesto:

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

Pokud jste na tom podobně, ztráta historie vás bolí méně, než si myslíte — a zisk z toho, že metriky konečně budete mít, je větší. Které čísla to jsou, rozebíráme v článku Čísla, která váš e-shop musí znát.

4. Zákazníci napříč více e-shopy

Při migraci skupiny e-shopů bylo potřeba přenést zhruba 30 tisíc zákazníků napříč všemi obchody. Přibližně dvě stě z nich nakupovalo ve více e-shopech téže skupiny.

Při importu se jim objednávky spárovaly podle e-mailové adresy do jednoho účtu a zákazníci s více doručovacími adresami si všechny adresy zachovali v profilu. To je detail, kterého si nikdo nevšimne, když funguje, a který nadělá hodně zlé krve, když nefunguje.

U menších počtů se vyplatí opak: klient s 25 B2B zákazníky se zvýhodněnými ceníky je přenesl ručně. Automatizovat přenos pětadvaceti záznamů je dražší než je přepsat.

Totéž platí o produktech. U e-shopu s pěti kategoriemi a padesáti položkami by naprogramování automatického stahování obsahu vyšlo přibližně na totéž, co ruční zadání — takže se zadávaly ručně.

5. Co se pokazí potichu

Tohle je seznam věcí, které po migraci nespadnou. Fungují dál a měsíce nikdo neví, že jsou špatně.

• Feed a měření si přestanou rozumět. Po jedné migraci spadl katalogový match rate na Facebooku prakticky na nulu — feed posílal jiné ID produktu a cenu s DPH, zatímco sledování nákupů posílalo jiné ID a cenu bez DPH. E-shop přitom prodával dál. Píšeme o tom v článku Feedy pro Google, Heureku a Metu.
• Dvojité odečtení skladu. Při napojení na externí sklad nebo CRM hrozí, že objednávka sníží zásobu v e-shopu a pak ještě jednou ve druhém systému při zpětném zaevidování.
• Dvě faktury se stejným číslem. Když někdo v externím systému ručně upraví objednávku, ke které už z e-shopu odešla faktura, vznikne druhá faktura se stejným číslem a jiným obsahem.
• Číselná řada, která se překrývá. Při zakládání nového satelitu je potřeba ručně posunout počáteční číslo objednávek a faktur, aby nekolidovalo s existujícími.
• Ceny se při nové měně nepřepočítají. Import katalogu v eurech do satelitu s českou korunou měnu nepřepočítá — pro každou měnovou a jazykovou kombinaci je potřeba samostatný satelit a vlastní import. Souvisí s tím článek E-shop pro více zemí.
• Drobnosti, které najde jen kontrola. Po spuštění automatické synchronizace se jednou dodatečně založily tři produkty navíc (nechaly se neaktivní) a u čtyř neseděla hmotnost — musela se dohledat a opravit ručně.

Společný jmenovatel: ani jedna z těchhle poruch se neohlásí. Proto po migraci nestačí podívat se, jestli e-shop běží.

6. Co udělat před migrací

1. Označte, které produkty patří k sobě. Pokud vedete barvy, velikosti nebo balení jako samostatné položky, doplňte párovací identifikátor. Tohle je největší kus práce a udělat ho umíte jen vy.
2. Zjistěte skutečný počet unikátních produktů. Ne počet řádků v exportu. Rozdíl bývá řádový.
3. Projděte parametry a jejich hodnoty. Duplicity a překlepy slučte teď — po migraci se to dělá hůř.
4. Rozhodněte, kolik historie jdete brát. A pokud část ne, domluvte, kam se archivuje.
5. Vyžádejte si analýzu původního e-shopu před cenovou nabídkou. Co se z platformy dá dostat a v jakém stavu, se jinak zjistí až při importu — tedy po podpisu. Kolik to stojí, rozebíráme v článku Kolik stojí migrace e-shopu.
6. Spočítejte API limity, pokud napojujete další systémy. Na Upgates jsou základní limity 100 requestů za hodinu, 1 500 za den, nejvýše tři souběžné požadavky a po 100 položkách v dávce; základní balík API stojí řádově jednotky eur měsíčně a limity se dají navýšit. Aktuální podmínky si ověřte, mění se.

7. Často kladené otázky

Přenesou se při migraci staré objednávky?

Ano. Zmigrovali jsme e-shop se 40 tisíci objednávkami včetně historie, takže si zákazníci po přechodu uměli otevřít i staré objednávky. Při stovkách tisíc objednávek se ale vyplatí zvážit, jestli část neuložit do archivu mimo platformu — import takového objemu trvá hodiny a nový systém zatěžuje zbytečně.

Přenesou se zákaznické recenze?

Závisí na původní platformě a na tom, jak jsou uložené. Je to jedna z věcí, které se dají říct až po analýze původního e-shopu — proto na ni na prvním hovoru nedostanete tvrdé ano.

Budu mít po migraci své metriky?

Od spuštění ano, zpětně v omezené míře. I když se historie objednávek přenese, data v novém systému nebudou mít stejnou kvalitu a rozsah jako ta, která začne sbírat sám. Retenci a podobné metriky proto počítejte od nuly.

Jak dlouho trvá import velkého e-shopu?

Samotné zpracování dávky 75 tisíc objednávek nám trvalo přibližně 12 hodin. Není to problém, jen to musí být v plánu přepnutí — a proto se migrace nedělá v pátek večer.

Musím si data uklidit před migrací, nebo to udělá agentura?

Technickou část udělá agentura. Rozhodnutí ne. Které samostatné produkty jsou ve skutečnosti varianty téhož zboží a které parametry znamenají totéž, víte jen vy — a bez toho se nepořádek přenese do nového systému nedotčený.

Závěr

Jedna klientka to pojmenovala přesněji než kterýkoli náš dokument. Chtěla, aby nový systém byl:

„…ten zdroj pravdy."

To je celý smysl migrace dat. Ne přenést řádky z jedné databáze do druhé, ale skončit se stavem, kdy tentýž produkt existuje ve třech systémech třikrát jinak a nikdo neví, která verze platí.

Přenést se dá téměř všechno. Otázka je, co z toho chcete přenést tak, jak to je teď.

Pokud si chcete nechat prohlédnout, v jakém stavu vaše data jsou, napište nám.

Mohlo by vás zajímat

• Migrace ze Shoptetu na Upgates
• Den přepnutí: jak probíhá migrace bez odstávky
• Kolik stojí migrace e-shopu
• Propojení e-shopu s ERP