Migravimas
Migravimas be pertrūkių reiškia, kad kiekvienas Jūsų domenui išsiųstas laiškas patenka į pašto dėžutę ir kad kiekvienas darbuotojas perjungimo dieną gali rašyti savo adresatams. Tai nereiškia, kad istorija, mobilieji įrenginiai ir įpročiai pasikeičia be jokio veiksmo.
Dvi platformos veikia lygiagrečiai.
Įprasta spraga atsiranda tada, kai MX perjungiamas, kol kopija dar nebaigta, arba kai kopijavimo aparatas, svetainė ar CRM vis dar siunčia laiškus su senaisiais prisijungimo duomenimis.
MX yra DNS įrašas: jis nurodo siunčiantiesiems serveriams, kur pristatyti Jūsų domeno laiškus. Pakeisti el. pašto paslaugą pirmiausia reiškia pakeisti šį pristatymo adresą. Visa kita (paskyros, istorija, įrenginiai) parengiama aplink jį.
SMTP protokolas gerai toleruoja trumpus sutrikimus. Siunčiantysis serveris, gavęs laikiną klaidą, laiko laišką eilėje ir bando dar kartą vėliau. Todėl laikinai nepasiekiamas serveris nereiškia prarastų laiškų. Tačiau galutinė klaida (nežinoma pašto dėžutė, atmestas laiškas) grąžina laišką siuntėjui, ir šis laiškas pats savaime niekada nebeateis. Pagrindinė perjungimo rizika yra ne gedimas, o naujoji platforma, atmetanti gavėją, nes nebuvo atkurtas alias ar sąrašas.
TTL (galiojimo laikas) nustato, kiek laiko DNS sprendiklis gali laikyti atsakymą atmintyje. Šiuo laikotarpiu dalis siuntėjų vis dar pristato laiškus senajai platformai. Tai normalu, todėl senoji platforma per pereinamąjį laikotarpį turi išlikti pajėgi gauti laiškus.
Likus dviem savaitėms. Pašto dėžučių, alias, sąrašų, bendrų pašto dėžučių ir visų el. laiškus siunčiančių programų inventorizacija. MX DNS TTL sumažinimas iki trumpos vertės (dažnai 300 sekundžių), kad perjungimo dieną pakeitimas greitai pasklistų. Tikslinių paskyrų sukūrimas. Pirmoji istorijos kopija.
TTL mažinamas anksti, nes sprendiklis, perskaitęs senąją vertę, ją laiko iki jos galiojimo pabaigos: trumpas TTL įsigalioja tik pasibaigus senajam podėliui. Pirmoji kopija užtrunka ilgiausiai; ją pradėjus anksti lieka laiko aptikti problemines pašto dėžutes.
Likus kelioms dienoms. Imties patikra: laiškų, aplankų ar etikečių, susitikimų, kontaktų skaičius. Metodo pataisymas, jei imtis neatitinka. Instrukcijų mobiliesiems įrenginiams ir Outlook parengimas. Siuntimo bandymas iš tikslinės platformos į Gmail ir Outlook.com, kai SPF, DKIM ir DMARC naujojoje platformoje jau galioja. Šiuos įrašus galima paskelbti prieš MX.
Konkrečiai: vienas SPF įrašas, kuris pereinamuoju laikotarpiu leidžia abi platformas (du atskiri SPF įrašai lemia patikros nesėkmę), naujosios platformos DKIM raktas, paskelbtas su savo selektoriumi šalia senojo, ir peržiūrėta DMARC politika. DMARC reikalauja, kad laiškas būtų autentifikuotas SPF arba DKIM siuntėjo domeno vardu; jei Jūsų politika griežta, o tikslinė platforma dar neleidžiama, Jūsų adresatai atmes Jūsų laiškus.
Išvakarėse. Antrasis perėjimas: kopijuojama tik tai, kas atėjo po pirmosios kopijos. Alias ir sąrašų pakeitimų įšaldymas.
Perjungimo dieną. MX perjungimas. Nedelsiama išorinė patikra: laiškas, išsiųstas iš išorinės asmeninės pašto dėžutės, turi pasiekti naująją platformą per TTL laikotarpį. Eilės stebėjimas. Siunčiančiųjų programų perkonfigūravimas. Paskirta vidinė pagalbos linija, turinti teisę grąžinti MX atgal, jei sutriktų kritinis srautas.
Tuo pačiu metu pakeiskite autodiscover įrašą, jei jis yra: būtent į jį kreipiasi Outlook, ieškodama savo serverio. Taip pat pašalinkite antrinius MX, kurie vis dar nurodytų į senąją platformą: siuntėjas, negalintis pasiekti pagrindinio MX, bando kitus.
Kitomis dienomis. Senoji platforma – tik skaitymo režimu. Neatitikimų (trūkstamo aplanko, bendros pašto dėžutės) fiksavimas. Prireikus – trečiasis tikslinis perėjimas. Tada siuntimo senojoje platformoje uždarymas, kad darbuotojas nebeatsakinėtų iš dviejų vietų.
Paskutinis punktas turi techninę priežastį. Senoji platforma vis dar laiko save atsakinga už Jūsų domeną: iš jos kolegai išsiųstas laiškas pristatomas joje vietoje, nesikreipiant į MX. Kolega jo niekada nepamatys savo naujojoje pašto dėžutėje.
| Rizika | Kas nutinka | Prevencija |
|---|---|---|
| MX perjungtas per anksti | Nauji laiškai ateina, trūksta istorijos | Perjungti po imties patikros ir antrojo perėjimo |
| Pamiršti alias ar sąrašai | Tikslinė platforma galutinai atmeta šiuos laiškus | Inventorizacija, alias įšaldymas išvakarėse, bendrų adresų bandymas |
| Neužbaigti SPF, DKIM ar DMARC | Adresatai Jūsų laiškus atmeta arba priskiria nepageidaujamiems | Paskelbti iki perjungimo dienos, patikrinti su tikru laišku |
| Programa, siunčianti su senąja paskyra | Sąskaitos, įspėjimai ar nuskaityti dokumentai nebeišsiunčiami | Programų sąrašas, naujas SMTP serveris sukonfigūruotas perjungimo dieną |
| Senojoje platformoje paliktas atviras siuntimas | Vidiniai laiškai lieka senojoje sistemoje | Uždaryti siuntimą, kai tik imtis patvirtinta |
| Neparengtas grąžinimas atgal | MX grąžinamas atgal, bet tuo metu gauti laiškai lieka tikslinėje platformoje | Rašytinis planas, numatantis šių laiškų perkėlimą |
Iliustracijai paimkime 40 žmonių kontorą. Ji nusprendžia perjungti ketvirtadienio pavakare, o ne penktadienį: kitą dieną komanda yra vietoje ir gali spręsti neatitikimus, o vidinė pagalbos linija turi priešais visą darbo dieną. Priimamajame esantis kopijavimo aparatas, skenuojantis į el. paštą, perkonfigūruojamas tą patį vakarą. Jei dvi bendros pašto dėžutės praneša apie trūkstamą aplanką, tikslinis perėjimas juos papildo. Šiame scenarijuje nė vienas laiškas neprarandamas, tačiau keli darbuotojai turi iš naujo susikurti paskyrą telefone: tai matomoji dalis, apie kurią reikia pranešti.
Jie pakeičia serverį Outlook arba mobiliajame įrenginyje. Pirmasis didelės pašto dėžutės įkėlimas užtrunka. Telefone jau podėlyje esantys laiškai gali dubliuotis, jei profilis nėra tvarkingai sukurtas iš naujo. Numatykite procedūrą „ištrinti paskyrą ir sukurti ją iš naujo“, o ne improvizuotą serverio keitimą.
Ta pati priežastis galioja ir Outlook: profilis saugo vietinį podėlį, susietą su senuoju serveriu. Naujas profilis pradeda nuo švarios būsenos; pakeistas senas profilis sumaišo abu pasaulius. Mobiliuosiuose įrenginiuose naudojamas protokolas (Exchange ActiveSync arba IMAP, priklausomai nuo tikslinės platformos) kartais keičiasi kartu su platforma – tai dar viena priežastis sukurti paskyrą iš naujo.
Serverio taisyklės, centralizuoti parašai ir delegavimo teisės nustatomi iš naujo. Praneškite apie tai. Tai nėra el. pašto pertrūkis. Tai administravimo darbas.
Šiam peradresavimui reikia aiškaus nustatymo: senoji platforma, kuri vis dar mano talpinanti pašto dėžutes, turi būti sukonfigūruota perduoti laiškus naujajai, užuot pristačiusi juos pas save. Kitu atveju tą patį darbą atlieka tikslinis papildomas perėjimas.
Kiekvieno pradinio taško ypatumai aprašyti puslapiuose migravimas iš Microsoft 365 ir migravimas iš Google Workspace.
Tiek, kiek reikia patikrinti, kad jokie srautai nebenaudoja senosios platformos, ir kad nustatyti neatitikimai išspręsti. Tai priklauso nuo pašto dėžučių skaičiaus, siunčiančiųjų programų ir darbo vietų perkonfigūravimo tempo. Uždarius per anksti, nebegalima ištaisyti klaidų; uždarius per vėlai, darbuotojai dirba dviejose sistemose.
Ne, jei jis parengtas. TTL laikotarpiu dalis siuntėjų vis dar pristato laiškus senajai platformai, kita dalis – naujajai. Abi gauna laiškus, o kitas perėjimas juos sujungia. Laiškai prarandami tik tada, kai jie atmetami, todėl tokie svarbūs alias ir sąrašai.
Paprastai ne: adresai nesikeičia. Tačiau įspėkite partnerius, kurie griežtai filtruoja Jūsų laiškus arba Jums priskyrė specialią taisyklę, taip pat tuos, kurie su Jumis keičiasi šifruotais laiškais, jei raktai keičiasi.
Taip, grąžinus senąjį MX, jei senoji platforma vis dar veikia. Tuo metu naujosios platformos gauti laiškai tada turi būti nukopijuoti atgal arba likti prieinami. Grąžinimo atgal plane nurodoma, kas priima sprendimą, per kiek laiko ir kaip šie laiškai perkeliami.
Paklauskite operatoriaus, ką jis garantuoja: laiškų pristatymą, istorijos perkėlimą ar abu. Tai skirtingi įsipareigojimai. Taip pat paprašykite rašytinio grąžinimo atgal plano, kuriame nurodytas asmuo, turintis teisę jį aktyvuoti.
Laiškų pristatymo garantija apima perjungimo dieną ir kitas dienas. Istorijos garantija apima kopiją ir jos patikrą. Paslaugų teikėjas gali įvykdyti vieną be kitos; sąmatoje turi būti nurodyta, kurią jis prisiima ir kaip ji tikrinama.
Klytic patarimai ir pasiūlymai, kaip pasirengti el. pašto migravimui, yra nemokami, ir joks laiškas neprarandamas. Klytic atliekamas migravimas įkainojamas pagal sąmatą. Prenumeratos pateiktos puslapyje Kainos ir apmokestinamos atskirai. Išlaidų straipsnių detalės pateiktos puslapyje kiek kainuoja migravimas iš Microsoft 365, o kontrolinis sąrašas – kontroliniame sąraše. Norėdami palyginti tikslines platformas, žr. kaip pasirinkti europietišką el. pašto paslaugą.
Šiame puslapyje aprašomas metodas. Faktinė eiga priklauso nuo Jūsų srautų, apimčių ir platformos, kurią paliekate.
Peržiūrėta 2026 m. spalio mėn.
Nemokama konsultacija, neprarandamas nė vienas laiškas. Klytic atliekamo migravimo sąmata pateikiama po inventorizacijos.
Pasveikinimo pasiūlymas
Bandomasis pasiūlymas be įsipareigojimų. Konsultantas Jums paskambins, kad išsiaiškintų Jūsų poreikius ir paruoštų Jūsų Klytic erdvę.
