اگر روی یک انتقال «سریع» ایمیل ابری حساب کنید، آن تلهها میتوانند یک قطعی برنامهریزیشده را به یک فاجعه پرهزینه و آسیبزننده به اعتبار تبدیل کنند.
چرا مهاجرت چیزی فراتر از یک عملیات کپی ساده است
انتقال دادهها از Google به Microsoft یک عملیات واحد و یکپارچه نیست. هر سرویس — mail، calendar، contacts، Drive، Vault، Chat، Groups — اطلاعات را در قالب مخصوص به خود ذخیره میکند که نیازمند منطق استخراج و نگاشت هدف (target mapping) مجزا است. ابزاری که در کپی کردن پیامهای Gmail عالی عمل میکند، ممکن است مجوزهای Drive را نادیده بگیرد، آرشیوهای Vault را از دست بدهد یا تاریخچه Chat را نادیده بگیرد. کار را با فهرست کامل از تمام حجمهای کاری (workload) که قصد انتقال آن را دارید، از جمله موارد خاص مانند حسابهای تعلیقشده، شروع کنید.
تله احراز هویت
نامهای کاربری و رمز عبور ساده یک ریسک امنیتی هستند و تقریباً همیشه در مواجهه با APIهای مدرن با شکست مواجه میشوند. در Google، شما به یک service account با قابلیت domain-wide delegation و مجموعهای از مجوزهای OAuth با محدوده (scope) دقیق نیاز دارید. محدودههای خیلی کم باعث باقی ماندن دادهها میشوند و محدودههای خیلی زیاد، راه را برای سوءاستفاده باز میکنند. در Microsoft، روش basic authentication بازنشسته شده است و فقط OAuth 2.0 کار میکند. هر ابزار مهاجرتی را که هنوز basic auth را تبلیغ میکند، کنار بگذارید.
برچسبها (Labels) در مقابل پوشهها (Folders)
سیستم برچسبگذاری Gmail اجازه میدهد یک پیام واحد تحت چندین برچسب قرار بگیرد، در حالی که Outlook هر پیام را مجبور میکند در یک پوشه واحد قرار گیرد. وقتی یک ایمیل با چندین برچسب کپی میشود، موتور مهاجرت میتواند:
- پیام را در هر پوشه مقصد تکرار کند (که باعث حجیم شدن فضای ذخیرهسازی و ایجاد رشتههای پیام تکراری میشود).
- آن را در یک پوشه قرار داده و برچسبهای اضافی را حذف کند (از دست رفتن سازماندهی).
- یک مسیر پوشه عمیق بسازد که از درخت برچسبها تقلید میکند (که اغلب برای کاربران نهایی گیجکننده است).
یک ابزار قابل اعتماد به شما اجازه انتخاب میدهد؛ اما یک ابزار ضعیف، یک حالت پیشفرض را تحمیل میکند که ممکن است با گردش کار (workflow) شما همخوانی نداشته باشد.
محدودیت نرخ درخواست (Throttling) گلوگاه اصلی است
تستهای سرعت که فقط بر پهنای باند خام تمرکز میکنند، این واقعیت را نادیده میگیرند که Microsoft’s Graph API محدودیتهای تعداد درخواست در ثانیه را اعمال میکند. اگر درخواستهای زیادی را خیلی سریع ارسال کنید، Microsoft شما را مسدود خواهد کرد. به دنبال ابزارهایی باشید که مدیریت خودکار throttle را پیادهسازی میکنند — یعنی در صورت نیاز، عملیات را متوقف، عقبنشینی (back off) و مجدداً از سر بگیرند — به جای اینکه تصور کنید یک اتصال اینترنت سریعتر مشکل را حل خواهد کرد.
انتقال تدریجی (delta)، نه تخلیه ناگهانی در جمعه شب
انتقال کل tenant در یک بازه زمانی آخر هفته، قطعی سرویس را تضمین میکند. یک رویکرد مرحلهبندی شده بهتر عمل میکند:
- Bulk load – انتقال بخش عمدهای از ایمیلها، فایلها و سایر دادهها، روزها یا هفتهها قبل از تغییر نهایی.
- Delta sync – در طول بازه انتقال، یک مهاجرت افزایشی (incremental) انجام دهید که فقط موارد جدید یا تغییر یافته را ثبت کند.
- MX record flip – پس از اینکه delta sync تایید کرد هیچ مورد معلق باقی نمانده است، رکورد mail exchange را به سمت Microsoft 365 تغییر دهید.
این روش زمان قطعی را از ساعتها به چند دقیقه کاهش میدهد.
چکلیست برای یک انتقال موفق
- فهرستبندی تمام حجمهای کاری (Mail، Drive، Vault، Chat، Groups و غیره).
- گنجاندن اشیاء پیچیده مانند حسابهای تعلیقشده.
- تایید پشتیبانی در مستندات فنی هر ابزار مهاجرت — و نه فقط در صفحه بازاریابی آن.
- محدود کردن OAuth scopes به حداقل مقدار مورد نیاز برای هر سرویس منبع.
- تست همگامسازی واقعی delta همراه با حذف موارد تکراری (deduplication) برای اطمینان از اینکه هیچ مورد تکراری در مقصد ظاهر نمیشود.
- اجرای یک طرح آزمایشی (pilot) که پیامهای Gmail با چندین برچسب و سلسلهمراتب پیچیده مجوزهای Drive را آزمایش کند.
Drive یک مورد جداگانه و متفاوت است؛ این سرویس بودجه و زمانبندی مخصوص به خود را دارد.