One licensing currency, two estates that cannot be swapped
RISE and GROW are two subscription packages for S/4HANA Cloud that share a licensing currency, the Full Use Equivalent basket, and share very little else. Tenancy, customisation depth, integration scope, industry coverage, and who controls the release calendar all differ. The choice is effectively permanent for the term, because switching from one to the other mid term triggers a full re implementation rather than a migration.
Prepared by Redress Compliance · August 10, 2026 · SAP advisory. The buyer side comparison of the two S/4HANA Cloud packages.
Executive summary
RISE is single tenant and brownfield friendly; GROW is multi tenant and fit to standard.
RISE wraps S/4HANA Cloud Private Edition, where the customer owns the data model, the configuration, and the custom code while SAP runs the infrastructure on a chosen hyperscaler, so the estate looks and behaves like an on premises system that somebody else operates.
GROW wraps Public Edition, where the customer adopts the standard data model and configuration and custom logic lives on side car extensions rather than in the core.
Both run on the FUE basket, but the conversion ratios are not shared. The metric is common and the arithmetic underneath it is not, which is the single most misread point in the comparison, because a FUE count modelled for one package does not transfer to the other.
Size the basket separately for each option, and size the digital access tariff separately too, since indirect use pricing does not become simpler because the platform changed.
Industry coverage and release control are where the decision usually turns. RISE covers all twenty five industry solutions; GROW covers a subset that expands by quarterly release, so an industry requirement can settle the question before any commercial conversation.
Release cadence works the same way: RISE is customer paced while GROW applies a mandatory quarterly release with a regression window, which is a standing operational commitment rather than a one time project cost.
The choice is permanent for the term, so the wrong one forces a re platforming inside the first renewal cycle. Switching from GROW to RISE mid term triggers a full re implementation rather than a migration path, which makes this a ten year decision made once.
On cost, GROW often runs lower per FUE at the entry tier while RISE runs lower per FUE at scale, so the crossover matters more than either headline rate and it moves with the size of the basket you actually need.
The dimensions that move the decision
| Dimension | RISE (Private) | GROW (Public) | Buyer side note |
|---|---|---|---|
| Tenancy | Single tenant | Multi tenant | Single tenant for regulated industries |
| Customisation | Deep custom code in core | Side car extensions | Existing custom code lifts on RISE |
| Migration path | Brownfield friendly | Greenfield friendly | A legacy estate lifts on RISE |
| Industry solutions | All 25 covered | Subset, expanding | Confirm industry fit before shortlisting GROW |
| Release cadence | Customer paced | Quarterly mandatory | GROW needs standing regression discipline |
| Cost per FUE | Lower at scale | Lower at entry tier | The crossover matters more than either rate |
The five characteristics that define each package are worth stating plainly, because most shortlists are built on brand rather than on fit.
RISE: single tenant deployment, brownfield migration where existing custom code lifts with limited refactoring, full industry solution coverage, a bundled platform allowance, and customer choice of hyperscaler.
GROW: multi tenant with a customer carve out at the data layer, greenfield deployment where no legacy custom code carries forward, a subset of industry solutions expanding quarterly, a mandatory quarterly release applied on the customer schedule with a regression window.
And extensibility that runs beside the core rather than inside it.
Map the existing estate against both lists before pricing either. The fit question on the private edition side sits in the RISE fit test.
Sizing the basket and the digital access tariff
- Size the FUE basket separately for each option, because the metric is shared and the conversion ratios are not, so a count modelled for one package does not transfer.
- Run a clean user reclassification first, since the basket is only as honest as the user types feeding it, and an inflated starting count locks an inflated subscription for the term.
- Price the digital access tariff for both, as indirect use liability follows your integrations rather than the platform, and it does not simplify because the deployment model changed.
- Model the per FUE crossover rather than the headline rate, given GROW often runs lower at entry tier and RISE lower at scale, so the answer depends on the size of the basket you need.
- Cost the release discipline on GROW as a standing commitment, because a mandatory quarterly release with a regression window is an operating cost every quarter rather than a project line. The counting mechanics sit in the FUE guide.
RISE with SAP against on premises
Where the private edition case genuinely holds, the FUE conversion arithmetic, and the offsets to negotiate before committing to either package.
Get the white paper →Where each model actually fits
The honest way to run this comparison is to map the existing estate against the two models before pricing either, because most of the decision is settled by facts about your estate rather than by preference.
A heavily customised legacy estate with deep custom code and a brownfield migration ahead of it fits RISE, since that code lifts with limited refactoring and the single tenant deployment preserves the operating model the organisation already understands.
A greenfield deployment with no legacy code to carry forward, in an industry the public edition already covers, fits GROW, and the fit to standard discipline that would be painful for a customised estate is straightforwardly cheaper for one starting fresh.
Two facts about the estate can settle it outright before any commercial conversation. The first is industry coverage, because RISE covers all twenty five industry solutions while GROW covers an expanding subset, so a requirement outside that subset ends the comparison.
The second is regulatory posture, because single tenancy is a genuine requirement in some regulated contexts rather than a preference, and multi tenancy with a data layer carve out may not satisfy it.
Release control is the operational consequence people underweight: GROW applies a mandatory quarterly release with a four week regression window, which is a standing quarterly commitment for the whole term rather than a migration cost.
And an organisation without the regression discipline to absorb it will find that out in quarter two.
Above all, treat the choice as permanent, because switching mid term triggers a full re implementation and the wrong choice forces a re platforming inside the first renewal cycle. The indirect use side sits in the digital access guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
The buyer side discipline
The comparison fails in a predictable way: teams shortlist on the package name, discover the fit problem during implementation, and pay for it at the first renewal. The discipline that prevents it is sequential and unexciting.
The FUE basket has to be modelled independently for each package, because the metric is shared and the conversion ratios underneath it are not.
Switching between the packages mid term triggers a full re implementation, which makes this a single decision that governs the entire cycle.
Map the estate against both models first, on tenancy requirement, custom code depth, migration shape, and industry coverage. Then size the FUE basket and the digital access tariff for each option separately, because the shared metric hides different arithmetic.
Then model the per FUE crossover against the basket you actually need rather than comparing entry rates, since GROW runs lower at the entry tier and RISE lower at scale. Then cost the release discipline as a standing operating commitment on the public edition side.
Only then price the two packages against each other, and treat the outcome as fixed for the term. The wider library sits in the SAP practice.
Your first five moves
- Check industry coverage first, because RISE covers all twenty five industry solutions and GROW an expanding subset, and a requirement outside it ends the comparison before it starts.
- Establish whether single tenancy is a requirement or a preference, since a genuine regulatory constraint settles the question independently of cost.
- Size the FUE basket separately for each package, after a clean user reclassification, because the shared metric carries different conversion ratios underneath it.
- Price the digital access tariff for both options, as indirect use liability follows your integrations rather than the deployment model and does not simplify with the move.
- Cost the quarterly release discipline on GROW as a standing commitment, and treat the final choice as permanent, because switching mid term is a full re implementation. The SAP practice runs the mapping with you.
Frequently asked questions
What is the difference between RISE and GROW with SAP?
RISE wraps S/4HANA Cloud Private Edition, single tenant with deep customisation and brownfield migration. GROW wraps Public Edition, multi tenant and fit to standard with greenfield deployment.
They share the FUE licensing currency and differ on tenancy, customisation depth, integration scope, industry coverage, and who controls the release calendar.
Do RISE and GROW use the same licensing metric?
They share the Full Use Equivalent basket as the currency, but the conversion ratios are not the same, which is the most misread point in the comparison.
A FUE count modelled for one package does not transfer to the other, so the basket has to be sized independently for each option before the two can be compared on cost.
Which is cheaper, RISE or GROW?
It depends on scale. GROW often runs lower per FUE at the entry tier while RISE runs lower per FUE at scale, so the crossover matters more than either headline rate and it moves with the size of the basket you actually need.
Model both against your real user population rather than comparing entry prices.
Can we switch from GROW to RISE later?
Not as a migration. Switching mid term triggers a full re implementation rather than a platform move, which is why the choice is effectively permanent for the term and why a wrong decision forces a re platforming inside the first renewal cycle.
Treat it as a single decision governing the whole cycle.
How does industry coverage differ?
RISE covers all twenty five industry solutions. GROW covers a subset that expands by quarterly release.
That single fact settles a great many comparisons before any commercial conversation, because a requirement outside the public edition subset removes GROW from the shortlist regardless of how the cost model looks.
What does the GROW release cadence commit you to?
A mandatory quarterly release applied on the customer schedule with a regression window.
It is a standing quarterly operating commitment for the whole term rather than a one time migration cost, so an organisation without the regression discipline to absorb it will discover the gap in the second quarter rather than during selection.
Does moving to either package change indirect access liability?
No. Digital access liability follows your integrations rather than the deployment model, so it travels into both packages unchanged.
Price the digital access tariff separately for each option during the comparison, and settle the document count before signing, because it does not become simpler because the platform changed.
