The SAP Modernisation Decision Tree

Stop choosing the commercial wrapper before you have chosen the architecture

A decision framework for Gulf and India enterprises. Altivate | Published 12 April 2026 | Updated 26 July 2026

1. “RISE or GROW?” is not a transformation decision

Ask most SAP buyers in the Gulf what they are deciding and you will hear “RISE or GROW.” That question arrives too early. It invites a commercial answer before the enterprise has made the architecture, migration and operating-model decisions that create the cost.

SAP positions RISE with SAP primarily for established customers running a broader transformation and SAP GROW primarily for a faster, defined-scope move to public cloud ERP. That is a fit distinction, not a hard eligibility line. SAP now states explicitly that GROW is also available to existing customers migrating from older on-premise systems.

Which means:

That last point is where the money is. SAP’s own August 2025 update describes organisations “transitioning to SAP S/4HANA Cloud Private Edition and SAP S/4HANA Cloud Public Edition” as part of the RISE with SAP journey. SAP’s training material is more explicit still: it is common for customers to run both editions under RISE in a two-tier ERP arrangement – public edition at the subsidiaries, private at headquarters – and SAP maintains a dedicated onboarding path for RISE with public edition.

So the practitioner shorthand “RISE wraps private, GROW wraps public” is commercially common and architecturally incomplete. If you believe RISE is private edition, then choosing RISE feels like a procurement decision. It isn’t. You have chosen single-tenant hosting, retained custom ABAP and customer-controlled upgrade windows – three constraints with a decade of cost attached – without ever having compared them to the alternative, and you have quietly foreclosed the two-tier option that may be the right answer for a group with standardised subsidiaries.

This paper therefore orders the decision the way the architecture actually orders it:

1. Where does your estate stand, and how much time do you actually have? (§2)
2. Public or private edition? (§3)
3. Greenfield, brownfield or bluefield? (§4)
4. Does a regional data-classification or sector rule override 2 and 3? (§5)

The commercial wrapper – RISE, GROW, or a direct licence – is attached last. It is the consequence of the first four answers, not the input to them.

The naming has also moved underneath buyers, which is a large part of why the confusion persists. In July 2025 SAP simplified the product names: SAP S/4HANA Cloud Public Edition → SAP Cloud ERP, and SAP S/4HANA Cloud Private Edition → SAP Cloud ERP Private. SAP’s own August 2025 article uses both new names. Most material currently ranking in search still uses the previous ones – so a buyer researching this topic is reading two vocabularies describing the same two products, written as though they were four.

Background: RISE with SAP and GROW with SAP as SAP positions them, and our own RISE vs GROW comparison.

2. The clock: for a real slice of estates, it already ran out

The industry has spent three years talking about “the 2027 deadline.” For many Gulf and India estates that framing is no longer current: their mainstream-maintenance date has already passed.

SAP’s maintenance timeline for SAP ERP 6.0 is tiered by Enhancement Package level, and the two tiers have completely different consequences:

If you are on EHP 0-5, this is not a deadline. It already happened. Your system is no longer receiving legal and regulatory change delivery. In a region where VAT treatment, e-invoicing mandates and payroll statutory rules have all moved inside the last three years, that is a live compliance exposure, not a roadmap item.

This is also the single easiest thing in this paper to check against your own system. Your basis team can tell you your EHP level in about five minutes. Ask.

The 2031-2033 option is a bridge with a toll, not an extension

SAP’s August 2025 update describes an SAP ERP, private edition, transition option providing “business continuity from 2031 to 2033 while enabling a structured path to SAP Cloud ERP or SAP Cloud ERP Private.” Read the eligibility conditions before treating it as breathing room – from that same article:

• The system must migrate to SAP ERP, private edition on SAP HANA before 31 December 2030. SAP HANA is “the only supported database for this offering.”
• A minimum system size of 2 TB applies to systems subscribed with the transition option.
• It must be combined with the max success plan (available January 2026).
• Pricing is time-dependent: customers committing by the end of 2025 received equivalent pricing with no uplift; those signing up in 2026 face a standard 20% uplift when switching to the transition option in 2031. Pricing beyond 2027 is undisclosed.

So the 2031-2033 window is available to customers who have already done most of the work – moved to private edition on HANA – and who commit commercially. It is aimed at large, complex estates that cannot finish by 2030. It is not a reason for anyone to wait.

The honest summary of the clock: if you are on EHP 0-5, you are already past it. If you are on EHP 6-8, you have until end-2027 at standard cost, end-2030 at a premium, and a conditional bridge to 2033 that requires you to have migrated anyway. None of these outcomes is improved by delay, and the one that costs least requires deciding earliest.

Related: should we upgrade from SAP ECC to SAP S/4HANA works through the same clock from the ECC side.

3. Decision Point 1 – Public or private edition

This is the decision that sets your ceiling. Strip the marketing language and it comes down to five operational constraints:

The trade-off is genuinely two-sided, and any paper that tells you one edition is simply better is selling you something.

Public edition’s constraint is its feature. Enforced clean core and mandatory updates are the mechanism by which you stop accumulating the technical debt that made your ECC upgrade a multi-year programme in the first place. Organisations that adopt public edition and then fight its constraints get the worst of both.

Private edition’s flexibility is its liability. Retaining custom ABAP means retaining the cost of owning it – and a private-edition migration that lifts twenty years of modifications across unchanged has moved the problem to a new data centre rather than solved it.

The question that actually decides it is not “how much customisation do we have?” – everyone has more than they think – but “how much of our customisation encodes something we compete on?” Custom code that encodes a genuinely differentiated process is worth carrying. Custom code that exists because someone in 2011 preferred a different screen layout is not, and a public-edition evaluation is the cheapest forcing function anyone will ever give you for finding out which is which.

In more depth: SAP public cloud vs private cloud explained.

4. Decision Point 2 – Greenfield, brownfield, or bluefield

These are the informal names. SAP’s own terminology is different, and it is worth knowing both, because vendors use one set and buyers search for the other:

A note on the name: “Bluefield” is SNP Group’s trademark, not an SAP term. SAP’s own term is Selective Data Transition. This matters when reading vendor material – a partner using “bluefield” may be describing SNP’s tooling specifically or using the word generically, and those are different conversations to have about tooling lock-in.

The selection criteria that actually discriminate:

• How much process history must survive? Not “how much data” – data can be archived or kept in a separate store. The question is how much of your operating model is encoded in the current configuration and must be preserved intact.
• What is your appetite for process redesign? Greenfield is a redesign programme wearing a migration costume. If the organisation has no appetite for changing how it works, greenfield will fail on change management long before it fails on technology.
• How much custom code, and how much of it is load-bearing? See §3.
• Timeline and risk tolerance. Brownfield is generally the shortest path to a technically equivalent system and the longest path to a materially better one.

The cross-reference most buyers miss: a true brownfield conversion of a heavily customised ECC system requires private edition. This is not our inference – SAP’s own training material states that public edition “is always implemented in a greenfield (new implementation) scenario.” Public edition’s clean-core enforcement is fundamentally incompatible with carrying arbitrary custom ABAP forward.

So Decision Point 2 can retroactively constrain Decision Point 1, and the constraint runs one way: choosing brownfield chooses private edition for you. That is precisely why the two must be evaluated as one decision on two axes rather than sequentially – and why a buyer who has quietly assumed brownfield (“we’ll just convert what we have”) has, without noticing, also assumed a decade of retained-customisation cost.

Method detail, one walkthrough each: greenfield, brownfield and bluefield.

5. Decision Point 3 – The Gulf and India regulatory overlay

This is the branch global RISE/GROW content never draws, and it is why a Gulf or India buyer cannot read a European decision guide and substitute their own currency.

The structural point first, because it is the one most often got wrong: in all three markets, the general data-protection law is usually not what forces in-country residency. Sector rules and data classification are. A privacy statute may permit cross-border transfer with safeguards while a health, banking or public-sector rule mandates in-country storage regardless. Get this backwards and you will either over-engineer a private-edition deployment you didn’t need, or discover a binding constraint after you’ve signed.

All positions stated as of 26 July 2026. Regulatory sourcing status is listed at the end; where an instrument could not be read directly, this section says so.

Saudi Arabia

Two independent questions, neither of which is “which hyperscaler?”

Is it Saudi Government Data? CST – the Communications, Space & Technology Commission, renamed from CITC in 2022 – administers the cloud rules. Note that the widely cited “CCRF v3” is no longer current: it was superseded by the Cloud Computing Services Provisioning Regulations, in force since 10 October 2023. Under the v3-era framework the classification was two-tier, not the three-tier “Government / Restricted / Public” that circulates in vendor content: Saudi Government Data (with four sub-levels – Top Secret, Secret, Confidential, Public) and Non-Government Data. Saudi Government Data could not leave the Kingdom at all absent explicit legal permission. Whether the 2023 regulations preserved that exact structure is something we could not confirm against CST’s own text, so treat the shape as indicative and the currency of the instrument as the checkable fact.

Does personal data cross the border? The PDPL and its September 2023 Implementing Regulation run an adequacy model – transfers are permitted to countries SDAIA designates as adequate. SDAIA has published no adequacy list as of July 2026. In practice that means every cross-border transfer needs a documented legal route. Available mechanisms include Standard Contractual Clauses, Binding Corporate Rules and, where their conditions are met, an accreditation-certificate route; the regulations also contain limited exceptions. SDAIA’s February 2025 Risk Assessment Guidelines – a four-phase methodology – support that documentation but are non-binding guidance, not an amendment. The applicable route, conditions and transfer-risk assessment are entity- and processing-specific: obtain a current legal determination rather than selecting one from this summary. The PDPL became fully enforceable in September 2024.

On hyperscalers, one correction worth making because vendors repeat the error. SAP BTP became available on Google Cloud in Saudi Arabia on 13 January 2025, scoped specifically to regulated customers – government plus private-sector Critical National Infrastructure operators. That announcement claims no exclusivity, and the scoping reflects the regulatory segment, not a limitation of other providers. Meanwhile AWS’s Riyadh region reportedly reached general availability in January 2026, and Microsoft’s Azure Saudi Arabia East is expected from Q4 2026 per Microsoft’s own February 2026 update, with construction complete. Anyone telling you there is one compliant Saudi hyperscaler is describing 2024.

UAE

The most important UAE fact is a negative one. The federal PDPL – Federal Decree-Law No. 45 of 2021 – states a cross-border transfer principle, but its Executive Regulations have still not been issued, more than four and a half years after enactment, per the 2026 edition of the Chambers data-protection guide, which attributes “limited enforcement activity and a cautious regulatory stance” to exactly that gap. There is no detailed federal rulebook to comply against yet. Any consultant presenting UAE federal privacy compliance as a settled, documented regime is describing something that does not exist.

What actually forces in-UAE storage is sector rules that never waited on the PDPL. Under Article 13 of the 2019 federal health-data law, health data relating to health services provided inside the UAE cannot be stored, processed, generated or transformed outside the country unless the Health Authority, in coordination with the Ministry, issues a decision. The law applies to health-field ICT across the UAE, including free zones. Separately, CBUAE Consumer Protection Standards 6.1.6.3 require licensed financial institutions to hold and store consumer and transaction data inside the UAE as prescribed by the Central Bank. These are scoped sector obligations, not a claim that every UAE workload must remain in-country; confirm entity, dataset and exception scope with current counsel.

Then there is domicile, which catches people out. DIFC and ADGM run their own data- protection laws – DIFC Law No. 5 of 2020, amended July 2025; ADGM Regulations 2021, amended September 2025 – and the mainland federal PDPL expressly excludes entities operating through those zones. More surprising: moving data from UAE mainland into DIFC or ADGM is itself treated as a cross-border transfer, requiring its own assessment, despite both sitting geographically inside the UAE. For a group with a DIFC holding company and mainland operating entities, that is a real architectural constraint, not a paperwork detail.

India

India’s general position is likely to remain permissive, but the timing matters. The DPDP Rules were notified on 13 November 2025, while the Gazette phases the substantive provisions that include the cross-border framework into force 18 months later, in May 2027. Section 16’s negative-list model and Rule 13(4)’s restriction for specified data of Significant Data Fiduciaries are therefore future design requirements, not operative July 2026 law. Build the transfer inventory and contractual controls now, then re-check the commencement position and any restricted-country notification before relying on the model.

What does force residency is sectoral, and narrower than the folklore. RBI’s directive, Storage of Payment System Data, 6 April 2018 – requires only that data relating to payment systems operated in India be stored in India, and applies to authorised payment system operators and specific bank categories. It is not “all Indian financial data must stay in India,” which is how it is routinely paraphrased. SEBI’s broader push exists but is paused: the “regulatory data must be stored and processed in India” clause added to its August 2024 cyber-security framework was placed in abeyance in December 2024 and remained so through this review. And IRDAI’s 2017 outsourcing regulations bar insurers from outsourcing core functions at all and require audit and access rights to survive any permitted overseas outsourcing – a functions-and-control model, not a residency mandate.

What this does to the tree

If a classification or sector rule applies, it constrains the eligible service, region, operating model and transfer design. It does not automatically choose public or private edition. First confirm that the required services are generally available in an approved region and that the provider’s data flows satisfy the rule; then compare the editions that remain eligible. If no binding rule applies, residency is not a reason to choose private edition.

Classify the data first. Choose infrastructure second.

For the Saudi case specifically: greenfield, brownfield and bluefield S/4HANA migration in KSA.

6. The decision tree

Read the tree in that order. The commercial wrapper sits at the bottom because it is the consequence of the four decisions above it. Every buyer who starts at the bottom ends up defending a choice they never made.

7. Three worked profiles

The test of a decision framework is whether it discriminates. If every path leads to “RISE with private edition,” it is a sales funnel with a flowchart drawn on it. These three composite profiles – illustrative constructions, not clients – land in three different places.

Profile A – Large Saudi enterprise, public-sector-adjacent, ECC EHP 7, deep custom ABAP, holding data that falls within the Saudi Government Data classification. The regulatory gate first narrows the design to service-region combinations that counsel and the data owner approve. Deep custom ABAP then makes System Conversion or Selective Data Transition the leading paths, which in turn makes private edition the likely architectural outcome. Regulation did not select the edition; service availability and the migration path did. Mainstream maintenance runs to end-2027, while the 2031-2033 transition option requires private edition on HANA by end-2030. Outcome: validate the in-Kingdom service design, then compare private-edition conversion with selective transition under RISE.

Profile B – UAE mid-market distributor, no incumbent SAP, standard processes, no sector-specific residency rule. There is no clock, because there is no ECC. Decision Point 1 has no residency constraint and no inherited customisation to protect, so public edition is the default and the burden of proof sits on anyone arguing otherwise. Decision Point 2 collapses – with no legacy system there is no conversion to do. Outcome: public edition, new implementation, GROW as the wrapper. This is the profile most likely to be oversold a private-edition deal, and the one where the shorthand “RISE = private” does the most commercial damage.

Profile C – Indian manufacturing group, ECC EHP 4 across three subsidiaries, moderate customisation, no payment-data exposure. EHP 4 means mainstream maintenance ended 31 December 2025 – this estate is already in customer-specific maintenance and receiving no statutory change delivery, which in an Indian payroll and tax context is the binding issue, not the ERP roadmap. The customisation is moderate and mostly inherited rather than differentiating, and with no payment-data localisation trigger, Decision Point 3 does not constrain the edition. That opens a genuine public-edition option and, across three subsidiaries, a two-tier model – public edition at the subsidiaries, private at the group – becomes worth evaluating rather than assumed away. Outcome: genuinely contested at Decision Point 1; urgency is high and independent of which way it resolves.

8. What must be true before the board approves a path

The tree is a forcing device, not a substitute for diligence. Four facts must be current when the decision reaches an investment committee:

1. Estate fact: EHP level, database, custom-code inventory and interface count are measured, not estimated.
2. Contract fact: SAP confirms the editions, services and transition options actually available under the proposed agreement.
3. Regulatory fact: counsel or the responsible authority confirms which data-classification, sector and transfer rules bind the specific entities and workloads.
4. Market fact: cloud-region and product availability is generally available on the signature date, not merely announced.

The transition option and regional positions in this paper are dated 26 July 2026. Recheck them before they become load-bearing. This framework is not legal advice and deliberately excludes promotional ROI figures that cannot be reconciled across their underlying sponsored studies.

9. The executive agenda

Run the decision in this order:

• This week: have the basis team confirm EHP level and the architecture team classify custom code into differentiating, necessary and inherited.
• Before solution design: classify regulated data by entity, country and sector; make every claimed residency constraint traceable to an instrument and an accountable legal interpretation.
• Before procurement: compare public, private and two-tier operating models on ten-year change cost – not implementation price alone.
• Before signature: attach the chosen commercial wrapper only after the first three gates have been approved, and record why rejected paths were rejected.

Altivate uses this sequence because it exposes the real decision while there is still time to change it. Altivate provides SAP advisory and implementation services and therefore has a commercial interest in this market. The decision should still follow the documented constraints, customer evidence and signed contract rather than partner status.

Use the tree to build the S/4HANA business case, or return to White Papers.

Sources and verification status

Claims below are tied to the most direct source available. Contractual entitlements, regulatory interpretations and service-region availability must still be confirmed for the specific deal and workload.

Maintenance timeline (§2)

• SAP News Center, Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition, Transition Option (August 2025) – [read] transition-option eligibility, the HANA-only condition, the 2 TB minimum, the max success plan requirement, the 20% uplift for 2026 signings, and the statement that both private and public edition transitions are part of the RISE journey.
• SAP News Center, SAP S/4HANA transition – updated policy (February 2020) – [read] Business Suite 7 mainstream maintenance to end-2027 with extended maintenance to end-2030.
• SAP Community, Maintenance Timelines for SAP ERP 6.0 – [search] the EHP 0-5 vs EHP 6-8 split. Corroborated by Natuvion, SAP ERP 6 end of maintenance (3 March 2025) – [search]
• which states extended maintenance applies to EHP 6-8 “for these versions – and only these versions”, with EHP 0-5 moving to customer-specific maintenance with “no HR or legal changes and only limited security updates”; and by SAPinsider (June 2023) – [search] – for the same dates plus the ~2 percentage-point premium.
• E3 Magazine, Deadline extension for ECC 6.0 until 2033 – [read] independent analysis that the 2031-2033 window is conditional on a RISE commitment and HANA, not a blanket extension.

RISE, GROW and public-edition extensibility (§1, §3, §4)

• SAP, What is SAP GROW, states that GROW is the primary path for companies making a first move to cloud ERP and is also available to existing customers migrating from older on-premise systems.
• SAP Help Portal, Developer Extensibility, documents cloud-ready, upgrade-stable custom ABAP in public edition, with a restricted language subset, released objects and predefined extension points.
• SAP Learning, Differentiating GROW and RISE with SAP, and SAP’s August 2025 RISE update describe the primary customer profiles, two-tier patterns and both public- and private-edition journeys.

Product naming (§1) – the July 2025 rename (public → SAP Cloud ERP; private → SAP Cloud ERP Private) is [search], corroborated across several independent commentaries and confirmed by SAP’s own August 2025 article using both new names [read].

Regulatory overlay (§5)

• Chambers and Partners, Data Protection & Privacy 2026 Global Practice Guide, UAE chapter: [read] the PDPL Executive Regulations “have yet to be issued”; DIFC and ADGM operate separate regimes (DIFC Law No. 5 of 2020 amended July 2025; ADGM Regulations 2021 amended September 2025); mainland-to-free-zone transfers count as cross-border.
• Reserve Bank of India, Storage of Payment System Data, RBI/2017-18/153, 6 April 2018: [read, primary regulator] the directive covers payment-system data specifically.
• Clyde & Co (March 2025) – [read] Saudi PDPL adequacy model, absence of an adequacy list, transfer mechanisms including contractual, corporate-rule and accreditation routes, and SDAIA’s February 2025 Risk Assessment Guidelines.
• Digital Policy Alert and Regulations.ai, with a Simmons & Simmons summary of the earlier framework – [read] the 2023 Cloud Computing Services Provisioning Regulations superseded CCRF v3, and the v3-era two-tier classification structure. CST’s own text could not be retrieved (connection reset on every attempt).
• Google Cloud Press Corner, 13 January 2025 – [read] SAP BTP availability on Google Cloud in Saudi Arabia for regulated customers; no exclusivity claimed.
• Government of India, Ministry of Electronics and Information Technology, Gazette notification G.S.R. 843(E) (13 November 2025) – [read, primary] the staged commencement schedule: sections 3 to 17 of the Act and the corresponding substantive Rules commence 18 months after publication.
• Microsoft News Center (February 2026) on the Q4 2026 Azure Saudi region, and press reporting on AWS’s Riyadh region – both [search].
• UAE Federal Law No. 2 of 2019, Article 13
• [read, primary] the health-data rule, its scope and the decision-based exception.
• CBUAE Consumer Protection Standards, 6.1.6.3
• [read, primary] the in-UAE holding and storage requirement for consumer and transaction data at licensed financial institutions.
• SEBI’s abeyance of its data-localisation clause and IRDAI’s outsourcing regulations – [search].