اگر آپ "تیزی" سے کلاؤڈ ای میل منتقلی پر بھروسہ کرتے ہیں، تو یہ جال ایک منصوبہ بند تعطل کو مہنگے اور ساکھ کو نقصان پہنچانے والے ہنگامے میں بدل سکتے ہیں۔
کیوں یہ مائیگریشن محض ایک ڈیٹا کاپی کرنے کا کام نہیں ہے
Google سے Microsoft تک ڈیٹا منتقل کرنا کوئی ایک واحد یا یکساں عمل نہیں ہے۔ ہر سروس—mail، calendar، contacts، Drive، Vault، Chat، Groups—معلومات کو اپنے مخصوص فارمیٹ میں محفوظ کرتی ہے، جس کے لیے الگ نکاسی کے منطق (extraction logic) اور ٹارگٹ میپنگ کی ضرورت ہوتی ہے۔ ایک ایسا ٹول جو Gmail پیغامات کی کاپی کرنے میں بہترین ہو، وہ Drive کی اجازتوں (permissions) کو چھوڑ سکتا ہے، Vault کے آرکائیوز کو ضائع کر سکتا ہے، یا Chat کی ہسٹری کو نظر انداز کر سکتا ہے۔ ہر اس ورک لوڈ کی مکمل فہرست سے آغاز کریں جسے آپ منتقل کرنے کا ارادہ رکھتے ہیں، بشمول معطل شدہ اکاؤنٹس (suspended accounts) جیسے پیچیدہ معاملات۔
آتھنٹیکیشن (Authentication) کا جال
سادہ یوزر نیم اور پاس ورڈز سیکیورٹی کے لیے خطرہ ہیں اور جدید APIs کے ساتھ تقریباً ہمیشہ ناکام ہو جاتے ہیں۔ Google پر آپ کو ڈومین وائیڈ ڈیلگیشن (domain-wide delegation) کے ساتھ ایک سروس اکاؤنٹ اور OAuth کی محدود پیمانے پر اجازتوں (permissions) کے سیٹ کی ضرورت ہوتی ہے۔ بہت کم اسکوپس (scopes) ڈیٹا کو پیچھے چھوڑ دیتے ہیں؛ جبکہ بہت زیادہ اسکوپس غلط استعمال کا راستہ کھول دیتے ہیں۔ Microsoft پر، بیسک آتھنٹیکیشن کو ختم کر دیا گیا ہے؛ اب صرف OAuth 2.0 کام کرتا ہے۔ کسی بھی ایسی مائیگریشن یوٹیلیٹی کو مسترد کر دیں جو اب بھی بیسک آتھ (basic auth) کا اشتہار دے رہی ہو۔
لیبلز بمقابلہ فولڈرز
Gmail کا لیبل سسٹم ایک ہی پیغام کو متعدد ٹیگز کے تحت رہنے کی اجازت دیتا ہے، جبکہ Outlook ہر پیغام کو ایک ہی فولڈر میں رکھنے پر مجبور کرتا ہے۔ جب ایک ملٹی لیبل ای میل کو کاپی کیا جاتا ہے، تو مائیگریشن انجن یہ کر سکتا ہے:
- پیغام کو ہر ٹارگٹ فولڈر میں ڈپلیکیٹ کر دے (جس سے اسٹوریج بڑھ جاتی ہے اور ڈپلیکیٹ تھریڈز بن جاتے ہیں)۔
- اسے ایک ہی فولڈر میں رکھ دے اور اضافی لیبلز کو ختم کر دے (تنظیم کا نقصان)۔
- ایک گہرا فولڈر پاتھ بنائے جو لیبل ٹری کی نقل کرے (جو اکثر اینڈ یوزرز کے لیے الجھن کا باعث بنتا ہے)۔
ایک قابل اعتماد ٹول آپ کو انتخاب کرنے کا موقع دیتا ہے؛ جبکہ ایک ناقص ٹول اپنی مرضی کا ڈیفالٹ سیٹ کر دیتا ہے جو شاید آپ کے ورک فلو کے مطابق نہ ہو۔
تھروٹلنگ (Throttling) اصل رکاوٹ ہے
وہ اسپیڈ ٹیسٹ جو صرف بینڈوتھ (bandwidth) پر توجہ دیتے ہیں، اس حقیقت کو نظر انداز کر دیتے ہیں کہ Microsoft کی Graph API فی سیکنڈ درخواستوں (requests) کی حد مقرر کرتی ہے۔ اگر آپ بہت زیادہ کالز بہت تیزی سے کریں گے تو Microsoft آپ کو بلاک کر دے گا۔ ایسی یوٹیلیٹیز تلاش کریں جو خودکار تھروٹل مینجمنٹ (automatic throttle management) کا استعمال کرتی ہوں—یعنی ضرورت کے مطابق رکنا، پیچھے ہٹنا اور دوبارہ شروع کرنا—بجائے اس کے کہ یہ سمجھا جائے کہ تیز انٹرنیٹ کنکشن اس مسئلے کو حل کر دے گا۔
انکریمنٹل (delta) کٹ اوور، نہ کہ جمعہ کی رات کا ڈیٹا ڈمپ
پورے ٹیننٹ (tenant) کو ایک ہی ویک اینڈ کے دوران منتقل کرنا ڈاؤن ٹائم (downtime) کی ضمانت دیتا ہے۔ ایک مرحلہ وار طریقہ کار زیادہ بہتر کام کرتا ہے:
- بک لوڈ (Bulk load) – حتمی تبدیلی سے کئی دن یا ہفتے پہلے ای میل، فائلز اور دیگر ڈیٹا کا بڑا حصہ منتقل کریں۔
- ڈیلٹا سنک (Delta sync) – کٹ اوور کے دوران، ایک انکریمنٹل مائیگریشن چلائیں جو صرف نئی یا تبدیل شدہ چیزوں کو حاصل کرے۔
- MX ریکارڈ فلپ (MX record flip) – جب ڈیلٹا سنک اس بات کی تصدیق کر دے کہ کوئی بھی آئٹم باقی نہیں رہا، تو میل ایکسچینج ریکارڈ کو Microsoft 365 کی طرف موڑ دیں۔
یہ طریقہ ڈاؤن ٹائم کو گھنٹوں سے کم کر کے منٹوں میں لے آتا ہے۔
کامیاب منتقلی کے لیے چیک لسٹ
- ہر ورک لوڈ کی فہرست بنائیں (Mail, Drive, Vault, Chat, Groups، وغیرہ)۔
- پیچیدہ اشیاء شامل کریں جیسے کہ معطل شدہ اکاؤنٹس۔
- کسی بھی مائیگریشن ٹول کی تکنیکی دستاویزات میں سپورٹ کی تصدیق کریں—صرف مارکیٹنگ پیج پر بھروسہ نہ کریں۔
- ہر سورس سروس کے لیے مطلوبہ کم سے کم OAuth اسکوپس کو محدود رکھیں۔
- ڈی ڈپلیکیشن (deduplication) کے ساتھ حقیقی ڈیلٹا سنکرونائزیشن کا تجربہ کریں تاکہ اس بات کو یقینی بنایا جا سکے کہ ٹارگٹ میں کوئی ڈپلیکیٹ آئٹم ظاہر نہ ہو۔
- ایک پائلٹ ٹیسٹ چلائیں جو ملٹی لیبل Gmail پیغامات اور Drive کی پیچیدہ پرمیشن ہائیرارکیز کا تجربہ کرے۔
Drive ایک الگ معاملہ ہے۔ اس کا اپنا بجٹ اور ٹائم لائن ہے۔