O migrare fără întreruperi înseamnă că fiecare mesaj trimis către domeniul dumneavoastră ajunge într-o căsuță și că fiecare angajat le poate scrie corespondenților săi în ziua comutării. Nu înseamnă că istoricul, telefoanele mobile și obiceiurile se schimbă fără nicio intervenție.
Două platforme funcționează în paralel.
Golul clasic apare atunci când MX-ul este comutat în timp ce o copie este incompletă sau când un copiator, un site ori un CRM trimite încă mesaje cu vechiul cont.
MX-ul este o înregistrare DNS: le indică serverelor expeditoare unde să livreze corespondența domeniului dumneavoastră. A schimba serviciul de e-mail înseamnă în primul rând a schimba această adresă de livrare. Restul (conturi, istoric, dispozitive) se pregătește în jurul ei.
Protocolul SMTP tolerează bine incidentele scurte. Un server expeditor care primește o eroare temporară păstrează mesajul în coadă și reîncearcă mai târziu. Prin urmare, un server indisponibil pentru moment nu duce la pierderea corespondenței. În schimb, o eroare definitivă (căsuță necunoscută, mesaj refuzat) trimite mesajul înapoi expeditorului, iar acest mesaj nu va mai ajunge niciodată de la sine. Riscul principal al unei comutări nu este pana, ci noua platformă care refuză un destinatar pentru că un alias sau o listă nu a fost recreată.
TTL-ul (durata de viață) stabilește cât timp un resolver DNS poate păstra un răspuns în memorie. Pe durata acestui interval, o parte dintre expeditori livrează încă pe platforma veche. Este normal și tocmai de aceea platforma veche trebuie să poată primi în continuare mesaje pe durata tranziției.
Cu două săptămâni înainte. Inventarul căsuțelor, aliasurilor, listelor, căsuțelor partajate și al tuturor aplicațiilor care trimit e-mail. Reducerea TTL-ului DNS al MX-ului la o valoare scurtă (adesea 300 de secunde), pentru ca ziua Z să se propage rapid. Crearea conturilor țintă. Prima copie a istoricului.
TTL-ul se reduce din timp deoarece un resolver care a citit valoarea veche o păstrează până la expirare: TTL-ul scurt intră în vigoare abia după ce vechiul cache a expirat. Prima copie este, la rândul ei, cea mai lungă; lansarea ei din timp lasă răgaz pentru a descoperi căsuțele care pun probleme.
Cu câteva zile înainte. Verificarea unui eșantion: număr de mesaje, dosare sau etichete, întâlniri, contacte. Corectarea metodei dacă eșantionul eșuează. Pregătirea instrucțiunilor pentru mobil și Outlook. Test de trimitere de pe platforma țintă către Gmail și Outlook.com, cu SPF, DKIM și DMARC deja valide pe noua platformă. Aceste înregistrări pot fi publicate înaintea MX-ului.
Concret: o singură înregistrare SPF care autorizează ambele platforme pe durata tranziției (două înregistrări SPF distincte fac verificarea să eșueze), o cheie DKIM a noii platforme publicată sub propriul selector, alături de cea veche, și o politică DMARC recitită. DMARC cere ca mesajul să fie autentificat prin SPF sau prin DKIM în numele domeniului expeditorului; dacă politica dumneavoastră este strictă, iar platforma țintă nu este încă autorizată, corespondenții dumneavoastră vă resping mesajele.
În ajun. A doua trecere: se copiază doar ce a sosit de la prima copie. Înghețarea modificărilor de aliasuri și liste.
În ziua Z. Comutarea MX-ului. Verificare externă imediată: un e-mail trimis dintr-o căsuță personală externă trebuie să ajungă pe noua platformă în intervalul TTL-ului. Monitorizarea cozii de așteptare. Reconfigurarea aplicațiilor care trimit mesaje. Un suport intern desemnat, cu dreptul de a readuce MX-ul la valoarea anterioară dacă un flux critic eșuează.
Schimbați în același timp înregistrarea autodiscover, dacă există: pe ea o interoghează Outlook pentru a-și găsi serverul. Eliminați și MX-urile secundare care ar indica încă platforma veche: un expeditor care nu reușește să contacteze MX-ul principal le încearcă pe următoarele.
În zilele următoare. Platforma veche în regim de citire. Semnalarea diferențelor (un dosar lipsă, o căsuță partajată). O a treia trecere țintită, dacă este nevoie. Apoi închiderea trimiterii de pe platforma veche, pentru ca un angajat să nu mai răspundă din două locuri.
Acest ultim punct are un motiv tehnic. Platforma veche se consideră în continuare responsabilă pentru domeniul dumneavoastră: un mesaj trimis de pe ea către un coleg este livrat local, fără consultarea MX-ului. Colegul nu îl va vedea niciodată în noua sa căsuță.
| Risc | Ce se întâmplă | Soluție |
|---|---|---|
| MX comutat prea devreme | Corespondența nouă sosește, istoricul lipsește | Comutați după verificarea eșantionului și a doua trecere |
| Alias sau listă uitată | Platforma țintă refuză definitiv aceste mesaje | Inventar, înghețarea aliasurilor în ajun, testarea adreselor colective |
| SPF, DKIM sau DMARC incomplete | Mesajele dumneavoastră sunt respinse sau clasate ca spam la corespondenți | Publicați înainte de ziua Z, verificați pe un mesaj real |
| Aplicație care trimite cu vechiul cont | Facturile, alertele sau scanările nu mai pleacă | Lista aplicațiilor, noul server SMTP configurat în ziua Z |
| Trimitere lăsată deschisă pe platforma veche | Mesaje interne rămân în vechiul sistem | Închideți trimiterea imediat ce eșantionul este validat |
| Revenire nepregătită | MX-ul revine la valoarea anterioară, dar mesajele primite între timp rămân pe platforma țintă | Plan scris, inclusiv recuperarea acestor mesaje |
Să luăm, cu titlu ilustrativ, o firmă de 40 de persoane. Aceasta alege să comute într-o joi la sfârșitul zilei, nu într-o vineri: a doua zi, echipa este prezentă pentru a trata diferențele, iar suportul intern are în față o zi lucrătoare. Copiatorul de la recepție, care scanează către e-mail, este reconfigurat chiar în aceeași seară. Dacă două căsuțe partajate semnalează un dosar lipsă, o trecere țintită le completează. În acest scenariu, niciun mesaj nu se pierde, dar mai mulți angajați trebuie să-și refacă contul pe telefon: aceasta este partea vizibilă care trebuie anunțată.
Aceștia schimbă serverul în Outlook sau pe mobil. Prima încărcare a unei căsuțe mari durează. Mesajele aflate deja în cache pe telefon pot apărea duplicat dacă profilul nu este refăcut corect. Prevedeți procedura „ștergerea contului și recrearea lui” în locul unei improvizații la nivelul serverului.
Motivul este același pentru Outlook: profilul păstrează un cache local legat de vechiul server. Un profil nou pornește de la o stare curată; un profil vechi modificat amestecă cele două lumi. Pe mobil, protocolul utilizat (Exchange ActiveSync sau IMAP, în funcție de platforma țintă) se schimbă uneori odată cu platforma, ceea ce este încă un motiv pentru a recrea contul.
Regulile de pe server, semnăturile centralizate și drepturile de delegare se configurează din nou. Anunțați acest lucru. Nu este o întrerupere a corespondenței. Este muncă de administrare.
Această redirecționare necesită o setare explicită: platforma veche, care crede în continuare că găzduiește căsuțele, trebuie configurată să retransmită către cea nouă în loc să livreze local. În lipsa acesteia, o trecere de recuperare țintită face aceeași treabă.
Particularitățile fiecărui punct de plecare sunt descrise în migrarea de la Microsoft 365 și migrarea de la Google Workspace.
Cât este necesar pentru a verifica faptul că niciun flux nu o mai folosește pe cea veche și că diferențele semnalate au fost tratate. Durata depinde de numărul de căsuțe, de aplicațiile care trimit mesaje și de ritmul de reconfigurare a stațiilor de lucru. O închidere prea devreme împiedică orice corectură; o închidere prea târzie lasă angajații să lucreze în două sisteme.
Nu, dacă este pregătită. Pe durata TTL-ului, o parte dintre expeditori livrează încă pe platforma veche, cealaltă pe cea nouă. Ambele primesc mesaje, iar trecerea următoare le reunește. Corespondența se pierde doar dacă este refuzată, de unde importanța aliasurilor și a listelor.
În general, nu: adresele nu se schimbă. Anunțați în schimb partenerii care vă filtrează strict mesajele sau care v-au atribuit o regulă specială, precum și pe cei care schimbă cu dumneavoastră corespondență criptată, dacă se schimbă cheile.
Da, prin restabilirea vechiului MX, cu condiția ca platforma veche să fie încă activă. Mesajele primite între timp de platforma nouă trebuie atunci recopiate sau trebuie să rămână consultabile. Planul de revenire precizează cine decide, în cât timp și cum sunt recuperate aceste mesaje.
Întrebați operatorul serviciului ce garantează: sosirea mesajelor, preluarea istoricului sau ambele. Sunt angajamente diferite. Cereți și planul de revenire, în scris, împreună cu persoana care are dreptul să îl activeze.
O garanție privind sosirea mesajelor se referă la ziua Z și la zilele următoare. O garanție privind istoricul se referă la copiere și la verificarea ei. Un prestator o poate respecta pe una fără cealaltă; oferta de preț trebuie să precizeze pe care o preia și cum se verifică.
La Klytic, sfaturile și sugestiile pentru pregătirea migrării serviciului de e-mail sunt gratuite și niciun e-mail nu se pierde. Migrarea realizată de Klytic se stabilește pe bază de ofertă. Abonamentele sunt prezentate pe pagina Tarife și se facturează separat. Detaliul elementelor de cost se găsește în cât costă o migrare Microsoft 365, iar lista de control în lista de verificare. Pentru a compara platformele țintă, consultați alegerea unui e-mail profesional european.
Această pagină descrie o metodă. Desfășurarea reală depinde de fluxurile dumneavoastră, de volume și de platforma pe care o părăsiți.
Consultate în octombrie 2026.
Consiliere gratuită, niciun e-mail pierdut. Migrarea realizată de Klytic se face pe bază de ofertă, după un inventar.
Ofertă de bun venit
Ofertă de probă fără angajament. Un consilier vă sună înapoi pentru a vă înțelege nevoile și a vă pregăti spațiul Klytic.
