Technický dluh e-shopu: jak jej poznat a splácet

Technický dluh nevidíte v administraci ani ve výsledovce. Projevuje se nepřímo. Každá nová funkce trvá déle, než by měla. Aktualizace pluginu rozbije košík. Vývojář odmítá sáhnout do části kódu, „protože to tam nějak funguje". A jednoho dne hosting oznámí, že starou verzi PHP přestává podporovat.

Pojem technický dluh se v softwaru používá pro odložená rozhodnutí. Rychlá oprava místo správného řešení, neaktualizovaná knihovna, doplněk nainstalovaný „jen na zkoušku". Každé takové rozhodnutí může mít dobrý důvod. Problém nastává, když se dluh jen hromadí a nikdo ho nesplácí. Pak platíte úroky: pomalejší vývoj, víc chyb a vyšší bezpečnostní riziko.

Symptomy: podle čeho technický dluh poznáte

Většinu symptomů pozná i majitel bez technického vzdělání. Stačí sledovat, jak se e-shop chová při změnách.

• Malé změny trvají neúměrně dlouho. Úprava textu v košíku zabere vývojáři dny, protože nejdřív musí pochopit, co ovlivní.
• Aktualizace se odkládají. Nikdo se neodváží aktualizovat platformu ani pluginy, protože minule se po aktualizaci něco rozbilo.
• Chyby se vracejí. Stejný problém se opravuje opakovaně, protože se řeší příznak, ne příčina.
• Znalost je v hlavě jednoho člověka. Chybí dokumentace a když externí vývojář odejde, nikdo neví, jak napojení na sklad funguje.
• Změny se dělají přímo na ostrém webu. Bez testovacího prostředí a bez verzování kódu.
• E-shop zpomaluje. Každý další plugin přidá skripty a databázové dotazy a stránky se načítají pomaleji.
• Hosting nebo platforma posílá varování. Konec podpory PHP, konec podpory verze platformy, nekompatibilní rozšíření.

Pokud poznáváte tři a více bodů, máte dluh, který už stojí peníze.

Termíny, které se nedají odložit (k 9/2026)

Část technického dluhu má pevný termín splatnosti. Když skončí podpora jazyka nebo platformy, přestávají vycházet bezpečnostní záplaty. E-shop dál funguje, ale každá nově objevená zranitelnost zůstává otevřená.

Zdroje: php.net (Supported Versions), Adobe Experience League (lifecycle policy), WooCommerce Developer Blog (září 2026), dokumentace PrestaShop.

PHP od roku 2024 dává každé verzi dva roky aktivní podpory a dva roky bezpečnostních oprav. Konec podpory vychází vždy na 31. prosince. U Magenta je situace citelnější: Adobe pro licencované Adobe Commerce nabízí u řady 2.4.6 prodlouženou podporu, pro Open Source ale 11. srpen 2026 znamenal konec záplat. Verze 2.4.9 přitom ukončuje podporu PHP 8.2, takže upgrade platformy a jazyka jde ruku v ruce.

U WooCommerce se dluh obvykle skrývá v pluginech. Samotné jádro se aktualizuje snadno, brzdou bývají rozšíření, která nové verze PHP nebo WooCommerce nepodporují. U PrestaShopu je častým dluhem řada 1.7, která na PHP 8 neběží.

Odkud se technický dluh bere

Dluh nevzniká z lenosti. Obvykle z rozumných rozhodnutí, která se nikdy nevrátila na stůl:

• Termín před kvalitou. Kampaň startuje v pondělí, tak se funkce dodělá „provizorně".
• Plugin na každý problém. Deset pluginů od deseti autorů, z nichž polovinu nikdo neaktualizuje.
• Úpravy jádra platformy. Zásah přímo do kódu platformy místo rozšíření. Při každém upgradu se musí ručně přenášet.
• Střídání dodavatelů. Každý vývojář řeší věci po svém a nikdo nemá celkový obraz.
• Chybějící vlastník. Za techniku e-shopu nikdo neodpovídá, takže se řeší jen to, co hoří.

Jak dluh změřit, aby nezůstal u pocitu

„Máme to zastaralé" je pocit. Pro rozhodnutí potřebujete čísla, která si vedete sami. Nemusí jich být mnoho:

• Doba dodání změny. Kolik dní uplyne od zadání drobné úpravy po nasazení. Když roste, roste i dluh.
• Chyby po nasazení. Kolikrát za měsíc se po aktualizaci nebo úpravě něco rozbilo a muselo se vracet.
• Podíl údržby. Kolik hodin vývojáře měsíčně padne na opravy a „udržení při životě" místo nových funkcí.
• Počet neudržovaných rozšíření. Pluginy a moduly, které autor rok a déle neaktualizoval.
• Verze pod podporou. Ano, nebo ne, pro PHP, databázi a platformu.

Stačí je jednou za čtvrtletí zapsat do tabulky. Trend vám řekne víc než jednorázové měření. A hlavně dá argument pro rozpočet: údržbu, která zabírá polovinu kapacity vývoje, už nikdo nepovažuje za zbytečnost.

Plán splácení v pěti krocích

Technický dluh se nesplácí najednou. Splácí se postupně, podle rizika a přínosu.

1. Inventura. Sepište verze platformy, PHP, databáze, všech pluginů a modulů a všechna napojení. Ke každému: kdo ho spravuje, kdy byl naposledy aktualizován, jestli má dokumentaci. Hlubší rozbor dělá technologický audit.
2. Prioritizace podle rizika. Na první místo patří věci s termínem: končící podpora PHP a platformy, neudržované pluginy s přístupem k platbám nebo zákaznickým datům. Pak to, co nejvíc brzdí vývoj.
3. Základní infrastruktura. Testovací prostředí, verzování kódu, zálohy s ověřenou obnovou. Bez nich je každý další krok riziko.
4. Pravidelné splácení. Vyhraďte na údržbu pevnou část kapacity vývoje v každém měsíci, ne až „až bude čas". Konkrétní podíl závisí na stavu e-shopu, důležitá je pravidelnost.
5. Rozhodnutí o platformě. Pokud inventura ukáže, že upgrade by znamenal přepsat většinu úprav, porovnejte ho s přechodem jinam. Kdy dává smysl, popisujeme v článku Replatforming: kdy je čas změnit platformu.

Upgrade, nebo migrace?

Pronajímaná (SaaS) platforma technický dluh neodstraní úplně. Přesune ale aktualizace jádra, serveru a jazyka na provozovatele. Dluh pak zůstává hlavně v doplňcích, šablonách a napojeních.

Jak na to prakticky

Začněte jednoduchou otázkou: na jaké verzi PHP a platformy váš e-shop běží a do kdy je podporovaná? Pokud odpověď neznáte nebo je „už ne", je to první položka splátkového kalendáře. Zabezpečení, které s dluhem úzce souvisí, rozebíráme v článku Bezpečnost e-shopu: základní hardening.

Stav techniky, rizika a prioritizovaný plán splácení zjistíme v rámci auditu e-shopu, technologický audit zvládáme do 10 dnů. Samotné upgrady, úklid pluginů a nastavení testovacího prostředí pak řeší naše služba programování a vývoj. Pokud chcete mít techniku e-shopu dlouhodobě pod dohledem, podívejte se na program Ecommerce Care.