टूल माइग्रेशन से पहले लागत का आकलन: छह जाँचें और तीन चरणों वाला ट्रांज़िशन

एनवायरनमेंट मैनेजमेंट टूल बदलना ऊपर से आसान लगता है: सॉफ़्टवेयर इंस्टॉल करें और डेटा एक्सपोर्ट कर दें।

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

पहले पक्का करें कि अकाउंट और एनवायरनमेंट सही तरह से मैप हो सकें

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

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

एनवायरनमेंट कॉन्फ़िगरेशन को कॉपी नहीं, दोबारा बनाना होता है

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

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

Cookies और लॉगिन स्थिति

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

क्या नेटवर्क एग्रेस बाइंडिंग संगत है?

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

क्या टीम की काम करने की आदतें टूटेंगी?

क्या परमिशन मॉडल समान है? क्या सदस्य बिना पासवर्ड साझा किए काम कर सकते हैं? क्या ऑपरेशन लॉग अब भी उपलब्ध रहेंगे? ये तीन बातें तय करती हैं कि टीम को कितना दोबारा सीखना होगा। टीम जितनी बड़ी होगी, यह लागत उतनी अधिक होगी।

क्या पुराने एनवायरनमेंट को कुछ समय रखना चाहिए?

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

ट्रांज़िशन अवधि कैसे तय करें

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

इसके बाद दो से चार हफ्तों की ऑब्ज़र्वेशन अवधि रखें। ऑपरेशन को पुराने तरीके के जितना करीब हो सके रखें और दोनों तरफ अकाउंट स्थिरता, वेरिफिकेशन ट्रिगर होने की आवृत्ति और टास्क सफलता दर की तुलना करें। अगर इस समय नया एनवायरनमेंट साफ़ तौर पर खराब है, तो रोलबैक की लागत अभी भी कम होगी।

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

कुछ आम निर्णय संबंधी गलतियाँ

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

एक और गलती सिर्फ माइग्रेशन करने के लिए माइग्रेशन करना है। अगर मौजूदा टूल ज़रूरतें पूरी करता है, तो केवल नए टूल में अधिक फीचर देखकर बदलना अक्सर उचित नहीं ठहरता। पहले साफ़-साफ़ लिखें कि मौजूदा टूल कहाँ अटक रहा है, फिर देखें कि नया टूल उन समस्याओं को वास्तव में हल कर सकता है या नहीं।

सबसे जोखिमभरा तरीका सभी अकाउंट को एक साथ स्थानांतरित करना है। इससे पूरा जोखिम एक ही समय पर केंद्रित हो जाता है। कुछ गलत होने पर कोई वापसी का रास्ता नहीं बचता।

निर्णय से पहले तीन सवालों के जवाब दें

मौजूदा टूल की ठोस समस्या क्या है? जवाब किसी खास परिस्थिति तक स्पष्ट होना चाहिए, सिर्फ यह कहना पर्याप्त नहीं कि टूल अच्छा नहीं लगता। क्या नया टूल इन समस्याओं को निश्चित रूप से हल कर सकता है, और क्या इसे पायलट में साबित किया जा सकता है? अगर माइग्रेशन विफल हो जाए तो लागत क्या होगी, क्या रोलबैक संभव है और उसमें कितना समय लगेगा?

तीनों सवालों के स्पष्ट जवाब मिलने के बाद ही शुरुआत करें।