நீங்கள் ஒரு "விரைவான" கிளவுட்-மின்னஞ்சல் மாற்றத்தை நம்பியிருந்தால், அந்தத் தடைகள் திட்டமிடப்பட்ட ஒரு சேவை இடைவெளியை (outage), செலவு மிகுந்ததாகவும், நற்பெயருக்குக் களங்கம் விளைவிக்கும் ஒரு பேரழிவாகவும் மாற்றக்கூடும்.

ஏன் இந்த இடமாற்றம் என்பது ஒரு சாதாரண நகல் எடுக்கும் பணி மட்டுமல்ல

Google-லிருந்து Microsoft-க்கு தரவை நகர்த்துவது என்பது ஒரே நேரத்தில் செய்யப்படும் ஒரு பெரிய செயல்பாடு அல்ல. ஒவ்வொரு சேவையும்—mail, calendar, contacts, Drive, Vault, Chat, Groups—தகவல்களைத் தமக்கென ஒரு தனித்துவமான வடிவமைப்பில் சேமித்து வைக்கின்றன; எனவே ஒவ்வொன்றிற்கும் தனித்தனி பிரித்தெடுக்கும் தர்க்கமும் (extraction logic) மற்றும் இலக்கு மேப்பிங்கும் (target mapping) தேவைப்படும். Gmail செய்திகளை நகல் எடுப்பதில் சிறந்து விளங்கும் ஒரு கருவி, Drive அனுமதிகளைத் தவிர்க்கலாம், Vault ஆவணங்களை (archives) விடுபடச் செய்யலாம் அல்லது Chat வரலாற்றைப் புறக்கணிக்கலாம். இடைநிறுத்தப்பட்ட கணக்குகள் (suspended accounts) போன்ற விதிவிலக்கான சூழல்களையும் (edge cases) சேர்த்து, நீங்கள் மாற்ற விரும்பும் ஒவ்வொரு பணிப்பகுதியையும் (workload) முழுமையாகப் பட்டியலிட்டுத் தொடங்குங்கள்.

அங்கீகாரச் சிக்கல் (The authentication trap)

சாதாரண பயனர் பெயர்கள் மற்றும் கடவுச்சொற்கள் ஒரு பாதுகாப்பு அபாயமாகும், மேலும் நவீன API-களுடன் அவை பெரும்பாலும் தோல்வியடையும். Google-இல், உங்களுக்கு domain-wide delegation வசதியுடன் கூடிய ஒரு service account மற்றும் மிகக் குறுகிய வரம்பிற்குட்பட்ட (tightly scoped) OAuth அனுமதிகள் தேவைப்படும். மிகக் குறைவான வரம்புகள் (scopes) தரவை விட்டுவிடும்; மிக அதிகமான வரம்புகள் தவறான பயன்பாட்டிற்கான வாய்ப்பைத் திறக்கும். Microsoft-இல், basic authentication நீக்கப்பட்டுவிட்டது; OAuth 2.0 மட்டுமே செயல்படும். இன்னும் basic auth-ஐ விளம்பரப்படுத்தும் எந்தவொரு இடமாற்றக் கருவியையும் தவிர்த்துவிடுங்கள்.

லேபிள்கள் (Labels) மற்றும் கோப்புறைகள் (Folders) இடையிலான வேறுபாடு

Gmail-இன் லேபிள் அமைப்பு ஒரு செய்தியைப் பல டேக்குகளின் (tags) கீழ் வைத்திருக்க அனுமதிக்கிறது, ஆனால் Outlook ஒவ்வொரு செய்தியையும் ஒரு தனி கோப்புறைக்குள் (folder) வைக்கக் கட்டாயப்படுத்துகிறது. பல லேபிள்கள் கொண்ட ஒரு மின்னஞ்சல் நகலெடுக்கப்படும்போது, இடமாற்ற இயந்திரம் (migration engine) பின்வருவனவற்றைச் செய்யலாம்:

  • செய்தியை ஒவ்வொரு இலக்கு கோப்புறைக்கும் நகலெடுக்கலாம் (இது சேமிப்பகத்தை அதிகப்படுத்துவதோடு, நகல் உரையாடல்களையும் உருவாக்கும்).
  • அதை ஒரு கோப்புறைக்குள் மட்டும் வைத்துவிட்டு, கூடுதல் லேபிள்களை நீக்கிவிடலாம் (இதனால் ஒழுங்கமைப்புத் தன்மை குறையும்).
  • லேபிள் மரத்தைப் போன்ற ஒரு ஆழமான கோப்புறைப் பாதையை உருவாக்கலாம் (இது பயனர்களுக்குக் குழப்பத்தை ஏற்படுத்தும்).

ஒரு நம்பகமான கருவி உங்களுக்குத் தேர்ந்தெடுக்கும் வாய்ப்பை வழங்கும்; ஆனால் தரம் குறைந்த கருவி, உங்கள் பணிப்பாய்விற்கு (workflow) பொருந்தாத ஒரு இயல்புநிலைத் தேர்வை (default) திணிக்கக்கூடும்.

Throttling தான் உண்மையானத் தடை

வெறும் இணைய வேகத்தை (bandwidth) மட்டும் கவனிக்கும் வேகச் சோதனைகள், Microsoft-இன் Graph API வினாடிக்கு ஒரு குறிப்பிட்ட அளவு கோரிக்கைகளை மட்டுமே அனுமதிக்கும் (request-per-second limits) என்ற உண்மையை கவனிக்கத் தவறிவிடுகின்றன. மிக வேகமாகவும் அதிகப்படியாகவும் கோரிக்கைகளை அனுப்பினால், Microsoft உங்களைத் தடுக்கும். வேகமான இணைய இணைப்பு மட்டுமே இந்தப் பிரச்சினையைத் தீர்க்கும் என்று நம்புவதற்குப் பதிலாக, தேவைக்கேற்ப நிறுத்துதல் (pausing), தள்ளிப்போடுதல் (backing off) மற்றும் மீண்டும் தொடங்குதல் (resuming) போன்ற தானியங்கித் தணிக்கை மேலாண்மையை (automatic throttle management) செயல்படுத்தும் கருவிகளைத் தேடுங்கள்.

வெள்ளிக்கிழமை இரவு மொத்தமாக நகலெடுக்காமல், படிப்படியான (delta) மாற்றத்தைச் செய்யுங்கள்

ஒரு வார இறுதித் திட்டத்தில் முழுத் टेनன்ட்டையும் (tenant) நகர்த்துவது, சேவைத் தடங்கலை (downtime) உறுதி செய்துவிடும். அதற்குப் பதிலாகப் படிநிலையான அணுகுமுறை சிறப்பாகச் செயல்படும்:

  1. Bulk load – இறுதி மாற்றத்திற்குப் பல நாட்களுக்கு அல்லது வாரங்களுக்கு முன்பே மின்னஞ்சல்கள், கோப்புகள் மற்றும் பிற தரவுகளின் பெரும்பகுதியை மாற்றவும்.
  2. Delta sync – மாற்றத்தின் போது, புதிய அல்லது மாற்றப்பட்ட உருப்படிகளை மட்டும் எடுக்கும் ஒரு படிப்படியான இடமாற்றத்தை (incremental migration) இயக்கவும்.
  3. MX record flip – எந்தத் தரவும் நிலுவையில் இல்லை என்பதை delta sync உறுதி செய்தவுடன், மின்னஞ்சல் பரிமாற்றப் பதிவை (mail exchange record) Microsoft 365-க்கு மாற்றவும்.

இந்த முறை சேவைத் தடங்கலை மணிக்கணக்கிலிருந்து நிமிடங்களாகக் குறைக்கிறது.

வெற்றிகரமான மாற்றத்திற்கான சரிபார்ப்புப் பட்டியல் (Checklist)

  • ஒவ்வொரு பணிப்பகுதியையும் பட்டியலிடுங்கள் (Mail, Drive, Vault, Chat, Groups, போன்றவை).
  • சிக்கலான உருப்படிகளையும் சேர்த்துக் கொள்ளுங்கள், உதாரணமாக இடைநிறுத்தப்பட்ட கணக்குகள்.
  • எந்தவொரு இடமாற்றக் கருவியின் தொழில்நுட்ப ஆவணங்களிலும் அதன் ஆதரவைச் சரிபார்க்கவும்—விளம்பரப் பக்கங்களை மட்டும் நம்ப வேண்டாம்.
  • ஒவ்வொரு மூலச் சேவைக்கும் (source service) தேவையான குறைந்தபட்ச OAuth வரம்புகளை (scopes) மட்டும் நிர்ணயிக்கவும்.
  • இலக்கில் நகல் உருப்படிகள் வராதிருப்பதை உறுதி செய்ய, deduplication வசதியுடன் கூடிய உண்மையான delta synchronization-ஐச் சோதிக்கவும்.
  • பல லேபிள்கள் கொண்ட Gmail செய்திகள் மற்றும் சிக்கலான Drive அனுமதி படிநிலைகளைச் சோதிக்கும் வகையில் ஒரு முன்னோடித் திட்டத்தை (pilot) நடத்துங்கள்.

Drive என்பது முற்றிலும் மாறுபட்ட ஒன்று. அதற்குத் தனிப்பட்ட பட்ஜெட்டும் காலக்கெடுவும் உண்டு.