Drupal से WordPress माइग्रेशन की योजना

फ्रीलांसर की मदद से Drupal वेबसाइट को WordPress पर माइग्रेट करना: कंटेंट और फ़ीचर ट्रांज़िशन की योजना

Drupal से WordPress पर माइग्रेशन का मतलब सिर्फ़ पेजों को एक जगह से दूसरी जगह ले जाना नहीं है। Drupal साइटें अक्सर ऐसे कंटेंट टाइप, टैक्सोनॉमी, फ़ील्ड, अनुमतियों और मॉड्यूल पर निर्भर होती हैं जिनका WordPress में सीधा विकल्प नहीं होता। इन बातों पर ध्यान न दिया जाए, तो नई साइट देखने में पूरी लग सकती है, लेकिन खोज फ़िल्टर काम नहीं करेंगे, लेखकों के नाम गायब हो सकते हैं या मीडिया फ़ाइलें अपने कंटेंट से अलग हो सकती हैं।

फ्रीलांसर यह काम संभाल सकता है, लेकिन साइट के मालिक को भी कुछ अहम फ़ैसले स्पष्ट करने होंगे। Drupal से WordPress वेबसाइट कैसे माइग्रेट करें, यह जानने से पहले कंटेंट की सूची तैयार करें, पहचानें कि लोग वास्तव में किन फ़ीचर्स का इस्तेमाल करते हैं और तय करें कि लॉन्च के बाद दोनों सिस्टम में क्या अंतर होगा। इससे माइग्रेशन के लिए एक ऐसी योजना बनेगी जिसे परखा जा सके—सिर्फ़ “सब कुछ ले चलो” जैसा अस्पष्ट निर्देश नहीं।

1. Drupal के कंटेंट टाइप को WordPress की संरचनाओं से जोड़ें

सबसे पहले Drupal के कंटेंट टाइप और उनसे जुड़े फ़ील्ड की सूची बनाएं। किसी समाचार लेख में शीर्षक, सारांश, मुख्य लेख, लेखक, प्रकाशन तिथि, विषय और मुख्य तस्वीर हो सकती है। किसी उत्पाद पेज में अलग फ़ील्ड हो सकते हैं और वह किसी श्रेणी या सप्लायर से जुड़ा हो सकता है। Drupal कंटेंट को WordPress में कैसे बदलें, इसकी योजना बनाते समय WordPress की संरचना तय करने से पहले फ्रीलांसर को यह सूची दें।

Drupal के नोड को WordPress पोस्ट या पेज में बदला जा सकता है, लेकिन कुछ कंटेंट के लिए कस्टम पोस्ट टाइप बेहतर होता है। उदाहरण के लिए, अपनी अलग आर्काइव और प्रोफ़ाइल फ़ील्ड वाली संस्थाओं की डायरेक्टरी को साधारण पेजों के बजाय “Organization” पोस्ट टाइप के रूप में रखना आम तौर पर ज़्यादा स्पष्ट होगा। टैक्सोनॉमी, उनके इस्तेमाल के आधार पर WordPress कैटेगरी या कस्टम टैक्सोनॉमी बन सकती हैं। फ़ील्ड-दर-फ़ील्ड मैपिंग टेबल से ये फ़ैसले साफ़ दिखाई देते हैं।

यह न मानें कि फ़ील्ड के नाम एक जैसे होने से उनका व्यवहार भी एक जैसा होगा। Drupal का कोई फ़ील्ड अगर कई वैल्यू स्वीकार करता है, तो WordPress में उसे ऐसी फ़ील्ड से अलग तरीके से सेट करना पड़ सकता है जो सिर्फ़ एक वैल्यू रखती है। इसी तरह, टाइमज़ोन के साथ सेव की गई तारीख के लिए रूपांतरण का स्पष्ट नियम चाहिए हो सकता है। असामान्य वैल्यू के उदाहरण दर्ज करें, ताकि फ्रीलांसर उनका परीक्षण कर सके—अंदाज़ा न लगाना पड़े।

मैपिंग में URL भी शामिल करें। अगर Drupal का कोई लेख अभी /news/community-update पर है, तो तय करें कि WordPress में यही पाथ रखा जाएगा या उसे किसी नए URL पर रीडायरेक्ट किया जाएगा। सोर्स कंटेंट टाइप, लक्ष्य संरचना, फ़ील्ड, टैक्सोनॉमी के नियम और URL के प्रबंधन वाली स्प्रेडशीट, परीक्षण के दौरान दोनों पक्षों के लिए संदर्भ का काम करेगी।

2. तय करें कि क्या दोबारा बनाना, बदलना या छोड़ना है

Drupal मॉड्यूल अक्सर किसी खास वर्कफ़्लो को संभालते हैं। अगर वह वर्कफ़्लो भी ज़रूरी है, तो सिर्फ़ दिखने वाले फ़ीचर की नकल करना काफ़ी नहीं होगा। साइट पर इस्तेमाल हो रहे मॉड्यूल और कस्टम फ़ंक्शन की सूची बनाएं और दर्ज करें कि हर एक पर कौन निर्भर है। सदस्य लॉगिन, संपादकीय मंज़ूरी की कतार और फ़िल्टर वाली खोज—इन तीनों के लिए WordPress में अलग-अलग समाधान चाहिए हो सकते हैं।

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

जो फ़ीचर बने रहेंगे, उन सभी के लिए फ्रीलांसर से प्रस्तावित समाधान और उसकी सीमाएँ बताने को कहें। अगर किसी विकल्प से कंटेंट संपादित करने का तरीका या आगंतुकों के लिए उसे ढूँढ़ने का तरीका बदलता है, तो काम शुरू होने से पहले उस बदलाव को दर्ज करें। “Drupal की तरह काम करता है” कोई उपयोगी स्वीकृति-परीक्षण नहीं है; “संपादक लेख प्रकाशित किए बिना उसे समीक्षा के लिए भेज सकते हैं” है।

ज़रूरी फ़ंक्शन और पसंदीदा विकल्पों को अलग रखें। इससे Drupal मॉड्यूल का सीधा विकल्प न मिलने पर काम का दायरा नियंत्रित करने में मदद मिलती है और साइट के मालिक को सरल प्रक्रिया मंज़ूर करने का मौका मिलता है। किसी Drupal वेबसाइट माइग्रेशन के लिए फ्रीलांसर को नियुक्त करने या व्यक्तिगत ठेकेदार और टीम चुनने से जुड़े व्यापक सवालों के लिए देखें: क्या मुझे फ्रीलांसर नियुक्त करना चाहिए।

3. प्रतिनिधि माइग्रेशन नमूना तैयार करें

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

नमूना इतना बड़ा हो कि अलग-अलग स्थितियाँ सामने आ सकें, लेकिन इतना छोटा भी रहे कि मालिक या संपादक हर रिकॉर्ड की समीक्षा कर सके। इस्तेमाल किए जाने वाले सोर्स आइटम और हर एक के लिए “सही” का मतलब पहले से तय करें। उदाहरण के लिए, लेख के नमूने में मूल लेखक, दो विषय-टर्म, अपडेट की तारीख और डाउनलोड करने योग्य अटैचमेंट होना ज़रूरी हो सकता है।

WordPress के नतीजे की तुलना Drupal से करें, सिर्फ़ डिज़ाइन मॉक-अप से नहीं। देखें कि कंटेंट संपादित किया जा सकता है या नहीं, टैक्सोनॉमी फ़िल्टर से अपेक्षित आइटम मिलते हैं या नहीं और मीडिया सही जगह दिखाई देता है या नहीं। कोई पेज देखने में ठीक लग सकता है, जबकि उसके टर्म डेटाबेस में मौजूद ही न हों। पूरे काम के बाद हज़ारों रिकॉर्ड में वही गलती ढूँढ़ने की तुलना में नमूने के आधार पर मैपिंग सुधारना कहीं सस्ता है।

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

4. कंटेंट की सफ़ाई और संपादकीय हस्तांतरण के नियम तय करें

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

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

एम्बेड किए गए मीडिया के लिए भी नियम तय करें। Drupal के कुछ कंटेंट में ऐसी पुरानी जगह पर सेव फ़ाइलों के लिंक हो सकते हैं या किसी पुराने वीडियो प्रोवाइडर के कोड से वीडियो एम्बेड हो सकता है। तय करें कि फ्रीलांसर फ़ाइल कॉपी करेगा, एम्बेड को बदलेगा या उसे संपादकीय समीक्षा के लिए चिह्नित करेगा। असमर्थित फ़ील्ड वैल्यू को चुपचाप हटाने के बजाय रिपोर्ट किया जाना चाहिए; कोई छूटी हुई वैल्यू उत्पाद, प्रोफ़ाइल या कानूनी सूचना को प्रभावित कर सकती है।

यह भी तय करें कि माइग्रेट की गई कॉपी की जाँच कौन करेगा और अपवादों को किस तरह सौंपा जाएगा। उदाहरण के लिए, फ्रीलांसर उन रिकॉर्ड की स्प्रेडशीट दे सकता है जिनमें इमेज नहीं हैं, और लॉन्च से पहले संपादक उनके विकल्प दे सकता है। स्पष्ट हस्तांतरण से तकनीकी माइग्रेशन का काम संपादकीय मंज़ूरी से अलग रहता है।

5. सिर्फ़ दिखावट नहीं, माइग्रेट किए गए डेटा की भी जाँच करें

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

जहाँ संभव हो, रिकॉर्ड की संख्या और चुने हुए फ़ील्ड की तुलना के लिए एक्सपोर्ट या डेटाबेस क्वेरी का इस्तेमाल करें। अगर दायरे में Drupal के 240 इवेंट हैं, तो माइग्रेशन रिपोर्ट में लक्ष्य साइट के रिकॉर्ड का हिसाब होना चाहिए या साफ़-साफ़ बताना चाहिए कि कौन-से रिकॉर्ड शामिल नहीं किए गए। बिना जाँच के यह न मानें कि संख्या मेल खाती है। अगर अंतिम संख्या अभी पता नहीं है, तो कोई लक्ष्य गढ़ने के बजाय उसे सत्यापन के लिए चिह्नित करें।

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

अपवादों को इतनी जानकारी के साथ दर्ज करें कि उन पर कार्रवाई की जा सके: सोर्स पहचान संख्या, लक्ष्य URL, समस्या, ज़िम्मेदार व्यक्ति और स्थिति। “कुछ इमेज गलत हैं” जैसा नोट सुलझाना मुश्किल है। प्रभावित लेख और छूटी हुई इमेज का नाम बताने से फ्रीलांसर और संपादक को स्पष्ट काम मिलता है।

6. कंटेंट में बदलावों के हिसाब से कटओवर की योजना बनाएं

फ्रीलांसर के WordPress बनाने के दौरान कंटेंट बदलता रह सकता है। माइग्रेशन शुरू करने से पहले तय करें कि कुछ समय के लिए कंटेंट पर रोक लगानी है या अंतिम बदलाव अलग से माइग्रेट करने हैं। रोक लगाने पर, तय अवधि में अंतिम ट्रांसफ़र और जाँच के दौरान संपादक Drupal पर नई सामग्री प्रकाशित नहीं करेंगे। बदलाव अलग से माइग्रेट करने की प्रक्रिया में फ्रीलांसर पहले शुरुआती कंटेंट आयात करता है और फिर उसके बाद बनाए या बदले गए रिकॉर्ड ट्रांसफ़र करता है।

कंटेंट पर रोक का तरीका समझाना आसान है, लेकिन व्यस्त न्यूज़रूम या संगठन के काम में रुकावट आ सकती है। अंतिम बदलाव अलग से माइग्रेट करने पर प्रकाशन जारी रह सकता है, लेकिन बदले हुए रिकॉर्ड पहचानने और डुप्लिकेट से बचने के लिए भरोसेमंद तरीका चाहिए। पूछें कि बदलावों का हिसाब कौन रखेगा, आख़िरी इंपोर्ट कब होगा और कटओवर के दौरान किए गए अपडेट की जाँच कैसे होगी।

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

7. एक्सेस, दस्तावेज़ और रोलबैक की तैयारी पूरी करें

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

अकाउंट एक्सेस की भी समीक्षा करें। अस्थायी अकाउंट हटा दें या जिन अनुमतियों की अब ज़रूरत नहीं है उन्हें कम कर दें। अगर माइग्रेशन के लिए लॉगिन जानकारी साझा की गई थी, तो उसे बदलें। WordPress के प्रबंधन के लिए एक नामित ज़िम्मेदार व्यक्ति तय करें, ताकि साइट किसी पुराने ठेकेदार के निजी लॉगिन पर निर्भर न रहे।

रोलबैक की तैयारी का मतलब है Drupal साइट की ऐसी कॉपी सुरक्षित रखना जिसे ज़रूरत पड़ने पर बहाल किया जा सके, और यह जानना कि नई साइट लॉन्च के दौरान गंभीर समस्या आने पर उसे कौन बहाल करेगा। बैकअप कहाँ रखा जाएगा, उसे बहाल करने की ज़िम्मेदारी किसकी होगी और किन परिस्थितियों में रोलबैक किया जाएगा—यह तय करें। सिर्फ़ इसलिए पुरानी साइट न हटाएँ कि WordPress लाइव हो गया है। उसे तब तक बनाए रखें जब तक तय जाँच पूरी न हो जाएँ और टीम यह पुष्टि न कर दे कि अहम कंटेंट और वर्कफ़्लो ठीक से काम कर रहे हैं।