Když se mě klient zeptá "jak dlouho trvá migrace e-shopu", snažím se odpovědět upřímně dřív, než řeknu jakékoli číslo. Protože "migrace e-shopu" je jedno z těch sousloví, která znějí jako jeden projekt — a ve skutečnosti jsou souborem desítek samostatných technických problémů. Každý s vlastní obtížností, vlastním rizikem a vlastním oknem pro špatná rozhodnutí, jejichž důsledky vycházejí na povrch týdny po go-live.
Nepíšu to jako varování. Píšu to proto, že po více než patnácti letech provádění migrací — Shoptet do PrestaShop, WooCommerce do PrestaShop, Magento do WooCommerce, starý shop na domácím řešení do čehokoli moderního — mám dost situací, kdy klient zjistí komplikace teprve tehdy, když je oba vidíme v produkci.
Databáze, které vypadají podobně, ale nejsou
Každá e-commerce platforma má vlastní datový model. Nejde o formát souboru ani o to, že jedna používá MySQL a druhá PostgreSQL. Jde o to, že tentýž koncept — produkt, objednávka, zákazník, kategorie — je na různých platformách modelován jinak na úrovni vztahů mezi tabulkami, typů polí, hierarchie závislostí a obchodní logiky zakódované přímo do struktury databáze.
WooCommerce ukládá atributy produktů jako meta pole v wp_postmeta — plochá tabulka klíč-hodnota se serializovanými PHP daty. Jeden produkt s pěti variantami znamená desítky řádků v této tabulce, z nichž část obsahuje serializovaná PHP pole bez přímého ekvivalentu v žádném jiném systému. PrestaShop ukládá produkty do samostatných tabulek: ps_product, ps_product_lang (překlady), ps_product_attribute (kombinace), ps_product_attribute_combination (vazby atributů na kombinace), ps_stock_available (stavy per kombinace per sklad). Magento jde ještě dál — model EAV (Entity-Attribute-Value) znamená, že každý atribut produktu žije v samostatné tabulce a dotaz na kompletní produkt je JOIN přes desítky tabulek.
Shoptet je jiný příběh — jde o SaaS platformu, která svou databázi vůbec nezpřístupňuje. Export dat probíhá přes XML feed nebo API s omezeným datovým modelem. To, co vidíte v exportu ze Shoptetu, není úplná struktura dat — je to jen to, co Shoptet rozhodl exportovat. Produktové parametry, varianty, vazby kategorií a zákaznická data mají v exportu vlastní formát, který se ani zdaleka nepodobá interní struktuře PrestaShop nebo WooCommerce.
Migrace produktových dat mezi těmito systémy není konverze CSV. Je to transformace datového modelu — překlad jedné ontologie do druhé. U jednoduchého katalogu plochých produktů bez variant to jde relativně hladce. U tisíce konfigurovatelných produktů s vícevariantními atributy, cenami per zákaznická skupina, se spřaženými produkty a cross-selly — každá kategorie dat vyžaduje vlastní mapování, vlastní transformační skript a vlastní sadu hraničních případů.
A nejde jen o mapování jedna ku jedné. Některé koncepty zdrojové platformy prostě v cílové platformě neexistují ve stejné podobě. Shoptet má "parametry produktu" — systém vyhledatelných atributů integrovaný s filtrováním kategorií. PrestaShop má vlastní systém vlastností (features) a atributů (attributes) s jinou logikou rozdělení. To není otázka mapování pole na pole — to je architektonické rozhodnutí: jak chcete, aby tato struktura fungovala v novém systému? A toto rozhodnutí vyžaduje pochopení obou platforem, nejen jedné.
Zákaznické účty: hesla, která nemáte
To je problém, o kterém klienti zjišťují příliš pozdě, a který generuje více frustrace než cokoli jiného při celé migraci.
Hesla zákazníků jsou hashována. Každá platforma používá vlastní algoritmus — WooCommerce používá PHPass (vlastní implementace bcrypt se solí), PrestaShop používá MD5 nebo vlastní variantu ve starších verzích, novější bcrypt nebo argon2i, Magento vlastní algoritmus se solí per uživatel. Shoptet hashuje hesla vlastním způsobem a neposkytuje k nim přístup vůbec — při migraci ze Shoptetu prostě zákaznická hesla nemáte, bod. Když migrujete zákaznickou databázi, máte tabulky s hashi hesel — ale hashe ze zdrojového systému jsou v cílovém systému k ničemu, protože cílový systém neví, jak je ověřit.
Technicky existuje několik přístupů, žádný není ideální.
Plný reset hesel — pošlete e-mail každému zákazníkovi s informací o migraci a odkazem na nastavení nového hesla. Jednoduché, bezpečné, transparentní. Ale vyžaduje přípravu komunikace, vyžaduje podporu zákazníků, kteří e-mail nedostali nebo ho ignorovali jako phishing, a generuje kumulovanou zátěž supportu v prvních dnech po go-live. U databáze 5 000 zákazníků, z nichž 10–15 % bude mít problémy s resetem — to je reálná práce na několik dní.
Migrace s dvojitou verifikací — při prvním přihlášení po migraci systém zkusí ověřit heslo starým algoritmem, po úspěchu ho znovu zahashuje vlastním. Technicky elegantní, pro zákazníka neviditelné. Problém: vyžaduje nestandardní kód v cílovém systému, který musí správně fungovat po celou přechodnou dobu, a musí být poté odstraněn. U SaaS platforem tento přístup nepřichází v úvahu — nemáte přístup k logice autorizace.
Vynucený reset při prvním přihlášení — kompromis. Zákazník existuje v novém systému, má celou historii objednávek dostupnou po přihlášení, ale musí projít resetem.
Ve všech variantách platí jeden společný jmenovatel: zákazníci musí být o migraci informováni. A informováni dobře — ne jednořádkovým systémovým "vaše heslo bylo resetováno", ale komunikací, která vysvětluje co se mění, proč, a co zákazník má udělat. Špatně provedená migrační komunikace generuje vlny negativních recenzí na Heurece, Zboží.cz a v Google, které nesouvisejí s kvalitou nového shopu — jen se zmatením zákazníků.
Historie objednávek: co vzít a co přenést nejde
Historie objednávek jsou data, která zákazníci považují za svá — a mají pravdu. Objednávka podaná před dvěma lety, kterou chce zákazník vidět pro záruční účely, by měla být po migraci dostupná.
V praxi je to jeden z nejtěžších prvků. Objednávka v e-commerce systému není jednoduchý záznam — je to graf závislostí: objednávka → položky objednávky → produkty (které se mohly změnit nebo být smazány) → zákazník → doručovací adresa → fakturační adresa → způsob platby → způsob doručení → historie stavů s timestampy → faktury → poznámky → reklamace. Každý prvek musí být správně namapován, přičemž část nemusí mít přímý ekvivalent v novém systému.
Produkty smazané z eshopu stále figurují v historických objednávkách. Ve zdrojovém systému jsou obvykle zachovány jako snapshot ceny a názvu v tabulce položek objednávky. V cílovém systému je třeba rozhodnout: vytváříte placeholder "archivní" produkty, aby byla historie kompletní, nebo akceptujete, že část položek se bude zobrazovat bez úplných dat?
Stavy objednávek jsou specifické pro platformu. "Vyřízeno" ve Shoptetu není totéž co "completed" ve WooCommerce nebo "Livré" v PrestaShop, i když sémanticky znamenají totéž. Při migraci historických stavů je třeba rozhodnout, jak mapovat mezistupně — objednávky otevřené v době migrace, částečně vyřízené objednávky, objednávky s vrácením části položek.
Způsoby platby a doručení mění názvy. Platební brána před třemi lety mohla změnit název nebo přestat existovat. Zásilkovna se ještě donedávna jmenovala Zásilkovna, pak Z-BOX, pak různě — a pokud historické záznamy obsahují konkrétní název, ten název prostě bude v historii. Lze migrovat přesné názvy — což vede k historii s metodami, které nový shop nepodporuje — nebo mapovat na aktuální, což je méně přesné, ale použitelnější.
Recenze produktů: problém s věrohodností
Recenze sebrané ve starém shopu jsou jedním z nejcennějších zdrojů — a jedním z nejtěžších ke správné migraci.
Technicky přenést obsah je relativně jednoduché: tabulka s textem, hodnocením, datem, autorem. Tady začíná problém věrohodnosti.
Většina platforem ověřuje recenze na úrovni systému — před zobrazením kontroluje, zda existuje vazba mezi uživatelem, který recenzi napsal, a objednávkou produktu, jehož se týká. Jde o antispamový mechanismus a signál důvěry pro kupující. Po migraci mohou být tyto vazby poškozeny: ID zákazníků se při migraci mění, ID produktů se mění, historické objednávky nemusí být správně navázány na účty.
Pokud migrujete recenze bez zachování těchto vazeb — nový systém je může zobrazovat jako "neověřené" nebo je úplně odfiltrovat jako potenciální spam. Pokud je migrujete s umělými vazbami — riskujete, že cílová platforma je označí za manipulované. To má zvláštní význam u Allegro.cz a dalších marketplace, kde integrace recenzí shopu ovlivňuje pozici nabídek.
Ekosystém externích recenzí — Heureka, Zboží.cz, Trusted Shops, Google Reviews — je ještě složitější. Recenze, které zákazníci napsali na těchto platformách, jsou vázány na doménu a profil shopu. Změna struktury URL, změna layoutu produktových stránek, změna domény — to vše může ovlivnit viditelnost hodnocení a jejich zobrazení ve výsledcích vyhledávání. Ověřená hvězdičková hodnocení na Heurece jsou navázána na feed produktů a certifikát shopu — při migraci je třeba ověřit, zda certifikát platí i pro novou platformu a novou strukturu feedu.
Flow objednávek: zakódovaná obchodní logika
To je prvek, díky kterému je odhad času nejtěžší — protože je zcela jiný pro každého klienta.
Flow objednávky ve "standardním" shopu je: košík → checkout → platba → potvrzení → realizace → odeslání → doručeno. Žádný shop s víceletou historií ale nemá "standardní" flow. Každý v průběhu let přizpůsoboval procesy vlastním potřebám — prostřednictvím úprav kódu, vlastních modulů, integrací s externími systémy. A tato obchodní logika neexistuje v žádném exportním souboru — existuje ve zdrojovém kódu starého shopu, v dokumentaci, kterou nikdo nepsal, a v hlavách lidí, kteří s tímto shopem pracují.
Nestandardní způsoby doručení — shop, který prodává výhradně palety firmám, má zcela jinou logiku výpočtu nákladů na doručení než "standardní" balíkový shop. Pravidla "pokud objednávka váží více než X tun nebo hodnota přesahuje Y, zavolejte pro nacenění" jsou zakódována v nějakém modulu, který je třeba přepsat od začátku nebo najít ekvivalent v nové platformě. U shopů s doručením přes Zásilkovnu, GLS nebo PPL je třeba znovu nakonfigurovat všechna pravidla cenových zón a způsoby výpočtu dopravy.
Nestandardní stavy objednávek — shop, který sám vyrábí zboží, má stavy "Přijato do výroby", "Ve výrobě", "Připraveno k odeslání", které žádná standardní platforma nemá. Na tyto stavy jsou navázána všechna e-mailová oznámení zákazníkům, všechna pravidla automatizace v Base.com, všechny integrace s ERP.
Nestandardní cenová pravidla a slevy — shop, který má věrnostní program, ceny per zákaznická skupina, množstevní slevy, dohodnuté ceny per B2B zákazník — každé z těchto pravidel musí být znovu vytvořeno. Platformy mají v tomto ohledu různé možnosti, což vyžaduje kompromisy nebo nestandardní kód.
Integrace s externími systémy — ERP, skladový systém, účetní program (Pohoda, ABRA Flexi, Money S3), Base.com, Brevo, dopravce s vlastním API. Každá integrace musí být v novém prostředí otestována od začátku. Změny v datové struktuře (nová ID produktů, objednávek, zákazníků) vyžadují aktualizaci na straně integrovaných systémů. Mapování stavů, která fungovala léta, musí být překonfigurována.
Proč "máme zálohu" problém neřeší
Jedním z nejčastějších argumentů je "v případě problémů se vždy vrátíme ke starému shopu". Technicky pravda. Prakticky — ne.
Po dobu, kdy nový shop funguje, byť jen několik dní, přicházejí nové objednávky. Tyto objednávky existují pouze v novém systému. Návrat ke starému znamená jejich ztrátu, nebo ruční přepisování, nebo provozování obou systémů současně — což je technicky možné, ale operačně noční můra.
Každá objednávka zadaná po go-live je reálnou transakcí — zákazník zaplatil, čeká na zboží. Neexistuje "testovací produkční režim".
Shoptet migraci komplikuje ještě jedním faktorem: při zrušení Shoptet předplatného přijdete o přístup k administraci a datům. Okno, kdy máte přístup k původnímu systému i k novému, je časově omezené a musí být pečlivě naplánováno.
Co reálně dělá rozdíl
Nepíšu to, abych odrazoval od migrace. Píšu to proto, aby migrace proběhla s otevřenýma očima.
Správně provedená migrace vypadá takto: dva až čtyři týdny analýzy předtím, než je napsán jediný řádek migračního kódu. Inventarizace všech nestandardních funkcionalit starého shopu. Rozhodnutí co migrovat, co přepsat od začátku a co opustit jako zastaralé. Stagingové prostředí, kde migrace probíhá a je testována opakovaně — ne jednou, ale mnohokrát s různými sadami dat. Migrační skripty, které jsou idempotentní — lze je spustit opakovaně a vždy dostanete stejný výsledek. Komunikace zákazníkům připravená a odeslaná před, nikoli po go-live. Plán podpory na prvních 48 hodin.
A harmonogram, který neříká "migrace zabere 2 týdny", ale "migrace produktů a kategorií zabere týden, migrace zákazníků s komunikací zabere dva týdny, obnova logiky flow objednávek zabere tolik, kolik zabere po inventarizaci".
Klient, který tomuto procesu rozumí a je připraven jím projít — má šanci na migraci, která nekončí dvoutýdenní krizí po go-live. Klient, který chce "rychlou migraci" — dostane ji, ale platí za ni dalších několik měsíců.
