ECC से S/4HANA माइग्रेशन: रास्ते, चरण और समय-सीमा

SAP ECC की मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को खत्म हो रही है, यानी अब से करीब 15 महीने बाद। अतिरिक्त शुल्क पर वैकल्पिक एक्सटेंडेड मेंटेनेंस 2030 के अंत तक चलती है (SAP News)। असली टेस्टिंग शुरू होते ही जटिल माइग्रेशन आसानी से 18 से 24 महीने तक खिंच जाते हैं। अगर आपने अब तक रास्ता नहीं चुना है, तो डेडलाइन से पहले go-live करना पहले ही मुश्किल दिखता है।

अगर आप वह CIO या प्रोग्राम लीड हैं जिसे यह फ़ैसला लेना है, तो आपके पास तीन रास्ते हैं: ग्रीनफ़ील्ड, ब्राउनफ़ील्ड या सिलेक्टिव डेटा ट्रांज़िशन। हर रास्ते के पीछे का काम इन्हीं पाँच चरणों का होता है। पहले SAP Readiness Check चलाइए, फिर चुनिए।

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

माइग्रेशन की मेहनत तय करने वाले अंतर:

क्षेत्र	SAP ECC	SAP S/4HANA
डेटाबेस	कोई भी समर्थित डेटाबेस (Oracle, Db2, SQL Server और अन्य)	सिर्फ़ SAP HANA
फ़ाइनेंस डेटा मॉडल	अलग-अलग FI, CO और प्रॉफ़िटेबिलिटी टेबल, साथ में टोटल टेबल	Universal Journal (टेबल ACDOCA), जो लाइन-आइटम का इकलौता स्रोत है
ग्राहक और वेंडर मास्टर	ग्राहक और वेंडर के अलग-अलग रिकॉर्ड	बिज़नेस पार्टनर अनिवार्य है
यूज़र इंटरफ़ेस	SAP GUI	SAP Fiori ऐप्स; ऑन-प्रिमाइस और Private Edition में SAP GUI अब भी उपलब्ध
डिप्लॉयमेंट	ऑन-प्रिमाइस	ऑन-प्रिमाइस, Private Edition (RISE with SAP) या Public Edition (GROW with SAP)
एक्सटेंशन	Z-प्रोग्राम और मॉडिफ़िकेशन	क्लीन कोर: रिलीज़्ड API, on-stack ABAP Cloud या SAP BTP पर side-by-side
मेंटेनेंस	EHP 6 से 8 के लिए मेनस्ट्रीम 2027 के अंत तक, एक्सटेंडेड 2030 के अंत तक	SAP ने 2040 के अंत तक मेंटेनेंस का वादा किया है

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

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

Decide

आपकी स्थिति में कौन सा माइग्रेशन रास्ता ठीक बैठता है?

पुराना सिस्टम बिखरा हुआ है और आप प्रोसेस नए सिरे से बनाना चाहते हैं

→ग्रीनफ़ील्ड

प्रोसेस ठीक हैं, ECC स्थिर है, इतिहास रखना ज़रूरी है

→ब्राउनफ़ील्ड

कई एंटिटी हैं, कुछ हिस्सा दोबारा इस्तेमाल करना है और चुना हुआ डेटा चाहिए

→ब्लूफ़ील्ड

ग्रीनफ़ील्ड: नए सिरे से शुरुआत

S/4HANA का नया इम्प्लीमेंटेशन। पुराना कोई कॉन्फ़िगरेशन आगे नहीं आता, प्रोसेस SAP के स्टैंडर्ड के हिसाब से नए सिरे से डिज़ाइन होते हैं, और सिर्फ़ वही डेटा लोड होता है जो ज़रूरी है, SAP S/4HANA Migration Cockpit से।

कब चुनें: जब पुराने सिस्टम इतने बिखरे हों कि उन्हें साफ़ तरीके से कन्वर्ट न किया जा सके, या बिज़नेस प्रोसेस की नकल करने की जगह उन पर दोबारा सोचना चाहता हो।

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

ब्राउनफ़ील्ड: सिस्टम कन्वर्ज़न

आपका मौजूदा ECC सिस्टम उसी जगह कन्वर्ट हो जाता है। कॉन्फ़िगरेशन, कस्टम कोड और इतिहास आपके साथ आते हैं। तकनीकी कन्वर्ज़न Software Update Manager (SUM) और उसके डेटाबेस माइग्रेशन विकल्प से चलता है।

कब चुनें: जब प्रोसेस परिपक्व हों, कंप्लायंस के लिए ट्रांज़ैक्शन इतिहास मायने रखता हो और कोई बड़ा पुनर्गठन चल न रहा हो।

किस पर ध्यान दें: साथ आने वाले तकनीकी कर्ज़ पर। पुरानी जटिलता तब तक आपके साथ चलती है, जब तक आप कन्वर्ज़न के दौरान जानबूझकर उसे साफ़ न करें।

सिलेक्टिव डेटा ट्रांज़िशन

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

कब चुनें: जब आप ग्रीनफ़ील्ड जैसी प्रोसेस की आज़ादी चाहते हों और जहाँ ज़रूरी हो वहाँ ब्राउनफ़ील्ड जैसी डेटा की निरंतरता।

बोर्ड आम तौर पर जो सवाल पूछते हैं, उन पर तीनों की तुलना यह है:

मापदंड	ग्रीनफ़ील्ड	ब्राउनफ़ील्ड	सिलेक्टिव
प्रोसेस का पुनर्डिज़ाइन	पूरा, SAP स्टैंडर्ड के हिसाब से	ज़्यादातर जस का तस	हर यूनिट के लिए चुना हुआ
ऐतिहासिक डेटा	आगे नहीं जाता (या सिर्फ़ ओपन आइटम और बैलेंस)	पूरी तरह आगे जाता है	चुना हुआ दायरा
go-live में लगने वाला समय	ज़्यादा	कम	दायरे पर निर्भर
तकनीकी कर्ज़	हट जाता है	साथ आता है	माइग्रेट हुए दायरे में घटता है
चेंज का असर	ज़्यादा	कम	मध्यम
किसके लिए सबसे अच्छा	बिखरा हुआ पुराना सिस्टम, बड़ा पुनर्डिज़ाइन	स्थिर, अच्छी तरह संभाला गया ECC	मर्जर, कार्व-आउट, चरणबद्ध रोलआउट

माइग्रेशन का क्रम

1. 01

   आकलन

   SAP Readiness Check चलाइए। कस्टम कोड, ऐड-ऑन और इंटरफ़ेस की सूची बनाइए।

2. 02

   डेटा वर्गीकरण

   डेटा को hot, warm और cold में बाँटिए। Cold डेटा को ले जाना ज़रूरी नहीं।

3. 03

   सफ़ाई

   डुप्लीकेट, गड़बड़ियाँ और खाली फ़ील्ड ठीक कीजिए। यह हमेशा योजना से ज़्यादा लगता है।

4. 04

   कोड में बदलाव

   ABAP Test Cockpit की जाँच चलाइए। Z-कोड घटाइए, सिर्फ़ पोर्ट मत कीजिए।

5. 05

   टेस्ट और कटओवर

   टेस्ट के कई राउंड और कम से कम एक पूरा कटओवर रिहर्सल।

1. आकलन और तैयारी

यहीं से शुरू कीजिए। हमेशा। SAP Readiness Check आपके ECC सिस्टम का विश्लेषण करता है और सरलीकरण आइटम, ऐड-ऑन की संगतता, कस्टम कोड, डेटा वॉल्यूम और साइज़िंग पर रिपोर्ट देता है।

चौंकाने वाली चीज़ें आम तौर पर ऐड-ऑन और कस्टम कोड निकलते हैं। मेरे कुछ क्लाइंट के दायरे में सैकड़ों कस्टम ऑब्जेक्ट थे, और ज़्यादातर को यह देखकर हैरानी हुई कि कितना निष्क्रिय कोड निकल आया। इसे दूसरे हफ़्ते में पकड़ना बारहवें महीने में पकड़ने से कहीं बेहतर है।

तकनीकी पूर्व-शर्तें भी उसी समय जाँच लीजिए। कन्वर्ज़न किसी भी एन्हांसमेंट पैकेज वाले SAP ERP 6.0 से हो सकता है। सिस्टम Unicode होना चाहिए, वरना दो चरणों में कन्वर्ज़न की योजना बनानी पड़ती है। Dual-stack सिस्टम को पहले अलग करना पड़ता है। ग्राहक और वेंडर मास्टर को कन्वर्ज़न से पहले बिज़नेस पार्टनर में बदलना ज़रूरी है। यह आखिरी बात किसी भी दूसरी बात से ज़्यादा टीमों को पकड़ लेती है।

2. डेटा का विश्लेषण और वर्गीकरण

डेटा को ले जाने से पहले उसे नापिए और छाँटिए:

1. Hot: अक्सर इस्तेमाल होता है, लाइव प्रोसेसिंग के लिए ज़रूरी।
2. Warm: कभी-कभार ज़रूरत पड़ती है, प्रासंगिक है पर रोज़ नहीं।
3. Cold: ऐतिहासिक या इस्तेमाल में न आने वाला, सिर्फ़ ऑडिट के लिए रखा गया।

Cold डेटा को S/4HANA में डालने की ज़रूरत नहीं। उसे आर्काइव कीजिए। जो टीमें यह चरण छोड़ देती हैं, वे नए सिस्टम में ऐसा कबाड़ ले आती हैं जो माइग्रेशन और परफ़ॉर्मेंस, दोनों को धीमा करता है।

3. डेटा की सफ़ाई और आर्काइविंग

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

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

4. कस्टम कोड में बदलाव

ABAP Test Cockpit (ATC) की S/4HANA readiness जाँचें चलाइए, जो आपके कोड की तुलना SAP के सरलीकरण आइटम से करती हैं। नतीजा बताता है कि किसमें सिंटैक्स ठीक करना है, किसकी जगह फ़ंक्शनल विकल्प चाहिए और किसे रिटायर कर देना चाहिए।

लक्ष्य कम Z-कोड है, सिर्फ़ चलने वाला Z-कोड नहीं। आप जो भी कस्टम ऑब्जेक्ट साथ ले जाते हैं, वह आगे हर अपग्रेड की लागत बढ़ाता है। मेरी क्लीन कोर गाइड बताती है कि जो बचे, उसे कैसे वर्गीकृत किया जाए।

5. टेस्टिंग, ट्रेनिंग और कटओवर

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

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

वे SAP टूल जो मैं किसी भी माइग्रेशन योजना में देखना चाहूँगा:

टूल	क्या करता है	कब इस्तेमाल करें
SAP Readiness Check	सरलीकरण आइटम, ऐड-ऑन, कस्टम कोड, साइज़िंग	रास्ता चुनने से पहले
ABAP Test Cockpit (ATC)	ऐसा कस्टम कोड ढूँढता है जो टूटेगा	कस्टम कोड में बदलाव के समय
SAP Signavio	दिखाता है कि प्रोसेस असल में कैसे चलते हैं, कागज़ पर कैसे दर्ज थे यह नहीं	डिज़ाइन फ़्रीज़ से पहले
SAP LeanIX	एप्लिकेशन और इंटरफ़ेस का नक्शा बनाता है	इंटीग्रेशन डिज़ाइन में
Software Update Manager (SUM)	तकनीकी कन्वर्ज़न चलाता है	ब्राउनफ़ील्ड कन्वर्ज़न में
SAP S/4HANA Migration Cockpit	मास्टर और ट्रांज़ैक्शनल डेटा लोड करता है	ग्रीनफ़ील्ड डेटा माइग्रेशन में

EHP 6 से 8 वाले SAP ERP 6.0 के लिए मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को खत्म होती है। वैकल्पिक एक्सटेंडेड मेंटेनेंस 31 दिसंबर 2030 तक चलती है, जिसके लिए मेंटेनेंस बेस पर दो प्रतिशत अंकों का अतिरिक्त शुल्क लगता है। पुराने एन्हांसमेंट पैकेज 2025 के अंत में ही मेनस्ट्रीम मेंटेनेंस से बाहर हो गए थे।

2030 के बाद एक ही संकरा रास्ता है। SAP का SAP ERP, private edition, ट्रांज़िशन विकल्प 2031 से 2033 को कवर करता है। यह सिर्फ़ उन बड़े सिस्टम पर लागू होता है जो 2030 के अंत से पहले SAP HANA पर SAP ERP, private edition में चले गए हों, और वह भी सिर्फ़ SAP के max success प्लान के साथ। इसे अपवाद मानिए, योजना नहीं।

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

1. 2027ECC की मेनस्ट्रीम मेंटेनेंस खत्म31 दिसंबर, SAP ERP 6.0 EHP 6 से 8 के लिए
2. 2028अभी शुरू करें तो संभावित go-liveअसली टेस्टिंग शुरू होने के बाद 18 से 24 महीने
3. 2030एक्सटेंडेड मेंटेनेंस खत्मवैकल्पिक, दो प्रतिशत अंकों के अतिरिक्त शुल्क पर
4. 2033ट्रांज़िशन विकल्प खत्मPrivate edition, सिर्फ़ बड़े सिस्टम के लिए

स्रोत: SAP News, फ़रवरी 2020 और अगस्त 2025

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

ग्रीनफ़ील्ड और ब्राउनफ़ील्ड ECC से S/4HANA माइग्रेशन में क्या अंतर है?

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

SAP ECC से S/4HANA माइग्रेशन की डेडलाइन क्या है?

EHP 6 से 8 वाले SAP ERP 6.0 के लिए मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को खत्म होती है। वैकल्पिक एक्सटेंडेड मेंटेनेंस 31 दिसंबर 2030 तक चलती है, जिसमें मेंटेनेंस बेस पर दो प्रतिशत अंकों का अतिरिक्त शुल्क लगता है। 2031 से 2033 का ट्रांज़िशन विकल्प सिर्फ़ उन बड़े सिस्टम के लिए है जो 2030 के अंत से पहले SAP HANA पर SAP ERP, private edition में चले गए हों।

SAP Readiness Check क्या बताता है?

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

ECC से S/4HANA माइग्रेशन में कितना समय लगता है?

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

Universal Journal (ACDOCA) क्या है और माइग्रेशन के लिए यह क्यों मायने रखता है?

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

ECC को S/4HANA में कन्वर्ट करने की तकनीकी पूर्व-शर्तें क्या हैं?

कन्वर्ज़न किसी भी एन्हांसमेंट पैकेज वाले SAP ERP 6.0 से हो सकता है। सिस्टम Unicode होना चाहिए, नहीं तो दो चरणों वाला तरीका अपनाइए। Dual-stack सिस्टम को पहले अलग करना ज़रूरी है। ग्राहक और वेंडर मास्टर को बिज़नेस पार्टनर में बदलना होगा। तारीख़ें पक्की करने से पहले SAP Readiness Check और ATC के कस्टम कोड चेक चला लीजिए।

ECC माइग्रेशन के लिए मुझे RISE with SAP चुनना चाहिए या GROW with SAP?

कस्टम कोड और जटिल प्रोसेस वाले ज़्यादातर ECC ग्राहक RISE with SAP के तहत S/4HANA Cloud Private Edition पर जाते हैं, जो मौजूदा सिस्टम के कन्वर्ज़न को सपोर्ट करता है। GROW with SAP में Public Edition है, जो स्टैंडर्ड प्रोसेस और सिर्फ़ रिलीज़्ड-API एक्सटेंशन वाला नया इम्प्लीमेंटेशन है। यह उन कंपनियों के लिए ठीक है जो SAP का स्टैंडर्ड अपनाने को तैयार हैं।