Cum muți un site pe alt hosting: verificări, DNS și plan de revenire

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:

1. pregătești noul server;
2. faci o primă copie a site-ului și bazei de date;
3. testezi magazinul pe noul server;
4. planifici migrarea finală;
5. faci un ultim backup/sync al datelor;
6. schimbi DNS-ul;
7. verifici comenzile, plățile și stocurile;
8. 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.

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

1. creează contul sau domeniul pe noul server;
2. verifică versiunea PHP;
3. transferă fișierele;
4. transferă baza de date;
5. creează utilizatorii și bazele de date necesare;
6. configurează conturile de email;
7. verifică SSL-ul;
8. recreează cron jobs;
9. testează site-ul;
10. 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

1. creează domeniul pe noul server;
2. configurează versiunea PHP;
3. creează baza de date;
4. transferă fișierele;
5. importă baza de date;
6. configurează variabilele aplicației;
7. configurează SSL;
8. recreează scheduled tasks;
9. verifică emailurile;
10. testează site-ul;
11. 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, 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.

Continuă cu un pas practic

• Cele mai bune VPS-uri în 2026: comparație pe preț și performanță
• 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.