GROW is SAP’s standardised public-cloud package for mid-market and growth-segment buyers. It uses the Full Use Equivalent metric familiar from RISE, but the matrix that maps users to FUE is narrower, the catalogue of legacy categories does not apply, and the operational restrictions of public-cloud deployment have direct implications for how the metric is consumed. A buyer who treats GROW FUE as a smaller version of RISE FUE will mis-size at signing and over-pay over the contract term. This article sets out the differences. The full advisory frame is covered in our S/4HANA migration compliance service, which now incorporates both RISE and GROW pathways.
The category compression
GROW collapses the SAP user catalogue into a smaller set of categories than RISE recognises. The Advanced Use, Core Use, and Self-Service Use bands familiar from RISE FUE are present in GROW, but the legacy mappings do not flow through because GROW is sold without a legacy-conversion proposal. The buyer sizes the subscription directly against forecast users in each band, with no contractual reference to a prior estate.
Advanced Use
Heavy users, configurators, key users, and developers consume one FUE each. The category is largely consistent with the RISE Advanced Use definition, but GROW does not offer the developer-specific entitlement separation that some RISE schedules support.
Core Use
Regular business users consume one-fifth of an FUE. The ratio matches the RISE Core Use ratio.
Self-Service Use
Self-service and approval users consume one-thirtieth of an FUE. The ratio matches the RISE Self-Service Use ratio.
The absence of legacy conversion
The principal difference between GROW FUE and RISE FUE is the absence of a legacy-conversion path in GROW. RISE buyers convert from an existing on-premise SAP estate, and the conversion arithmetic translates legacy named users into FUE through the documented matrix. GROW buyers either are new to SAP or are accepting GROW as a replacement that does not credit the prior entitlement. The GROW signing therefore starts from zero and is sized purely against forward forecast. Estates with substantial legacy SAP entitlement that move to GROW typically lose the legacy economic value, which is a material implicit cost of the GROW selection. The GROW package contents article sets out the inclusion list and the RISE conversion economics article documents the conversion path that GROW does not offer.
The legacy-conversion gap is the principal hidden cost of GROW for established SAP customers. A move from ECC to GROW writes off the residual value of the existing entitlement portfolio. For greenfield buyers, the gap is irrelevant.
The public-cloud restrictions
GROW runs on SAP’s public-cloud edition of S/4HANA. The public-cloud edition imposes constraints on custom code, on configuration depth, and on integration scope. The constraints affect how users actually consume the system, which affects how many users are required, which affects the FUE quantum. An organisation that requires deep custom development will need additional Advanced Use FUE in GROW because the in-system development is constrained. The public-cloud restrictions article covers the technical detail.
The scaling dynamic
GROW is marketed as a starter package with growth runway. The growth runway is contractually structured around predefined uplift increments. Buyers that exceed the original size mid-term face an uplift purchase at the prevailing GROW list price, with limited price protection beyond the original commitment. The economic implication is that the original size should include realistic growth headroom rather than the minimum starting footprint that the proposal suggests. The RISE T-shirt sizing article covers the related sizing discipline that applies to both products.
The BTP overlay
GROW includes a Business Technology Platform allowance, with a different consumption profile from the RISE BTP allowance. The GROW BTP allowance is typically pre-configured against a small set of expected use cases (workflow automation, low-code app building, basic analytics), and consumption beyond those use cases requires additional purchase. The forecasting work that supports the GROW signature should include a BTP consumption forecast separate from the FUE forecast. See the cloud credit roll-over article for the related credit mechanics across RISE and GROW.
The exit position
GROW contracts are public-cloud subscription contracts. Exit at term end requires the buyer to either renew the GROW contract, migrate to a different SAP product (RISE on private cloud, or a return to on-premise), or migrate off SAP entirely. The migration choices have material technical and economic implications that should be understood at signing, not at term end. The GROW topic page covers the term-end choices and the contractual sequence required to engage each.
The negotiation levers
GROW negotiation has fewer levers than RISE negotiation because the package is standardised. The levers that remain are the FUE quantum, the BTP allowance, the term length, the uplift cap, and the price-protection clauses. Each is negotiable; none is volunteered. The aggregate yield of a competently negotiated GROW signature in our practice is between twelve and twenty per cent of the proposal’s list price, contributing to the $180M+ in savings the practice has delivered across 500+ engagements.
— 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
Buyers considering GROW should run an internal user-segmentation forecast against the three FUE bands and an internal BTP consumption forecast against the planned use cases. The two forecasts produce a defensible signing size that becomes the negotiation baseline. The GROW sizing handbook contains the forecast templates. The mid-market GROW deployment case file illustrates the forecast in practice on a 600-user implementation.