S/4HANA माइग्रेशन की समय-सीमा और रास्ते के हिसाब से प्रोजेक्ट प्लान

मेरे अनुभव में SAP ECC से S/4HANA माइग्रेशन की समय-सीमा brownfield conversion के लिए 12 से 18 महीने और greenfield implementation के लिए 18 से 24 महीने होती है। Selective data transition में 12 से 18 महीने लगते हैं। प्रोजेक्ट प्लान SAP Activate के छह चरणों पर चलता है, और जो चरण सबसे ज़्यादा बार overrun होता है, वह है custom code।

छोटा जवाब: प्लान की शुरुआत SAP Readiness Check से कीजिए और डेटा को 30 से 40 प्रतिशत प्रयास दीजिए। Brownfield पर तीन mock conversions की योजना बनाइए और cutover downtime एक weekend से लेकर एक हफ़्ते तक कुछ भी होने की उम्मीद रखिए।

यह लेख मेरी ECC से S/4HANA माइग्रेशन गाइड के पीछे का समय-सीमा और planning का ब्योरा है, जो रास्तों और ECC की डेडलाइन को कवर करती है। अगर आप ECC से हटने के बजाय पहली बार SAP लागू कर रहे हैं, तो मेरी SAP implementation timeline गाइड उस स्थिति को चरणों की अवधि के साथ कवर करती है।

रास्ता ही लंबाई तय करता है। मेरा नियम: जब आप दूसरे सिस्टम से आ रहे हों या नई प्रक्रियाएँ तय करनी हों, तब greenfield। जब प्रक्रियाएँ तय हैं और चल रही हैं तब brownfield, और जब कुछ क्षेत्रों की प्रक्रियाएँ दोबारा तय करनी हों तब selective।

जिन प्रोग्राम्स को मैंने देखा है, उनमें हर रास्ते में इतना समय लगता है, और आमतौर पर यह चीज़ें उसे लंबा खींचती हैं:

रास्ता	आम समय-सीमा	प्लान किस चीज़ के इर्द-गिर्द बनता है	आमतौर पर क्या लंबा खींचता है
Brownfield (system conversion)	12 से 18 महीने	मौजूदा ECC सिस्टम को Software Update Manager से convert करना, फिर बार-बार test conversions	Custom code का adaptation और business partner conversion
Greenfield (नया implementation)	18 से 24 महीने	Fit-to-standard डिज़ाइन, build और बार-बार data load cycles	Explore workshops जो लंबी requirement lists बन जाती हैं, और data cleansing
Selective data transition	12 से 18 महीने	यह तय करना कि कौन से company codes, units और history जाएँगे, फिर विशेष tooling	Data scoping और विशेषज्ञ partners पर निर्भरता

कैलेंडर उतना ही मायने रखता है जितना रास्ता। Enhancement package 6 से 8 पर चल रहे ECC के लिए mainstream maintenance 31 दिसंबर 2027 को खत्म होता है (SAP News)। इस महीने शुरू हुआ brownfield अक्टूबर 2027 से अप्रैल 2028 के बीच go-live करता है, और अभी शुरू हुआ greenfield 2028 में पहुँचता है।

इसलिए आज लिखे गए ज़्यादातर प्लान को बजट में कुछ extended maintenance चाहिए। इसे शुरुआत में ही रखिए, दूसरे साल में किसी झटके की तरह नहीं।

RISE with SAP एक commercial package है, रास्ता नहीं। RISE के तहत brownfield या selective माइग्रेशन SAP Cloud ERP Private पर पहुँचता है, जो उस चीज़ का मौजूदा नाम है जो SAP इस्तेमाल करता है जिसे बहुत से लोग अब भी S/4HANA Cloud Private Edition के नाम से खोजते हैं। GROW with SAP के लिए मैं जो 6 से 9 महीने बताता हूँ और RISE के लिए 9 से 18 महीने, वे नए implementations के लिए हैं, ECC माइग्रेशन के लिए नहीं।

SAP Activate, S/4HANA के लिए SAP का delivery method है। इसके छह चरण हैं: Discover, Prepare, Explore, Realize, Deploy और Run (SAP Activate)।

माइग्रेशन भी इन्हीं चरणों का इस्तेमाल करता है। जो बदलता है, वह हर चरण के अंदर का काम है।

माइग्रेशन प्रोजेक्ट प्लान

1. 01

   Discover

   Readiness Check, रास्ते का फ़ैसला और business case।

2. 02

   Prepare

   प्लान, governance, टीम और पहला sandbox।

3. 03

   Explore

   Fit-to-standard या delta डिज़ाइन, WRICEF list पर सहमति।

4. 04

   Realize

   Build, custom code, data loads, test conversions।

5. 05

   Deploy

   Dress rehearsal, cutover और go-live।

6. 06

   Run

   Hypercare, स्थिरता और ECC को बंद करना।

माइग्रेशन में हर चरण में यह होता है, और यहाँ रास्ते अलग होते हैं:

चरण	माइग्रेशन में क्या होता है	रास्ते कैसे अलग होते हैं
Discover	SAP Readiness Check, रास्ते का फ़ैसला, business case, custom code और डेटा की पहली झलक	Selective को यहीं पहला data scope चाहिए
Prepare	प्लान, governance, टीम, data ownership, sandbox	Brownfield पहला sandbox conversion चलाता है; greenfield सिस्टम और workshop schedule तैयार करता है
Explore	Fit-to-standard workshops या delta डिज़ाइन, WRICEF list पर सहमति, data mapping	Greenfield सबसे ज़्यादा समय यहीं लगाता है; brownfield लागू होने वाले simplification items पर काम करता है
Realize	Build, custom code adaptation, data load cycles, test rounds	Brownfield mock conversions चलाता है; greenfield load cycles चलाता है, आमतौर पर Migration Cockpit से
Deploy	Dress rehearsal, cutover, go-live	Downtime window रास्ते, data volume और approach पर निर्भर करती है
Run	Hypercare, स्थिरता	ECC को बंद कीजिए और जो रखा है उसे archive कीजिए

WRICEF का मतलब है workflows, reports, interfaces, conversions, enhancements और forms। यह उन सब चीज़ों की list है जो आप SAP के standard से आगे बनाते हैं, और यही वह संख्या है जिस पर नज़र रखनी है।

जिन 21 SAP प्रोग्राम्स का मैंने नेतृत्व किया है या जिन्हें संकट से निकाला है, उनमें सबसे बड़ी गलती है implementation की शुरुआत में ठीक से योजना न बनाना। Prepare में तय कीजिए कि data cleansing की ज़िम्मेदारी किसकी है, कौन सा custom code हटेगा और हर test conversion और rehearsal कब होगा। यही तारीखें प्लान की रीढ़ बनती हैं।

Brownfield: test conversions के इर्द-गिर्द योजना

Brownfield प्लान conversion cycle के इर्द-गिर्द बनता है। Software Update Manager सिस्टम को convert करता है, और हर test run बताता है कि असली conversion में कितना समय लगेगा और क्या टूटेगा।

Brownfield पर मैं cutover से पहले तीन mock conversions की योजना बनाता हूँ। हर एक production की हाल की copy पर चलना चाहिए, ताकि timings का कोई मतलब हो। आखिरी वाला go-live की तरह चलना चाहिए: वही क्रम, वही लोग, वही checks।

SAP का अपना प्लान भी, उसके downtime-optimized approach के लिए, कुछ ऐसा ही है। उसमें एक sandbox run, एक quality assurance run, एक clone पर load verification और एक dress rehearsal शामिल है (SAP Learning)। SAP कहता है कि तकनीकी रूप से कम runs संभव हैं, लेकिन उनसे जोखिम बढ़ता है।

Greenfield: डिज़ाइन और data loads के इर्द-गिर्द योजना

Greenfield का समय Explore में जाता है। Fit-to-standard workshops तय करती हैं कि आप SAP के standard का कितना हिस्सा अपनाते हैं, और हर gap एक WRICEF object बन जाता है जिसे बनाना, test करना और maintain करना पड़ता है।

डेटा load cycles में जाता है, आमतौर पर SAP S/4HANA Migration Cockpit से। कई पूरे load cycles की योजना बनाइए, हर एक के बाद ऐसा reconciliation जिस पर business sign करे। मेरी Migration Cockpit step-by-step गाइड staging tables, migration objects और load process को कवर करती है।

Selective: data scope के इर्द-गिर्द योजना

Selective प्लान data scope से शुरू होता है। कौन से company codes, business units और कितने सालों की history जाएगी, और किन प्रक्रियाओं को नया डिज़ाइन मिलेगा।

वही scope tools, विशेषज्ञ partner और test cycles तय करता है। इसे देर से बदलिए और समय-सीमा भी उसके साथ खिसक जाती है।

मेरे अनुभव में custom code वह चरण है जो सबसे ज़्यादा बार overrun होता है। यह माइग्रेशन की वह छिपी लागत भी है जिसे सबसे ज़्यादा भुला दिया जाता है, और मेरी S/4HANA माइग्रेशन cost गाइड इसे कवर करती है।

ये वे जगहें हैं जिन पर मैं नज़र रखूँगा, इसी क्रम में:

1. Custom code. टीमें इसका scope एक report से तय करती हैं, फिर remediation शुरू होने पर असली आकार पता चलता है। एक प्रोग्राम में smartShift के साथ विश्लेषण ने custom objects को 18,000 से घटाकर 3,200 कर दिया। पहले हटाइए, फिर adapt कीजिए।
2. वे custom objects जो assessment से छूट गए। मेरे अनुभव में जो custom objects SAP Readiness Check से छूट जाते हैं, वही बाद में तकलीफ़ देते हैं। उसके output को अपना scope मानने से पहले मेरी SAP Readiness Check गाइड पढ़िए।
3. डेटा. Data migration में 30 से 40 प्रतिशत प्रयास लगता है। जब cleansing का कोई owner नहीं होता तो यह देर से शुरू होता है, फिर test cycles को दबा देता है। SAP data migration क्यों विफल होता है पर मेरा लेख इसमें और गहराई से जाता है।
4. Explore. बजट Explore में चोट खाते हैं, क्योंकि WRICEF list बढ़ती जाती है। जब scope vendor के हाथ में होता है, तो vendor की तरफ़ किसी के पास उसे बढ़ने से रोकने की कोई वजह नहीं होती।
5. समय बचाने के लिए काटे गए rehearsals. तारीख बचाने के लिए छोड़ा गया rehearsal आमतौर पर go-live weekend पर उससे ज़्यादा समय खा जाता है जितना उसने बचाया था।

मेरी राय: go-live की तारीख Explore के अंत में तय कीजिए, जब WRICEF list और custom code का scope पता हो। Kickoff पर तय की गई तारीख बस एक अनुमान है, जिसके साथ बोर्ड presentation जुड़ा है।

मैंने cutover downtime एक weekend से लेकर एक हफ़्ते तक देखा है। Data volume, conversion approach, एक साथ go-live करने वाली entities और interfaces की संख्या, और business कितनी जल्दी validate कर सकता है, ये सब इसे आगे-पीछे करते हैं।

Brownfield के लिए SAP, Software Update Manager में एक downtime-optimized conversion approach देता है। यह data conversion और migration के एक हिस्से को uptime में ले जाता है, जबकि production चलता रहता है।

यह मुफ़्त का समय नहीं है। SAP अतिरिक्त test runs, ज़्यादा जटिल planning, downtime से पहले customizing और development पर freeze, और इस approach में प्रशिक्षित एक expert की ज़रूरत बताता है।

इसलिए तकनीकी approach चुनने से पहले वह downtime तय कीजिए जिसे business स्वीकार कर सकता है। फिर उसे mock conversions में साबित कीजिए, go-live weekend पर नहीं। Cutover को month-end close और peak season से दूर रखिए।

कोई प्लान उतना ही अच्छा है जितनी उसके पीछे की मान्यताएँ। किसी के sign करने से पहले मैं ये सवाल पूछूँगा:

1. प्लान कौन सा रास्ता मानकर चल रहा है, और हमारे Readiness Check के नतीजों में क्या उसका समर्थन करता है?
2. Usage analysis के बाद कितने custom objects scope में हैं, और कितने हटाए जाएँगे?
3. Data cleansing की ज़िम्मेदारी किसकी है, और यह किस चरण में शुरू होता है?
4. कितने mock conversions या load cycles की योजना है, और किस डेटा पर?
5. प्लान कितना downtime मानकर चल रहा है, और कौन सा test run उसे साबित करता है?
6. तारीख कब तय होती है, और अगर Explore में WRICEF list बढ़ती है तो उसका क्या होता है?

Partner से आपके जैसे प्रोग्राम्स के references और उनका high-level डिज़ाइन माँगिए। अगर जवाब generic हैं और आपके business के हिसाब से नहीं हैं, तो इसे खतरे का संकेत मानिए।

इसी तिमाही में SAP Readiness Check चलाइए। किसी के go-live की तारीख पर हामी भरने से पहले custom code और डेटा के निष्कर्ष CFO और program director के सामने रखिए।

फिर प्लान को उस cutover window से उल्टा बनाइए जिसे आप स्वीकार कर सकते हैं, brownfield पर तीन mock conversions के साथ या उन load cycles के साथ जिनकी आपके रास्ते को ज़रूरत है। पहले रास्ते को ही परखने के लिए मेरा greenfield बनाम brownfield माइग्रेशन assessment आज़माइए।

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

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

मेरे अनुभव में ECC से brownfield conversion में 12 से 18 महीने, greenfield implementation में 18 से 24 महीने और selective data transition में 12 से 18 महीने लगते हैं। Custom code वह चरण है जो सबसे ज़्यादा बार overrun होता है, और data migration में 30 से 40 प्रतिशत प्रयास लगता है।

S/4HANA माइग्रेशन प्रोजेक्ट प्लान के चरण कौन से हैं?

प्लान SAP Activate पर चलता है: Discover, Prepare, Explore, Realize, Deploy और Run। माइग्रेशन में Discover में Readiness Check और रास्ते का फ़ैसला होता है, Realize में custom code, data loads और test conversions, और Deploy में dress rehearsal और cutover।

S/4HANA brownfield माइग्रेशन के लिए कितने mock conversions चाहिए?

Brownfield पर मैं cutover से पहले तीन mock conversions की योजना बनाता हूँ। अपने downtime-optimized approach के लिए SAP एक sandbox run, एक quality assurance run, एक load verification और एक dress rehearsal तय करता है, और कहता है कि कम runs से जोखिम बढ़ता है।

S/4HANA cutover downtime कितना लंबा होता है?

मैंने cutover downtime एक weekend से लेकर एक हफ़्ते तक देखा है। यह data volume, conversion approach और इस पर निर्भर करता है कि कितनी entities और interfaces एक साथ go-live करते हैं। SAP का downtime-optimized conversion काम के एक हिस्से को uptime में ले जाता है, लेकिन इसके लिए ज़्यादा test runs और planning चाहिए।

क्या हम 2027 में ECC support खत्म होने से पहले S/4HANA माइग्रेशन पूरा कर सकते हैं?

Enhancement package 6 से 8 पर चल रहे ECC के लिए mainstream maintenance 31 दिसंबर 2027 को खत्म होता है। अक्टूबर 2026 में शुरू हुआ brownfield अक्टूबर 2027 से अप्रैल 2028 के बीच go-live करता है, और greenfield 2028 में। अभी शुरू होने वाले ज़्यादातर प्रोग्राम्स को कुछ extended maintenance का बजट रखना चाहिए।

S/4HANA माइग्रेशन प्रोजेक्ट्स में सबसे ज़्यादा देरी किस वजह से होती है?

मेरे अनुभव में सबसे ज़्यादा बार custom code overrun होता है, उसके बाद देर से शुरू होने वाला data cleansing और Explore में लगातार बढ़ती WRICEF list। इनमें से ज़्यादातर की जड़ प्रोग्राम की शुरुआत में ठीक से योजना न बनाना है।