काम रोके बिना नए सिस्टम पर कैसे जाऊँ?

अगर आप पुराने सिस्टम को तब तक बंद नहीं करते जब तक नया सिस्टम खुद को साबित न कर दे, तो काम रोके बिना बदलाव कर सकते हैं: दोनों को एक ही असली लेनदेन पर चलाकर नतीजों की तुलना करें, प्रक्रिया के ज़िम्मेदार लोगों द्वारा बताई गई दुर्लभ स्थितियों की जाँच करें, हर मॉड्यूल को लाइव करने से पहले इंसानी मंज़ूरी लें, और पुराने सिस्टम को वापसी के लिए तैयार रखें। Microsoft अपनी माइग्रेशन लागू करने की गाइड में बदलाव के बाद पहले 24 से 48 घंटों तक नए सिस्टम पर नज़र रखने और स्थिरता की अवधि में पुराने वातावरण को वापसी के विकल्प के रूप में रखने की सलाह देता है।

भाग 5 में आपने हर सिस्टम के लिए एक रास्ता चुना। यह भाग बदलाव का वह सामान्य तरीका नहीं दोहराता जिसे हमने बिना रुकावट लीगेसी सिस्टम का आधुनिकीकरण में समझाया था। यह नए सवाल पर ध्यान देता है: जब नया कोड AI ने लिखा या बदला हो, तब क्या जाँचें।

AI द्वारा बदले गए कोड को अलग तरह की जाँच क्यों चाहिए

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

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

एक ही असली लेनदेन पर नतीजों की तुलना करें

अपने कारोबार की कोई बंद हो चुकी अवधि लें, जैसे वह महीना जिसके खाते बंद हो चुके हैं, उसके लेनदेन नए सिस्टम में चलाएँ और जो निकले उसकी तुलना पुराने सिस्टम के नतीजों से करें। किन चीज़ों की तुलना करें:

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

कुछ टूल तैयारी में मदद करते हैं, फ़ैसला नहीं करते। उदाहरण के लिए मेनफ़्रेम के लिए AWS Transform कोड की विशेषताओं, जॉब की जटिलता और शेड्यूलर के रास्तों के आधार पर 3 चरणों (कॉन्फ़िगरेशन, दायरा तय करना और समीक्षा) में टेस्ट योजना बनाता है, फिर मेनफ़्रेम से टेस्ट डेटा इकट्ठा करने वाली स्क्रिप्ट 4 चरणों में तैयार करता है। लेकिन Amazon उसी गाइड में साफ़ करता है कि ये स्क्रिप्ट आपके अपने मेनफ़्रेम पर और आपकी टीम की अनुमतियों से चलानी होंगी। टूल तैयारी करता है; चलाना और फ़ैसला करना आपकी टीम का काम है। डेटा की जाँच के लिए Microsoft सुझाव देता है कि त्वरित जाँच के लिए पंक्तियों की गिनती और गहरी जाँच के लिए चेकसम की तुलना करें: चेकसम डेटा से निकाली गई एक संख्या है जो एक भी अक्षर बदलने पर बदल जाती है।

दुर्लभ स्थितियाँ: उनसे पूछें जो इन्हें जानते हैं

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

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

हर मॉड्यूल पर इंसानी मंज़ूरी

इस सिद्धांत का सबसे साफ़ प्रकाशित उदाहरण बैंकिंग सिस्टम बदलने की वह प्रक्रिया है जिसकी घोषणा Thought Machine ने Amazon के साथ 29 सितंबर 2026 को की। इसमें 4 चरण हैं: AWS Transform से पुराने एप्लिकेशन का कारोबारी तर्क निकालना, दोहराए गए रूपों को एकीकृत विनिर्देशों में मिलाना, AI एजेंटों से नए वित्तीय उत्पाद और उनके टेस्ट बनाना, और एक सत्यापन चरण जो कुछ भी स्वीकार करने से पहले बैंक की इंजीनियरिंग और जोखिम टीमों को स्पष्ट मंज़ूरी का अधिकार देता है। मंज़ूरी के बाद भी नतीजा सीधे लाइव नहीं जाता, बल्कि आगे के मूल्यांकन के लिए एक अलग सैंडबॉक्स वातावरण में जाता है।

आपकी कंपनी के लिए यह सबक न बैंक माँगता है न Amazon: सिस्टम का हर मॉड्यूल, जैसे बिलिंग, पेरोल या इन्वेंटरी, लाइव होने से पहले दो हस्ताक्षर पाता है। एक तकनीकी, जो पुष्टि करे कि सारे टेस्ट चलाए गए, और एक प्रक्रिया के ज़िम्मेदार व्यक्ति का, जो पुष्टि करे कि नतीजे कारोबार की दृष्टि से सही हैं। Microsoft बदलाव के बाद भी यही माँगता है: एप्लिकेशन के ज़िम्मेदार लोग पुष्टि करें कि सभी मुख्य काम सही चल रहे हैं।

साथ-साथ चलाना और वापसी योजना

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

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

Origami का नज़रिया

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

हम कन्वर्ज़न तेज़ करने और टेस्ट बनाने के लिए AI का इस्तेमाल करते हैं, लेकिन हर मॉड्यूल की मंज़ूरी आपकी टीम के नामित लोगों के पास रहती है। हम कैसे काम करते हैं, यह देखने के लिए हमारी सेवाएँ देखें।

इस हफ़्ते का अभ्यास: हर मॉड्यूल के लिए बदलाव शीट

भाग 5 में जिस भी सिस्टम को आपने बदलने या दोबारा बनाने के लिए चुना, उसके लिए कोई भी बदलाव की तारीख तय करने से पहले प्रक्रिया के ज़िम्मेदार लोगों के साथ यह शीट भरें:

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

आगे क्या

एक सवाल बचा है जो हर प्रबंधक अपना कोड और डेटा किसी AI टूल को भेजने से पहले पूछता है: आधुनिकीकरण के दौरान मेरा डेटा कहाँ जाता है? भाग 7, जो आखिरी भाग है, इसका जवाब देता है और पूरी सीरीज़ के अभ्यासों को 90 दिनों की योजना में जोड़ता है।

स्रोत

• Microsoft: माइग्रेशन लागू करना, Cloud Adoption Framework — वापसी की शर्तों पर बैठक, बदलावों पर रोक, डेटा का सत्यापन, 24 से 48 घंटों की निगरानी और पुराने वातावरण को वापसी के लिए रखना।
• Amazon: AWS Transform में मेनफ़्रेम एप्लिकेशन बदलना — टेस्ट योजनाएँ, टेस्ट डेटा इकट्ठा करने की स्क्रिप्ट और Reforge चरण।
• Amazon: पुराने बैंकिंग सिस्टम के माइग्रेशन पर Thought Machine और AWS की घोषणा — चार चरण और इंजीनियरिंग व जोखिम टीमों की मंज़ूरी।
• AWS Transform: आधिकारिक पेज।