Proč o tom píšu

Stránka hlinka.cz je věnovaná tomu, čím se dlouhodobě zabývám: přebírání starších podnikových aplikací v C#/.NET a MS SQL. Obvykle jde o interní firemní systémy. Občas se ale objeví projekt, který stojí za to popsat veřejně. Nedávno jsem dokončil migraci jednoho e-shopu a je to dobrý příklad toho, kdy má podobný zásah smysl – a kdy naopak ne.

Hned na úvod chci jednu věc říct jasně: nenabízím migrace běžných, aktuálně podporovaných krabicových e-shopů, kde dává větší smysl zůstat u stávající platformy nebo využít její standardní migrační cestu. Pokud provozujete Shoptet, WooCommerce, Shopify nebo aktuální verzi OXIDu, zpravidla dává největší smysl zůstat u dané platformy a držet ji průběžně aktuální – buď vlastními silami, nebo prostřednictvím dodavatele. V takové situaci moje práce nedává valný smysl.

Tahle případová studie popisuje jiný typ problému. Situaci, kdy:

  • e-shop byl kdysi postavený na míru nebo na platformě, která už není podporovaná,
  • provozovatel má k systému zdrojové kódy,
  • nikdo systém neudržuje – autor odešel, dodavatelská firma zanikla, nebo se údržba za rozumných podmínek nikomu nevyplatí,
  • e-shop přesto funguje, vydělává a zákazníci ho znají.

Pokud se v tomto popisu poznáváte, čtěte dál.

Konkrétní případ: e-shop se šperky z polodrahokamů

Klient provozuje e-shop s minerály, šperky a léčivými kameny od roku 2009. Adresa: www.whitelady.cz.

Z technického hlediska šlo o skutečného pamětníka: OXID eShop Community Edition 4.x, postavený na PHP 5, MariaDB a šablonovacím systému Smarty. V době svého vzniku to byla solidní volba. Dnes je však tato větev OXIDu řadu let bez bezpečnostních aktualizací a většina hostingových firem už PHP 5 ani nedokáže rozumně provozovat.

Samotný e-shop přitom stále fungoval a měl aktivní zákazníky. V databázi bylo 4 387 produktů, 977 objednávek a 1 353 zákaznických účtů. Za patnáct let provozu se navíc ve vyhledávačích nasbíralo mnoho odkazů. Vypnout celý systém a začít znovu by znamenalo zahodit i tu část hodnoty, kterou nelze jednoduše koupit.

Co znamená „nikdo to neudržuje“

V tomto konkrétním případě to znamenalo hlavně toto:

  • autoři původní zakázky se už dávno věnují jiným věcem,
  • OXID 4.x je „end of life“ – komunita se přesunula k novějším větvím, ty však nejsou zpětně kompatibilní: nesedí struktura databáze, šablony ani hooky,
  • každá drobná úprava, například změna ceny dopravy nebo nový bannerový pruh, představovala dobrodružství,
  • hosting v evropském prostředí narážel na nepodporované PHP 5, a tím i na bezpečnostní rizika.

Klient měl tři reálné možnosti:

  1. Pokračovat jako dosud – až do prvního vážnějšího bezpečnostního incidentu nebo do chvíle, kdy stávající hosting přestane fungovat.
  2. Postavit nový e-shop na krabicové platformě a smířit se s tím, že patnáct let SEO, URL struktur, zákaznických účtů a historie objednávek bude z velké části pryč.
  3. Převést stávající systém na moderní technologický základ a zachovat vše, co má v původním řešení hodnotu.

Vybrali jsme třetí cestu. Níže popisuji, jak dopadla.

Cílový stav

Cílem bylo zachovat obchodní kontinuitu e-shopu – produkty, zákazníky, objednávky a funkční odkazy – ale převést ho na úplně jiný technologický základ:

  • .NET 10 LTS a Blazor Web App místo PHP a Smarty,
  • MS SQL Server místo MariaDB,
  • ASP.NET Core Identity pro zákaznické účty, rozšířené o ověřování původních OXID hesel a jejich postupný převod na bezpečnější algoritmus,
  • kompletní zachování historických URL cest; 301 přesměrování slouží pouze ke sjednocení kanonické varianty adres, tedy z HTTP na HTTPS a z původní subdomény eshop.whitelady.cz na www.whitelady.cz,
  • responzivní design, protože původní web byl navržený především pro desktop.

To vše se podařilo. E-shop od června 2026 běží na nové platformě.

Jak migrace probíhala

Migrace proběhla bez přerušení provozu. Stará verze dál běžela a přijímala objednávky, zatímco nová vznikala paralelně. Klíčové kroky byly následující:

  1. Inventura – zmapování toho, co všechno konkrétní instalace OXIDu dělá. U patnáct let starého systému to není triviální; většina dokumentace bývá v hlavách původních autorů, případně neexistuje vůbec.
  2. Doménový model v C# – produkty, kategorie, objednávky, slevy, vouchery, CMS stránky a SEO přesměrování. Celkem více než 40 entit.
  3. Migrátor – konzolová aplikace, která čte původní MariaDB a převádí původní data věcně 1:1 do MS SQL, přičemž technické anomálie staré databáze normalizuje do bezpečných a předvídatelných hodnot. Je idempotentní, takže ji lze spouštět opakovaně, a podporuje i dry-run režim.
  4. Veřejný frontend – katalog, košík, checkout a zákaznický účet.
  5. Administrace – minimální použitelná správa, aby klient po přepnutí mohl spravovat produkty, objednávky i CMS obsah.
  6. Cutover – finální spuštění migrace nad ostrou databází a přepnutí DNS. Proběhlo při nízkém provozu a bez výpadku pro zákazníky.

U podobných projektů pracuji tak, aby každá fáze končila funkčním stavem, na kterém se dá v případě potřeby zastavit. Nejde tedy o „big bang“ přepis naslepo, který po šesti měsících teprve ukáže, zda vůbec povede k použitelnému výsledku.

Co bylo nejtěžší

Za zmínku stojí hlavně tři věci, protože se u podobných projektů často opakují:

Hesla zákazníků. OXID je ukládal vlastním hashovacím algoritmem založeným na MD5 se solí. Z dnešního pohledu to není bezpečné řešení, ale je to fait accompli: v databázi je 1 353 účtů a jejich hesla nikdo nezná v otevřené podobě. Řešením byl vlastní password hasher pro ASP.NET Core Identity, který umí ověřit původní OXID hash a při prvním úspěšném přihlášení heslo přehashovat na moderní PBKDF2. Pro zákazníka je změna neviditelná; pro systém se databáze s každým přihlášením postupně „uzdravuje“.

SEO a URL. OXID používal vlastní systém SEO URL včetně historie změn (oxseohistory). Celkem šlo o 34 172 záznamů. Všechny se přenesly do nové databáze a do middleware, který každý příchozí požadavek nejprve porovná s historickými URL a v případě shody vrátí 301 přesměrování ke sjednocení kanonické podoby adres. Z pohledu Googlu tak nedošlo k žádnému zbytečnému přesunu.

Datové zvláštnosti starého systému. Patnáct let provozu v MySQL znamená řadu drobných nepravidelností: data typu „0000-00-00“, čísla uložená jako prázdný řetězec nebo rozdílné interpretace téhož sloupce v různých částech kódu. Migrátor musí tyto případy zachytit a normalizovat, aby cílová databáze byla čistá a předvídatelná.

Co migrace přinesla v praxi

Po spuštění nové verze lze shrnout konkrétní přínosy zvlášť pro provozovatele a zvlášť pro zákazníky.

Pro provozovatele

Zásadní snížení bezprostředního existenčního rizika. .NET 10 LTS má podporu do listopadu 2028. Hosting na Windows Serveru s ASP.NET Core podporují i levnější sdílená prostředí. Odpadla tak závislost na PHP 5, které hostingové společnosti přestaly nabízet.

Změny jsou konečně jednodušší. Cena poštovného, nový bannerový blok, textová stránka nebo změna kategorií – to vše lze řešit přes administrační rozhraní nebo přes EF Core migraci, nikoli ručními zásahy do PHP souborů na serveru a následným čekáním, zda se něco nerozbilo.

Logování a monitoring. Dříve se provozovatel o chybách často dozvěděl až od zákazníka. Nyní Serilog zapisuje strukturované logy s 90denní retencí, aplikace sleduje vlastní spotřebu paměti a health-check endpoint ukazuje, zda reaguje databáze. Každý restart aplikace zapíše svou příčinu do logu.

Srovnávače a feedy. Nová verze automaticky generuje produktové feedy pro Heureku, Zboží.cz a Google Merchant. Klient je tak nově zastoupený na srovnávačích bez ručního exportu.

Platební brána. Integrace Comgate nahradila původní platební řešení. Jde o aktuálně podporovanou českou platební bránu s webhooky a automatickým zpracováním stavů objednávek.

CI/CD a Docker. Každý commit prochází přes GitHub Actions, tedy buildem a testy. Nasazení na produkci je opakovatelný a zdokumentovaný proces, nikoli ruční FTP upload.

Pro zákazníky

E-shop konečně dobře funguje na mobilu. Původní verze byla navržená hlavně pro desktop. Nový e-shop je plně responzivní – katalog, košík i checkout fungují na mobilu bez horizontálního posouvání.

Přihlašovací údaje zůstaly stejné. Zákazníci se mohou přihlásit stejným heslem jako dříve. Nikdo nemusel nastavovat nové heslo a nikomu nepřišel matoucí e-mail typu „váš účet byl přenesen“. Ze zákaznického pohledu se e-shop jednoduše zlepšil.

Záložky a zapamatované adresy dál fungují. Všech 34 172 historických URL přesměrovává na správné místo. Zákazník s uloženým odkazem na konkrétní produkt se dostane na správnou stránku. Pokud použije starší variantu adresy na HTTP nebo na subdoméně eshop.whitelady.cz, je automaticky přesměrován na kanonickou adresu na www.whitelady.cz

AI poradce pro výběr kamene. Nová funkce, která v původním OXIDu neexistovala. Zákazník může napsat dotaz přirozenou větou – například „hledám kámen pro znamení Lva“ nebo „chci dárek pro někoho, kdo medituje“ – a e-shop mu na základě sémantického vektorového vyhledávání s využitím HuggingFace embeddingů nabídne relevantní produkty. Jde o rozšíření nad rámec 1:1 migrace; původní fulltextové vyhledávání nic podobného neumělo.

PDF faktura ke každé objednávce. Zákazníci si mohou stáhnout fakturu přímo ze svého účtu. Původní systém tuto možnost nepodporoval.

Čas a cena

U tohoto konkrétního projektu – tedy e-shopu s desítkami tisíc záznamů, plnou funkcionalitou katalogu, košíku, checkoutu, účtů, slev, voucherů, CMS a administrace plus přechodem na nový hosting – zabralo celé řešení od prvního řádku kódu po nasazení na produkci přibližně 130 hodin. Přibližně 50 hodin z toho tvořila prvotní konverze 1:1 z PHP do .NET, tedy přenesení dat a funkcionality bez nových rozšíření. Zbývající čas připadl na nové funkce, administraci, napojení platební brány, feedy, AI vyhledávání a přepracování hostingu.

Celý vývoj probíhal za výrazné pomoci AI – konkrétně nástroje Claude od společnosti Anthropic, používaného jako programátorský asistent v každodenní práci. AI nenahradila architektonická rozhodnutí, znalost domény ani odpovědnost za výsledek, ale výrazně zrychlila rutinní části práce: generování boilerplate kódu, převod datových struktur i psaní migračních skriptů. Bez podobného nástroje by projekt trval podstatně déle.

Konkrétní cena vždy závisí na rozsahu funkcionality a stavu původního systému. Po úvodním seznámení – typicky po 2 až 3 hodinách placeného auditu, ze kterého vznikne písemný odhad – dokážu určit realistické cenové rozmezí.

Kdy má smysl mě oslovit

Vaše situace by měla splňovat víceméně všechny tyto podmínky:

  • Máte funkční systém, který vydělává nebo má vnitřní hodnotu – například zákazníky, historii, SEO nebo znalost uživatelů.
  • Máte k němu zdrojové kódy. Bez nich podobný postup z principu nedává smysl.
  • Nejde o aktuální verzi živé krabicové platformy. V takovém případě je vhodné řešit situaci primárně s danou platformou.
  • Důvod migrace je technologický – nepodporované PHP, chybějící tým, bezpečnostní rizika – nikoli čistě marketingový ve stylu „chceme to hezčí“. Vzhled se zlepší také, ale jako vedlejší produkt.
  • Počítáte s tím, že nejde o záležitost na pár dnů. Realistický horizont jsou měsíce. Uvedených 130 hodin je sice pracovně necelý měsíc, ale je třeba počítat s konzultacemi a testováním i na vaší straně a průběžnými úpravami dle vašeho přání.

Pokud do tohoto popisu spadáte, napište mi na hlinka@hlinka.cz. Jako první vám pošlu seznam otázek pro úvodní audit. Na jeho základě následně vznikne konkrétní odhad.

Napsat k migraci e-shopu Zpět na přehled služeb