लीगेसी सिस्टम को दोबारा लिखूँ, माइग्रेट करूँ या बदल दूँ?

लीगेसी सिस्टम को आधुनिक बनाने के 4 रास्ते हैं: उसे जैसा है वैसा क्लाउड पर ले जाना, उसका कोड किसी आधुनिक प्लेटफ़ॉर्म पर बदलना, आपके निकाले गए बिज़नेस नियमों के इर्द-गिर्द उसे दोबारा बनाना, या उसे तैयार प्रोडक्ट से बदलकर सिर्फ़ डेटा रखना। फ़ैसला 4 सवाल करते हैं: क्या आपके नियम आपकी कंपनी के अपने हैं? समस्या उस जगह में है जहाँ सिस्टम चलता है या सिस्टम में ही? उसका कोड अब भी कौन समझता है? आपके कर्मचारी कितना बदलाव झेल सकते हैं? Amazon इन रास्तों को 7 रणनीतियों में और Microsoft 8 में बाँटता है, और दोनों हर सिस्टम का फ़ैसला अलग करते हैं।

भाग 4 में आपने अपने सिस्टम के बिज़नेस नियम निकाले और प्रक्रिया के मालिकों से उनकी पुष्टि करवाई। यही नियम नीचे की तुलना को संभव बनाते हैं: इनके बिना आप नहीं जानते कि हर रास्ते पर सिस्टम का कौन-सा व्यवहार खो जाएगा।

चारों रास्ते आसान शब्दों में

तकनीकी नाम बहुत हैं, लेकिन वे 4 फ़ैसलों में सिमट जाते हैं जिन्हें कोई भी मैनेजर समझ सकता है। यह तालिका उनकी तुलना करती है; कोष्ठक में दिए नाम वे हैं जो आप वेंडरों से सुनेंगे:

सोर्स कोड वह प्रोग्राम टेक्स्ट है जिसमें सिस्टम लिखा गया था। अगर वह आपके पास नहीं है, या अब कोई उसे नहीं समझता, तो कोड बदलने का रास्ता कठिन हो जाता है; Amazon की रणनीति गाइड ऐसे एप्लिकेशन को, जिसे कोई मेंटेन करना नहीं जानता या जिसका सोर्स कोड उपलब्ध नहीं है, उन मामलों में गिनती है जो दोबारा डिज़ाइन की ओर ले जाते हैं।

AI से कोड बदलने वाले टूल कहाँ काम आते हैं

AWS Transform जैसे टूल मुख्य रूप से दूसरे रास्ते पर काम करते हैं: वे पुराना कोड पढ़ते हैं और उसे आधुनिक प्लेटफ़ॉर्म पर बदलते हैं, जैसे पुराने .NET Framework एप्लिकेशन को Linux पर चलने वाले आधुनिक वर्ज़न पर ले जाना। Amazon कहता है कि यह टूल Windows, मेनफ़्रेम और VMware एप्लिकेशन को 5 गुना तक तेज़ी से आधुनिक बनाता है; यह Amazon का अपनी सेवा के बारे में दावा है, कोई गारंटीशुदा नतीजा नहीं। उसके प्राइसिंग पेज के अनुसार सेवा हर एजेंट मिनट के 0.035 डॉलर लेती है और यूज़र के खाली समय का पैसा नहीं लेती।

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

खर्च और समय किन बातों से तय होते हैं

हम आपको कोई आँकड़ा नहीं देंगे, क्योंकि आपके सिस्टम को जाने बिना दिया गया हर आँकड़ा अंदाज़ा है। ये वे कारक हैं जो हर रास्ते पर खर्च और समय को बढ़ाते या घटाते हैं:

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

कदमों के क्रम पर दो आधिकारिक स्रोत सलाह देते हैं। Amazon की गाइड आर्किटेक्चर दोबारा बनाने को सबसे जटिल और सबसे महँगी रणनीति बताती है, और बड़े माइग्रेशन में पहले ले जाने और फिर माइग्रेशन पूरा होने के बाद आधुनिक बनाने की सलाह देती है। Microsoft का Cloud Adoption Framework कहता है कि जैसा है वैसा ले जाना तभी ठीक है जब आपको भरोसा हो कि वर्कलोड कम से कम दो साल अपनी मौजूदा स्थिति में रहेगा; वरना काम दोबारा करने से बचने के लिए सीधे आधुनिक बनाना बेहतर है। खुद माइग्रेशन के कदम हमने क्लाउड पर जाने की अपनी व्यावहारिक गाइड में बताए हैं।

दो विकल्प जिन्हें सब भूल जाते हैं: रखना और बंद करना

हर लीगेसी सिस्टम को अभी आधुनिक बनाने की ज़रूरत नहीं है। Amazon और Microsoft दोनों की सूचियाँ ऐसे दो विकल्पों से शुरू होती हैं जिनमें पूरे प्रोजेक्ट का खर्च नहीं आता:

• बंद करना: कुछ सिस्टम असल में अब इस्तेमाल ही नहीं होते। Amazon उदाहरण देता है ऐसे एप्लिकेशन का जिन पर पिछले 90 दिनों में कोई इनबाउंड कनेक्शन नहीं आया, या जिनका प्रोसेसर और मेमोरी इस्तेमाल 5 प्रतिशत से कम है। उनका डेटा आर्काइव करके उन्हें बंद करने से रखरखाव और सुरक्षा जोखिम घटते हैं।
• रखना: ऐसा स्थिर सिस्टम जो अपना काम करता है और जिसे जल्द बदलने की कोई वजह नहीं है, या ऐसा सिस्टम जो फ़ैक्टरी की किसी ऐसी मशीन से जुड़ा है जिसका कोई विकल्प नहीं। यहाँ फ़ैसला है उसे रखना, नज़र रखना और बाद में दोबारा देखना।

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

Origami का नज़रिया

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

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

इस हफ़्ते का अभ्यास: हर सिस्टम के लिए एक फ़ैसला

अपने सिस्टम की सूची पर लौटें और हर सिस्टम के लिए दो कॉलम जोड़ें: क्या उसके नियम आपकी कंपनी के अपने हैं या साझा? और समस्या कहाँ है: उस जगह में जहाँ वह चलता है या सिस्टम में ही? फिर अस्थायी रास्ता लिखें:

ये समझाने के लिए उदाहरण हैं; आपकी तालिका अलग होगी। ज़रूरी यह है कि हर सिस्टम के रास्ते का एक लिखित कारण हो, जिसे कोटेशन माँगने से पहले प्रक्रिया के मालिक देख लें।

आगे क्या

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

स्रोत

• Amazon: बड़े माइग्रेशन की गाइड में सात माइग्रेशन रणनीतियाँ — बंद करना, रखना, रीहोस्ट, दोबारा खरीदना, आर्किटेक्चर दोबारा बनाना और हर एक कब ठीक है।
• Microsoft: अपनी क्लाउड माइग्रेशन रणनीतियाँ चुनें — आठ रणनीतियाँ और रीहोस्ट के लिए दो साल की शर्त।
• AWS Transform: आधिकारिक पेज — सेवा क्या आधुनिक बनाती है और 5 गुना तक तेज़ी का दावा।
• AWS Transform: प्राइसिंग — हर एजेंट मिनट के 0.035 डॉलर।
• AWS Transform: समर्थित रीजन — रीजन और दूसरे रीजन में डेटा प्रोसेसिंग।
• सऊदी प्रेस एजेंसी: दिसंबर में सऊदी अरब में AWS रीजन।
• SDAIA: व्यक्तिगत डेटा सुरक्षा।