ERP मॉडर्नाइज़ेशन की 10 ग़लतियाँ जिनसे बचना चाहिए

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

यह उन CIO, CFO और प्रोग्राम डायरेक्टर के लिए है जो S/4HANA या किसी दूसरे ERP का मॉडर्नाइज़ेशन प्लान कर रहे हैं या बचा रहे हैं। नीचे हर ग़लती के साथ बताया गया है कि वह व्यवहार में कैसी दिखती है और उसका हल क्या है। इसके बाद एक पन्ने की शुरुआती-चेतावनी चेकलिस्ट है और यह कि 2026 के SAP बदलावों का क्या मतलब है।

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

1. go-live को फ़िनिश लाइन मानना

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

मैंने ऐसे प्रोजेक्ट देखे हैं जहाँ स्टीयरिंग कमेटी go-live के तुरंत बाद भंग हो जाती है। छह महीने बाद अपनाने की दर सपाट रहती है और बैकलॉग का कोई ओनर नहीं होता।

हल: go-live के बाद 6 से 12 महीने की गवर्नेंस अवधि को फ़ंड कीजिए। स्टीयरिंग कमेटी का कार्यकाल बढ़ाइए। सिर्फ़ अपटाइम नहीं, प्रोसेस को अपनाए जाने की निगरानी कीजिए। नामित ओनर के साथ go-live के बाद के क्वालिटी गेट तय कीजिए।

2. लेगसी प्रोसेस को बिना दोबारा सोचे माइग्रेट करना

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

इसका S/4HANA वाला रूप: ECC से जस-के-तस उठाए गए कस्टम बैच जॉब, जो ऐसे टेबल स्ट्रक्चर पर बने हैं जो अब हैं ही नहीं। माइग्रेशन तकनीकी रूप से साफ़ है। बिज़नेस लॉजिक टूटा हुआ है।

हल: बिल्ड से पहले प्रोसेस को दोबारा डिज़ाइन कीजिए। ऑपरेशंस, फ़ाइनेंस और डिलीवरी टीमों को हर वर्कफ़्लो साथ में दिखाइए और हर कदम को चुनौती दीजिए।

लेगसी क्षेत्र	अक्सर क्या ग़लत होता है	इसकी जगह क्या करें
ECC का कस्टम कोड	इस्तेमाल न होने वाला कस्टम कोड S/4HANA में ले जाया जाता है	यूसेज एनालिसिस और SAP के कस्टम कोड चेक चलाइए; इस्तेमाल न होने वाला कोड रिटायर कीजिए
पुराने वर्कफ़्लो	अप्रूवल फ़्लो दोबारा बनाए जाते हैं, जबकि अब ऑटोमेशन संभव है	बिज़नेस ओनर के साथ फिर देखिए; स्टैंडर्ड Fiori ऐप या SAP Build Process Automation इस्तेमाल कीजिए
ग़ैर-मानक मास्टर डेटा	लचीले लेगसी सेट-अप S/4HANA वैलिडेशन में फ़ेल होते हैं	माइग्रेशन से पहले साफ़ और एकसमान कीजिए, जहाँ फ़िट हो वहाँ SAP MDG के साथ
लेगसी टेबल पर रिपोर्ट	सीधा टेबल एक्सेस S/4HANA के डेटा मॉडल से मेल नहीं खाता	CDS व्यू पर दोबारा बनाइए
छिपे हुए मैनुअल वर्कअराउंड	साइड प्रोसेस go-live के बाद लौट आते हैं	माइग्रेशन से पहले प्रोसेस माइनिंग कीजिए और कमियों को डिजिटाइज़ कीजिए

3. डेटा माइग्रेशन देर से शुरू करना

ख़राब डेटा को नए ERP में ले जाना बिना कुछ फेंके घर बदलने जैसा है। कबाड़ साथ चला आता है, और एक संरचित सिस्टम के अंदर उसे साफ़ करना और मुश्किल होता है।

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

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

4. चेंज मैनेजमेंट को साइड टास्क मानना

आम रूप: चेंज मैनेजमेंट “पहले से हो चुका” है, यानी कुछ स्लाइड, एक डेमो और go-live से पहले एक ट्रेनिंग सेशन।

लोग इसलिए विरोध नहीं करते कि उन्हें बदलाव पसंद नहीं। वे तब विरोध करते हैं जब कोई यह नहीं समझाता कि चीज़ें क्यों बदल रही हैं या उससे उन्हें क्या फ़ायदा होगा। वे सिस्टम को बस इतना मानते हैं कि चेकलिस्ट पास हो जाए, फिर स्प्रेडशीट पर लौट जाते हैं।

आम ट्रिगर शेड्यूल का दबाव है: समय बचाने के लिए ट्रेनिंग छोटी कर दी जाती है, go-live पर यूज़र पर बोझ आ पड़ता है, और अतिरिक्त हाइपरकेयर की लागत उस ट्रेनिंग से ज़्यादा बैठती है जो काटी गई थी।

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

5. वेंडर रोडमैप के भरोसे प्लानिंग

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

वेंडर रोडमैप ग्राहकों के बड़े समूहों के लिए बनाते हैं। आपका बिज़नेस उस डिज़ाइन का केंद्र शायद ही कभी होता है।

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

6. लेगसी सिस्टम के लिए कोई डीकमीशनिंग प्लान नहीं

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

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

7. इंटीग्रेशन की जटिलता को कम आँकना

जब इंटीग्रेशन फ़ेल होता है, तो बिज़नेस को IT से पहले पता चलता है, क्योंकि वर्कफ़्लो टेस्ट सिस्टम में नहीं, प्रोडक्शन में प्रोसेस के बीच में रुक जाते हैं।

आम पैटर्न: IT और बिज़नेस दोनों मानते हैं कि इंटीग्रेशन की ज़रूरतें दूसरे ने तय कर दी हैं। किसी ने नहीं की होतीं। जब तक कमियाँ टेस्टिंग में दिखती हैं, दोबारा डिज़ाइन करने का समय नहीं बचता।

हल: इंटीग्रेशन डिज़ाइन ब्लूप्रिंटिंग में शुरू कीजिए। हर परिदृश्य, मिडलवेयर, मैपिंग और मैसेज वॉल्यूम तय कीजिए, और बिज़नेस के साथ हर इंटरफ़ेस के लिए रीयल-टाइम बनाम बैच साफ़ कीजिए। go-live से पहले SLA के साथ एक इंटरफ़ेस ओनर नामित कीजिए। नए SAP प्रोग्राम के लिए मिडलवेयर SAP Integration Suite है; SAP PI/PO 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है।

8. यह मान लेना कि ERP सब कुछ संभाल लेगा

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

ERP संरचित, ट्रांज़ैक्शन वाले, वित्तीय आधार वाले प्रोसेस में अच्छा है। IT सर्विस रिक्वेस्ट, वर्कफ़्लो ऑर्केस्ट्रेशन और नॉलेज मैनेजमेंट में समर्पित प्लेटफ़ॉर्म बेहतर हैं।

हल: सोच-समझकर तय कीजिए कि ERP में क्या नहीं बनाना है। अपवादों के लिए SAP BTP पर साइड-बाय-साइड एक्सटेंशन, और ट्रांज़ैक्शनल कोर के बाहर ऑर्केस्ट्रेशन के लिए ServiceNow या उस जैसा कुछ इस्तेमाल कीजिए। मेरा लेख SAP और ServiceNow के साथ ERP मॉडर्नाइज़ेशन उस बँटवारे को कवर करता है।

9. लंबी अवधि की लाइसेंसिंग लागत को कम आँकना

मैं एक ऐसी टीम को जानता हूँ जिसका लाइसेंसिंग ख़र्च दूसरे साल में दोगुना हो गया, क्योंकि उसे एक फ़ीचर चाहिए था जो ऊँचे टियर के लाइसेंस के पीछे था। बिज़नेस केस में सिर्फ़ go-live की लागत मॉडल की गई थी।

ERP लाइसेंस यूज़र, मॉड्यूल, ट्रांज़ैक्शन और API इस्तेमाल पर शुल्क लेते हैं, और लागत बिज़नेस के साथ बढ़ती है, चाहे आपने उसकी योजना बनाई हो या नहीं। SAP पर Digital Access मॉडल का मतलब है कि थर्ड-पार्टी सिस्टम से बने डॉक्यूमेंट पर ऐसी लाइसेंस लागत आ सकती है जो मूल कमर्शियल मॉडल में नहीं थी। RISE और SAP GROW के तहत Full User Equivalent (FUE) की गिनती अपनाए जाने के साथ बढ़ती है।

हल: साइन करने से पहले तीन से पाँच साल का लाइसेंस मॉडल बनाइए। रोल को लाइसेंस टाइप से मैप कीजिए, FUE की बढ़त को यथार्थवादी अपनाने के कर्व पर मॉडल कीजिए, बाहरी सिस्टम जोड़ने से पहले इनडायरेक्ट एक्सेस समझिए, और go-live के बाद निष्क्रिय यूज़र का ऑडिट कीजिए।

10. ERP को IT प्रोजेक्ट मानना

सबसे आम और सबसे नुक़सानदेह पैटर्न। प्लानिंग IT में शुरू होती है, IT की अगुवाई में चलती है और IT की समस्याएँ सुलझाती है।

मैंने ऐसी टीमें देखी हैं जो काग़ज़ पर हर माइलस्टोन छू लेती हैं, जबकि बिज़नेस अब भी पूछ रहा है कि कुछ बेहतर महसूस क्यों नहीं हो रहा। इसका आमतौर पर मतलब होता है कि ERP कल के प्रोसेस के लिए बना, डिज़ाइन में ऑपरेशंस, फ़ाइनेंस या कमर्शियल लीडर के बिना।

हल: कमर्शियल, फ़ाइनेंस और ऑपरेशंस के लीडर को शुरू से स्टीयरिंग कमेटी में रखिए। चार्टर में सिर्फ़ तकनीकी स्कोप नहीं, रणनीतिक तालमेल भी लिखिए। डिज़ाइन शुरू होने से पहले प्रोग्राम के लक्ष्यों को बोर्ड-स्तर के नतीजों से परखिए।

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

1. चार्टरओनरशिप और लागतकोई ऑपरेशंस या फ़ाइनेंस लीड नहीं, पाँच साल का लाइसेंस मॉडल नहीं, रिटायरमेंट की तारीख़ नहीं
2. ब्लूप्रिंटप्रोसेस और इंटीग्रेशन डिज़ाइनआज का प्रोसेस कॉपी किया गया, इंटरफ़ेस अब भी बिना डिज़ाइन
3. पहला मॉक लोडडेटाअभी तक कोई डेटा क्वालिटी रिपोर्ट नहीं
4. go-liveउसके बाद क्या होता हैबाद के 12 महीनों के लिए कोई फ़ंडेड गवर्नेंस नहीं

ग़लती	शुरुआती चेतावनी संकेत	ओनर
1. go-live को फ़िनिश लाइन मानना	go-live के बाद के 12 महीनों के लिए कोई फ़ंडेड गवर्नेंस प्लान नहीं	स्पॉन्सर
2. कॉपी की गई लेगसी प्रोसेस	डिज़ाइन वर्कशॉप “आज हम इसे कैसे करते हैं” वाली स्क्रीन से शुरू होती हैं	प्रोसेस ओनर
3. देर से डेटा का काम	पहले मॉक लोड से पहले कोई डेटा क्वालिटी रिपोर्ट नहीं	डेटा माइग्रेशन लीड
4. चेंज को साइड टास्क मानना	चेंज प्लान सिर्फ़ ट्रेनिंग का कैलेंडर है	चेंज लीड
5. रोडमैप पर निर्भरता	डिज़ाइन का कोई फ़ैसला ऐसे फ़ीचर का इंतज़ार कर रहा है जो रिलीज़ नहीं हुआ	सॉल्यूशन आर्किटेक्ट
6. डीकमीशनिंग नहीं	चार्टर में किसी भी लेगसी सिस्टम की रिटायरमेंट तारीख़ नहीं	PMO
7. इंटीग्रेशन को कम आँका	ब्लूप्रिंट के अंत तक इंटरफ़ेस डिज़ाइन नहीं हुए	इंटीग्रेशन लीड
8. सब कुछ ERP में	नॉन-ट्रांज़ैक्शनल वर्कफ़्लो के लिए कस्टम ऑब्जेक्ट	एंटरप्राइज़ आर्किटेक्ट
9. लाइसेंसिंग	बिज़नेस केस में पाँच साल का लाइसेंस मॉडल नहीं	CFO
10. सिर्फ़ IT का प्रोग्राम	स्टीयरिंग कमेटी में कोई ऑपरेशंस या फ़ाइनेंस लीड नहीं	स्पॉन्सर

डिप्लॉयमेंट। नए SAP प्रोग्राम के लिए डिफ़ॉल्ट है SAP Cloud ERP Private पर RISE with SAP, या मध्यम आकार की कंपनियों के लिए पब्लिक एडिशन (SAP Cloud ERP) पर SAP GROW। नए on-premise डिप्लॉयमेंट दुर्लभ हैं। ECC ग्राहकों के लिए मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को समाप्त हो रहा है, जिससे ग़लतियाँ 2, 3 और 7 को ठीक करने का समय घट जाता है।

Clean core। SAP अब एक्सटेंशन को चार clean core स्तरों पर ग्रेड करता है, A (सिर्फ़ released API, BTP पर साइड-बाय-साइड या ABAP Cloud के साथ इन-सिस्टम) से D (clean नहीं) तक। पब्लिक एडिशन सिर्फ़ स्तर A की अनुमति देता है, जो ग़लती 2 के पीछे की बातचीत को ज़रूरी बना देता है। प्राइवेट एडिशन में अब भी क्लासिक एक्सटेंशन की अनुमति है, इसलिए अनुशासन गवर्नेंस से आना होगा। क्लासिक कस्टम कोड ही हर अपग्रेड को एक प्रोजेक्ट बनाता है। मेरी clean core रणनीति का लेख और आगे जाता है।

डिलीवरी टूलिंग में AI। Joule अब SAP Cloud ALM और SAP Activate Roadmap Viewer में है, और SAP Build Code एक्सटेंशन डेवलपमेंट के लिए Joule इस्तेमाल करता है। पार्टनर से पूछिए कि AI टूलिंग उनके रेट कार्ड में कैसे झलकती है। अगर नहीं झलकती, तो या तो क़ीमत ऊँची है या बचत उनके मार्जिन में जा रही है।

लाइफ़साइकल टूलिंग। SAP Cloud ALM क्लाउड प्रोग्राम के लिए लाइफ़साइकल मैनेजमेंट टूल है। Solution Manager 7.2 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है, इसलिए जिन एनवायरनमेंट में दोनों चल रहे हैं, उन्हें आगे बढ़ने की योजना चाहिए।

दस ग़लतियाँ नहीं बदलीं। उन्हें ग़लत करने की क़ीमत बदली है। RISE प्रोग्राम में clean core का फ़ैसला, डिप्लॉयमेंट मॉडल और FUE मॉडल, सब मोबिलाइज़ेशन के पहले हफ़्तों में तय हो जाते हैं। इन्हें प्रभावित करने की खिड़की छोटी है।

go-live के बाद ERP मॉडर्नाइज़ेशन के प्रयास कमज़ोर क्यों पड़ जाते हैं?

ज़्यादातर टीमें go-live तक की प्लानिंग करती हैं और वहीं रुक जाती हैं। एन्हांसमेंट, फ़ीडबैक, प्रोसेस के सुधार या बैकलॉग का कोई ओनर नहीं होता। स्टीयरिंग कमेटी का go-live पर भंग हो जाना मुसीबत का सबसे भरोसेमंद संकेत है। पहले दिन से go-live के बाद 6 से 12 महीने की गवर्नेंस को फ़ंड कीजिए।

लेगसी प्रोसेस को नए ERP में कॉपी करने का जोखिम क्या है?

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

ख़राब डेटा क्वालिटी ERP मॉडर्नाइज़ेशन को कैसे नुक़सान पहुँचाती है?

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

ERP प्रोजेक्ट में चेंज मैनेजमेंट को अक्सर कम क्यों आँका जाता है?

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

ERP go-live के सालों बाद भी लेगसी सिस्टम क्यों चलते रहते हैं?

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

RISE with SAP और clean core इन ग़लतियों को कैसे बदलते हैं?

पब्लिक एडिशन पर clean core के नियम गहरा कस्टमाइज़ेशन असंभव बना देते हैं, जिससे ग़लती 2 के पीछे की प्रोसेस वाली बातचीत ज़रूरी हो जाती है। प्राइवेट एडिशन पर क्लासिक एक्सटेंशन अब भी मान्य हैं, इसलिए clean core गवर्नेंस पर निर्भर करता है। PI/PO का मेंटेनेंस ख़त्म होने के साथ इंटीग्रेशन SAP Integration Suite पर जाता है। लाइसेंसिंग FUE की बढ़त का सवाल बन जाती है। डीकमीशनिंग और ज़रूरी हो जाती है, क्योंकि लेगसी सिस्टम को समानांतर चलाने से बहु-वर्षीय सब्सक्रिप्शन के ऊपर लागत जुड़ती है।