ਜੇਕਰ ਤੁਸੀਂ "ਤੇਜ਼ੀ" ਨਾਲ ਕਲਾਉਡ-ਈਮੇਲ ਮੂਵਮੈਂਟ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਜਾਲ ਇੱਕ ਯੋਜਨਾਬੱਧ ਰੁਕਾਵਟ (outage) ਨੂੰ ਇੱਕ ਮਹਿੰਗੇ ਅਤੇ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਵਾਲੇ ਹਾਦਸੇ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।

ਮਾਈਗ੍ਰੇਸ਼ਨ ਇੱਕ ਸਿੰਗਲ ਕਾਪੀ ਜੌਬ ਤੋਂ ਕਿਤੇ ਵੱਧ ਕਿਉਂ ਹੈ

Google ਤੋਂ Microsoft ਤੱਕ ਡਾਟਾ ਲਿਜਾਣਾ ਕੋਈ ਇੱਕ ਸਿੰਗਲ, ਵੱਡੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ। ਹਰੇਕ ਸੇਵਾ—mail, calendar, contacts, Drive, Vault, Chat, Groups—ਜਾਣਕਾਰੀ ਨੂੰ ਆਪਣੇ ਖਾਸ ਫਾਰਮੈਟ ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਜਿਸ ਲਈ ਵੱਖਰੇ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਲੌਜਿਕ ਅਤੇ ਟਾਰਗੇਟ ਮੈਪਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਅਜਿਹਾ ਟੂਲ ਜੋ Gmail ਮੈਸੇਜਾਂ ਦੀ ਕਾਪੀ ਕਰਨ ਵਿੱਚ ਮਾਹਰ ਹੈ, ਉਹ Drive ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ, Vault ਆਰਕਾਈਵਸ ਨੂੰ ਡ੍ਰੌਪ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ Chat ਹਿਸਟਰੀ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਹਰ ਉਸ ਵਰਕਲੋਡ (workload) ਦੀ ਪੂਰੀ ਇਨਵੈਂਟਰੀ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮੂਵ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਸਸਪੈਂਡ ਕੀਤੇ ਗਏ ਅਕਾਊਂਟਸ ਵਰਗੇ ਕੇਸ ਵੀ ਸ਼ਾਮਲ ਹਨ।

ਅਥੈਂਟੀਕੇਸ਼ਨ (Authentication) ਦਾ ਜਾਲ

ਸਾਧਾਰਨ ਯੂਜ਼ਰਨੇਮ ਅਤੇ ਪਾਸਵਰਡ ਸੁਰੱਖਿਆ ਲਈ ਖਤਰਾ ਹਨ ਅਤੇ ਆਧੁਨਿਕ APIs ਨਾਲ ਲਗਭਗ ਹਮੇਸ਼ਾ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ। Google 'ਤੇ ਤੁਹਾਨੂੰ ਡੋਮੇਨ-ਵਾਈਡ ਡੈਲੀਗੇਸ਼ਨ ਵਾਲੇ ਇੱਕ ਸਰਵਿਸ ਅਕਾਊਂਟ ਅਤੇ OAuth ਪਰਮਿਸ਼ਨਾਂ ਦੇ ਇੱਕ ਸਖ਼ਤ ਸਕੋਪ (scope) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਬਹੁਤ ਘੱਟ ਸਕੋਪ ਡਾਟਾ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਦਿੰਦੇ ਹਨ; ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਕੋਪ ਦੁਰਵਰਤੋਂ ਲਈ ਰਸਤਾ ਖੋਲ੍ਹ ਦਿੰਦੇ ਹਨ। Microsoft 'ਤੇ, ਬੇਸਿਕ ਅਥੈਂਟੀਕੇਸ਼ਨ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ; ਹੁਣ ਸਿਰਫ਼ OAuth 2.0 ਕੰਮ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਯੂਟੀਲਿਟੀ ਨੂੰ ਛੱਡ ਦਿਓ ਜੋ ਅਜੇ ਵੀ ਬੇਸਿਕ ਅਥੈਂਟੀਕੇਸ਼ਨ ਦਾ ਪ੍ਰਚਾਰ ਕਰ ਰਹੀ ਹੈ।

ਲੇਬਲਸ (Labels) ਬਨਾਮ ਫੋਲਡਰਸ (Folders)

Gmail ਦਾ ਲੇਬਲ ਸਿਸਟਮ ਇੱਕ ਸਿੰਗਲ ਮੈਸੇਜ ਨੂੰ ਕਈ ਟੈਗਸ ਦੇ ਅਧੀਨ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ Outlook ਹਰੇਕ ਮੈਸੇਜ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਫੋਲਡਰ ਵਿੱਚ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਮਲਟੀ-ਲੇਬਲ ਈਮੇਲ ਦੀ ਕਾਪੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਇੰਜਣ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:

  • ਮੈਸੇਜ ਨੂੰ ਹਰੇਕ ਟਾਰਗੇਟ ਫੋਲਡਰ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਕਰਨਾ (ਸਟੋਰੇਜ ਵਧਾਉਣਾ ਅਤੇ ਡੁਪਲੀਕੇਟ ਥ੍ਰੈਡਸ ਬਣਾਉਣਾ)।
  • ਇਸਨੂੰ ਇੱਕ ਸਿੰਗਲ ਫੋਲਡਰ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ ਵਾਧੂ ਲੇਬਲਸ ਨੂੰ ਹਟਾ ਦੇਣਾ (ਸੰਗਠਨ ਦਾ ਨੁਕਸਾਨ)।
  • ਇੱਕ ਡੂੰਘਾ ਫੋਲਡਰ ਪਾਥ ਬਣਾਉਣਾ ਜੋ ਲੇਬਲ ਟ੍ਰੀ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ (ਅਕਸਰ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਉਲਝਣ ਵਾਲਾ)।

ਇੱਕ ਭਰੋਸੇਯੋਗ ਟੂਲ ਤੁਹਾਨੂੰ ਚੋਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ; ਇੱਕ ਮਾੜਾ ਟੂਲ ਅਜਿਹਾ ਡਿਫੌਲਟ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਨਾਲ ਮੇਲ ਨਾ ਖਾਵੇ।

ਥ੍ਰੌਟਲਿੰਗ (Throttling) ਅਸਲ ਰੁਕਾਵਟ ਹੈ

ਸਪੀਡ ਟੈਸਟ ਜੋ ਸਿਰਫ਼ ਬੈਂਡਵਿਡਥ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ, ਉਹ ਇਸ ਤੱਥ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿੰਦੇ ਹਨ ਕਿ Microsoft ਦੀ Graph API ਪ੍ਰਤੀ-ਸਕਿੰਟ ਰਿਕਵੈਸਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਾਲਾਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਦੇ ਹੋ, ਤਾਂ Microsoft ਤੁਹਾਨੂੰ ਬਲਾਕ ਕਰ ਦੇਵੇਗਾ। ਅਜਿਹੀਆਂ ਯੂਟੀਲਿਟੀਜ਼ ਲੱਭੋ ਜੋ ਆਟੋਮੈਟਿਕ ਥ੍ਰੌਟਲ ਮੈਨੇਜਮੈਂਟ — ਲੋੜ ਅਨੁਸਾਰ ਰੁਕਣਾ, ਪਿੱਛੇ ਹਟਣਾ ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ — ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਇਹ ਮੰਨ ਕੇ ਚੱਲੋ ਕਿ ਤੇਜ਼ ਇੰਟਰਨੈਟ ਕਨੈਕਸ਼ਨ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਦੇਵੇਗਾ।

ਇਨਕਰੀਮੈਂਟਲ (delta) ਕੱਟਓਵਰ, ਨਾ ਕਿ ਸ਼ੁੱਕਰਵਾਰ ਰਾਤ ਦਾ ਡੰਪ

ਪੂਰੇ ਟੈਨੈਂਟ ਨੂੰ ਇੱਕੋ ਵੀਕੈਂਡ ਵਿੱਚ ਮੂਵ ਕਰਨਾ ਡਾਊਨਟਾਈਮ ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪੜਾਅਵਾਰ ਪਹੁੰਚ ਬਿਹਤਰ ਕੰਮ ਕਰਦੀ ਹੈ:

  1. Bulk load – ਅੰਤਿਮ ਬਦਲਾਅ ਤੋਂ ਕਈ ਦਿਨ ਜਾਂ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਜ਼ਿਆਦਾਤਰ ਮੇਲ, ਫਾਈਲਾਂ ਅਤੇ ਹੋਰ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ।
  2. Delta sync – ਕੱਟਓਵਰ ਵਿੰਡੋ ਦੌਰਾਨ, ਇੱਕ ਇਨਕਰੀਮੈਂਟਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਓ ਜੋ ਸਿਰਫ਼ ਨਵੀਆਂ ਜਾਂ ਬਦਲੀਆਂ ਹੋਈਆਂ ਆਈਟਮਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ।
  3. MX record flip – ਜਦੋਂ ਡੈਲਟਾ ਸਿੰਕ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਦੇਵੇ ਕਿ ਕੋਈ ਵੀ ਪੈਂਡਿੰਗ ਆਈਟਮ ਨਹੀਂ ਹੈ, ਤਾਂ ਮੇਲ ਐਕਸਚੇਂਜ ਰਿਕਾਰਡ ਨੂੰ Microsoft 365 ਵੱਲ ਮੋੜ ਦਿਓ।

ਇਹ ਵਿਧੀ ਡਾਊਨਟਾਈਮ ਨੂੰ ਘੰਟਿਆਂ ਤੋਂ ਘਟਾ ਕੇ ਮਿੰਟਾਂ ਵਿੱਚ ਲਿਆ ਆਉਂਦੀ ਹੈ।

ਸਫਲ ਮੂਵਮੈਂਟ ਲਈ ਚੈੱਕਲਿਸਟ

  • ਹਰੇਕ ਵਰਕਲੋਡ ਦੀ ਕੈਟਾਲੌਗ ਬਣਾਓ (Mail, Drive, Vault, Chat, Groups, ਆਦਿ)।
  • ਗੁੰਝਲਦਾਰ ਆਬਜੈਕਟਸ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ ਕਿ ਸਸਪੈਂਡ ਕੀਤੇ ਗਏ ਅਕਾਊਂਟਸ।
  • ਕਿਸੇ ਵੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲ ਦੀ ਤਕਨੀਕੀ ਦਸਤਾਵੇਜ਼ੀ ਵਿੱਚ ਸਪੋਰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ — ਸਿਰਫ਼ ਮਾਰਕੀਟਿੰਗ ਪੇਜ 'ਤੇ ਨਹੀਂ।
  • OAuth ਸਕੋਪਸ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਰੱਖੋ ਜੋ ਹਰੇਕ ਸਰੋਤ ਸੇਵਾ ਲਈ ਲੋੜੀਂਦੇ ਹਨ।
  • ਡਿਡੂਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਅਸਲ ਡੈਲਟਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ ਟਾਰਗੇਟ ਵਿੱਚ ਕੋਈ ਡੁਪਲੀਕੇਟ ਆਈਟਮ ਨਾ ਆਵੇ।
  • ਇੱਕ ਪਾਇਲਟ ਚਲਾਓ ਜੋ ਮਲਟੀ-ਲੇਬਲ Gmail ਮੈਸੇਜਾਂ ਅਤੇ Drive ਦੀਆਂ ਗੁੰਝਲਦਾਰ ਪਰਮਿਸ਼ਨ ਹਾਇਰਾਰਕੀਜ਼ ਦੀ ਜਾਂਚ ਕਰੇ।

Drive ਇੱਕ ਵੱਖਰੀ ਚੀਜ਼ ਹੈ। ਇਸਦਾ ਆਪਣਾ ਬਜਟ ਅਤੇ ਸਮਾਂ-ਸੀਮਾ ਹੈ।