एक जटिल डेटा माइग्रेशन के लिए सुझाया गया वर्कफ़्लो

यह आलेख डेटा की बड़ी मात्रा को माइग्रेट करने के लिए एक चरण-दर-चरण प्रक्रिया का सुझाव देता है। एक शक्तिशाली क्लाउड-आधारित सीआरएम से डेटा स्थानांतरित करते समय, इसके जटिल सेटअप के कारण सावधानीपूर्वक योजना बनाना महत्वपूर्ण है - जैसे कस्टम ऑब्जेक्ट, डेटा के बीच लिंक और अद्वितीय रिकॉर्ड आईडी। आपको तकनीकी चरणों और व्यवहार में माइग्रेशन कैसे काम करता है, दोनों के बारे में सोचने की जरूरत है।

  • तकनीकी दृष्टिकोण: प्रमुख माइग्रेशन चरणों को कवर करता है - डेटा निकालना, रूपांतरित करना और डेटावर्स में लोड करना - अखंडता सुनिश्चित करते हुए, संबंधों को संरक्षित करना, और सत्यापन और त्रुटि प्रबंधन के माध्यम से प्रदर्शन को अनुकूलित करना।
  • कार्यात्मक दृष्टिकोण: डेटा विभाजन और संग्रह जैसे कार्यात्मक माइग्रेशन कार्यों को कवर करता है, और यह सुनिश्चित करने के लिए व्यावसायिक हितधारकों को शामिल करने की आवश्यकता पर प्रकाश डालता है कि डेटा उनकी आवश्यकताओं को पूरा करता है।

डेटा माइग्रेशन के लिए तकनीकी दृष्टिकोण

एक संरचित दृष्टिकोण का पालन करके एक सहज माइग्रेशन सुनिश्चित करें - अखंडता को संरक्षित करते हुए और व्यवधान को कम करते हुए डेटा निकालें, बदलें और लोड करें।

चरणों के रूप में छह परस्पर जुड़े वृत्तों के साथ डेटा माइग्रेशन वर्कफ़्लो को दर्शाने वाला आरेख।

स्रोत से स्टेजिंग डेटाबेस में डेटा निकालें

जटिल डेटा माइग्रेशन के लिए, हम एक अलग डेटाबेस (उदाहरण के लिए, SQL सर्वर) में डेटा स्टेजिंग की अनुशंसा करते हैं। यह स्टेजिंग क्षेत्र चल रहे व्यावसायिक संचालन को बाधित किए बिना स्रोत प्रणाली का एक स्नैपशॉट कैप्चर करता है।

मुख्य विचार:

  • पूर्ण बनाम डेल्टा लोड: डेटा को पूर्ण या वृद्धिशील (डेल्टा) लोड के रूप में व्यवस्थित करें। डेटा आगमन को ट्रैक करने और भविष्य के लोड के लिए परिवर्तनों की पहचान करने के लिए ऑटोजेनरेटेड टाइमस्टैम्प का उपयोग करें।
  • विफलता हैंडलिंग: माइग्रेशन को रोकने के बिना विफल रिकॉर्ड (उदाहरण के लिए, फ़ील्ड की लंबाई, अमान्य लुकअप के कारण) को छोड़ने के लिए प्रक्रिया डिज़ाइन करें। लॉग इन करें और पुन: प्रसंस्करण से पहले समस्याओं को हल करें।
  • फ़ील्ड मैपिंग: दक्षता में सुधार के लिए डेटा को Dataverse में माइग्रेट करने से पहले स्टेजिंग लेयर और स्टेजिंग डेटाबेस में मान श्रेणियों में लक्ष्य प्रारूपों से मेल खाने के लिए स्रोत मानों को कनवर्ट करें.
  • डेटा सत्यापन: लापता संदर्भों जैसी समस्याओं को पकड़ने के लिए अखंडता जांच चलाएँ। चूंकि डेटा निष्कर्षण घंटों या दिनों तक चल सकता है, इसलिए अपूर्ण रिकॉर्ड को फ़िल्टर करने और स्थिरता सुनिश्चित करने के लिए स्टेजिंग परत का उपयोग करें।
  • डेटा विज़ुअलाइज़ेशन: डेटा का ऑडिट और विश्लेषण करने के लिए स्टेजिंग डेटाबेस का उपयोग करें—उदाहरण के लिए, रिकॉर्ड की गणना करें या वित्तीय फ़ील्ड का योग करें—अंतिम माइग्रेशन से पहले।

डेटा को लक्ष्य स्टेजिंग डेटाबेस में बदलें

स्रोत सिस्टम से डेटा निकालने के बाद, इसे एक लक्ष्य स्टेजिंग डेटाबेस में बदलें जो Dataverse स्कीमा को प्रतिबिंबित करता है और जिसमें सीधे सम्मिलित करने या अपडेट करने के लिए तैयार मान होते हैं।

प्रमुख परिवर्तन चरण:

  • फ़ील्ड मैपिंग: Dataverse स्तंभों को लक्षित करने के लिए स्रोत स्तंभों को मैप करें. जहां आवश्यक हो, तालिकाओं में शामिल होने और मर्ज करने के लिए स्क्रिप्ट का उपयोग करें।

  • ऑप्शनसेट रूपांतरण: मैपिंग तालिका (उदाहरण के लिए, OptionSetMapping) और बल्क अद्यतन क्वेरीज़ का उपयोग करके पाठ-आधारित विकल्पसेट मानों को Dataverse पूर्णांकों में कनवर्ट करें. स्रोत से लक्ष्य सिस्टम में विकल्प सेट मानों के परिवर्तन को मानकीकृत और स्वचालित करने के लिए एक तालिका बनाएं।

    तालिका: OptionSetMapping

    स्तंभ का नाम डेटा प्रकार
    स्रोत तालिका का नाम स्ट्रिंग
    लक्ष्य तालिका का नाम स्ट्रिंग
    स्रोत पाठ स्ट्रिंग
    लक्ष्य पाठ स्ट्रिंग
    लक्ष्य मूल्य स्ट्रिंग

    OptionSetMapping तालिका का उपयोग कुशलतापूर्वक परिवर्तित करने और बल्क में विकल्प सेट मानों को अद्यतन करने के लिए। उदाहरण के लिए, मेल खाने वाले पाठ मानों के आधार पर संपर्क तालिका में सभी विकल्पसेट मानों को अद्यतन करने के लिए:

    Update C.\<OptionsetValue\> = M.\<TargetValue\> 
FROM Contact C 
JOIN OptionsetMapping M 
  ON C.OptionsetText = M.TargetText 
  AND M.TargetTableName = 'Contact'

  • कस्टम GUID से बचें: Dataverse को विखंडन और प्रदर्शन समस्याओं को रोकने के लिए GUIDs उत्पन्न करने दें।

  • स्ट्रिंग लंबाई की जांच: सुनिश्चित करें कि स्ट्रिंग मान Dataverse सीमाओं के अनुरूप हों। आवश्यकतानुसार ट्रिम या समायोजित करें।

  • परिकलित फ़ील्ड: व्युत्पन्न फ़ील्ड जोड़ें (उदाहरण के लिए, लुकअप के लिए नाम) यदि स्रोत में अनुपलब्ध है।

  • अन्य विचार: Dataverse स्कीमा से मेल खाने के लिए टेबल डिज़ाइन करते समय, निम्नलिखित प्रमुख कॉलम और सहायक तालिकाओं पर विचार करें।

    • DataMigration_CreatedDateTime: डेटा लोड बैचों को ट्रैक करने के लिए ऑटोपॉप्युलेटेड टाइमस्टैम्प।
    • कार्रवाई ध्वज: सम्मिलित करें (i), अद्यतन (u), या हटाएँ (D) इंगित करता है।
    • प्रसंस्करण ध्वज: ट्रैक स्थिति—संसाधित (पी), असंसाधित (यू), त्रुटि (ई), या सफलता (एस)।
    • अद्वितीय स्तंभ: रिकॉर्ड मैप करने के लिए एक अद्वितीय आईडी (उदाहरण के लिए, स्रोत सिस्टम से अद्वितीय आईडी) का उपयोग करें।
    • सफलता/त्रुटि तालिकाएँ: परिणामों को लॉग करने और पुन: प्रयासों का समर्थन करने के लिए अलग-अलग तालिकाएँ (उदाहरण के लिए, Contact_Success, Contact_Error) बनाए रखें।

अनुक्रम तालिकाएँ और प्रीलोड लुकअप

स्थैतिक रूपांतरणों के बाद, चक्रीय निर्भरताओं को कम करने के लिए अपनी तालिकाओं को ऑर्डर करें—ऐसे मामले जहां तालिकाएँ एक-दूसरे को संदर्भित करती हैं, जिससे अलग-अलग आयात असंभव हो जाते हैं. इस दृष्टिकोण का उपयोग करें:

  • माइग्रेशन के लिए योग्य सभी तालिकाओं की सूची बनाएं।
  • प्रति तालिका अद्वितीय लुकअप की गणना करें (यदि माइग्रेट नहीं कर रहे हैं तो आउट-ऑफ़-द-बॉक्स फ़ील्ड Created By और अन्य तालिका लुकअप पर ध्यान न दें)।
  • तालिकाओं को लुकअप गणना के आधार पर आरोही क्रम में क्रमबद्ध करें.
  • दोनों लुकअप की गणना करते हुए, N:N संबंध तालिकाएँ शामिल करें।
  • मल्टी-टेबल लुकअप को बाहर करें (उदाहरण के लिए, "के संबंध में" फ़ील्ड).

यह दृष्टिकोण डेटा माइग्रेशन लोड के अनुक्रम को परिभाषित करता है और अधिकांश परिदृश्यों में अच्छी तरह से काम करता है। अधिक जटिल मामलों के लिए:

  • सम्मिलित करने के दौरान GUIDs उत्पन्न होने पर स्टेजिंग और Dataverse के बीच रिकॉर्ड का मिलान करने के लिए एक अद्वितीय पहचानकर्ता (उदाहरण के लिए, importsequencenumber) का उपयोग करें.
  • लॉकिंग समस्याओं से बचने और प्रदर्शन में सुधार करने के लिए सफलता और त्रुटि लॉग को अलग करें।
  • सम्मिलित करने के दौरान संदर्भों को हल करने के लिए पहले से ही माइग्रेट की गई तालिकाओं से लुकअप GUIDs प्रीलोड करें।
  • चक्रीय निर्भरताओं को संभालें:
    • आश्रित लुकअप के बिना रिकॉर्ड सम्मिलित करना.
    • संबंधित रिकॉर्ड लोड होने के बाद उन लुकअप का अद्यतन करना.

Dataverse में डेटा लोड करें

अगला कदम डेटावर्स में डेटा लोड करने के लिए अपने दृष्टिकोण को निर्धारित करना और लागू करना है।

  1. टूलींग: डेटा आकार और जटिलता के आधार पर एक टूल का चयन करें:

    • SDK कॉन्फ़िगरेशन माइग्रेशन टूल
    • Azure डेटा फ़ैक्‍टरी
    • किंग्सवेसॉफ्ट
    • लिपिक
    • XrmToolBox का डेटा ट्रांसपोर्टर

  2. मुख्य विचार (उपकरण-अज्ञेयवादी):

    • चक्रीय निर्भरताओं को संभालें: वृत्ताकार लुकअप को कम करने के लिए अनुक्रम तालिका लोड। आश्रित लुकअप के बिना रिकॉर्ड सम्मिलित करें, फिर उन्हें बाद में अपडेट करें।

    • रिकॉर्ड आईडी ट्रैक करें: सफलता तालिका में Dataverse GUIDs कैप्चर करें, फिर एक अद्वितीय पहचानकर्ता (उदाहरण के लिए, importsequencenumber) का उपयोग करके मुख्य तालिका को अपडेट करें।

    • बैच आकार और थ्रेड्स की संख्या अनुकूलित करें: बल्क ऑपरेशन के लिए प्रदर्शन को अनुकूलित करने के लिए मार्गदर्शन की समीक्षा करें। आपके द्वारा उपयोग किए जाने वाले एप्लिकेशन को सेवा सुरक्षा त्रुटियों को प्रबंधित करना चाहिए जो तब होती हैं जब असाधारण संख्या में अनुरोध Dataverse को भेजे जाते हैं। यदि आप अपना स्वयं का कोड लिखते हैं और Dataverse Web API का उपयोग करते हैं, तो सुनिश्चित करें कि आपने सेवा सुरक्षा API सीमाओं में वर्णित 429 त्रुटियों का पुनः प्रयास करें. यदि आप Dataverse SDK का उपयोग करते हैं, तो यह आपके लिए इन त्रुटियों को प्रबंधित करता है।

      इष्टतम प्रदर्शन प्राप्त करने के लिए, तालिका जटिलता के आधार पर बैच आकार और थ्रेड गणना ट्यून करें:

      • आउट-ऑफ़-द-बॉक्स (OOB) टेबल (उदाहरण के लिए, संपर्क, खाता, लीड): बिल्ट-इन प्लगइन्स और नौकरियों के कारण ये टेबल धीमी हैं। अनुशंसित: बैच का आकार 200-300, 30 थ्रेड्स तक (यदि ≤10 लुकअप और 50-70 कॉलम)।
      • साधारण टेबल (कुछ या कोई लुकअप): अनुशंसित: बैच का आकार ≤10, 50 थ्रेड्स तक।
      • मध्यम रूप से जटिल कस्टम टेबल (कुछ लुकअप): अनुशंसित: बैच का आकार ≤100, 30 थ्रेड तक.
      • बड़ी/जटिल टेबल (>100 कॉलम, >20 लुकअप): अनुशंसित: गड़बड़ी कम करने के लिए बैच का आकार 10-20, 10-20 थ्रेड्स तक.

  3. इन्फ्रास्ट्रक्चर टिप्स: डेटा माइग्रेशन प्रदर्शन को अधिकतम करने के लिए, अपने माइग्रेशन को उसी क्षेत्र में स्थित वर्चुअल मशीन (VM) से चलाएं जहां आपका Dataverse परिवेश है. यह दृष्टिकोण विलंबता को काफी कम करता है और पूरी प्रक्रिया को गति देता है। अपने Dataverse परिवेश के क्षेत्र को निर्धारित करने का तरीका जानें.

  4. त्रुटि प्रबंधन: त्रुटियों को अनदेखा न करें—व्यापक विफलताओं को रोकने के लिए उन्हें हल करें। प्लेसहोल्डर रिकॉर्ड सम्मिलित करने और GUIDs कैप्चर करने के लिए डिफ़ॉल्ट (उदाहरण के लिए, रिक्त लुकअप, डिफ़ॉल्ट विकल्पसेट मान) का उपयोग करें.

  5. स्थिति अद्यतन: केवल प्रारंभिक रिकॉर्ड सम्मिलन के दौरान सक्रिय स्थिति सेट करें। निष्क्रिय रिकॉर्ड या कस्टम स्थिति/स्थिति कोड के लिए, डेटा सत्यापन के बाद उन्हें अद्यतन करें. अधिकांश कस्टम तालिकाओं के लिए, स्थिति अद्यतन सम्मिलित करने के तुरंत बाद अनुसरण कर सकते हैं। हालाँकि, मामला, अवसर या लीड जैसी विशेष तालिकाओं के लिए, माइग्रेशन के अंत तक स्थिति अपडेट में देरी करें। एक बार जब ये रिकॉर्ड बंद हो जाते हैं, तो उन्हें तब तक संशोधित नहीं किया जा सकता है जब तक कि उन्हें फिर से नहीं खोला जाता है - एक समय लेने वाली प्रक्रिया जो डेटा अखंडता को जोखिम में डालती है।

  6. स्वामित्व और सुरक्षा: डेटा प्रविष्टि के दौरान सही रिकॉर्ड स्वामी सेट करें, क्योंकि Dataverse में उपयोगकर्ता-स्तर और व्यवसाय इकाई सुरक्षा दोनों मालिक की व्यवसाय इकाई से जुड़े होते हैं. निर्माण के समय सही व्यवसाय इकाई असाइन करें—बाद में इसे अपडेट करने से सभी सुरक्षा भूमिकाएँ निकल जाती हैं.

    • स्टब उपयोगकर्ताओं का उपयोग करें:
      • Dataverse स्टब उपयोगकर्ताओं (गैर-लाइसेंस) का समर्थन करता है, जो बड़े या ऐतिहासिक माइग्रेशन के लिए उपयोगी हैं। स्टब उपयोगकर्ताओं को स्वचालित रूप से विक्रेता सुरक्षा भूमिका असाइन की जाती है—इस भूमिका का नाम न बदलें या संशोधित न करें. स्टब उपयोगकर्ता रिकॉर्ड के मालिक हो सकते हैं यदि उनके पास प्रासंगिक तालिकाओं तक उपयोगकर्ता-स्तरीय पठन पहुंच है।
    • सिफारिशें:
      • माइग्रेशन के दौरान सम्मिलित करने के समय पर सही व्यवसाय इकाई सेट के साथ सभी गैर-लायसेंसधारी उपयोगकर्ता बनाएँ.
      • निर्माण के बाद व्यवसाय इकाई को न बदलें—ऐसा करने से विक्रेता सहित सभी भूमिकाएँ निकल जाती हैं.
      • सुनिश्चित करें कि विक्रेता भूमिका के पास सभी माइग्रेशन-योग्य तालिकाओं तक पठन पहुँच है.
      • यहां तक कि इस भूमिका के साथ Dataverse वातावरण में अक्षम किए गए उपयोगकर्ता भी रिकॉर्ड के मालिक हो सकते हैं।

  7. मुद्रा प्रबंधन: पूर्व-सत्यापन प्लगइन का उपयोग करके सम्मिलित करने के दौरान विनिमय दरें निर्धारित करें, क्योंकि Dataverse ऐतिहासिक दरों का समर्थन नहीं करता है.

Dataverse में डेटा लोड पोस्ट करें

Dataverse में डेटा लोड करने के बाद, डेटा अखंडता सुनिश्चित करने और डाउनस्ट्रीम समस्याओं को कम करने के लिए इन चरणों का पालन करें:

  1. GUIDs के साथ मुख्य तालिका अपडेट करें:

    • एक सफल लोड के बाद, Dataverse रिकॉर्ड GUIDs को सफलता तालिका से मुख्य तालिका में एक अद्वितीय पहचानकर्ता का उपयोग करके कॉपी करें, जैसे .importsequencenumber
    • रिकॉर्ड को इस रूप में चिह्नित करने के लिए संसाधन ध्वज का अद्यतन करें:
      • पी - संसाधित
      • ई - त्रुटि
      • यू - असंसाधित यह रणनीति पहले से संसाधित रिकॉर्ड को छोड़कर कुशल पुन: प्रसारण को सक्षम बनाती है और बाद के लोड में लुकअप रिज़ॉल्यूशन का समर्थन करती है।

  2. विफल रिकॉर्ड का पुनः प्रयास करें: पुन: कार्य को कम करने और संदर्भात्मक अखंडता बनाए रखने के लिए, इन कार्रवाइयों पर विचार करें:

    • स्ट्रिंग मान ट्रिम करें यदि वे अनुमत लंबाई से अधिक हैं।
    • मैपिंग अनुपलब्ध होने पर डिफ़ॉल्ट विकल्पसेट मान लागू करें।
    • यदि मूल स्वामी उपलब्ध नहीं है (यहां तक कि एक स्टब उपयोगकर्ता के रूप में भी) तो फ़ॉलबैक स्वामी असाइन करें.
    • अनसुलझे लुकअप के लिए रिक्त या डिफ़ॉल्ट मानों का उपयोग करें।
    • यहां तक कि प्लेसहोल्डर रिकॉर्ड भी संबंधित तालिकाओं में लुकअप के लिए आवश्यक GUIDs जनरेट करने में मदद कर सकते हैं।

डेटा माइग्रेशन के लिए लोचदार तालिकाओं का उपयोग करना

लोचदार तालिकाओं को वास्तविक समय में बड़ी मात्रा में डेटा को संभालने के लिए डिज़ाइन किया गया है। इलास्टिक टेबल के साथ, आप स्केलेबिलिटी, विलंबता या प्रदर्शन समस्याओं के बिना बड़ी मात्रा में डेटा आयात, संग्रहीत और विश्लेषण कर सकते हैं।

लोचदार तालिकाएँ लचीली स्कीमा, क्षैतिज स्केलिंग और एक विशिष्ट समय अवधि के बाद डेटा को स्वचालित रूप से हटाने के लिए अद्वितीय क्षमताएं प्रदान करती हैं।

लोचदार तालिकाओं को Azure Cosmos DB में संग्रहीत किया जाता है और समर्थन करता है:

  • JSON कॉलम के माध्यम से स्कीमा-रहित डेटा
  • स्वचालित क्षैतिज स्केलिंग
  • टाइम-टू-लाइव (TTL) पुराने डेटा के स्वत: हटाने के लिए
  • प्रदर्शन अनुकूलन के लिए विभाजन

लोचदार तालिकाएँ चर स्कीमा के साथ थोक आयात के लिए सबसे उपयुक्त हैं।

लोचदार तालिकाएँ विशिष्ट डेटा प्रकारों के लिए आदर्श हैं।

डेटा प्रकार विवरण
कच्चा अंतर्ग्रहण डेटा स्रोत लॉग, सेंसर फ़ीड, या विरासत प्रणालियों से थोक निर्यात। उदाहरण के लिए, ग्राहक सहभागिता लॉग किसी लीगेसी ERP, पुराने ईमेल थ्रेड्स, और पिछले सिस्टम से समर्थन टिकट।
अर्ध-संरचित रिकॉर्ड वैकल्पिक या विकसित हो रहे फ़ील्ड वाला डेटा जो किसी कठोर स्कीमा में फिट नहीं बैठता है. उदाहरण के लिए, वैकल्पिक फ़ील्ड के साथ ग्राहक प्रतिक्रिया प्रपत्र, या कस्टम नोट्स या टैग के साथ ईवेंट पंजीकरण प्रपत्र.
सत्यापन के लिए डेटा का मंचन डेटा को संबंधपरक तालिकाओं में सिंक्रनाइज़ करने से पहले एक अस्थायी होल्डिंग ज़ोन. उदाहरण के लिए, मुख्य लीड तालिका में जोड़े जाने से पहले डुप्लीकेशन और सत्यापन की प्रतीक्षा कर रहा आयात किया गया लीड डेटा.
समय-संवेदनशील या समाप्त होने वाला डेटा अस्थायी CRM रिकॉर्ड को स्वतः हटाने के लिए TTL (टाइम-टू-लाइव) का उपयोग करें. उदाहरण के लिए, किसी अभियान से जुड़े प्रचार छूट कोड, ग्राहक सर्वेक्षणों या ऑनबोर्डिंग पोर्टल के लिए एकमुश्त एक्सेस लिंक और अस्थायी सर्वेक्षण प्रतिक्रियाएं.
विभाजित बल्क डेटा प्रदर्शन और मापनीयता में सुधार करने के लिए आईडी या श्रेणी द्वारा विभाजन डेटा। उदाहरण के लिए, बल्क डेटा माइग्रेशन के दौरान खाता आईडी या क्षेत्र आईडी के आधार पर विभाजन या विश्लेषण के लिए अभियान आईडी द्वारा ग्राहक गतिविधि लॉग को विभाजित करना.

लोचदार तालिकाओं के लिए अनुपयुक्त डेटा प्रकार

लोचदार तालिकाओं को लचीले, उच्च-स्तरीय परिदृश्यों के लिए अनुकूलित किया जाता है-लेकिन हर डेटा प्रकार फिट नहीं होता है। यह खंड सामान्य सीआरएम डेटा पैटर्न पर प्रकाश डालता है जो प्रदर्शन, लागत-दक्षता और रखरखाव सुनिश्चित करने के लिए कहीं और बेहतर संग्रहीत होते हैं। उन सुविधाओं के बारे में अधिक जानें जो वर्तमान में लोचदार तालिकाओं के साथ समर्थित नहीं हैं

डेटा प्रकार कारण
अत्यधिक संबंधपरक डेटा इलास्टिक टेबल जॉइन या लुकअप का समर्थन नहीं करते हैं
व्यवसाय-महत्वपूर्ण रिकॉर्ड कोई लेन-देन अखंडता या प्लगइन समर्थन नहीं
जटिल सत्यापन की आवश्यकता वाला डेटा व्यावसायिक नियमों के साथ मानक तालिकाओं में बेहतर तरीके से संभाला जाता है

कार्यात्मक डेटा विभाजन और अभिलेखीय ढांचा

प्रभावी तकनीकी योजना में सही उपकरण और बुनियादी ढांचे का चयन करना, स्रोत और लक्ष्य डेटा वॉल्यूम को संरेखित करना और ऑडिटिंग और सुलह प्रक्रियाओं को स्थापित करना शामिल है। अग्रिम विश्लेषण की कमी के कारण कई माइग्रेशन जटिल हो जाते हैं, खासकर किस डेटा को स्थानांतरित करने की आवश्यकता है और यह कहां है। यह खंड एक सफल माइग्रेशन का समर्थन करने के लिए डेटा विश्लेषण के मूल सिद्धांतों को रेखांकित करता है।

डेटा विभाजन

डेटा सेगमेंटेशन एक CRM सिस्टम से Dataverse में माइग्रेट करने में एक महत्वपूर्ण कदम है। माइग्रेशन योजना और निष्पादन को सरल बनाने के लिए व्यावसायिक फ़ंक्शन के आधार पर डेटा तालिकाओं को व्यवस्थित करें—जैसे विक्रय, सेवा, या विपणन.

टेबल्स सेगमेंटेशन

माइग्रेशन के लिए योग्य सभी तालिकाओं को सूचीबद्ध करके प्रारंभ करें, जिन्हें व्यवसाय क्षेत्र के आधार पर समूहीकृत किया गया है (उदाहरण के लिए, बिक्री, विपणन, सेवा). तब:

  • एक्सेल या एक समान उपकरण में स्कीमा का दस्तावेजीकरण करें।
  • स्तंभ उपयोग की जाँच करने के लिए स्रोत सिस्टम में मूल क्वेरीज़ चलाएँ।
  • कम उपयोग वाले स्तंभों को ध्वजांकित करें. यदि 5% से कम रिकॉर्ड में मान हैं, तो यह तय करने के लिए व्यावसायिक हितधारकों से परामर्श करें कि उन्हें रखना है या छोड़ना है।

यह सरल विश्लेषण माइग्रेशन के दायरे को काफी कम कर सकता है। लंबे समय तक चलने वाले सीआरएम सिस्टम में, 30-40% कॉलम और 20% तक तालिकाओं को खत्म करना, प्रक्रिया को सुव्यवस्थित करना और प्रदर्शन में सुधार करना आम बात है।

कॉलम प्रासंगिकता

कुछ स्रोत सिस्टम कॉलम सीधे Dataverse पर मैप करते हैं, जबकि अन्य परिकलित फ़ील्ड बन जाते हैं। इन स्तंभों को अलग करें और यह तय करने के लिए व्यावसायिक हितधारकों से परामर्श करें कि माइग्रेशन नौकरियों की आवश्यकता है या नहीं।

उन स्तंभों पर ध्यान न दें जो केवल स्रोत सिस्टम में प्रासंगिक हैं या लक्ष्य में सार्थक नहीं हैं। इसमें कई आउट-ऑफ़-द-बॉक्स फ़ील्ड शामिल हैं जैसे द्वारा निर्मित, द्वारा संशोधित, या पंक्ति संस्करण संख्या, जब तक कि वे आपके माइग्रेशन में एक विशिष्ट उद्देश्य की पूर्ति न करें।

फ़ाइल प्रकार डेटा

यदि आपके स्रोत सिस्टम में फ़ाइल-प्रकार का डेटा शामिल है, तो इन फ़ील्ड्स को जल्दी फ़्लैग करें और एक अलग माइग्रेशन कार्यनीति की योजना बनाएं. निम्नलिखित फ़ाइल प्रकारों पर विचार करें:

  • Office दस्तावेज़ (उदाहरण के लिए, Word, Excel, PowerPoint): अधिकतम 20,000 फ़ाइलों के लिए, बहु-उपयोगकर्ता पहुँच सक्षम करने के लिए SharePoint जैसे सहयोगी प्लेटफ़ॉर्म पर माइग्रेट करें.
  • मल्टीमीडिया फ़ाइलें (उदाहरण के लिए, चित्र, वीडियो): ऐसा प्लेटफ़ॉर्म चुनें जो प्लेबैक का समर्थन करता हो। विकल्पों में SharePoint, स्ट्रीमिंग सेवाएँ या अन्य मीडिया-अनुकूल संग्रहण समाधान शामिल हैं.
  • बड़ी मात्रा या फ़ाइल आकार: यदि भंडारण लागत एक चिंता का विषय है, तो Azure ब्लॉब स्टोरेज या Dataverse में मूल फ़ाइल कॉलम का उपयोग करें, जो पर्दे के पीछे Azure Blob का उपयोग करता है।
  • मैलवेयर सुरक्षा: सुरक्षा सुनिश्चित करने के लिए माइग्रेशन से पहले मैलवेयर डिटेक्शन टूल (उदाहरण के लिए, Azure एडवांस्ड थ्रेट प्रोटेक्शन) के माध्यम से फ़ाइलें चलाएँ।

फ़ाइल प्रासंगिकता की समीक्षा करने के बाद, आप अक्सर पाते हैं कि कुल डेटा वॉल्यूम काफी कम हो जाता है - विशेष रूप से लंबे समय तक चलने वाले सीआरएम सिस्टम में - माइग्रेशन को अधिक कुशल बनाता है।

डेटा अभिलेखीय रणनीतियाँ

कुछ डेटा - जैसे पुराने ईमेल, बंद मामले, या अयोग्य लीड - महत्वपूर्ण बने हुए हैं लेकिन शायद ही कभी एक्सेस किए जाते हैं। व्यवसाय संचालन को बाधित किए बिना माइग्रेशन वॉल्यूम को कम करने के लिए, एक स्मार्ट अभिलेखीय रणनीति विकसित करें।

चरण 1: संग्रह योग्य डेटा की पहचान करें

सामान्य उम्मीदवारों में शामिल हैं:

  • तीन साल से अधिक पुराने ईमेल
  • बंद मामले
  • खोए हुए अवसर
  • अयोग्य लीड
  • मार्केटिंग ईमेल, पोस्ट और ऑडिट लॉग

उन अन्य तालिकाओं की पहचान करने के लिए अपने सिस्टम की समीक्षा करें जिन्हें आप संग्रहीत कर सकते हैं.

चरण 2: एक अभिलेखीय दृष्टिकोण चुनें

  • डेटा को स्रोत सिस्टम में रखें। लागत कम करने के लिए दूसरों को निष्क्रिय करते हुए पहुंच के लिए कुछ व्यवस्थापक लाइसेंस बनाए रखें।
  • बाहरी भंडारण पर ले जाएं। संग्रहीत रिकॉर्ड्स संग्रहीत करने के लिए स्थानीय डेटाबेस, Azure ब्लॉब संग्रहण या Azure तालिकाओं का उपयोग करें. यह दृष्टिकोण भंडारण और माइग्रेशन लागत को कम करता है लेकिन इसके लिए एक अलग माइग्रेशन रणनीति की आवश्यकता होती है।
  • एक अलग Dataverse वातावरण का उपयोग करें। यह विकल्प कम आम है, लेकिन यदि आप संग्रहीत डेटा को अलग करना चाहते हैं तो यह उपयोगी है। कटओवर योजना को सरल बनाने के लिए आप बाद में इस वातावरण को रिटायर कर सकते हैं।

Dataverse में तेज़ और विश्वसनीय डेटा माइग्रेशन सुनिश्चित करने के लिए:

  • विलंबता को कम करने और माइग्रेशन गति में सुधार करने के लिए अपने Dataverse वातावरण के समान क्षेत्र में वर्चुअल मशीन (VM) का उपयोग करें।
  • एक उच्च-प्रदर्शन VM चुनें। कम से कम, बड़े डेटा वॉल्यूम को कुशलतापूर्वक संभालने के लिए आठ कोर, 4-जीबी रैम और 28-जीबी स्टोरेज के साथ D500 VM का उपयोग करें।
  • VM पर एक स्थानीय डेटाबेस को प्राथमिकता दें। माइग्रेशन के दौरान दूरस्थ कनेक्शन से बचें। यदि आप Azure Data Factory का उपयोग करते हैं, तो इसे उसी क्षेत्र में तैनात करें जहां इष्टतम प्रदर्शन के लिए आपके Dataverse परिवेश है।

अगला कदम

वास्तुशिल्प उत्कृष्टता के लिए Power Platform Well-Architected का पालन करें

  • Last updated on