SAP GROW with SAP is SAP’s public-cloud S/4HANA package, sold to mid-market buyers as a fixed-content, fixed-process, rapid-implementation offering. The package is presented as turnkey. The buyer-side reality is more nuanced: GROW includes a defined and inflexible set of capabilities, excludes a defined and inflexible set, and operates under public-cloud constraints that materially shape the operational fit. This article sets out a clear inventory of what GROW includes, what it excludes, and where the package boundaries create practical issues that buyers commonly discover after sign rather than before. It is one of the engagement patterns inside our contract negotiation service for GROW-route buyers.
The GROW positioning
GROW is positioned for mid-market buyers (commonly defined by SAP as having revenues below a threshold that varies by region) seeking a rapid, standardised S/4HANA implementation without the customisation burden of an enterprise S/4HANA deployment. The package is delivered on SAP’s public cloud, with the application managed by SAP and the infrastructure abstracted from the buyer. The implementation methodology is SAP-defined and the configuration latitude is limited to defined extensibility points. The economic case for GROW rests on the speed of implementation, the predictable subscription pricing, and the absence of an infrastructure operational burden.
The package is not equivalent to enterprise S/4HANA on RISE. Many enterprise features, modules, and extensibility patterns are absent from GROW. The GROW topic page sets out the architectural detail.
What GROW includes
The included scope is principally the core financial and operational modules of S/4HANA: financial accounting, controlling, sales, procurement, inventory management, and the integration framework. The included scope also covers the SAP Build extensibility platform, with allocated build credits for in-tenant extensions. The package includes the SAP Best Practices content library for the included modules, providing pre-configured process scenarios that the buyer adopts at implementation. The included service component covers the SAP-managed application operations and the SLA-backed availability commitments.
The included scope is well-suited to mid-market buyers whose operational processes align with the SAP Best Practices content and who do not require deep industry-specific customisation. Buyers with non-standard processes need to evaluate the fit-to-standard gap before committing to the package, because the gap defines the customisation burden under the limited extensibility latitude of public cloud.
What GROW excludes
Several categories of capability are excluded from the base GROW package and either require additional purchase or are not available at all. The principal exclusions are: deep industry-specific modules (such as the industry-specific extensions for utilities, oil and gas, banking, and certain other verticals); complex manufacturing modules (advanced production planning, demand-driven MRP at the most sophisticated tier); some HR functionality (with SuccessFactors purchased separately for full HR coverage); and many of the SAP analytics products (with SAC and BTP analytics services purchased separately).
The exclusion list is the negotiation surface. The buyer-side discipline is to compare the buyer’s actual process requirements against the inclusion list and to identify the gap before contract sign. The gap is either covered by additional purchases (which add to the total cost of ownership) or absorbed as a process change (which adds to the implementation cost and risk). Either resolution is acceptable; the unmitigated discovery of the gap after sign is the failure mode to avoid.
The public-cloud constraints
GROW operates on SAP’s public cloud, which means several operational constraints that differ from on-premise or private-cloud S/4HANA. Upgrade cycles are SAP-managed and occur on a defined schedule that the buyer accepts rather than controls. Custom code in the traditional sense is not permitted; extensibility runs through SAP Build using approved patterns. The data-residency model is SAP-defined per region. The integration model is bounded by the SAP-permitted integration patterns and the bandwidth limits of the public cloud tenant.
For mid-market buyers whose operations align with the SAP-managed pattern, the constraints are typically acceptable. For buyers with custom code requirements, atypical integration needs, or specific data-residency requirements, the constraints are material and may render the package unfit. The fit assessment should be completed before contract sign, not after.
The FUE count in GROW
GROW prices in FUE units, similarly to RISE, but with different conversion ratios applicable to the public-cloud structure. The contracted FUE quantity is derived from the buyer’s projected user population multiplied by the GROW ratio table. The recurring buyer-side error is accepting the SAP-proposed projection without buyer-side analysis. The projected user count drives the contracted FUE quantity, and the contracted FUE quantity drives the subscription cost across the contract life.
The mitigation is a buyer-side user count and band-mix projection, conducted as a parallel exercise to the SAP proposal. Where the buyer’s projection differs from the SAP-proposed projection, the contract negotiation should focus on the gap. The licence optimisation pillar covers the projection methodology, which is the same in its substance whether applied at GROW sign or at RISE sign or at conversion event.
The migration from ECC
Mid-market buyers migrating from ECC to GROW face a structural decision: the migration is effectively a greenfield re-implementation rather than a brownfield in-place conversion. The custom code in the ECC environment does not transfer; the historical data transfers only through controlled data-migration patterns; the user-master populations must be re-created in the GROW tenant. The migration is therefore a major project, comparable in scope and cost to the original ECC implementation.
The economic case for GROW versus alternative routes (RISE for mid-market, on-premise S/4HANA, continued ECC) must include the migration cost and the migration risk in the comparison. The package’s low ongoing subscription cost is one factor; the up-front re-implementation cost is the other. The S/4HANA migration compliance pillar covers the broader migration frame, and the mid-market GROW case file shows the pattern in practice.
GROW’s public-cloud restrictions are not negotiable. The package is what it is. The buyer-side discipline is to confirm the fit before sign, because the discovery of misfit after sign typically means an expensive workaround inside the package or an early exit from the contract.
The extensibility question
Extensibility in GROW runs through SAP Build, with allocated credits inside the package and additional credits available for purchase. The extensibility model is restricted to defined patterns (key-user extensibility, side-by-side extensions on BTP, in-app extensions through Build). Custom ABAP development in the traditional sense is not permitted; ABAP cloud extensibility within Build is a controlled alternative with limits.
For buyers with limited customisation needs, the extensibility model is adequate. For buyers with substantial customisation requirements, the extensibility model is the principal source of post-sign discomfort. The pre-sign assessment should include a concrete extension inventory, with each prospective extension mapped to an approved Build pattern or flagged as out-of-scope for the package. The inventory becomes the contract negotiation surface for the Build credit allocation.
How GROW compares to RISE
The headline differentiator: RISE is enterprise-scoped and supports deeper customisation; GROW is mid-market-scoped and is more standardised. Both price in FUE, both run on SAP-managed cloud, both include SAP-defined service components. The choice between the two for a borderline buyer (typically larger mid-market, smaller enterprise) is a structural commercial decision that turns on the customisation requirement, the integration requirement, the regulatory requirement, and the projected growth trajectory.
The RISE contracts pillar covers the RISE-specific structure; the comparison frame is set out in the GROW vs RISE white paper. Mid-market buyers should run the comparison before committing to one route or the other; the cost differential and the operational implications justify the analysis.
The contract mechanics
GROW contracts share much of the RISE legal structure but with a more standardised commercial model. The base subscription is term-based (commonly three or five years), with annual escalators, defined renewal terms, and SAP-defined SLA provisions. The buyer-side leverage is most concentrated at initial sign, with reduced leverage at renewal because the migration cost from GROW to an alternative is substantial. The implication is that the initial-sign negotiation should secure as much flexibility as possible — in pricing structure, in FUE quantity, in credit allocations, and in exit provisions — because the negotiation surface narrows after sign.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
Where to start
Compare the GROW inclusion list to the buyer’s actual process requirements, line by line. The gap between the two is the implementation scope. The contract negotiation service brief covers the engagement model; the GROW topic page covers the package architecture.