SAP S/4HANA Implemented Once, Implemented Right.

These three terms describe the approach to handling existing SAP ECC data and configuration when moving to S/4HANA, and the choice between them is the most consequential decision in any ECC-to-S/4HANA programme. Brownfield (also called Shell Conversion or System Conversion) means technically migrating your existing ECC system — its full configuration, all historical data, and all customisations — to S/4HANA using SAP's SUM/DMO tool. The business processes remain as they are in ECC; the main work is making the technical migration succeed and adapting custom code that is incompatible with S/4HANA's simplified data model. This is the fastest and lowest-change-management-risk approach, but it also captures the least S/4HANA business value because you are running ECC processes in an S/4HANA technical shell rather than adopting S/4HANA's simplified architecture. Greenfield means implementing S/4HANA as a new system — using SAP Best Practice processes as the design baseline and migrating only master data and open balances rather than full historical transaction data. This captures the maximum business value (full Universal Journal benefits, embedded analytics, process simplification) but carries higher change management risk because business users are adopting new processes rather than familiar ones. Selective Data Migration (SDM) is a hybrid approach that allows organisations to reimport historical data from ECC into a newly configured S/4HANA system — combining some of the process redesign opportunity of greenfield with historical data retention. It is more complex to execute than either pure approach and is most appropriate when specific modules need full process redesign while others can be migrated with minimal change. We help organisations choose the right approach through a structured assessment that considers customisation volume, data quality, change management capacity, and the specific business value opportunities available from S/4HANA in your context.

SAP has announced 2027 as the end of mainstream maintenance for SAP ECC, with extended maintenance available until 2030 for an additional fee — and SAP has been consistent in signalling that 2030 is a genuine hard deadline after which ECC will no longer receive security patches, legal change patches, or support. The urgency of this deadline for your organisation depends on several factors: how long your S/4HANA migration will take (a complex greenfield implementation for a large, multi-entity organisation can take 24–36 months, which means organisations that have not started planning by 2024–2025 will struggle to be live before the 2027 deadline), whether you need India legal change patches for GST regulation changes after 2027 (these will not be available for ECC on mainstream maintenance), and the competitive cost pressure of running an increasingly expensive on-premise ECC landscape while competitors on RISE with SAP benefit from continuous S/4HANA feature investment. Our honest assessment: the 2027 deadline is real and organisations that have not started their S/4HANA migration planning by 2025 will face either an extended maintenance cost, a rushed migration, or a period of running without current security patches — none of which are attractive. The best time to start the migration planning was two years ago; the second best time is now.

RISE with SAP is SAP's bundled offering for moving to S/4HANA Cloud (public or private cloud) — it combines the S/4HANA Cloud ERP licence, the cloud infrastructure (on SAP's chosen hyperscaler — AWS, Azure, or GCP depending on your region), the SAP Business Technology Platform (BTP) entitlements, and SAP's technical migration service into a single subscription contract. The appeal of RISE is the simplification of the commercial arrangement and the elimination of on-premise infrastructure costs and Basis management overhead. The right fit assessment for RISE depends on: whether your organisation's customisation and extension requirements can be met within the clean-core (extension-only, no modification) architecture that RISE with SAP requires — organisations with very extensive legacy ABAP modifications may find clean-core compliance difficult and may be better served by on-premise S/4HANA; whether your data sovereignty requirements (particularly for BFSI and defence sector organisations in India) can be met by SAP's cloud infrastructure in the India region; and whether the total cost of RISE subscription over a 5-year horizon is competitive with on-premise S/4HANA licensing and infrastructure TCO for your scale. We are neutral on the RISE vs. on-premise decision and will help you model the full 5-year TCO for each option alongside the functional implications before you commit.

SAP's eDocument framework for India GST e-invoice is not a simple configuration activity — it involves configuration in multiple areas of SAP that must work correctly together, and in our experience it is consistently underestimated in scope by implementation teams who have not done it before. The configuration scope covers: TAXINN tax procedure setup for GST tax codes and condition types; output type configuration for the eDocument framework trigger; tax determination procedure configuration for place of supply rules; eDocument connector configuration for the GSTN IRP API endpoint (production and sandbox); GSTIN management for multi-GSTIN scenarios; e-invoice exclusion logic for transactions that are exempt from e-invoice (B2C transactions below the turnover threshold, SEZ supplies, exports with LUT); e-way bill integration configuration for goods movement; IRN number storage and print output design with QR code embedding; and error handling and re-submission workflow for rejected e-invoice submissions. In a focused engagement, a properly configured and tested India eDocument implementation takes 6–8 weeks — more if the underlying TAXINN configuration was not correctly set up initially. Organisations that go live with SAP without e-invoice configured and then discover the gap when they first invoice a B2B customer above the e-invoice threshold face an urgent post-go-live remediation that is significantly more expensive and operationally disruptive than getting it right during implementation.

SAP PI/PO (Process Integration / Process Orchestration) is approaching end of mainstream maintenance alongside ECC — which means organisations running PI/PO for their SAP integrations should plan the migration to BTP Integration Suite as part of their broader S/4HANA programme rather than treating it as a separate future project. The migration complexity depends primarily on the size and nature of your PI/PO interface inventory. Simple message-mapping-based interfaces (flat-file to IDOC, REST to IDOC, SOAP to SOAP) can be migrated to BTP iFlows relatively straightforwardly. Complex PI/PO scenarios involving the Business Process Engine (BPE) for multi-step workflow orchestration, Java mapping programs, or deeply customised Adapter Modules require more significant re-engineering work. Our recommended approach is a PI/PO interface inventory and complexity assessment first — typically a 2–4 week engagement — that categorises your interface portfolio by migration complexity and provides a phased migration roadmap with effort estimates per interface tranche. The migration should then proceed in tranches (simpler interfaces first) with parallel operation maintained during each interface tranche's migration so no production integration is ever cut over without a tested BTP replacement in place. For most mid-size SAP landscapes (20–60 PI/PO interfaces), the migration takes 16–24 weeks when run as a dedicated programme alongside the S/4HANA migration.