Cum îți muți site-ul pe alt hosting fără downtime și fără să-ți cadă emailul de firmă

Ai decis să schimbi furnizorul de hosting: e prea scump, prea lent sau pur și simplu nu mai răspunde nimeni la suport. Frica ta reală nu e site-ul în sine, ci ziua în care faci mutarea și, brusc, clienții nu mai găsesc site-ul, iar emailurile pe adresa de firmă încep să dispară. E o teamă justificată, pentru că majoritatea migrărilor prost făcute exact aici se prăbușesc.

Vestea bună: o migrare fără downtime nu ține de noroc, ci de ordine. Dacă respecți secvența corectă — întâi construiești totul pe noul server, verifici, abia apoi muți DNS-ul — vizitatorii nu simt nimic, iar emailul continuă să curgă. În articolul ăsta îți arăt exact pașii, capcanele reale (mai ales pe partea de email) și ce să ceri de la orice furnizor serios înainte să apeși pe buton.

Prima regulă: site și email sunt două lucruri diferite

Cea mai frecventă greșeală e să crezi că "mut site-ul" înseamnă și mutarea automată a emailului. Nu e așa. Domeniul tău (ex. firma.ro) are înregistrări DNS separate: una spune unde stă site-ul, alta spune unde stau emailurile.

• Înregistrarea A / CNAME → arată spre serverul de site
• Înregistrarea MX → arată spre serverul de email
• Înregistrările SPF, DKIM, DMARC → autentifică emailul, ca să nu ajungă la spam

Dacă muți hostingul și lași emailul unde era, trebuie doar să NU atingi înregistrările MX și de autentificare. Problema apare când furnizorul nou "resetează" tot DNS-ul la valorile lui implicite și, fără să vrei, îți rescrie și MX-ul. Din secunda aia, emailul de firmă începe să pice. Deci: identifică întâi ce ține de site și ce ține de email, separat.

Ordinea corectă a pașilor (aici se câștigă lupta)

Downtime-ul apare aproape mereu când muți DNS-ul înainte să fie gata noul server. Secvența corectă e invers:

1. Construiește / copiază site-ul complet pe noul hosting, dar accesează-l pe o adresă temporară sau prin fișierul hosts local.

2. Testează tot: pagini, formulare, coș, viteză, certificat SSL.

3. Notează-ți TOATE înregistrările DNS actuale (fă un screenshot / export). E plasa ta de siguranță.

4. Scade TTL-ul la înregistrări cu o zi înainte (ex. la 300 secunde), ca schimbarea să se propage rapid.

5. Abia acum schimbă înregistrarea A către noul IP. NU atinge MX-ul.

6. Ține vechiul server activ încă câteva zile, până se propagă complet DNS-ul (poate dura până la 24-48h).

Așa, în orice moment, cine intră pe site vede fie varianta veche, fie cea nouă — niciodată o pagină moartă.

Cum ții emailul în viață în timpul mutării

Emailul e partea sensibilă, pentru că un mail pierdut nu se mai recuperează. Reguli clare:

• Dacă NU schimbi și furnizorul de email, nu atinge deloc înregistrările MX, SPF, DKIM și DMARC. Lasă-le exact cum sunt.
• Dacă schimbi și emailul (ex. treci pe Google Workspace sau Zoho), creează întâi căsuțele noi, migrează mesajele vechi prin IMAP, și abia apoi schimbă MX-ul.
• Ai grijă la propagare: cât timp DNS-ul se propagă, unele mailuri pot ajunge pe serverul vechi, altele pe cel nou. De asta ții ambele active câteva zile.
• După mutare, trimite un email de test din exterior (de pe alt cont) și verifică că ajunge și că nu cade în spam. Verifică SPF și DKIM cu un tool de deliverability.

Regula de aur: nu anula abonamentul vechi de email în ziua mutării. Așteaptă să confirmi că totul curge pe noul server.

Capcanele care produc downtime chiar și când faci totul "corect"

Câteva lucruri care prind oamenii pe picior greșit:

• Certificatul SSL: dacă noul server nu are certificat valid înainte de mutare, vizitatorii primesc avertisment "site nesigur". Emite-l și verifică-l ÎNAINTE de schimbarea DNS.
• Nameserverele vs. înregistrările individuale: dacă schimbi nameserverele complet, se resetează TOT DNS-ul dintr-o dată, inclusiv MX-ul. E mai sigur să modifici doar înregistrarea A, punctual.
• Baza de date și fișierele: pe site-uri dinamice (WordPress, magazine), dacă cineva plasează o comandă pe serverul vechi după ce ai migrat baza, comanda aia se pierde. De aceea muți la ore cu trafic mic și, ideal, pui site-ul vechi pe "read-only" în fereastra de tranziție.
• Redirect-urile și linkurile hardcodate: verifică să nu fi rămas adrese vechi (http, IP fix) în cod sau în setări.

Cum lucrăm noi mutările la MPO Web Studio

La MPO Web Studio facem migrări remote, pentru clienți din toată țara, fără să fie nevoie să vină cineva la fața locului. Abordarea noastră e simplă și fără stres pentru tine:

• Construim întâi copia completă pe noul hosting și ți-o arătăm pe o adresă de test — vezi cu ochii tăi că totul merge înainte să atingem ceva la domeniu.
• Mapăm tot DNS-ul actual și separăm clar site-ul de email, ca adresa ta de firmă să nu clipească măcar.
• Facem schimbarea la ore cu trafic mic și monitorizăm propagarea până se stabilizează.
• Preț transparent, spus din start, fără costuri-surpriză după ce a început treaba.

Dacă ai un site și un email de firmă pe care ți-e frică să le atingi, scrie-ne pe WhatsApp, ne uităm împreună la situația ta și îți spunem cinstit dacă merită mutat și cum. Fără presiune.