Kontrolný zoznam pre replatforming e-shopu

Ešte pred porovnávaním cieľových platforiem preverte, čo skutočne máte na tej súčasnej: koľko produktov a variantov, koľko zákazníckych účtov a akú históriu objednávok, ktoré vlastné polia sa aktívne používajú a ktoré sú opustenými zvyškami, na ktorých aplikáciách či integráciách vitrína závisí a ktoré URL adresy majú v súčasnosti zmysluplnú návštevnosť. Práve tento audit mení vetu „migrujeme“ na projekt s presne stanoveným rozsahom a reálnym zoznamom toho, čo sa musí presunúť.

V tejto fáze buďte úprimní ohľadom kvality dát. Ak má váš katalóg známe duplicity, osirotené kategórie alebo nekonzistentné atribúty, zapíšte si to už teraz — vyčistiť to je lacnejšie pred presunom než po ňom, a preskočenie auditu je spôsob, ako tímy tieto problémy objavia až uprostred migrácie.

Každá platforma štruktúruje produkty, varianty, kategórie aj zákaznícke dáta mierne odlišne. Pred presunom akýchkoľvek dát vybudujte explicitné mapovanie: ktoré zdrojové pole ide na ktoré cieľové pole, ktoré zdrojové koncepty (vlastný atribút, štítok, typ balíka) nemajú priamy ekvivalent na cieli a vyžadujú rozhodnutie, a ktoré polia sa dajú bezpečne úplne vypustiť, pretože na nich už nič nezávisí.

Toto mapovanie zdokumentujte niekde trvanlivom — v tabuľke či zdieľanom dokumente, nie len v niekoho pamäti. Stane sa referenciou, ku ktorej sa všetci vracajú počas QA, a je to prvá vec, ktorú budete chcieť, keď po spustení niečo nebude vyzerať v poriadku.

Štruktúra URL adries je jedno z najčastejších miest, kde migrácia potichu poškodí SEO a poruší záložky. Zostavte si úplný zoznam súčasných URL adries — stránky produktov, kategórií a kolekcií, blogové či obsahové stránky a akékoľvek vlastné vstupné stránky — a pred spustením čohokoľvek rozhodnite novú URL adresu pre každú z nich. Stránky bez čistého ekvivalentu na novej platforme si vyžadujú explicitné rozhodnutie (zvyčajne presmerovanie na najbližšiu zodpovedajúcu kategóriu alebo hlavnú stránku), nie tichú chybu 404.

Toto plánovanie prebieha dávno pred prepnutím, ideálne paralelne s prácou na mapovaní dát, keďže obe veci spolu súvisia: to, ako mapujete kategórie a produkty, často určuje, ako budú vyzerať nové URL adresy. Celý postup nájdete v samostatnom návode na mapovanie presmerovaní, odkazovanom nižšie.

Nikdy neberte prvý import ako finálny. Nahrajte namapované dáta na testovaciu alebo skúšobnú inštanciu cieľovej platformy a obchod naozaj používajte: prechádzajte kategórie, prezerajte stránky produktov, kontrolujte výber variantov a ceny, otestujte košík aj proces pokladne a potvrďte, že sa zákaznícke účty a história objednávok zobrazujú správne. Zapojte niekoho mimo migračného tímu — čerstvý pohľad odhalí veci, ktoré si tí, čo mapovanie budovali, prestali všímať.

Berte túto fázu ako iteratívnu. Je normálne, že sa pri prvom prechode nájdu problémy s mapovaním; cieľom je zachytiť a opraviť ich práve tu, na testovacom prostredí, kde chyba stojí len opätovný import, nie výpadok naostro či chybu viditeľnú pre zákazníkov.

Písomne rozhodnite, čo sa počas prepnutia stane: ako sa naložia s novými objednávkami na starej platforme, ak migrácia trvá dlhšie (dočasné zmrazenie objednávok, stránka údržby, alebo pokračovanie prevádzky až do definovanej finálnej synchronizácie), kto vykoná finálnu synchronizáciu dát, kto overí DNS aj SSL na novej platforme a kto má právomoc vrátiť zmeny späť alebo pozastaviť spustenie, ak niečo nebude v poriadku.

Dajte tímu na daný deň zdieľaný kontrolný zoznam, nie len plán v niečej hlave. Uponáhľané alebo nejasné prepnutie je presne miesto, kde inak dobre pripravené migrácie strácajú dáta — napríklad zopár objednávok zadaných v medzere medzi finálnou synchronizáciou a spustením naostro — preto na túto medzeru plánujte explicitne, namiesto toho, aby ste dúfali, že nebude záležať.

Dni a týždne po prepnutí sú presne obdobie, keď sa prejavia problémy, ktoré testovacie prostredie nezachytilo: nesprávne nastavená platobná brána pre živú návštevnosť, pravidlo dane či dopravy, ktoré sa pri reálnych objednávkach správalo inak, presmerovania fungujúce pre stránky, ktoré ste testovali, ale nie pre okrajové prípady, alebo meraci pixel, ktorý potichu prestal fungovať. Nastavte si zámerný proces sledovania namiesto toho, aby ste predpokladali, že ticho znamená úspech.

Náš kontrolný zoznam QA po spustení (odkazovaný nižšie) túto fázu pokrýva podrobne — overenie pokladne a platieb, namátkovú kontrolu presmerovaní, kontinuitu analytiky aj sledovanie Search Console —, keďže si zaslúži vlastný, dedikovaný proces, nie uponáhľaný dodatočný nápad vo chvíli, keď sa pozornosť tímu už presunula inam.