หากคุณหวังพึ่งการย้ายระบบอีเมลคลาวด์แบบ "รวดเร็ว" กับดักเหล่านั้นอาจเปลี่ยนช่วงเวลาหยุดทำงานที่วางแผนไว้ ให้กลายเป็นความล้มเหลวที่สิ้นเปลืองงบประมาณและทำลายชื่อเสียงได้
ทำไมการย้ายข้อมูลจึงเป็นมากกว่าแค่การคัดลอกไฟล์เพียงครั้งเดียว
การย้ายข้อมูลจาก Google ไปยัง Microsoft ไม่ใช่การดำเนินการแบบเบ็ดเสร็จเพียงขั้นตอนเดียว แต่ละบริการ ไม่ว่าจะเป็น mail, calendar, contacts, Drive, Vault, Chat หรือ Groups ต่างก็จัดเก็บข้อมูลในรูปแบบของตัวเอง ซึ่งต้องใช้ตรรกะในการดึงข้อมูล (extraction logic) และการจับคู่ปลายทาง (target mapping) ที่แยกจากกัน เครื่องมือที่เก่งเรื่องการคัดลอกข้อความ Gmail อาจข้ามการตั้งค่าสิทธิ์ใน Drive, ทำไฟล์เก็บถาวรใน Vault หล่นหาย หรือละเลยประวัติการแชทใน Chat ดังนั้น ควรเริ่มต้นด้วยการทำรายการ (inventory) ของทุกภาระงาน (workload) ที่คุณตั้งใจจะย้าย รวมถึงกรณีพิเศษ (edge cases) อย่างเช่น บัญชีที่ถูกระงับ (suspended accounts)
กับดักด้านการยืนยันตัวตน (Authentication)
การใช้เพียงชื่อผู้ใช้และรหัสผ่านเป็นความเสี่ยงด้านความปลอดภัย และมักจะล้มเหลวเมื่อใช้งานร่วมกับ API สมัยใหม่ สำหรับ Google คุณจำเป็นต้องมี service account ที่มีการมอบอำนาจครอบคลุมทั้งโดเมน (domain-wide delegation) และมีการกำหนดขอบเขตของสิทธิ์ OAuth (OAuth permissions) อย่างรัดกุม หากกำหนดขอบเขต (scopes) น้อยเกินไป ข้อมูลบางส่วนอาจตกหล่น แต่หากมากเกินไปก็จะกลายเป็นช่องทางในการถูกโจมตี ส่วนใน Microsoft นั้น การยืนยันตัวตนแบบพื้นฐาน (basic authentication) ได้ถูกยกเลิกไปแล้ว และจะใช้ได้เฉพาะ OAuth 2.0 เท่านั้น ดังนั้นควรหลีกเลี่ยงเครื่องมือย้ายข้อมูลใดก็ตามที่ยังโฆษณาว่ารองรับ basic auth
ระบบ Labels เทียบกับระบบ Folders
ระบบ label ของ Gmail ช่วยให้ข้อความหนึ่งฉบับสามารถอยู่ภายใต้หลายแท็กได้ ในขณะที่ Outlook จะบังคับให้แต่ละข้อความอยู่ในโฟลเดอร์เดียวเท่านั้น เมื่อมีการคัดลอกอีเมลที่มีหลาย label เครื่องมือย้ายข้อมูล (migration engine) อาจดำเนินการได้ดังนี้:
- คัดลอกข้อความซ้ำไปยังแต่ละโฟลเดอร์ปลายทาง (ทำให้พื้นที่จัดเก็บเพิ่มขึ้นและเกิดเธรดข้อความซ้ำซ้อน)
- วางไว้ในโฟลเดอร์เดียวและตัด label ส่วนเกินทิ้ง (ทำให้เสียความเป็นระเบียบ)
- สร้างเส้นทางโฟลเดอร์ที่ลึกเพื่อเลียนแบบโครงสร้าง label (ซึ่งมักสร้างความสับสนให้กับผู้ใช้งาน)
เครื่องมือที่เชื่อถือได้จะให้คุณเป็นผู้เลือก ส่วนเครื่องมือที่ไม่มีคุณภาพจะบังคับค่าเริ่มต้นที่อาจไม่สอดคล้องกับขั้นตอนการทำงานของคุณ
Throttling คือคอขวดที่แท้จริง
การทดสอบความเร็วที่เน้นเพียงแบนด์วิดท์ (bandwidth) มักมองข้ามความจริงที่ว่า Microsoft Graph API มีการจำกัดจำนวนคำขอต่อวินาที (request-per-second limits) หากคุณส่งคำขอมากเกินไปและเร็วเกินไป Microsoft จะบล็อกคุณ ดังนั้นควรเลือกใช้เครื่องมือที่มีระบบจัดการ throttle อัตโนมัติ เช่น การหยุดชั่วคราว (pausing), การลดความเร็วลง (backing off) และการกลับมาทำงานใหม่ (resuming) ตามความเหมาะสม แทนที่จะคิดว่าการมีอินเทอร์เน็ตที่เร็วขึ้นจะช่วยแก้ปัญหานี้ได้
การเปลี่ยนผ่านแบบ Incremental (delta) ไม่ใช่การเทข้อมูลทั้งหมดในคืนวันศุกร์
การย้ายข้อมูลทั้ง tenant ภายในช่วงสุดสัปดาห์เดียวจะทำให้เกิด downtime อย่างแน่นอน การใช้วิธีแบบแบ่งเป็นระยะ (staged approach) จะได้ผลดีกว่า:
- Bulk load – ย้ายอีเมล ไฟล์ และข้อมูลอื่นๆ ส่วนใหญ่ล่วงหน้าหลายวันหรือหลายสัปดาห์ก่อนการสลับระบบจริง
- Delta sync – ในช่วงเวลาเปลี่ยนผ่าน ให้ทำการย้ายข้อมูลแบบ incremental เพื่อเก็บเฉพาะรายการใหม่หรือรายการที่มีการเปลี่ยนแปลงเท่านั้น
- MX record flip – สลับค่า mail exchange record ให้ชี้ไปยัง Microsoft 365 เมื่อการทำ delta sync ยืนยันแล้วว่าไม่มีรายการค้างอยู่
วิธีนี้จะช่วยลด downtime จากหลายชั่วโมงให้เหลือเพียงไม่กี่นาที
รายการตรวจสอบ (Checklist) เพื่อการย้ายข้อมูลที่ประสบความสำเร็จ
- ทำรายการทุกภาระงาน (Mail, Drive, Vault, Chat, Groups และอื่นๆ)
- รวมถึงวัตถุที่จัดการยาก เช่น บัญชีที่ถูกระงับ
- ตรวจสอบการรองรับ ในเอกสารทางเทคนิคของเครื่องมือย้ายข้อมูล ไม่ใช่ดูแค่หน้าการตลาด
- จำกัด OAuth scopes ให้เหลือเพียงขั้นต่ำที่จำเป็นสำหรับแต่ละบริการต้นทาง
- ทดสอบการทำ delta synchronization ที่แท้จริง พร้อมระบบกำจัดข้อมูลซ้ำ (deduplication) เพื่อให้แน่ใจว่าจะไม่มีรายการซ้ำปรากฏในปลายทาง
- ทดสอบระบบนำร่อง (pilot) โดยลองใช้กับข้อความ Gmail ที่มีหลาย label และโครงสร้างสิทธิ์ใน Drive ที่มีความซับซ้อน
Drive เป็นอีกเรื่องหนึ่งที่แยกต่างหาก ซึ่งมีงบประมาณและกรอบเวลาของตัวเอง