Magento Open Source, Adobe Commerce a Magento 1 vs. 2
Magento Open Source je zdarma dostupný, samostatně hostovaný e-commerce software postavený na PHP; Adobe Commerce (dříve Magento Commerce) je placená úroveň s dalšími funkcemi pro B2B, staging obsahu a cloudový hosting, provozovaná na infrastruktuře spravované Adobe. Magento 1 dosáhlo konce životnosti už před lety a obchody, které na něm stále běží, migrují většinou právě z tohoto důvodu, nezávisle na jakémkoli srovnávání platforem.
Kvůli tomuto rozpětí může projekt „migrace Magenta“ znamenat přechod malého obchodu na Magento 1 na zcela jinou platformu, přechod z Magenta 1 na Magento 2 (stále Magento, ale přestavba na hlavní verzi), nebo odchod z Adobe Commerce Cloud na řešení s jinou nákladovou strukturou. Které z toho se týká vašeho případu, určíme dřív, než cokoli odhadujeme.
Datový model EAV a nastavení víceobchodového provozu
Magento ukládá produktová data pomocí struktury EAV (entity-attribute-value), která je silná pro vysoce konfigurovatelné katalogy bohaté na atributy, ale strukturně odlišná od jednodušších plochých produktových tabulek, jaké používá většina ostatních platforem. Konfigurovatelné produkty (obdoba variant v Magentu), sady vlastních atributů i vrstvená navigace řízená atributy vyžadují při přechodu na platformu bez ekvivalentu EAV výslovné mapování.
Víceobchodová/vícewebová architektura Magenta, provoz několika výloh, měn nebo lokalizací z jedné instalace, je další věc, kterou je třeba pečlivě namapovat, protože většina platforem řeší více obchodů jinak: samostatné obchody, jeden obchod s nastaveními specifickými pro daný trh, nebo žádný nativní ekvivalent.
Rozšíření, vlastní moduly a vývojáři Magenta
Obchody na Magentu se běžně spoléhají na rozšíření z marketplace a na zakázkově vytvořené moduly pro cokoli nad rámec základní funkcionality — platební metody, cenová pravidla pro B2B nebo katalogovou logiku specifickou pro daný byznys. Protože je Magento platforma náročná na vývojáře, podstatná část toho, co obchod „umí“, často žije ve vlastním kódu PHP, ne v nastaveních administrace, a tuto logiku je třeba identifikovat a buď znovu vybudovat, nebo nahradit — ne jen exportovat.
Stejné to je se šablonami: šablony Magenta jsou postavené na vlastním systému layout XML/bloků, který nemá jinde přímou obdobu, takže odchod z Magenta obvykle znamená stavbu výlohy na nové platformě od začátku.
SEO, URL adresy a jak řešíme migraci Magenta
Magento spravuje přepisy URL interně a podporuje poměrně flexibilní struktury URL adres, ale konkrétní podoba (cesty kategorií, přípony URL produktů, URL specifické pro pohled obchodu) se obchod od obchodu podle nastavení hodně liší. Právě kvůli této proměnlivosti začínáme auditem vašich skutečných živých vzorů URL, ne předpokládaným výchozím nastavením Magenta.
U migrace Magenta stavíme mapu URL a přesměrování podle toho, co váš obchod dnes skutečně dělá, řešíme varianty URL pro více obchodů, pokud jsou relevantní, a ověřujeme, že se metadata a kanonické značky přenesou správně. Podrobněji tento postup popisuje naše služba SEO a migrace přesměrování.
Časté otázky
Stále jsem na Magentu 1. Umíte to migrovat?
Ano, odchod z Magenta 1 je jeden z běžnějších projektů, se kterými se setkáváme, obvykle vyvolaný koncem jeho životnosti, ne preferencí platformy. Řešíme to jako kompletní replatforming, protože Magento 1 a 2 mají odlišnou podkladovou architekturu.
Co se stane s mými vlastními moduly pro Magento?
Zjistíme, co každý vlastní modul skutečně dělá — například platební integraci, cenové pravidlo nebo katalogovou funkci — a vyhodnotíme, zda má cílová platforma vestavěnou nebo rozšiřující obdobu, nebo zda je potřeba zakázkový vývoj.
Dají se B2B funkce Adobe Commerce migrovat na neenterprise platformu?
Záleží na konkrétních funkcích. Firemní účty, workflow nabídek a vrstvené B2B ceny nemají přímou obdobu na každé platformě, takže to posuzujeme případ od případu už při vstupním posouzení, ne s předpokladem přesné shody.
Jak ovlivňuje struktura atributů EAV délku migrace?
Katalogy s mnoha vlastními atributy a sadami atributů obecně vyžadují víc času na mapování než jednoduché ploché katalogy, protože u každého atributu je potřeba výslovně rozhodnout, kam na cílové platformě patří.