RISE with SAP and GROW with SAP explained

RISE with SAP and GROW with SAP are the vendor's two commercial bundles for running its ERP as a subscription: one contract that packages the software, the cloud infrastructure it runs on, the services that operate it and a credit allowance for the platform beside it. RISE is the bundle for existing customers moving an established system to the cloud; GROW is the public-cloud-first bundle for organisations adopting the ERP new. For consultants they change the shape of projects, the roles partners play and who runs the system — and leave the actual functional work largely where it was.

What is inside the bundles?

The mechanism is the same in both: instead of buying a perpetual licence and arranging hosting, hardware and system operations separately, the customer signs one subscription with SAP that includes several layers.

• The ERP itself — in a private cloud edition under RISE, where the customer keeps a dedicated system, its own upgrade timing within limits and more room for custom code; in the public cloud edition under GROW, where the system is multi-tenant, upgraded on the vendor's cadence and extended only through clean-core mechanisms.
• The infrastructure — the underlying cloud is provided through one of the large hyperscalers, with SAP holding the contract rather than the customer holding it directly. Under RISE the customer chooses the hyperscaler and the region for its dedicated system; under GROW the public edition runs on infrastructure SAP operates, and that choice is not the customer's to make.
• Operations as a service — the technical running of the system: installation, patching, backup, monitoring, system copies, availability commitments. What an in-house Basis team or a hosting partner used to do becomes part of what SAP delivers.
• Platform credits — an allowance for BTP services, so that extensions, integration and analytics can be built beside the core rather than inside it.
• Tools and enablement — process-analysis and migration tooling under RISE; adoption services, learning content and preconfigured processes under GROW, which is built around the idea that a new adopter starts from the standard and stays close to it.

How do RISE and GROW differ?

By who they are for, and therefore by how much of the old system comes along. RISE assumes a customer with a long-lived installation, custom code and integrations that must survive the move; the private cloud edition exists to make that survivable, and a RISE project is often a conversion of the kind the platform-shift guide describes, with cloud operations added. GROW assumes there is nothing to bring along, or nothing worth bringing; the public cloud edition exists to get a company live on standard processes quickly, and a GROW project is a fit-to-standard implementation from the first workshop. The two editions also differ in freedom: private cloud tolerates more custom code and more control over timing; public cloud offers less freedom and in exchange removes most of the upgrade burden.

What do the bundles change for consultants?

• Project shapes. More conversions-to-private-cloud and more public-cloud greenfields; fewer on-premise builds. Both follow the Activate methodology closely, because the bundles are sold with it, and public-cloud projects in particular run on fit-to-standard rather than open-ended design.
• Partner roles. The implementation partner still does the functional design, configuration, data migration, testing and change management; SAP holds the operational contract and the system. That splits responsibilities that used to sit with one integrator, and adds a new kind of work — managing the boundary between the partner, the customer and the vendor's operations team.
• Cloud operations. The Basis role moves from doing the operations to governing them: raising requests, reviewing what the vendor did, owning the landscape design, the integration connectivity and the platform accounts that remain the customer's. Service management skills matter more; hands-on server work matters less.
• Extension discipline. Clean core stops being advice and becomes a contract term, especially in public cloud. Developers who know the released-API rules and the platform side get the work; modification-first habits do not.
• Commercial literacy. Consultants close to the sale — architects, engagement managers, presales — need to understand what is and is not in the subscription, because a great deal of scoping friction on these projects comes from the customer assuming the bundle covers something it does not.

What do the bundles not change?

The business processes. A company still has to decide how it sells, buys, makes, pays and closes its books, and someone still has to turn those decisions into configuration, migrate the data, test the result and teach people to use it. The functional consultant's week is recognisably the same under RISE, under GROW and on a classic installation; the difference is how much of the design is negotiated against a standard that cannot be changed. Integration still has to be built, master data still has to be governed, authorisations still have to be designed, and the employer map is the same set of integrators, boutiques, in-house teams and freelancers — with the vendor's own services organisation somewhat more present than before.

How should you position for it?

Learn the vocabulary, because interviews and project kick-offs use it: which edition, which hyperscaler, what is in the subscription, where the platform credits go. Then position by track. Functional people gain from real fit-to-standard experience, which public-cloud projects supply in abundance. Technical people gain from clean-core extension work and from the platform. Basis people gain from moving toward landscape governance and cloud connectivity. Whichever track, say so on your public profile: a findable profile that names your city, your role and the areas you work in is what a partner staffing one of these programmes searches first.