Modelová case study: migrace e-shopu se 100 000 produkty bez výpadku
Sto tisíc produktů se nepřenese jedním importem v noci před spuštěním. Na modelovém příkladu ukazujeme, jak se velká migrace plánuje, aby e-shop ani na hodinu nepřestal prodávat.
Migrace malého e-shopu se dá stihnout přes víkend. U katalogu se sto tisíci produkty to nejde. Samotný přenos dat přes API trvá hodiny až dny, obrázků jsou stovky gigabajtů a každá chyba v převodu se násobí tisíci. Přitom e-shop takové velikosti obvykle nemůže vypnout ani na den, protože by přišel o tržby a signály ve vyhledávání.
Proto se velká migrace neplánuje jako jeden velký skok, ale jako série malých, opakovaných přenosů. Níže je modelový scénář, jak takový projekt vedeme, a místa, kde se u velkých katalogů nejčastěji zasekne.
Výchozí situace modelového e-shopu
Pro model volíme typický profil velkého českého e-shopu:
- zhruba 100 000 produktů, část z nich s variantami, celkem kolem 150 000 variant,
- stovky kategorií a desítky parametrů, ze kterých se generují filtry,
- vlastní řešení nebo starší open source platforma, která přestala stačit,
- napojení na ERP, tři dodavatelské feedy, Heureku, Zboží.cz a Merchant Center,
- organická návštěvnost tvoří podstatnou část tržeb,
- provoz 24/7, žádné okno, kdy by se dalo „na chvíli zavřít“.
Cílem je přejít na novou platformu bez výpadku objednávek a bez trvalé ztráty návštěvnosti z vyhledávání.
Proč nestačí jeden velký import
U malého e-shopu se data vyexportují, převedou a nahrají do nové platformy. U sta tisíc produktů narazíte na tři limity najednou:
- Čas. Plný import trvá dlouho a během té doby se na staré platformě mění ceny, sklad a objednávky. Data jsou zastaralá dřív, než import doběhne.
- Limity API. Platformy omezují, kolik požadavků smí integrace poslat. Plný přenos se tak nedá libovolně zrychlit.
- Chybovost. Při stovce tisíc záznamů najdete desítky okrajových případů, které na vzorku neuvidíte: rozbité znaky, varianty bez ceny, produkty bez kategorie.
Řešení je přenášet data opakovaně, ne jednou. Nejdřív plný import na testovací prostředí, pak pravidelné rozdílové běhy a v den spuštění jen poslední malá delta.
Limity API, se kterými je třeba počítat
Limity se liší podle platformy a tarifu. Pro představu dva veřejně dokumentované příklady (k 9/2026, aktuální stav ověřte v dokumentaci platformy):
| Platforma | Co omezuje | Dopad na velkou migraci |
|---|---|---|
| Shoptet | Nejvýše 3 souběžná spojení na jeden token a 50 z jedné IP adresy. Od ledna 2025 navíc systém „kbelíku“ o kapacitě 200 kapek, ze kterého se každou sekundu uvolní 10, složitější požadavek stojí víc kapek. | Přenos se nedá zrychlit přidáním dalších paralelních procesů. Je třeba optimalizovat požadavky a počítat s delším během. |
| Shopify | GraphQL Admin API počítá cenu dotazu v bodech, standardně 50 bodů za sekundu, na vyšších tarifech víc. Obchod, který má 50 000 a více variant, smí přes API nebo import založit jen 1 000 nových variant denně, na Shopify Plus toto omezení neplatí. | Bez tarifu Plus nebo výjimky od Shopify se velký katalog nedá nahrát rychle. |
Druhý řádek stojí za modelový výpočet. Pokud má e-shop 150 000 variant a běží na tarifu s denním limitem, prvních 50 000 variant založí bez omezení. Zbylých 100 000 variant při limitu 1 000 denně znamená 100 dní zakládání. To je důvod, proč se volba tarifu a platformy u velkých katalogů řeší v auditu, ne až při importu. Víc o platformě v hesle Shopify.
U Shoptetu je navíc potřeba vědět, že soukromé REST API pro vlastníka e-shopu je dostupné jen v Shoptet Premium. V ostatních tarifech se napojuje přes doplňky partnerů nebo přes importy souborů. Detaily k platformě najdete v hesle Shoptet.
Delta importy: jak to funguje
Základem je převodní vrstva mezi starou a novou platformou, v podstatě ETL proces: data se vytáhnou ze staré platformy, převedou do struktury nové a nahrají. Klíčové je, aby si vrstva pamatovala stav.
- Každý záznam má stabilní identifikátor, typicky kód produktu nebo EAN, a k němu ID v nové platformě.
- U každého běhu se ukládá čas a otisk dat. Další běh přenese jen produkty, u kterých se otisk změnil.
- Obrázky se přenášejí jednou a pak jen nové nebo změněné. Právě obrázky bývají u velkých katalogů objemově největší položka.
- Sklad a ceny mají vlastní rychlý běh, protože se mění nejčastěji.
V modelu vypadá přenos takto: plný import na test trvá desítky hodin a opakuje se po každé opravě mapování. Jakmile je mapování stabilní, běží delta jednou denně a trvá jen zlomek času. V den spuštění pak zbývá přenést změny za posledních pár hodin. Detailně se katalogu věnujeme v článku Migrace produktového katalogu bez chyb, obecné principy bez výpadku v článku Migrace e-shopu bez výpadku provozu.
Harmonogram modelového projektu
Délku u takto velkého projektu stanovujeme individuálně. Pro model počítáme s tímto rozložením etap, kde T je den přepnutí:
| Kdy | Etapa | Výstup |
|---|---|---|
| T−8 týdnů | Audit dat, integrací a limitů cílové platformy | Rozhodnutí o tarifu, seznam rizik |
| T−7 až T−5 | Datová mapa, první plný import na test | Převodní vrstva, seznam chyb v datech |
| T−5 až T−3 | Integrace: ERP, platby, doprava, feedy | Otestovaná napojení |
| T−4 až T−2 | Mapa přesměrování pro všechny indexované URL | Tabulka 301 a její test crawlerem |
| T−2 až T−1 | Denní delta importy, uživatelské testy, zaškolení | Stabilní data, schválení spuštění |
| T−7 dní | Snížení TTL záznamů v DNS | Rychlé přepnutí v den D |
| T | Zmrazení katalogu, poslední delta, přepnutí | Spuštěný e-shop |
| T+1 až T+30 | Monitoring a opravy | Stabilní provoz |
Den přepnutí: zmrazení bez zavření
„Bez výpadku“ neznamená, že se nic nezastaví. Znamená to, že se nezastaví prodej. Zmrazení se týká jen ruční práce na katalogu.
- Týden předem snížit TTL. Google v dokumentaci ke změně hostingu doporučuje snížit TTL záznamů v DNS na nízkou hodnotu aspoň týden před přesunem. Díky tomu se po přepnutí rychle projeví nová adresa serveru.
- Zmrazit katalog. Pár hodin před přepnutím se zastaví ruční úpravy produktů, cen a kategorií. Automatický sklad a objednávky běží dál.
- Poslední delta. Přenesou se změny od posledního běhu, zákazníci a objednávky.
- Přepnutí DNS a aktivace přesměrování. Nová platforma začne přijímat návštěvníky.
- Hlídat starou platformu. Během šíření DNS může část zákazníků ještě chvíli nakupovat na staré. Stará platforma proto zůstává v provozu a objednávky z ní se po přepnutí dosynchronizují. Stejně tak platby: notifikace brány k objednávkám ze staré platformy musí dál chodit tam.
- Testovací objednávky s každým způsobem platby a dopravy, kontrola ERP a feedů.
- Uvolnit zmrazení až po kontrole vzorku dat na nové platformě.
Typická rizika u velkých katalogů
| Riziko | Jak se projeví | Prevence |
|---|---|---|
| Limity API nebo zakládání variant | Import trvá dny místo hodin | Ověřit limity a tarif v auditu, testovací plný import |
| Nestabilní identifikátory | Duplicitní produkty po delta běhu | Párovat přes kód nebo EAN, ukládat mapu ID |
| Změna ID ve feedech | Merchant Center bere produkty jako nové a ztrácí historii | Zachovat původní ID ve feedu |
| Neúplná mapa URL | Vlna chyb 404 po spuštění | Mapa ze sitemap, Search Console, analytiky a crawleru |
| Filtry generující tisíce URL | Googlebot plýtvá procházením | Rozhodnout, které filtry indexovat, zbytek canonical nebo noindex |
| Paralelní úpravy během migrace | Změny se ztratí | Zmrazení katalogu a jasný log změn |
Jak na to prakticky
Pokud máte katalog v desítkách tisíc produktů a migraci zvažujete, začněte těmito kroky:
- Spočítejte produkty i varianty. U některých platforem rozhodují limity právě varianty.
- Zjistěte limity API a importů cílové platformy pro váš tarif.
- Zkontrolujte, jestli má každý produkt stabilní kód nebo EAN.
- Vyexportujte všechny indexované URL a jejich návštěvnost.
- Naplánujte spuštění mimo sezónu a počítejte s měsícem monitoringu.
Velké migrace u nás řeší tým, který má za sebou stovky migrací a miliony zpracovaných produktů. Převodní vrstvu a delta importy stavíme v rámci služby importy a exporty, celý projekt vedeme jako migraci e-shopu. Enterprise projekty oceňujeme individuálně a konkrétní nabídku posíláme do 48 hodin od zaslání URL. Co sledovat po spuštění, popisujeme v článku o post-launch monitoringu.
Potřebujete s tím pomoct?