Známý příběh
Klient přišel s příběhem, který slýcháme často: PHP aplikace z roku 2013, běžící na jednom serveru, obsluhující 50 000 uživatelů denně. Fungovala — tak tak. Načítání stránek trvalo v průměru 4 sekundy. Každý deployment byl ruční FTP upload následovaný modlitbou. Kódová báze neměla testy, dokumentaci a tři vývojáři, kteří jí rozuměli, už dávno odešli.
Vzor Strangler Fig
Neudělali jsme velký třesk a nepřepisovali všechno najednou. Takhle migrační projekty umírají. Místo toho jsme použili vzor Strangler Fig: stará PHP aplikace dál obsluhovala provoz, zatímco jsme ji kousek po kousku přestavovali. Nastavili jsme reverzní proxy (Nginx), která směrovala konkrétní cesty na novou Next.js aplikaci a zbytek na legacy PHP. Každý sprint jsme migrovali 2–3 routy, ověřili paritu a přepnuli konfiguraci proxy.
Výzva jménem data
Nejtěžší nebyl kód — byla to data. Legacy MySQL databáze měla přes 200 tabulek, nekonzistentní pojmenování, žádné cizí klíče a byznysovou logiku zakopanou ve stored procedurách. Postavili jsme datovou vrstvu, která abstrahovala staré schéma, a postupně migrovali na čistou PostgreSQL databázi pomocí dual-write vzoru. Šest týdnů obě databáze běžely synchronně, zatímco jsme ověřovali integritu dat.
Výsledky mluví za vše
Po osmi měsících byla migrace hotová. Načítání stránek kleslo ze 4 sekund na 800 ms. Deploymenty se změnily z ručního FTP na automatizované CI/CD přes GitHub Actions. Tým přestal se změnami otálet a začal dodávat funkce každý týden. Poučení: nemusíte přepisovat všechno najednou. Potřebujete strategii, proxy a disciplínu migrovat postupně. Pokud vás vaše legacy aplikace brzdí, byli jsme tam — a můžeme pomoct.