Migrare hosting WordPress fără downtime - ghid pas cu pas

Migrarea hostingului pentru un site WordPress activ este una dintre acele operațiuni care arată simplu pe slide-uri de marketing („1-click migration!") și devine coșmar la 2 dimineața când checkout-ul pică în mijlocul campaniei Black Friday. Am făcut peste 60 de migrări în ultimii cinci ani, de la blog cu 500 vizite/lună până la magazine WooCommerce cu trafic constant și sincronizare ERP live, și pot să confirm: diferența între o migrare reușită și un dezastru de 4 ore stă în pregătire, nu în execuție.

În termeni simpli: „zero downtime" nu înseamnă magic, înseamnă disciplină. DNS TTL coborât din timp, sync paralel între servere, test prin hosts file, swap controlat, verificare imediată. Trade-off-ul real nu este între metode, ci între cât timp investești în pregătire (recomandat: 4-6 ore) și cât timp pierzi în debug post-swap (fără pregătire: 2-8 ore + clienți pierduți).

Ghidul ăsta îți arată 3 strategii ranked după use case, checklist pre-flight care a salvat fundul a 40+ clienți, și pașii concreți cu cod pentru migrarea manuală - varianta care îți dă control total. Dacă nu ai decis încă unde muți, citește mai întâi comparativ Hostico vs Hosterion vs Romarg.

Cele 3 strategii de migrare - care ți se potrivește

Nu există „cea mai bună" metodă. Există metoda potrivită pentru dimensiunea, complexitatea și nivelul tău de confort tehnic. Iată cele 3 strategii pe care le folosesc în practică, ranked după frecvență de utilizare.

A. Migrare cu plugin (Duplicator, All-in-One WP Migration, Migrate Guru)

Cea mai populară și cea mai accesibilă metodă. Plugin-ul împachetează site-ul într-o arhivă (fișiere + dump SQL), o muți pe noul server, rulezi installer-ul și gata. Funcționează decent pentru site-uri sub 2 GB și fără particularități (multisite, custom tables masive, certificate SSL cu pinning).

Plugin-uri recomandate:

• Duplicator Pro (preferat al meu pentru control) - 99 $/an pentru o licență, generează arhive curate, installer.php robust, suportă export/import multi-step pentru site-uri mari.
• All-in-One WP Migration - freemium, limita la 512 MB pe versiunea gratuită, unlimited extension costă 99 $ one-time. Cel mai prietenos UI.
• Migrate Guru (BlogVault) - free, dedicat migrării (nu împachetează, transferă direct), gestionează automatic site-uri peste 1 GB. Limită: doar transfer host-to-host, nu și local.

Trade-off: rapid și prietenos, dar abstractizează lucrurile și când ceva merge prost (PHP timeout în import, memory limit, permissions wp-content) ai mai puțin control la debug. Battle-tested: funcționează în 85% din cazuri sub 2 GB.

Setup minim Duplicator:

1. Install Duplicator pe sursă, generează un nou „Package" (Full sau Database+Files).
2. Download installer.php + arhiva .zip.
3. Upload ambele în root-ul noului server prin FTP/SFTP.
4. Accesează https://destinatie.com/installer.php, completează credentiale MySQL nou, click „Run Deployment".
5. Plugin-ul face automat search-replace URL.

Pro tip dev: pentru site-uri 1-2 GB activează în Duplicator opțiunea „MySQL Mode: PHP" și mărește în panou max_execution_time la 300 secunde - altfel arhiva pică la 60 secunde standard.

B. Migrare manuală (mysqldump + rsync + WP-CLI)

Singura metodă care îți dă 100% control și care funcționează indiferent de dimensiune. Recomandată peste 2 GB, pentru WooCommerce serioase, multisite WordPress, sau când plugin-ul refuză din motive obscure.

Componente:

• mysqldump - export bază de date cu opțiunile potrivite (--single-transaction pentru InnoDB).
• rsync - copiere fișiere incrementală, doar diferențele între execuții.
• WP-CLI - command line interface oficial WordPress, obligatoriu pentru search-replace corect.
• SSH pe ambele capete (sursă + destinație).

Trade-off: necesită SSH activ și familiaritate cu linia de comandă. În schimb, migrare 5 GB durează 20-40 minute net (fără DNS) și ai vizibilitate pe fiecare pas.

Vom intra în detaliu în secțiunea „Pașii migrării manuale" mai jos. Pe scurt: dump DB pe sursă → rsync wp-content/ → import DB pe destinație → search-replace URL cu WP-CLI → test prin hosts file → swap DNS.

C. Migrare asistată de provider (SiteGround Migrator, Cloudways Auto, cPanel WHM Transfer)

Aproape toți providerii serioși din RO și internațional oferă migrare gratuită „white glove" la primul abonament. Le trimiți accesul, ei mută, tu verifici.

Variante:

• SiteGround Migrator - plugin propriu, free, doar inbound (spre SiteGround). Funcționează excelent pentru WordPress standard, mai puțin pentru WooCommerce mare.
• Cloudways Auto-Migration - plugin gratuit, in/out, integrare directă cu DigitalOcean/Vultr/AWS via Cloudways.
• cPanel WHM Transfer Tool - între două servere cPanel, transferă conturi întregi cu un click. Cel mai bun când ambele capete sunt cPanel (Hostico, THC, cyberfolks etc.).
• Hostico, THC, cyberfolks - migrare gratuită gestionată de echipa tehnică, durează 12-48 ore în coadă, dar fac ei toată munca.

Trade-off: dependent de program-ul providerului (uneori 48 ore în coadă), zero control pe timing, dar zero efort din partea ta. Battle-tested: funcționează în 95% din cazuri pentru site-uri sub 5 GB.

Tabel comparativ - 3 strategii

Recomandarea mea pentru 80% dintre cazuri: plugin (Duplicator) pentru sub 2 GB, manual peste. Provider-assisted doar dacă nu ai SSH access sau dacă timpul de wait nu te deranjează.

Pre-flight checklist - 9 puncte obligatorii

Aici este partea importantă: migrarea reușită începe cu 4-6 ore de pregătire, nu cu execuția. Treci prin lista de mai jos înainte să atingi orice plugin sau comandă SSH.

• Backup full pe sursă (fișiere + DB) descărcat local, NU doar pe server. Standard 3-2-1: original + backup local + backup cloud.
• Cont nou pe destinație activ, plătit, cu SSH/cPanel accesibil. Verifică PHP version, MariaDB/MySQL version, limite (post_max_size, upload_max_filesize, memory_limit).
• SSL pe destinație emis ÎNAINTE - generează Let's Encrypt pentru domeniu pe noul server cât timp DNS încă pointează în altă parte (se face cu HTTP-01 challenge după DNS swap sau cu DNS-01 challenge înainte; Cloudways/SiteGround fac asta automat din panou).
• Staging pe destinație funcțional cu același conținut - testează plugin-uri, theme, checkout în staging înainte de swap real.
• Test domeniu via hosts file local - adaugă în /etc/hosts (Linux/Mac) sau C:\Windows\System32\drivers\etc\hosts (Windows) linia IP_NOU domeniu.ro www.domeniu.ro, deschide browser, vezi site-ul nou cu domeniul real. Cea mai bună verificare pre-swap.
• DNS TTL coborât la 300 secunde cu MINIMUM 24 ore înainte de swap planificat. Verifică cu dig +short -t A domeniu.ro și dig +noall +answer domeniu.ro - vezi TTL-ul curent.
• Cloudflare orange cloud OFF temporar (DNS only, fără proxy) pentru perioada migrării. Cache-ul Cloudflare poate servi conținut vechi după swap.
• Mail check - dacă căsuțele de email sunt pe același cont hosting cu site-ul, mutarea hostingului NU mută automat MX records. Decizie: muți și email-ul (downtime mail) sau lași MX records pe provider vechi (necesită păstrare cont vechi 30+ zile)?
• Freeze content - anunță echipa că între ora X și Y nu se publică articole, comenzi noi, comentarii moderate. Altfel ai diff între sursă și destinație care va trebui re-sincronizat.

Tehnica zero-downtime - cum funcționează în realitate

Hai să demitizăm conceptul. „Zero downtime" pentru migrare WordPress înseamnă sub 60 secunde de interruption pentru utilizatorul final, nu literalmente zero. Iată cum se obține:

1. TTL DNS jos (300s) cu 24h înainte → propagarea schimbării va fi rapidă (5-15 minute global).
2. Sync paralel între sursă și destinație → noul server are deja TOATE datele înainte de swap.
3. Hosts file test → confirmi că destinația funcționează cu domeniul real, fără să schimbi DNS pentru lume.
4. Freeze frontend → marcheză site-ul read-only 5-10 minute (sau mai puțin) pentru a evita diff comenzi/comentarii noi.
5. Final delta sync → rsync cu doar diferențele acumulate de la sync inițial (de obicei sub 100 MB).
6. DNS swap → schimbi A record-ul (sau CNAME-ul), TTL 300s asigură propagare rapidă.
7. Verificare imediată → SSL, login, frontend, checkout, plăți, email.

Setup minim: sursă activă cu trafic real, destinație gata 99%, fereastră 30 minute pentru pașii 4-7. Downtime efectiv pe utilizator: 0-90 secunde.

Pașii migrării manuale (varianta B)

Aici este partea cu cod. Toate comenzile sunt testate pe Ubuntu 22.04 + WordPress 6.4+ + MariaDB 10.6. Adaptează la stack-ul tău.

Pasul 1 - Snapshot bază de date pe sursă

# SSH în sursă
ssh user@sursa.com

cd /home/user/public_html

# Export DB cu single-transaction pentru InnoDB (zero lock)
mysqldump -u DB_USER -p \
    --single-transaction \
    --quick \
    --routines \
    --triggers \
    --default-character-set=utf8mb4 \
    DB_NAME > /tmp/wp_dump_$(date +%Y%m%d_%H%M).sql

# Verifică dimensiune
ls -lh /tmp/wp_dump_*.sql

# Compresia reduce dimensiunea cu ~70-80%
gzip /tmp/wp_dump_*.sql

--single-transaction este KEY - face dump consistent pentru InnoDB fără să blocheze tabelele (zero impact pe trafic live). --routines și --triggers includ stored procedures dacă există.

Pasul 2 - rsync wp-content/ la destinație

# Pe sursă, rsync direct la destinație via SSH
rsync -avz --progress \
    --exclude='wp-content/cache/' \
    --exclude='wp-content/uploads/cache/' \
    --exclude='*.log' \
    /home/user/public_html/wp-content/ \
    user@destinatie.com:/home/user/public_html/wp-content/

# Pentru fișiere root WordPress (wp-admin, wp-includes etc)
# - de obicei sărim, instalăm WP curat pe destinație
# Dacă ai mods în core (nu ar trebui!), include și astea:
rsync -avz --progress \
    --exclude='wp-content/' \
    /home/user/public_html/ \
    user@destinatie.com:/home/user/public_html/

-a = archive mode (păstrează permisiuni, timestamps), -v = verbose, -z = compresie pe transfer. Exclude cache - va fi regenerat oricum.

Pasul 3 - Import DB pe destinație

# Transfer dump-ul
scp /tmp/wp_dump_*.sql.gz user@destinatie.com:/tmp/

# SSH în destinație
ssh user@destinatie.com

# Creează DB nou (sau folosește existent)
mysql -u root -p -e "CREATE DATABASE wp_new CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "GRANT ALL ON wp_new.* TO 'wp_user'@'localhost' IDENTIFIED BY 'STRONG_PASS';"
mysql -u root -p -e "FLUSH PRIVILEGES;"

# Import
gunzip < /tmp/wp_dump_*.sql.gz | mysql -u wp_user -p wp_new

# Verifică număr tabele
mysql -u wp_user -p wp_new -e "SHOW TABLES;" | wc -l

Pasul 4 - Update wp-config.php pe destinație

# Pe destinație
cd /home/user/public_html
nano wp-config.php

Modifică:

define( 'DB_NAME', 'wp_new' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'STRONG_PASS' );
define( 'DB_HOST', 'localhost' );

// Adăugă temporar pentru debug dacă e nevoie
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// SCHIMBĂ AICI URL-URILE STAGE (dacă încă nu ai făcut DNS swap):
// Necesar pentru hosts file test
define( 'WP_HOME', 'https://domeniu.ro' );
define( 'WP_SITEURL', 'https://domeniu.ro' );

Pasul 5 - WP-CLI search-replace (CRITIC)

Dacă URL-ul site-ului se schimbă (de obicei rămâne la fel - același domeniu, alt server), atunci search-replace NU este necesar. Dacă schimbi și domeniul (rar, dar se întâmplă la rebranding), DA - rulează WP-CLI search-replace.

Niciodată nu folosi SQL find/replace direct - distruge PHP serialized data (widgets, customizer settings, theme options, ACF fields). Battle-tested issue care a omorât zeci de migrări.

# Instalează WP-CLI dacă nu există
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# Verifică instalare
wp --info

# Dry-run search-replace (NU modifică, doar arată ce ar face)
cd /home/user/public_html
wp search-replace 'https://vechiu.ro' 'https://domeniu.ro' --dry-run --report-changed-only

# Dacă output-ul arată corect, rulează real
wp search-replace 'https://vechiu.ro' 'https://domeniu.ro' --report-changed-only

# Search-replace recursiv pentru serialized data (KEY!)
# WP-CLI face asta by default, dar verifică flag-ul --precise dacă ai probleme
wp search-replace 'https://vechiu.ro' 'https://domeniu.ro' --precise --recurse-objects

# Flush cache
wp cache flush
wp rewrite flush --hard

Pasul 6 - Test via hosts file local

Pe laptop-ul tău, editează hosts file:

# Mac/Linux
sudo nano /etc/hosts

# Adaugă linia (înlocuiește IP_NOU cu IP-ul real destinație)
IP_NOU  domeniu.ro www.domeniu.ro

# Salvează (Ctrl+O, Ctrl+X în nano)

# Flush DNS cache local
# Mac:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved):
sudo systemd-resolve --flush-caches

# Verifică
ping domeniu.ro  # ar trebui să răspundă IP_NOU

Deschide browser, navighează la https://domeniu.ro. Acum vezi versiunea de pe destinație cu domeniul real, fără ca lumea să o vadă. Testează:

• Frontend principal + 3-5 pagini
• Login admin
• Checkout flow (pentru magazine)
• Form submissions
• Images, fonts, CSS, JS - toate ar trebui să se încarce de pe domeniu.ro (verifică în DevTools Network tab)
• Verifică Console pentru erori JS

Dacă găsești probleme acum, debug LIVE pe destinație fără presiunea swap-ului DNS.

După test, scoate linia din hosts file pentru a reveni la vechiul server.

Pasul 7 - Final delta sync (1 oră înainte de swap)

Cu o oră înainte de DNS swap, rulează un sync final pentru a prinde modificări recente (comenzi noi, media uploads, comentarii):

# Pe sursă, sync incremental (doar diferențe)
rsync -avz --progress --delete \
    --exclude='wp-content/cache/' \
    /home/user/public_html/wp-content/ \
    user@destinatie.com:/home/user/public_html/wp-content/

# Dump DB nou + import
mysqldump -u DB_USER -p --single-transaction DB_NAME | \
    ssh user@destinatie.com "mysql -u wp_user -p'STRONG_PASS' wp_new"

--delete în rsync șterge pe destinație fișiere care nu mai există pe sursă (atenție: doar dacă ești 100% sigur că wp-content e identic structural).

Pasul 8 - DNS swap (the moment of truth)

În panoul registrar/DNS provider (Cloudflare, RoTLD, Namecheap etc.):

1. Pune site-ul în mode read-only (plugin tip „Maintenance" sau redirecționează frontend la o pagină statică „Revenim în 5 min").
2. Schimbă A record pentru domeniu.ro și www.domeniu.ro la IP_NOU.
3. Cu TTL 300s, propagarea ar trebui completă în 5-15 minute global.
4. Verifică propagare:

# De pe mai multe locații (sau folosește whatsmydns.net)
dig +short -t A domeniu.ro @8.8.8.8     # Google DNS
dig +short -t A domeniu.ro @1.1.1.1     # Cloudflare DNS
dig +short -t A domeniu.ro @208.67.222.222  # OpenDNS

# Ar trebui să returneze IP_NOU

5. După propagare confirmată (5-15 min), activează site-ul live pe destinație, scoate maintenance mode.

Pasul 9 - Verificare post-swap (15 minute critic)

Imediat după swap, treci prin checklist:

# SSL valid?
curl -vI https://domeniu.ro 2>&1 | grep -E "SSL|expire|issuer"

# HTTPS redirect din HTTP?
curl -I http://domeniu.ro
# ar trebui 301 → https://

# www → non-www (sau invers, după preferință)?
curl -I https://www.domeniu.ro

În browser:

• Login admin WordPress
• Vezi frontend principal + 5 pagini random
• Submit form contact
• Pentru magazine: comandă test cu plată (Stripe test mode dacă posibil)
• Email tranzacțional sosește?
• DevTools Console - zero erori JS roșii

Dacă găsești probleme, ai 24-48 ore să le repari fereastra DNS scurtă. După aceea, ridicarea TTL-ului înapoi la 3600/86400 face rollback-ul mai lent.

Probleme frecvente post-swap și fix-uri

Le-am întâlnit pe toate. Iată cele mai comune și fix-urile rapide.

SSL nu redirecționează după swap

Simptom: http://domeniu.ro rămâne pe HTTP, nu redirect la HTTPS.

Fix: verifică .htaccess (Apache/LiteSpeed) sau config nginx:

# .htaccess - adăugă la TOP
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# nginx server block
server {
    listen 80;
    server_name domeniu.ro www.domeniu.ro;
    return 301 https://$host$request_uri;
}

Sau prin Cloudflare (dacă reactivezi proxy): SSL/TLS → Edge Certificates → „Always Use HTTPS" → ON.

Mixed content (HTTPS site încarcă HTTP assets)

Simptom: padlock browser cu warning, imagini sau CSS nu se încarcă pe HTTPS.

Fix:

# WP-CLI rezolvă din DB
wp search-replace 'http://domeniu.ro' 'https://domeniu.ro' --precise

# Pentru hardcoded în theme/plugins
grep -r "http://domeniu.ro" wp-content/themes/active-theme/
grep -r "http://domeniu.ro" wp-content/plugins/

Plugin de backup: „Really Simple SSL" forțează HTTPS pe tot output-ul.

Sesiuni invalidate (utilizatori delogati în masă)

Simptom: după swap, toți utilizatorii logați (admin, customers) sunt scoși din cont.

Cauză normală: AUTH_KEY și SECURE_AUTH_KEY din wp-config.php au fost păstrate identice? Dacă DA, sesiunile rămân. Dacă NU (le-ai regenerat la setup destinație), sesiunile sunt invalidate.

Fix: nu este o problemă reală, doar inconvenient. Utilizatorii se relogheaza, cookie-urile noi se setează. Pentru viitor: copiază AUTH keys din wp-config.php vechi.

Cron WordPress oprește/dublează pe vechiul server

Simptom: emailuri tranzacționale duplicate, comenzi procesate de două ori.

Cauză: dacă ai cron real Linux pe vechiul server (/usr/bin/wget https://domeniu.ro/wp-cron.php), el continuă să ruleze și hit-uiește acum noul server (dacă DNS s-a propagat) sau dă error 404 dacă vechiul server nu mai are site-ul.

Fix imediat: SSH pe vechiul server, crontab -e, comentează linia cu wp-cron. Pe noul server, configurează cron real:

# crontab -e pe destinație
*/5 * * * * /usr/bin/wget -q -O - https://domeniu.ro/wp-cron.php >/dev/null 2>&1

Și dezactivează pseudo-cron WP în wp-config.php:

define('DISABLE_WP_CRON', true);

Email MX records nu funcționează după swap

Simptom: mail-uri tranzacționale nu pleacă, sau email-uri inbound nu vin.

Cauză: ai migrat doar hostingul, nu și mail-ul. MX records pointau pe vechiul provider.

Decizie:

• Vrei să muți email-ul cu site-ul: în DNS, schimbă MX records să arate la noul provider (ex: mx1.destinatie.com). Necesită setup căsuțe pe noul server ÎNAINTE. Downtime mail: minute.
• Vrei să păstrezi email pe vechiul provider: nu atinge MX records. Atenție - vechiul provider trebuie păstrat plătit cât timp folosești mail-ul.
• Alternativă curată: muți email-ul la Google Workspace sau Microsoft 365, devine independent de hosting.

Gotchas per provider

Fiecare provider are particularitățile lui. Cele mai comune:

• SiteGround Migrator - doar inbound (spre SiteGround). Pentru outbound trebuie metoda manuală sau plugin terț. NU face WooCommerce mari decent (>3 GB).
• Cloudways - one-click migration funcționează în ambele direcții, dar staging mode poate să nu copieze corect anumite plugin-uri cu custom tables. Verifică staging înainte de a face „Push to Live".
• cPanel WHM Transfer - între cPanel și cPanel (Hostico, THC, cyberfolks etc.), tool-ul gratuit transferă conturi întregi în 30-60 minute. Trebuie acces root WHM pe sursă SAU API access (cei mai mulți providers îl oferă la cerere).
• Hostico/THC/cyberfolks - migrare gestionată gratuit, dar coada este 12-48 ore. Pentru migrare urgentă, paid expedite există dar nu mereu disponibil.
• Hetzner Cloud / OVH self-managed - zero ajutor, faci tot manual. Compensate prin preț.

Linkuri utile pentru context

Înainte sau după migrare, mai citește:

• Hostico vs Hosterion vs Romarg - comparativ provideri RO
• DNS pentru începători - tipuri de record și cum funcționează
• SSL pentru site mic - ghid Let's Encrypt și Cloudflare

Întrebări frecvente

Cât durează o migrare WordPress completă?

Depinde de strategie și dimensiune. Plugin pentru site sub 2 GB: 30-90 minute net (excl. DNS propagation). Manual pentru 5 GB: 60-180 minute net. Provider-assisted: 4-48 ore (mare parte wait în coadă). Adăugă MINIMUM 4-6 ore de pregătire pre-flight + 24 ore DNS TTL reduction lead time. Total realist end-to-end: 1-3 zile calendaristice, cu downtime efectiv 0-60 secunde dacă ești atent.

Search-replace cu SQL direct - de ce nu merge?

WordPress stochează multe opțiuni ca PHP serialized data (a:3:{s:5:"width";...}). Lungimea string-urilor este hard-coded în formatul serialized. SQL REPLACE() simplu modifică conținutul dar NU recalculează lungimea, deci serialized-ul devine corupt. WordPress nu mai poate deserializa → widgets, customizer settings, ACF fields, theme options se rup. WP-CLI search-replace deserializează → înlocuiește → re-serializează cu lungime nouă corectă. Singura metodă safe.

Cum migrez WordPress multisite?

Multisite are particularități: tabelul wp_blogs, multiple wp_X_options pentru fiecare subsite, paths/domains în config. Plugin-uri ca Duplicator Pro suportă multisite explicit. Manual: dump DB include toate tabelele wp_*, în wp-config.php păstrezi define( 'MULTISITE', true ); și constantele subdomain/subdirectory. WP-CLI search-replace rulează cu flag-ul --network. Test obligatoriu pe staging înainte de DNS swap - multisite e mai fragil la migrare.

Cum verific că migrarea a fost completă (nu am uitat ceva)?

Compară output-ul comenzilor pe sursă vs destinație:

# Număr fișiere
find /home/user/public_html -type f | wc -l

# Dimensiune wp-content
du -sh /home/user/public_html/wp-content/

# Număr tabele DB
mysql -u user -p DB_NAME -e "SHOW TABLES;" | wc -l

# Număr posts
mysql -u user -p DB_NAME -e "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish';"

# Număr users
mysql -u user -p DB_NAME -e "SELECT COUNT(*) FROM wp_users;"

Cifrele trebuie să fie identice (sau foarte apropiate, cu mici diferențe de cache/log files). Pentru magazine, verifică comenzi: SELECT COUNT(*) FROM wp_posts WHERE post_type='shop_order';.

Am pierdut email-ul după migrare - ce fac?

Verifică MX records în DNS. Dacă încă pointează la vechiul provider și acolo mai sunt căsuțele, mail-ul curge. Dacă MX a fost schimbat fără setup pe noul server, ai pierdere temporară. Fix imediat: revert MX records la vechiul provider, recovery mail apoi. Pe termen lung: planifică migrare email separat de hosting, sau mutare la Google Workspace.

Pot să fac rollback dacă ceva merge prost?

DA, dacă DNS TTL e jos. Rollback = schimbi A record înapoi la IP-ul vechi. Propagare 5-15 minute cu TTL 300s. Condiție: vechiul server încă să fie up și conțină datele (de aceea NU închizi vechiul cont imediat după swap - păstrează 7-14 zile minimum). Dacă în acel interval au fost comenzi/comentarii pe noul server, le pierzi la rollback - aici e trade-off-ul.

De ce să nu folosesc DNS swap fără TTL reduction?

Pentru că propagarea cu TTL 86400 (24h, valoarea default la mulți registrars) înseamnă că schimbarea A record-ului ajunge la tot internetul în 24 ore - între timp, jumătate din traffic merge pe vechiul server (probabil offline sau în mod maintenance), cealaltă jumătate pe noul server. Inconsistență totală: comenzi pe vechi, traffic pe nou, customer support haos. Cu TTL 300s, propagarea durează 5-15 minute global.

Cum aleg între Duplicator, AIO și Migrate Guru?

Duplicator Pro - cel mai control, best pentru WooCommerce și site-uri 500MB-2GB. All-in-One WP Migration - cel mai prietenos UI, best pentru bloguri și site-uri simple sub 512 MB (free) sau orice cu unlimited extension. Migrate Guru - cel mai bun pentru migrare host-to-host fără descărcare locală (gen schimbi de la Hostico la SiteGround), gestionează automat site-uri 1-5 GB. Pentru ceva peste 5 GB sau cu particularități (multisite, custom tables masive), abandonezi plugin-urile și treci la manual.

Concluzie

Migrare hosting WordPress fără downtime nu este o operațiune magică, este o operațiune disciplinată. 80% din succes vine din pregătire (DNS TTL, staging, hosts file test, freeze content), 20% din execuția propriu-zisă. Pluginurile gen Duplicator rezolvă majoritatea cazurilor sub 2 GB; manualul cu mysqldump + rsync + WP-CLI rămâne ground truth pentru site-uri mari sau complicate; provider-assisted este opțiunea zero-effort când timpul de wait nu te deranjează.

Trade-off real: investește 4-6 ore în pre-flight checklist și economisești 2-8 ore de debug post-swap. Eu pun freeze pe content cu 1 oră înainte, fac final delta sync, swap DNS și verific imediat. Downtime efectiv user-side: 30-60 secunde. Asta este „zero downtime" în lumea reală.

Sfat final pentru cei la prima migrare: testează cu un site de test (creează unul rapid pentru exercițiu) înainte să faci migrare pe producție. Diferența între citit ghidul și a face manual mâinile pe SSH este enormă. Battle-tested: prima migrare faci 4 greșeli, a doua 2, a treia 1, a patra nici una.

Surse

• https://wp-cli.org/
• https://developer.wordpress.org/cli/commands/search-replace/
• https://wordpress.org/documentation/article/moving-wordpress/
• https://duplicator.com/knowledge-base/
• https://servmask.com/products/unlimited-extension (AIO WP Migration)
• https://blogvault.net/migrate-guru/
• https://www.cloudways.com/blog/migrate-wordpress/
• https://www.siteground.com/kb/migrator-plugin/