ძველი ფოსტის ყუთის გადატანა ახალ სისტემაში: პრაქტიკული ჩეკლისტი

ელფოსტა ბევრი კომპანიისთვის მხოლოდ მიმოწერა არ არის. ის შეთანხმებების, ინვოისებისა და კლიენტებთან საუბრების არქივია. ამიტომ, როცა ძველი ფოსტის სერვისიდან Microsoft 365-ზე ან Google Workspace-ზე გადადიხართ, მთავარი კითხვა ასეთია: დაგვრჩება თუ არა ყველა წერილი? კარგი ამბავი ის არის, რომ სწორი თანმიმდევრობით ამის რისკი ძალიან მცირდება. ქვემოთ მოცემულია მარტივი ჩეკლისტი.

1. დაიწყეთ აღწერით

გადატანამდე ჩამოწერეთ, რა გაქვთ ახლა:

• ყველა ფოსტის ყუთი და თითოეული ყუთის დაახლოებითი ზომა;
• ალიასები (დამატებითი მისამართები ერთსა და იმავე ყუთზე), საერთო ყუთები, გადამისამართებები და ჯგუფური მისამართები, მაგალითად info@ ან sales@;
• ვინ რა მოწყობილობიდან კითხულობს ფოსტას: კომპიუტერი, ტელეფონი, ტაბლეტი;
• არის თუ არა სერვერზე ავტომატური არქივაციის ან წაშლის წესები.

ეს სია მიგიჩენთ, რა უნდა გადაიტანოთ და რა არ უნდა დაგავიწყდეთ.

2. გაიგეთ, რა გადადის და რა არა

IMAP-ზე დაფუძნებული გადატანა ორივე პლატფორმაზე ძირითადად ფოსტის საქაღალდეებს გადაიტანს. Microsoft-ის დოკუმენტაციის მიხედვით, გადაიტანება მხოლოდ მომხმარებლის შემოსულები და სხვა ფოსტის საქაღალდეები. Microsoft-ის ახსნა-განმარტებებში ასევე წერია, რომ კონტაქტები, კალენდრის ჩანაწერები და ამოცანები ამ გზით არ გადადის. ამიტომ კალენდარი და კონტაქტების წიგნი ცალკე უნდა გადაიტანოთ ან ხელით გადაიტანოთ. იგივე ეხება ფოსტის წესებს (rules), რომლებიც ყუთში გქონდათ დაყენებული.

Microsoft-ის IMAP გადატანას ლიმიტებიც აქვს. ერთ ყუთზე შეიძლება გადავიდეს მაქსიმუმ 500 000 წერილი, ხოლო ერთი წერილის ზომა 35 მბ-ს არ უნდა აღემატებოდეს. თუ ვინმეს ძალიან დიდი ან მრავალწლიანი ყუთი აქვს, ეს წინასწარ უნდა გაითვალისწინოთ.

3. მოამზადეთ ახალი სისტემა

ახალ პლატფორმაზე წინასწარ შექმენით თითოეული ადამიანის ანგარიში და დაამატეთ საჭირო ალიასები. Google Workspace-ის მონაცემთა გადატანის სერვისი ყოველ მომხმარებელზე ითხოვს ძველი ყუთის მისამართს, მისი IMAP პაროლს და ახალი Workspace მისამართს. ზოგ IMAP სერვერზე ჩვეულებრივი პაროლი არ კმარა და საჭიროა აპლიკაციისთვის განკუთვნილი ცალკე პაროლი. გადატანა უნდა დაიწყოს და გაუშვას სუპერადმინისტრატორმა. IMAP ჩართული უნდა იყოს როგორც ძველ, ისე ახალ ანგარიშზე. მცირე გუნდისთვის, 20 მომხმარებლამდე, მონაცემების პირდაპირ ადმინ კონსოლშიც შეიყვანთ, უფრო დიდისთვის კი CSV ფაილია საჭირო. ერთი ძველი მისამართი ერთზე მეტ ახალ მომხმარებელზე ვერ გადავა.

4. გამორთეთ არქივაციის წესები

ეს პუნქტი ხშირად რჩება შეუმჩნეველი. Microsoft-ის გადატანის ინსტრუმენტი ვერ ხედავს ძველ სისტემაში მოქმედ არქივაციისა და ფოსტის ჩანაწერების მართვის წესებს. თუ ასეთი წესი გადატანის დროს წერილს წაშლის ან გადაიტანს, ინსტრუმენტი ის წერილი „დაკარგულად“ ჩათვლის. ამის გამო რთულდება იმის გარჩევა, რა დაიკარგა სინამდვილეში. Microsoft-ის რეკომენდაციაა, რომ გადატანამდე ასეთი წესები გამორთოთ.

5. DNS: MX ჩანაწერის TTL წინასწარ შეამცირეთ

ფოსტის გადატანა ორი ცალკე საქმეა: ძველი წერილების გადაკოპირება და ახალი წერილების გადამისამართება MX ჩანაწერებით. MX ჩანაწერები განსაზღვრავს, რომელ სერვერზე მივა თქვენი დომენის ფოსტა. TTL მიუთითებს, რამდენ ხანს ინახავს ამ ჩანაწერს ინტერნეტის სხვა სერვერები. თუ TTL დიდია, ცვლილება შესაძლოა მთელი დღე არ გავრცელდეს და ახალი წერილები ძველ სერვერზე კვლავ მოვიდეს. ერთ-ერთი პრაქტიკული რჩევის მიხედვით, MX ჩანაწერის TTL გადართვამდე სულ მცირე 24-48 საათით ადრე უნდა დაწიოთ, მაგალითად 300 წამამდე. ზოგი DNS პროვაიდერი მინიმალურ მნიშვნელობას ზღუდავს, ამიტომ ჯერ ნახეთ, რა დიაპაზონია დაშვებული. გადართვის დღეს ამის გაკეთება უკვე გვიანია.

6. ჯერ ერთი სატესტო ყუთი

სანამ ყველას ფოსტას გადაიტანთ, ერთი რეალური ყუთი გადაიტანეთ საცდელად. შეამოწმეთ საქაღალდეების სტრუქტურა, ძებნა, დანართების გახსნა და წერილების რაოდენობა. თუ რამე არასწორად გამოვიდა, ამას ახლა გამოასწორებთ და არა მთელი კომპანიის გადატანის შემდეგ.

7. გადართვის დღე: წერილების გადაკოპირება და MX

სწორი თანმიმდევრობა ასეთია: ჯერ მთავარი გადაკოპირება, შემდეგ MX ჩანაწერის გადართვა, შემდეგ დამატებითი სინქრონიზაცია. MX ცვლილების შემდეგ ზოგი წერილი ჯერ კიდევ შეიძლება ძველ სერვერზე მივიდეს, რადგან DNS-ის გავრცელებას დრო სჭირდება. ამიტომ გადართვის შემდეგ გაუშვით განმეორებითი (delta) სინქრონიზაცია, რომ ეს წერილებიც გადმოვიდეს. ძველი MX ჩანაწერები გადართვისას წაშალეთ, რომ ფოსტა შემთხვევით ძველ სისტემაში არ გაგრძელდეს. ერთ-ერთი სახელმძღვანელოს რჩევაა, ძველი ყუთი კიდევ დაახლოებით 30 დღე ჩართული დატოვოთ, სანამ დარწმუნდებით, რომ არაფერი გამოგრჩათ.

8. გადართვის შემდეგ

• შეამოწმეთ, რომ ახალი წერილები ახალ სისტემაში მოდის და გადის;
• ახალ პროვაიდერზე გადაამოწმეთ SPF, DKIM და DMARC ჩანაწერები, რომ თქვენი წერილები სპამში არ ხვდებოდეს (ამ თემაზე ჩვენს ბლოგზე ცალკე სტატია გვაქვს);
• ყველას გაუგზავნეთ ახალი შესვლის ინსტრუქცია, დააყენეთ ფოსტა ტელეფონებსა და Outlook-ში და ჩართეთ ორსაფეხურიანი ავტორიზაცია;
• როცა ყველაფერი სტაბილურია, TTL დააბრუნეთ ჩვეულებრივ მნიშვნელობაზე. მხოლოდ ამის შემდეგ დახურეთ ძველი სერვისი.

მოკლედ, წესი მარტივია: ჯერ აღწერა და მომზადება, შემდეგ წერილების გადაკოპირება და MX ჩანაწერის ბოლოს გადართვა. თუ ერთ-ორ ყუთზე ფიქრობთ, ამის გაკეთება თავადაც შეგიძლიათ. თუ გყავთ ბევრი თანამშრომელი, საერთო ყუთები ან ძალიან დიდი არქივი, უმჯობესია დახმარება სთხოვოთ.

თუ გჭირდებათ მხარდაჭერა, Appy.ge ქართული IT კომპანიაა და Microsoft-ის ოფიციალური CSP პარტნიორია. ის ასევე ამზადებს Google Workspace-ს და დაგეხმარებათ ფოსტის გადატანის დაგეგმვასა და განხორციელებაში.

წყაროები:
• What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365 - Microsoft Learn — https://learn.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes
• migrate IMAP to office 365 - Microsoft Q&A — https://learn.microsoft.com/en-us/answers/questions/5887227/migrate-imap-to-office-365
• Migrate email from an IMAP account - Google Workspace Admin Help — https://knowledge.workspace.google.com/admin/migrate/migrate-email-from-an-imap-account?hl=en
• Business Email Migration Guide: 10 Steps for 2026 - Prestige Technologies — https://www.prestigetechnologies.com/blog/business-email-migration-guide/