Během existence webu jednou za čas dojde k nutnosti na něm něco změnit, tak že je ohrožena jeho funkčnost. Může se jednat o poměrně jednoduchou úpravu designu, přes přesun na novou doménu z důvodu změny značky, přechod na HTTPS, anebo komplexní migraci na nový redakční systém. Prakticky vždy dochází k rizikům, které mohou negativně ovlivnit návštěvníka anebo pozice ve vyhledávačích.
Mnoho lidí přistupuje zvláště k jednoduchým úpravám poměrně laxně. Případné problémy chtějí řešit za pochodu, popřípadě až se objeví. Problém je, že na ně můžete přijít až po několika letech. Přitom třeba zhoršené pozice některých stránek vás budou trápit po celou tuto dobu.
Pak tu je samozřejmě špatně řízená migrace, která může mít řadu následků, které přesahují propady ve výsledcích vyhledávaní, návštěvnosti a výkonu. Označujeme je za sekundární dopady.
Snížení komfortu uživatelské přívětivosti
Ten kdo pocítí nedotažené přípravy jsou uživatelé. Mohou narazit na stránky, které neexistují (server vrací chybu 404). Pokud jste po přesunu neprovedli kompletní test crawlovacím robotem, nemáte šanci tuto chybu odhalit. Navíc při změnách redakčního systému se mohou projevit i s přibýváním nového obsahu.
Další je například pozapomenutý obsah na nezabezpečeném protokolu HTTP. Pokud jste kompletně přešli na HTTPS, tak stahovaný nezabezpečený obsah (stačí jeden obrázek) je potenciální riziko. To samozřejmě internetový prohlížeč dá návštěvníkovi jasně najevo. Označí stránku za nezabezpečenou. Tomuto opět můžete předejít proběhnutím webu pomocí robota, který stáhne všechny odkazy a zjistí jestli jsou na HTTPS.
Snížení funkčnosti analytiky
Důkladné měření výkonosti webu je dobrým předpokladem pro budoucí zlepšování uživatelské přívětivosti. Tato měření často potřebují dlouhou dobu sbírat data a pravidelně vyhodnocovat. Ovšem s přesunem se může pozapomenout nejen na měřící kódy, ale i různé parametry, které se předávají v URL. Stačí jedno neopatrné přesměrování mezi HTTPS a vše se ztratí. Pokud generujete řetězce anebo přenášíte data pomocí koláčků, je dobré se ujistit, že všechno bude fungovat tak jak má.
Škálování a infrastruktura
Pokud přecházíte na nový redakční systém anebo řešení je dobré ujistit se, že je dobře škálovatelné. Nový neznamená rychlejší. Právě naopak. Starší řešení často muselo počítat s menším přiděleným výkonem, který v dané době mohl být velmi velký. Dnes však je výkon daleko levnější. Nikdo nešetří, neoptimalizuje, prostě se přikoupí další paměť, procesory, místo na disku.
No a tady se dostáváme k samotnému problému. Při přechodu na nový systém je třeba otestovat kolik toho zvládne při předpokládaném růstu plus nějaká rezerva. Může se totiž stát, že zázemí, které máte nebude do budoucna dostatečné a opět se stěhovat, kdy web padá kvůli přetížení není nic jednoduchého.
Je také třeba zamyslet se nad možnostmi dneška a zamyslet se jestli do infrastruktury nezapojit technologie jako CDN, DDOS ochrana anebo failover. Mimochodem na co se nejčastěji zapomíná je vhodné použití zálohování. V dnešní době není nic neobvyklého ani náročného mít více automatických záloh, kdy se zálohuje do jiné geografické lokality.
Mimochodem čím větší budete mít infrastrukturu celého projektu, tím náročnější také přesun bude. Ale s tím je třeba počítat a dobře se na to připravit.
Budoucí příležitosti
Už to částečně zaznělo v předchozím odstavci. Berte v potaz že přesunem webu, infrastruktury, systémů atd. se vám zároveň otvírají možnosti něco vylepšit. Například pokud zvažujete přechod ze starého serveru na nový, můžete místo toho zvážit výhody řešení v cloud. Nepojedete sice na vlastním železe ale nemusíte se starat o to, když se něco pokazí, také je zde větší možnost škálování, redundance a přikoupení výkonu.
Jinými slovy, když už se v něčem hrabete tak nepropásněte možnost rovnou udělat další věci pořádně. Přeci jen pokud to za půl roku, rok anebo i dva budete muset stejně udělat je lepší to odbýt najednou a ušetřit náklady.
Sekundární dopady jsou o ušetření peněz.
