# Cum muți un site pe alt hosting: verificări, DNS și plan de revenire > Inventariază fișiere, bază, cron, email, DNS și integrări. Testează serverul nou înainte de schimbarea publică. Pentru aplicații cu scrieri, stabilește o perioadă controlată sau o strategie de sincronizare; o simplă copie nu. - **Autor:** GabrielDev - **Publicat:** 2026-09-02 - **Actualizat:** 2026-10-12 - **Categorie:** Hosting & VPS - **URL:** https://inonline.ro/hosting-vps/cum-muti-un-site-pe-alt-hosting-fara-downtime --- Mutarea unui site pe alt hosting pare simplă până când apar problemele: fișiere lipsă, baza de date importată greșit, SSL care nu mai funcționează, emailuri care nu mai ajung sau DNS care încă trimite vizitatorii către serverul vechi. Partea bună este că o migrare poate fi făcută cu **foarte puțin sau chiar fără downtime vizibil** dacă pregătești noul server înainte să modifici DNS-ul. În acest ghid îți arătăm cum faci migrarea în funcție de platforma folosită: WordPress, WooCommerce, Laravel, cPanel, Plesk sau VPS/SSH. ## Regula de bază pentru o migrare fără downtime Nu începe prin schimbarea DNS-ului. Mai întâi trebuie să ai **noul server funcțional în paralel cu cel vechi**. Muți fișierele și baza de date, configurezi aplicația, verifici SSL-ul și testezi site-ul. Abia după aceea modifici DNS-ul. ``` SERVER VECHI │ ├── backup │ ▼ SERVER NOU │ ├── fișiere ├── bază de date ├── configurație ├── SSL └── servicii │ ▼ TESTARE │ ▼ SCHIMBARE DNS │ ▼ MONITORIZARE │ ▼ OPRIRE SERVER VECHI ``` Această abordare este importantă mai ales pentru magazine online și aplicații care primesc date în timp real. ## Ce trebuie să ai pregătit înainte de migrare Indiferent de platformă, există câteva lucruri pe care trebuie să le verifici înainte să începi: - backup complet al fișierelor; - backup al bazei de date; - versiunea PHP; - versiunea MySQL/MariaDB; - extensiile PHP necesare; - configurația DNS; - SSL; - emailurile; - cron jobs; - serviciile externe folosite de aplicație. Nu este obligatoriu ca toate acestea să fie mutate. De exemplu, dacă emailul este administrat printr-un serviciu extern, nu trebuie să muți conturile de email doar pentru că schimbi hostingul. ## WordPress: cum muți site-ul pe alt hosting Pentru un site WordPress clasic, migrarea presupune în principal transferul fișierelor, importul bazei de date și configurarea noului server. ### Pasul 1: fă backup Salvează întregul site și exportă baza de date. Dacă folosești un plugin de backup, verifică să includă atât fișierele, cât și baza de date. ### Pasul 2: pregătește noul hosting Creează domeniul pe noul hosting și setează o versiune PHP compatibilă cu WordPress, tema și pluginurile instalate. ### Pasul 3: transferă fișierele Copiază întregul site, inclusiv `wp-content`, `wp-config.php` și fișierele ascunse relevante. ### Pasul 4: importă baza de date Creează baza de date și utilizatorul pe noul server, apoi importă backupul SQL. ### Pasul 5: verifică `wp-config.php` Actualizează datele de conectare la baza de date dacă acestea diferă pe noul server: ``` DB_NAME DB_USER DB_PASSWORD DB_HOST ``` ### Pasul 6: testează site-ul Înainte de DNS, verifică homepage-ul, wp-admin, paginile interne, imaginile, formularele, pluginurile, tema și permalinks. Dacă site-ul funcționează corect, poți trece la schimbarea DNS-ului. ## WooCommerce: atenție la comenzile noi Un magazin WooCommerce necesită mai multă atenție decât un site WordPress obișnuit deoarece baza de date se modifică permanent. În timpul migrării pot apărea comenzi, clienți, plăți, recenzii sau modificări de stoc. Procesul recomandat este: - pregătești noul server; - faci o primă copie a site-ului și bazei de date; - testezi magazinul pe noul server; - planifici migrarea finală; - faci un ultim backup/sync al datelor; - schimbi DNS-ul; - verifici comenzile, plățile și stocurile; - păstrezi serverul vechi activ până confirmi că totul funcționează. Pentru magazine cu volum mare de comenzi poate fi necesară o strategie de sincronizare sau replicare a bazei de date. ## Laravel: cum muți o aplicație pe alt server O aplicație Laravel presupune mai mult decât copierea fișierelor și bazei de date. Trebuie recreat și mediul în care aplicația rulează. Dacă nu ești familiar cu .env, migrațiile și queue-urile, vezi întâi [structura unei aplicații Laravel](https://inonline.ro/web-programare/laravel-pentru-incepatori-de-la-zero-la-primul-proiect-live). ### Pasul 1: transferă proiectul Poți folosi Git, SFTP, SSH sau rsync. Dacă proiectul este într-un repository, o variantă practică este să faci deploy pe noul server direct din Git și să instalezi dependențele acolo. ### Pasul 2: configurează PHP Folosește versiunea PHP compatibilă cu proiectul și instalează toate extensiile necesare. ### Pasul 3: instalează dependențele ``` composer install --no-dev --optimize-autoloader ``` Comanda exactă poate varia în funcție de procesul de deployment al proiectului. ### Pasul 4: configurează `.env` Verifică în special: ``` APP_ENV APP_URL DB_HOST DB_PORT DB_DATABASE DB_USERNAME DB_PASSWORD ``` Nu uita variabilele pentru SMTP, Redis, API-uri, storage, queue-uri sau alte servicii externe. ### Pasul 5: setează document root Pentru Laravel, document root-ul trebuie configurat în mod normal către directorul `public`, nu către rădăcina proiectului. ### Pasul 6: migrează baza de date Importă baza de date existentă sau folosește strategia de deployment a proiectului dacă acesta reconstruiește schema prin migration-uri. ### Pasul 7: verifică storage-ul Dacă aplicația folosește uploaduri, verifică directoarele de storage, permisiunile și linkurile simbolice. ### Pasul 8: configurează Scheduler și queue workers Dacă aplicația folosește Laravel Scheduler, cron-ul trebuie configurat pe noul server. ``` * * * * * cd /path/to/project && php artisan schedule:run >> /dev/null 2>&1 ``` Dacă există queue workers, configurează și Supervisor, systemd sau mecanismul utilizat de proiect. ### Pasul 9: testează aplicația Verifică login-ul, formularele, API-urile, uploadurile, emailurile, joburile, dashboard-ul și toate funcțiile care generează sau modifică date. ## cPanel: migrarea între două hostinguri Dacă ambele servere folosesc cPanel, procesul poate fi semnificativ mai simplu. ### Pașii practici - creează contul sau domeniul pe noul server; - verifică versiunea PHP; - transferă fișierele; - transferă baza de date; - creează utilizatorii și bazele de date necesare; - configurează conturile de email; - verifică SSL-ul; - recreează cron jobs; - testează site-ul; - schimbă DNS-ul. Dacă noul furnizor oferă migrare gratuită de conturi cPanel, merită să folosești serviciul respectiv. Transferul unui cont complet poate fi mai sigur decât mutarea manuală a componentelor. ### Ce verifici după transfer - document root; - PHP și extensiile; - baze de date; - utilizatori MySQL; - cron jobs; - email accounts; - forwardere; - subdomenii; - SSL; - redirecturi. ## Plesk: cum muți un site Plesk simplifică administrarea site-ului, dar trebuie să verifici configurația aplicației și a serverului înainte de schimbarea DNS-ului. ### Pașii practici - creează domeniul pe noul server; - configurează versiunea PHP; - creează baza de date; - transferă fișierele; - importă baza de date; - configurează variabilele aplicației; - configurează SSL; - recreează scheduled tasks; - verifică emailurile; - testează site-ul; - schimbă DNS-ul. Verifică în special document root-ul și configurația PHP. O aplicație poate funcționa perfect pe serverul vechi și să dea erori pe noul server dacă versiunea PHP sau extensiile diferă. ## VPS / SSH: migrare manuală Dacă ai acces SSH la ambele servere, poți controla mult mai precis procesul. ### Pasul 1: transferă fișierele Pentru directoare mari, rsync este o soluție eficientă deoarece poate transfera doar diferențele dintre două versiuni. ``` rsync -avz /path/to/site/ user@new-server:/path/to/site/ ``` ### Pasul 2: exportă baza de date ``` mysqldump -u USER -p DATABASE > backup.sql ``` ### Pasul 3: transferă backupul ``` scp backup.sql user@new-server:/path/to/backup.sql ``` ### Pasul 4: importă baza de date ``` mysql -u USER -p DATABASE < backup.sql ``` ### Pasul 5: configurează serverul web Verifică Nginx sau Apache, document root-ul, PHP-FPM, redirecturile și regulile necesare aplicației. ### Pasul 6: configurează serviciile Nu uita de: - cron; - Supervisor; - Redis; - queue workers; - firewall; - backupuri; - monitorizare; - log rotation; - SMTP. ## Cum testezi noul server înainte de DNS Aceasta este partea care face diferența dintre o migrare controlată și una riscantă. Site-ul trebuie testat pe noul server **înainte ca domeniul să fie direcționat acolo**. Poți folosi: - un URL temporar oferit de hosting; - un subdomeniu de test; - o configurare locală a fișierului hosts; - un mediu staging. Verifică homepage-ul, paginile interne, formularele, login-ul, imaginile, CSS-ul, JavaScript-ul, checkout-ul, emailurile și orice funcție critică. ## Schimbarea DNS După ce noul server este verificat, poți schimba DNS-ul. Înainte de modificare, notează [înregistrările DNS și registrarul domeniului](https://inonline.ro/tools/verificare-domeniu), ca să poți reveni rapid dacă ceva nu merge. În funcție de configurație, poate fi necesar să modifici: - A; - AAAA; - CNAME; - nameserverele. **Nu schimba automat nameserverele.** Dacă DNS-ul este administrat separat, este posibil să fie suficient să modifici doar înregistrarea care indică spre noul server. Dacă ai control asupra TTL-ului, îl poți reduce înainte de migrare pentru a limita perioada în care unele resolvere păstrează vechea adresă în cache. Totuși, TTL-ul nu garantează propagarea instantanee pentru toți utilizatorii. ## Ce faci imediat după schimbarea DNS Nu închide încă serverul vechi. Monitorizează: - erorile HTTP; - logurile serverului; - traficul; - formularele; - comenzile; - emailurile; - performanța; - uptime-ul. Verifică și site-ul din mai multe rețele și dispozitive pentru a observa eventualele probleme de propagare DNS. ## Emailurile trebuie verificate separat Schimbarea hostingului nu înseamnă automat că trebuie să muți și emailul. Înainte de migrare identifică cine gestionează emailul și verifică: - MX; - SPF; - DKIM; - DMARC; - SMTP; - conturile de email; - forwarderele. Dacă emailul este găzduit separat, păstrează configurația existentă și evită modificări DNS inutile. ## Ce se întâmplă cu magazinele și aplicațiile active? Un site de prezentare este relativ simplu de mutat deoarece datele se modifică rar. Un magazin online sau o aplicație SaaS este diferit. În timpul migrării pot apărea comenzi, utilizatori, plăți, mesaje sau alte date noi. Dacă faci un backup cu câteva ore înainte de schimbarea DNS, acele date nu apar automat în copia respectivă. Pentru proiectele importante poate fi necesară: - sincronizarea incrementală; - replicarea bazei de date; - o fereastră scurtă de mentenanță; - blocarea temporară a anumitor operațiuni; - un proces de deployment special adaptat aplicației. ## Checklist final - ☐ Backup verificat - ☐ Fișiere transferate - ☐ Baza de date transferată - ☐ PHP și extensiile verificate - ☐ Configurația aplicației verificată - ☐ SSL funcțional - ☐ Email verificat - ☐ Cron jobs configurate - ☐ Queue workers configurate, dacă există - ☐ Site testat pe noul server - ☐ DNS documentat - ☐ DNS schimbat - ☐ Site verificat după propagare - ☐ Monitorizare activă - ☐ Serverul vechi păstrat temporar ## Greșeli frecvente ### Închizi serverul vechi imediat Dacă apare o problemă, pierzi cea mai simplă variantă de revenire. ### Schimbi DNS-ul înainte de testare În loc să testezi noul server în liniște, transformi problema într-o eroare vizibilă pentru utilizatori. ### Uiți baza de date Copierea fișierelor nu este suficientă pentru majoritatea aplicațiilor dinamice. ### Uiți cron-ul Aplicația poate părea funcțională, dar procesele automate nu mai rulează. ### Uiți queue workers În Laravel, emailurile, notificările sau alte joburi pot rămâne blocate dacă worker-ele nu sunt pornite pe noul server. ### Uiți emailurile Site-ul poate funcționa perfect în timp ce emailurile companiei nu mai ajung la destinație. ### Ignori diferențele dintre versiunile PHP O aplicație care funcționa pe serverul vechi poate avea erori dacă noua versiune PHP nu este compatibilă. ## Concluzie Mutarea unui site pe alt hosting nu trebuie să însemne automat ore de downtime. Cel mai sigur proces este să **pregătești noul server în paralel cu cel vechi, să muți datele, să testezi totul și abia apoi să schimbi DNS-ul**. Pentru WordPress, migrarea este relativ simplă. WooCommerce necesită atenție suplimentară la comenzile și datele care se modifică în timp real. Laravel implică și configurarea mediului de execuție, Composer, document root, cron, queue workers și serviciile externe. cPanel și Plesk pot simplifica procesul, iar VPS-ul oferă cel mai mult control, dar și cea mai mare responsabilitate asupra configurării serverului. **Regula de aur: nu opri serverul vechi până când nu ești sigur că noul server funcționează corect.** ## Întrebări frecvente ### Pot muta un site fără downtime? Da. Pentru multe site-uri, downtime-ul poate fi redus foarte mult dacă noul server este pregătit și testat înainte de schimbarea DNS-ului. ### Cât timp trebuie să păstrez hostingul vechi? Nu îl închide imediat. Păstrează-l până când ai confirmat că noul server funcționează corect și că nu există probleme cu traficul, emailurile, formularele sau datele. ### Se pierd datele când schimb hostingul? Nu ar trebui să se piardă dacă fișierele și baza de date sunt transferate corect. Pentru aplicațiile active trebuie însă gestionate datele generate în timpul migrării. ### Trebuie să schimb nameserverele? Nu neapărat. Dacă DNS-ul este administrat separat, poate fi suficient să modifici înregistrarea A, AAAA sau CNAME care indică spre serverul nou. ### Ce se întâmplă cu SSL-ul? SSL-ul trebuie să fie disponibil și pe noua infrastructură sau la nivelul serviciului care termină conexiunea HTTPS. Verifică HTTPS înainte de schimbarea DNS-ului. ### Pot muta un magazin online fără să opresc comenzile? Este posibil să reduci foarte mult întreruperea, însă magazinele active necesită o strategie pentru datele care se modifică în timpul migrării. Pentru proiectele mari poate fi necesară sincronizarea bazei de date sau o fereastră scurtă de mentenanță. ### Care este diferența dintre migrarea WordPress și Laravel? WordPress presupune în principal mutarea fișierelor și bazei de date. Laravel necesită de obicei și configurarea mediului PHP, Composer, `.env`, document root, cron, queue workers și eventual Redis sau alte servicii. ### Pot muta un site între două conturi cPanel? Da. Dacă ambele servere folosesc cPanel, instrumentele de transfer ale panelului sau serviciul de migrare al noului furnizor pot simplifica procesul. ### Pot muta un site de pe cPanel pe VPS? Da, dar procesul este mai complex deoarece pe VPS trebuie configurate componente precum serverul web, PHP, baza de date, SSL, firewall-ul, backupurile și serviciile aplicației. ## Checklist pentru schimbarea controlată a serverului Inventariază fișiere, bază, cron, email, DNS și integrări. Testează serverul nou înainte de schimbarea publică. Pentru aplicații cu scrieri, stabilește o perioadă controlată sau o strategie de sincronizare; o simplă copie nu garantează lipsa pierderilor. Redu TTL din timp dacă este potrivit și păstrează serverul vechi cât cere planul de revenire. Verifică TLS, formulare, plăți și cozi după comutare. Propagarea DNS și sesiunile pot produce perioade mixte; nu promite zero downtime pentru orice arhitectură. ## Continuă cu un pas practic - [Cele mai bune VPS-uri în 2026: comparație pe preț și performanță](/hosting-vps/cele-mai-bune-vps-uri-in-2026-comparatie-pret-performanta) - [Shared hosting vs. VPS vs. cloud: ce ai nevoie de fapt](/hosting-vps/shared-hosting-vs-vps-vs-cloud-ce-ai-nevoie-de-fapt) Pentru lucru ghidat: [Deploy pentru aplicații web — lecții de probă și fișă de proiect](/academy/deploy-pentru-aplicatii-web).