GROW with SAP vs RISE with SAP. One user metric, two systems you cannot swap.

RISE wraps S/4HANA Cloud Private Edition and GROW wraps Public Edition. Both price users in FUE, but tenancy, custom code, industry coverage and upgrade control differ, and switching mid term means a new implementation.

RISE with SAP and GROW with SAP are both subscription packages for S/4HANA in SAP's cloud, and both are priced in Full Use Equivalents (FUE). Beyond that shared metric they differ on almost every point that shapes a ten year ERP decision: tenancy, custom code, integration scope, industry coverage and who sets the upgrade calendar.

The choice also holds for the full term. Moving from one package to the other mid term means a new implementation, so the comparison has to be done properly once, before the order form is signed.

What is the difference between GROW with SAP and RISE with SAP?

RISE wraps S/4HANA Cloud Private Edition. It is single tenant: you own the data model, the configuration and the custom code, while SAP runs the infrastructure on the hyperscaler you pick. In practice it looks and behaves like an on premises system that SAP operates for you.

GROW wraps S/4HANA Cloud Public Edition. It is multi tenant, with your data carved out at the data layer, and you adopt SAP's standard data model and configuration. In 2025 SAP began marketing the two editions as SAP Cloud ERP Private and SAP Cloud ERP, so quotes and order documents may use either set of names.

What sits behind each row of the table?

Most shortlists are built on the package brand. The detail that matters sits one level down, so map your current SAP system against these points before you price either option.

• RISE hosting. You choose AWS, Microsoft Azure, Google Cloud or another host, and the bundle includes a platform allowance in SAP BTP credits.
• RISE migration. A brownfield conversion keeps your ECC history, and existing custom code lifts with limited refactoring.
• GROW migration. SAP offers no system conversion into Public Edition, so no legacy custom code carries forward and history arrives as migrated data.
• GROW extensions. Key user tools and ABAP Cloud on released SAP objects inside the tenant, or side by side apps on SAP BTP. Modifying SAP's code is not possible.
• GROW upgrades. Releases are applied on SAP's schedule, with a test window before production.

If your team is still deciding whether the private edition makes sense at all, start with our RISE fit test. The edition trade offs in more detail are in our Private versus Public Edition comparison.

Do RISE and GROW use the same FUE licensing metric?

Yes. Both packages count users in FUE, and SAP's own licensing overview gives the same weights for both editions: 1 Advanced Use user is 1 FUE, 5 Core Use users are 1 FUE, 30 Self Service users are 1 FUE, and a developer counts as 2 FUE.

The weights are shared, but a count modeled for one package still does not transfer to the other. Two things differ underneath: how each user lands in a user type, and what SAP charges per FUE in each package.

Where the two counts diverge

• Classification in Private Edition. SAP classifies each user from the authorizations the user holds. Broad roles carried over from ECC push users into Advanced Use even when they only display data.
• Classification in Public Edition. Every business catalog carries a price category. A user's type is set by the highest category in the business roles assigned to that user, so role design drives the count.
• Price per FUE. Each package has its own price list and volume tiers, so the same FUE total produces two different subscription fees.

A worked example: one workforce, two counts

Say a company has 1,200 SAP users: 120 finance and planning staff, 480 operational users and 600 employees who approve, request and look up data. The table shows the Private Edition count after a clean role review, and a Public Edition count where 80 warehouse users receive a standard role that includes one catalog priced as Advanced Use.

The same people produce 64 more FUE in the second column, about 27 percent more. The gap can run the other way too: a brownfield RISE conversion with wide ECC authorizations often inflates the Private Edition count instead. Our FUE guide covers the counting rules, and the FUE calculator runs the weights for you.

The practical rule is to reclassify users before either count goes to SAP. The basket is only as accurate as the user types feeding it, and an inflated starting count locks an inflated subscription in place for the whole term.

Which is cheaper, GROW with SAP or RISE with SAP?

It depends on the size of your basket. GROW often runs lower per FUE at the entry tier, while RISE runs lower per FUE at scale. The point where the two lines cross matters more than either headline rate, and it shifts with the number of FUE you actually need.

How do you find the crossover for your own basket?

1. Build one clean FUE count per package, using each edition's classification rules.
2. Ask SAP for both quotes at three basket sizes: today's cleaned count, the count at the end of your growth plan, and a smaller count that assumes a divestment or a slower rollout.
3. Add the costs that sit outside the subscription for each package, listed below.
4. Compare total cost per year at each size and note where the cheaper option changes.

• GROW: regression testing. Every release needs test cycles, key user time and test automation upkeep, every year of the term.
• RISE: infrastructure beyond the base. Extra system tiers, memory and disaster recovery are priced on top, as our RISE hidden costs guide explains.
• Both: BTP consumption beyond the credits in the bundle, for extensions and integration.
• Both: digital access for documents created in SAP by external systems.

Does digital access change between the two packages?

No. Indirect use liability follows your integrations, and a new deployment model does not make it simpler. Both packages license digital access per document, so price the tariff separately for each option and settle the expected document volume before signing.

The rules and document types are set out in our digital access guide and the note on how SAP counts a document.

Which companies fit RISE and which fit GROW?

Facts about your current systems settle most of this decision before preference or price comes into it. A heavily customized ECC system with a brownfield migration ahead of it fits RISE. A greenfield start in an industry that Public Edition already covers fits GROW.

For the customized system, the custom code lifts with limited refactoring and the single tenant model keeps the operating model your team already knows. For the new start, fit to standard is cheaper to adopt because there is no old code to rebuild or retire.

Two facts that can settle it before any pricing

• Industry coverage. RISE covers all 25 industry solutions. GROW covers a subset that expands release by release, so a requirement outside that subset ends the comparison. SAP's GROW page cites customer results across 26 industries, which shows who buys it rather than how deep each industry's processes go. Check your own processes against the Public Edition scope items SAP publishes.
• Tenancy. In some regulated settings single tenancy is a requirement, and multi tenancy with a data layer carve out may not satisfy the regulator or your own security policy. Get a written answer from compliance before the commercial work starts.

How size and starting point change the answer

A 400 person company replacing an older accounting system usually has few custom objects and no ECC history. GROW suits it, and the regression work each release is small because the process scope is narrow.

A 15,000 user group with ECC, thousands of custom objects and industry add ons sits at the other end. RISE is usually the only realistic landing point, and the negotiation shifts to FUE tiers and infrastructure sizing. Groups in between often run both: RISE for the headquarters system and GROW for smaller subsidiaries, a setup SAP calls two tier ERP.

What does the GROW release cycle commit you to?

GROW commits you to two major releases a year, in February and August, which SAP pushes to your systems on its published schedule. With three systems, SAP upgrades the test system first and the development and production systems about three weeks later. With two systems, the gap is about two weeks.

Between releases SAP applies patches every two weeks. Release testing is therefore an operating cost for every year of the term, separate from the migration budget, and a company without regression discipline finds the gap in its first cycle. Plan for these items:

• Test automation. Keep the automated test scripts for your key processes current, and extend them each time you activate new scope.
• Key user time. Block time from finance and operations users in each test window, twice a year.
• Release review. Read SAP's release notes for changes to the apps and APIs your integrations call, before the test system is upgraded.
• Change freezes. Keep month end and year end activity away from the production upgrade weekends.

RISE works differently. SAP ships a new S/4HANA release every two years, each with seven years of mainstream maintenance, and you choose when to upgrade within that span.

Can you switch from GROW to RISE later?

Not as a migration. Switching packages mid term means a full new implementation, and you may still owe the subscription you are leaving. A wrong choice therefore forces a second platform project inside the first renewal cycle, which makes this a ten year decision taken once.

Contract wording to ask for before you sign

• Edition change right. A clause that credits the remaining value of the GROW subscription against a RISE subscription if you move. Without it you pay twice during the overlap.
• FUE reduction at renewal. The right to reduce the basket at each renewal, so a divestment or a smaller rollout does not leave you paying for unused FUE.
• Price hold on added FUE. Additional FUE bought during the term at the same net rate as the original basket.
• Digital access terms. The price per document and the expected volume written into the order form.
• BTP credit terms. The credit amount, what it covers and whether unused credit carries over.
• Renewal cap. A limit on the price increase at the first renewal, when your ability to walk away is at its lowest.

Our GROW negotiation guide covers the Public Edition order form in more depth, and this note on BTP credits covers the platform allowance.

What goes wrong in RISE versus GROW decisions we review?

The failure follows a predictable sequence. A team shortlists on the package name, finds the fit problem during implementation, and pays for it at the first renewal. Behind it we usually find one FUE count reused for both packages, or a release cycle budgeted as a one time project line that runs short in year two.

Why picking the cheaper quote first is the wrong order

A common piece of advice is to get both quotes early and let price narrow the field. We think that sequence wastes months, because industry coverage, tenancy rules and custom code depth remove one package for most companies before a price is useful.

Entry rates also hide the crossover. Map fit first, size each basket separately, then ask for quotes at the sizes you need.

Two packages can share a metric and still produce two different bills for the same people.

What the account team will say, and what to say back

• "GROW is the modern choice, RISE is for customers who cannot let go." Ask them to show Public Edition scope items for your three most specific industry processes, in the current release.
• "The FUE count carries over, so you can compare the quotes directly." Ask for the user type classification behind each count, user by user, and rerun it yourself under each edition's rules.
• "You can move to RISE later if you outgrow GROW." Ask for that in the contract as an edition change right with a credit for the remaining term.
• "Digital access is simpler in the cloud." Ask for the document price and expected volume in writing for both options.

What to do next

1. Check industry coverage first. Hold your core industry processes against the current Public Edition scope items. A gap there removes GROW before any pricing work.
2. Settle tenancy. Establish whether single tenancy is a regulatory requirement or a preference, because a requirement decides the question regardless of cost.
3. Reclassify users, then count twice. Build one FUE count under Private Edition rules and one under Public Edition rules.
4. Price digital access for both. Get the document price and volume in writing for each option.
5. Find the crossover. Ask for quotes at three basket sizes and add the costs outside the subscription.
6. Budget the release cycle. For GROW, cost two test cycles a year for the whole term as an operating line.
7. Treat the choice as permanent. Negotiate the edition change right and renewal terms before you sign. The SAP knowledge hub has the wider library, and our SAP team can run the mapping with you.

Frequently asked questions