Email köçürülməsi zamanı əvvəlcə nə müəyyən edilir?
Email köçürülməsi mövcud məktubların və razılaşdırılmış məlumatların başqa poçt sisteminə keçirilməsidir. Domen adı eyni qalsa da, poçt qutularının yerləşdiyi server və istifadəçilərin giriş üsulu dəyişə bilər. Layihə mənbə sistemin, məlumat həcminin və köçürüləcək elementlərin inventarı ilə başlamalıdır. Hesab sayı təkbaşına kifayət etmir: beş böyük arxiv qutusu iyirmi yeni hesabdan daha çox iş tələb edə bilər.
cPanel və digər IMAP serverlərindən Google Workspace və ya Microsoft 365 mühitinə keçid, iki bulud platforması arasında miqrasiya və hosting dəyişməsi ayrı ssenarilərdir. Hər birində icazələr, məlumat formatı və köçürmə vasitəsinin limitləri yoxlanmalıdır. Məqsəd riskləri əvvəlcədən görmək, pilot nəticəsinə əsasən plan qurmaq və təhvil zamanı nəticəni müqayisə etməkdir.
Məktubla birlikdə başqa nələr köçürülür?
| Məlumat növü | Keçiddən əvvəl yoxlama |
|---|---|
| Məktublar və qoşmalar | Qutu həcmi, mesaj ölçüsü və mənbə giriş imkanı |
| Qovluq və etiketlər | Mənbə və hədəfdə təşkil olunma fərqləri |
| Kontakt və təqvim | Köçürmə vasitəsinin dəstəyi və ayrıca ixrac ehtiyacı |
| Alias, qrup və ortaq ünvanlar | Hədəfdə yenidən yaradılacaq ünvan və səlahiyyətlər |
| Qayda, imza və avtomatik cavab | Avtomatik daşınmayan istifadəçi sazlamaları |
| Kompüterdəki yerli arxiv | Serverdə olmayan PST və digər faylların ayrıca inventarı |
IMAP bütün hesab məlumatlarının universal köçürmə üsulu deyil. Məsələn, Microsoft-un IMAP miqrasiyası məktubları daşıyır, kontakt, təqvim və tapşırıqları isə köçürmür. Bu məhdudiyyət rəsmi sənəddə göstərilir. İstifadə edilən konkret vasitənin imkanları yoxlanmadan “hər şey avtomatik keçəcək” nəticəsi çıxarılmamalıdır.
Keçid planının mərhələləri
- İnventar: hesablar, ünvanlar, həcmlər, cihazlar və bağlı tətbiqlər siyahıya alınır.
- Hazırlıq: yeni mühitdə hesablar, uyğun lisenziyalar və giriş səlahiyyətləri hazırlanır.
- Pilot: təmsilçi bir poçt qutusu köçürülür, nəticələr və istisnalar qeyd edilir.
- Əsas köçürmə: pilotdan alınan nəticəyə əsasən qalan qutular planla daşınır.
- Keçid pəncərəsi: son sinxronizasiya, MX dəyişikliyi və cihazların qoşulması əlaqələndirilir.
- Qəbul: şirkətin məsul şəxsi ilə testlər və məlumat müqayisəsi tamamlanır.
Bu mərhələlər sabit müddət vədi deyil. Pilot zamanı serverin cavab sürəti, limitlər və səhv mesajları görünür. Onlara əsasən tətbiq vaxtı daha real qiymətləndirilə bilər. Mənbəyə giriş dəyişərsə və ya yeni böyük arxiv aşkarlanarsa plan yenilənməlidir. Miqrasiya xidmətinin əhatəsi haqqında əlavə məlumatı da oxuya bilərsiniz.
MX dəyişəndə email dayanacaqmı?
DNS qeydlərinin keşlənməsi səbəbindən bütün göndərənlər yeni MX məlumatını eyni anda görməyə bilər. Keçid zamanı köhnə və yeni sistemin vəziyyətini izləmək, köhnə serverə çatan məktublar üçün son sinxronizasiyanı planlamaq lazımdır. Köhnə xidməti DNS dəyişikliyi edilən anda bağlamaq gecikmiş məktubların qəbuluna təsir edə bilər.
Fasilə riskini azaltmaq üçün sınaq, uyğun keçid vaxtı və əvvəlcədən istifadəçi məlumatlandırılması hazırlanır. Bununla belə, “sıfır fasilə” bütün sistemlər və şərtlər üçün təminat deyil. Cari DNS cavabına baxmaq və MX dəyişəndən sonra qəbul problemini yoxlamaq keçidin müşahidəsinə kömək edir.
Pilot hesab necə seçilməlidir?
Yalnız boş hesabı sınaqdan keçirmək real çətinlikləri göstərməyə bilər. Pilotda köhnə məktublar, fərqli qovluqlar, qoşmalar və gündəlik istifadə ssenarisi olan hesab seçilməsi faydalıdır. Məlumatın şəxsi xarakteri və giriş icazəsi nəzərə alınmalıdır. Şirkətin təsdiqləmədiyi şəxsi hesablar layihəyə daxil edilməməlidir.
Nümunə planlaşdırmada on iki hesabdan biri əvvəlcə sınaq üçün seçilir. Pilotda ayrıca saxlanan kontaktlar aşkar edilərsə, onlar əsas məktub köçürməsinə əlavə iş kimi daxil edilir. Bu nümunə real müştəri nəticəsi deyil; pilotun görünməyən iş həcmini necə üzə çıxardığını göstərir. Qərarlar və istisnalar yazılı saxlanıldıqda yekun qəbul daha aydın olur.
Nəticəni məktub sayından başqa necə yoxlamaq olar?
Say və həcm faydalı göstəricilərdir, amma təkbaşına tam sübut deyil. Qovluqların görünməsi, tarix aralığı üzrə nümunə məktublar, qoşmaların açılması və axtarış nəticələri yoxlanmalıdır. Mənbə və hədəfdə fərqli qovluq və etiket məntiqi saylarda fərq yarada bilər; hər fərq araşdırılmalı və qəbul edilən istisna kimi qeyd olunmalıdır.
Hər istifadəçinin girişini, daxili və xarici göndərişi, kənardan qəbulu və şöbə ünvanlarına çatdırılmanı sınayın. CRM və saytın göndərdiyi avtomatik məktubları unutmayın. Yeni provayderdən gələn nümunə məktubda SPF, DKIM və DMARC nəticələri yoxlanmalıdır. Autentifikasiya auditi yeni göndəriş quruluşunu qiymətləndirməyə kömək edir.
Geri dönüş və köhnə sistemin bağlanması
Geri dönüş yalnız köhnə MX qeydini yazmaqdan ibarət deyil. Yeni sistemdə artıq yaranmış məktubların necə saxlanacağı və iki mühitdə qalan məlumatın necə uyğunlaşdırılacağı da nəzərə alınmalıdır. Ona görə dəyişiklikdən əvvəl məsul şəxs, qərar meyarı və məlumatın qorunması üsulu müəyyənləşdirilməlidir.
Köhnə hesabların nə vaxt bağlanacağı qəbul nəticəsinə və razılaşdırılmış saxlama müddətinə bağlı olmalıdır. Miqrasiya xidməti uzunmüddətli ehtiyat nüsxə sistemini əvəz etmir. Köçürmədən sonra da backup və bərpa qaydası ayrıca planlanır. Backup ilə arxivin fərqi saxlanma qərarını anlamağa kömək edir.
İlkin qiymətləndirmə üçün məlumatlar
Müraciətdə domen, indiki və istənilən platforma, hesab sayı, təxmini ümumi həcm və kontakt/təqvim ehtiyacını yazın. Şifrə və məktub məzmunu tələb olunmur. Qiymət və müddət bu inventar, mənbənin vəziyyəti və razılaşdırılmış əlavə işlər əsasında dəqiqləşdirilməlidir.
Layihə üçün yüklənən yoxlama cədvəli
Miqrasiya yoxlama cədvəlini endirin — CSV. Faylı Excel və ya başqa cədvəl proqramında açaraq məsul şəxsi, nəticəni və tamamlanma tarixini qeyd edə bilərsiniz. Bu, planlaşdırma şablonudur; real layihə nəticəsi və ya xidmət zəmanəti deyil.