Migrace webhostingu bez výpadku: kompletní checklist

Stěhování webu je jedna z mála operací, kde se chyba pozná okamžitě — návštěvník uvidí prázdnou stránku nebo přestane chodit pošta. Výpadek přitom není nevyhnutelný. V drtivé většině případů vzniká tím, že se přepne DNS dřív, než je nový server opravdu připravený, nebo tím, že se na e-maily myslí až jako na poslední položku.

Ukážu ti postup, který u migrací používám. Stojí na jednom principu: starý hosting nevypínáš, dokud nový bezchybně nejede. Chvíli platíš oba, zato nemáš z čeho mít strach.

Inventář: sepiš si, co vlastně stěhuješ

Web není jen složka se soubory. Než sáhneš na cokoliv dalšího, projdi administraci starého hostingu a zapiš si, co tam reálně běží:

• domény a subdomény (včetně těch, na které si už nikdo nevzpomene — test., stary., mail.)
• verze PHP a zapnutá rozšíření (imagick, intl, soap, zip)
• databáze — verze MySQL/MariaDB, kódování a collation
• e-mailové schránky, aliasy a přesměrování včetně jejich velikosti
• cron úlohy a jejich časování
• DNS záznamy: A, AAAA, CNAME, MX, TXT (SPF), DKIM selektor, DMARC, případně SRV
• SSL certifikáty — kdo je vydává a kdy expirují
• přesměrování a pravidla v .htaccess nebo v konfiguraci webserveru
• externí služby, které mají povolenou IP starého serveru (platební brána, API dodavatele, SMTP relay)

Dvě věci, na které se zapomíná nejčastěji: cron úlohy a DKIM klíč. Cron nikomu nechybí do chvíle, kdy přestanou chodit objednávky do skladu. DKIM klíč zůstane na starém serveru a nová pošta se začne označovat jako neověřená.

Záloha, kterou umíš obnovit

Záloha, kterou jsi nikdy nezkusil obnovit, je jen soubor. Udělej si kompletní kopii souborů (přes SSH nejlépe tar, jinak FTP) a dump databáze:

mysqldump --single-transaction --default-character-set=utf8mb4 -u uzivatel -p databaze > zaloha.sql

Dump si otevři a zkontroluj, že končí řádkem -- Dump completed — useknutý export kvůli timeoutu je klasika, kterou zjistíš až při importu. Jak k zálohám přistupují čeští poskytovatelé, jsem rozebíral v článku Jak zálohují české hostingy?; vlastní záloha při migraci ale není volitelná, ať máš hosting jakýkoliv.

TTL: krok, který rozhoduje o délce výpadku

TTL (Time To Live) je údaj u každého DNS záznamu, který říká, jak dlouho si ho smí resolvery držet v cache. Když má tvůj A záznam TTL 24 hodin a ty ho změníš, část světa bude ještě celý den chodit na starý server.

Proto se TTL snižuje předem: minimálně 24–48 hodin před plánovaným cutoverem nastav u A, AAAA a MX záznamů TTL na 300 sekund. Musí uplynout původní (dlouhá) hodnota, aby se ta krátká stihla rozšířit. V den přepnutí pak celá změna proběhne během několika minut. Po migraci TTL zase vrať na 3600 a víc — krátké TTL znamená víc dotazů a o kousek pomalejší DNS.

Pokud máš u domény zapnutý DNSSEC a zároveň měníš i DNS servery (ne jen hosting), řeš to jako samostatný krok. Špatně zvládnutá výměna DS záznamu neznamená pomalý web — znamená, že doména přestane úplně existovat, včetně pošty.

Přenos souborů a databáze

Soubory přenes přímo mezi servery, ne přes svůj notebook. Když máš na obou stranách SSH, rsync je nejrychlejší a umí i dosynchronizovat změny:

rsync -avz --progress /var/www/web/ uzivatel@novy-server:/var/www/web/

Databázi naimportuj a hlavně zkontroluj kódování — nesoulad mezi utf8 a utf8mb4 se projeví rozsypanou diakritikou. Pak uprav přístupové údaje v konfiguraci aplikace (wp-config.php, .env, configuration.php).

Co dělat nemusíš: search-replace domény v databázi. Když stěhuješ jen hosting a doména zůstává stejná, URL se nemění a přepisovat siteurl znamená zbytečně si zadělávat na problém.

Test na novém serveru dřív, než sáhneš na DNS

Tohle je krok, který odděluje klidnou migraci od té s výpadkem. Nový web si otestuješ na jeho reálné doméně, ale jen ze svého počítače — přes soubor hosts. Na macOS a Linuxu je v /etc/hosts, na Windows v C:\Windows\System32\drivers\etc\hosts:

203.0.113.10   example.cz www.example.cz

Od té chvíle tvůj prohlížeč chodí na nový server, zatímco celý zbytek světa jede pořád na starém. Projdi si:

1. Homepage a nejnavštěvovanější podstránky — načtou se obrázky, CSS, fonty?
2. Přihlášení do administrace a uložení testovacího záznamu (funguje zápis do DB?)
3. Formuláře a odchozí e-maily — přijde zpráva z kontaktního formuláře?
4. Objednávkový proces a platební brána, pokud jde o e-shop
5. Přesměrování a chybové stránky — 301 z www verze, vlastní 404
6. Error log na novém serveru — po projití webu by měl být prázdný

Zvlášť zkontroluj verzi PHP na novém serveru. Skok z PHP 7.4 na 8.4 při migraci odhalí chyby, o kterých jsi netušil — a odhalí je ve chvíli, kdy to nechceš řešit.

Cutover: hodina, kdy běží obě instalace

Vlastní přepnutí je pak už jen změna A a AAAA záznamu na novou IP. Během několika minut (díky sníženému TTL) přejdou návštěvníci na nový server.

Pozor na jednu věc: v přechodovém okně jsou obě instalace živé. U prezentačního webu je to jedno. U e-shopu nebo jakékoliv aplikace, která zapisuje do databáze, znamená rozdělený provoz, že část objednávek spadne do staré databáze a už ji nikdy nedostaneš do té nové. Buď proto naplánuj cutover na nejslabší hodinu provozu, nebo starý web na těch pár minut přepni do režimu údržby. Krátké plánované okno je vždycky lepší než tichá ztráta dat.

SSL certifikát: vystav ho ještě před přepnutím

Certifikát na novém serveru chceš mít připravený dřív, než tam doména začne mířit — jinak návštěvníkům na chvíli vyskočí varování o nedůvěryhodném spojení.

Záleží na tom, jakým způsobem se ověřuje vlastnictví domény. HTTP-01 funguje tak, že certifikační autorita stáhne soubor z http://tvojedomena/.well-known/acme-challenge/<token> — tedy až ve chvíli, kdy doména míří na nový server. DNS-01 ověřuje TXT záznam _acme-challenge.tvojedomena, takže certifikát vystavíš předem a jako bonus umí i wildcard certifikáty; HTTP-01 wildcard nezvládne (zdroj: Let's Encrypt — Challenge Types).

Ještě jedno omezení: Let's Encrypt vydá maximálně 5 certifikátů pro stejnou sadu domén za 7 dní (zdroj: Let's Encrypt — Rate Limits). Když si migraci zkoušíš nanečisto, použij jejich staging prostředí s vyššími limity.

E-maily: nejrizikovější část celé migrace

Web se dá v nejhorším případě na hodinu vypnout a nikdo neumře. Nedoručený e-mail je ale pryč nebo se vrátí odesílateli — a to už zákazník pozná.

Postup, který se osvědčil:

1. Založ na novém hostingu všechny schránky a aliasy ještě před přepnutím MX.
2. Udělej první synchronizaci obsahu ze starých schránek (typicky přes IMAP, nástrojem jako imapsync), zatímco pošta ještě chodí na starý server.
3. Přepni MX záznam — díky sníženému TTL to jsou minuty.
4. Po přepnutí spusť druhou, rozdílovou synchronizaci. Doplní zprávy, které přišly na starý server v mezičase.
5. Aktualizuj SPF, DKIM a DMARC na nový server. Nový server posílá z jiné IP; pokud ji SPF nepovolí a DKIM klíč zůstane starý, poletí ti pošta do spamu.
6. Starý mailhosting nech běžet ještě 14–30 dní. Opozdilci s dlouhou cache si tam poštu pořád najdou a ty ji můžeš dosynchronizovat.

Pokud řešíš poštu na vlastní doméně jako samostatnou službu, parametry schránek si porovnej v kategorii e-mail hosting.

Kompletní checklist migrace

Co zkontrolovat 24 hodin po migraci

Den po přepnutí si udělej krátkou obhlídku. Zajímá tě error log (nové chyby po přesunu bývají o právech k souborům nebo o chybějícím PHP rozšíření), rychlost odezvy serveru — TTFB by se měl vejít do 0,8 sekundy, což je hranice, kterou web.dev označuje jako dobrou (web.dev — TTFB) — a doručitelnost pošty: pošli testovací zprávu na Gmail a v hlavičkách si ověř, že SPF i DKIM prošly.

Zkontroluj taky, že na novém hostingu opravdu běží zálohování. A pokud narazíš na chyby 508 nebo na limit počtu souborů, přečti si, co se za slovem „neomezený" reálně skrývá — limity se u nového poskytovatele počítají jinak.

FAQ

Jak dlouho trvá migrace webu?

Vlastní přepnutí DNS je otázka minut, pokud jsi předem snížil TTL. Celá příprava — inventář, záloha, přenos dat a testování — zabere u běžného webu půl dne až den. U e-shopu s velkou databází a desítkami schránek počítej s několika dny.

Můžu web přestěhovat úplně bez výpadku?

U prezentačního webu ano, tam paralelní běh obou serverů nic nerozbije. U aplikace, která zapisuje do databáze, je poctivější naplánovat si pár minut údržby, než riskovat, že se data rozdělí mezi dva servery.

Co je propagace DNS a proč se říká „až 48 hodin"?

Žádná centrální propagace neexistuje. Jde jen o to, že jednotlivé resolvery drží starou hodnotu, dokud jí neuplyne TTL. Číslo 48 hodin pochází z dob, kdy bylo běžné TTL 86 400 sekund. S TTL 300 sekund je „propagace" hotová za pár minut.

Kdy můžu zrušit starý hosting?

Nejdřív po 14 dnech, u pošty spíš po 30. Do té doby na starý server můžou dorazit opožděné e-maily a ty ho zároveň potřebuješ jako poslední zálohu, kdyby se na novém něco ukázalo.

Musím migrovat i e-maily, když stěhuju jen web?

Nemusíš — MX záznam může mířit jinam než A záznam. Oddělený mailhosting je dokonce rozumná strategie: problém na webu pak neshodí firemní poštu.

Udělá mi migraci hosting sám?

Řada českých poskytovatelů nabízí migraci zdarma a u standardního WordPressu obvykle proběhne hladce. I tak si udrž vlastní zálohu a projdi testovací checklist — odpovědnost za funkční web po přesunu zůstává na tobě.

Závěr

Migrace bez výpadku stojí na třech věcech: snížit TTL s předstihem, otestovat nový server přes soubor hosts ještě před přepnutím a e-maily řešit jako samostatnou operaci s dvojí synchronizací. Zbytek je rutina. Nejdražší chyby při stěhování nevznikají z technické složitosti, ale ze špatného pořadí kroků — a z toho, že se starý hosting zruší příliš brzy.

Pokud teprve vybíráš, kam web přestěhovat, projdi si parametry poskytovatelů v kategorii webhosting — a u WordPressu se dívej i na to, jestli má hosting staging a automatickou migraci, protože ty ti z tohoto checklistu ušetří pár hodin.