GROW with SAP is positioned as the public-cloud S/4HANA package for mid-market organisations, sold as a tightly bundled subscription with limited customisation, prescriptive process scope, and a faster time-to-go-live than RISE. The product positioning aligns with new-implementation buyers: organisations without an existing SAP estate, or organisations spinning up a new entity where a clean greenfield deployment makes sense. The conversion path from a mature ECC estate to GROW is unusual, and where it is feasible at all the licensing economics and the data assumptions both deserve careful examination. Our S/4HANA migration compliance engagements have covered the question several times; this article sets out the framing.
Why most ECC estates don’t go to GROW
The first-order reason is fit. ECC estates carry customisation accumulated over years or decades: bespoke ABAP, modified standard objects, additional country versions, integration patterns built around the on-premise architecture, and process variations that diverge from SAP’s standard scope. GROW does not accommodate that estate. The platform is structured around standard processes, with extensibility confined to the BTP side-by-side model and no in-core modification permitted. An ECC estate brought into GROW would need to be substantially re-platformed, not migrated. The GROW topic page covers the platform constraints.
The second-order reason is licensing economics. GROW is priced as a per-FUE subscription with a relatively flat rate structure. ECC estates with high engine consumption (payroll, BW, PI, process integration) carry licensing that does not translate cleanly into GROW’s FUE framework. The translation either leaves the buyer paying for engine entitlement they no longer hold, or paying more in GROW FUE terms than the equivalent ECC licence cost. The GROW vs RISE comparison white paper sets out the comparison detail.
The rare cases where it works
Migration from ECC to GROW becomes feasible in a defined set of conditions. The estate is small enough that the customisation can be retired or reimplemented. The process scope aligns reasonably well with GROW’s standard scope. The user base is concentrated in transactional roles rather than custom or specialist roles. The data volume is manageable inside GROW’s sizing tiers. And the buyer is willing to accept the simplification of process and the loss of the customisation as part of the migration scope.
The carve-out pattern
The most common pattern we have seen is a carve-out migration: a subsidiary or business unit of a larger ECC-using organisation, with its own user base, its own processes, and limited integration with the parent estate. The carve-out moves to GROW while the parent estate continues on ECC or migrates to RISE. The carve-out economics work because the unit is small enough to absorb the simplification and large enough to justify a separate SAP contract.
The newly-acquired entity pattern
A second pattern is the newly-acquired entity. A buyer organisation that has standardised on SAP elsewhere acquires a non-SAP entity and decides to bring it onto GROW rather than implementing the full ECC or RISE stack. The decision rests on the same conditions as the carve-out plus the additional consideration that the entity has no SAP estate to migrate. The migration is in effect a greenfield deployment with a small data import, not an ECC migration.
The licensing math
The licensing math for ECC to GROW is straightforward in structure and complex in detail. The buyer’s ECC licence position is a combination of named-user entitlements (Professional, Limited Professional, Employee, Developer, plus the legacy categories) and engine entitlements (payroll EE counts, BW data volumes, PI message counts, others). The GROW equivalent is FUE units within a defined ratio table, with engines either bundled into the FUE rate or licensed separately within GROW.
The translation requires the buyer to map each ECC entitlement to its GROW equivalent and to evaluate whether the result represents a fair value exchange. For named users the mapping is usually unfavourable: ECC’s Limited Professional categories convert into GROW FUE at ratios that effectively buy back entitlement the buyer already holds. For engines the mapping depends on whether the engine is bundled or separately licensed in GROW. The GROW package contents piece covers the bundle composition.
The headline ECC-to-GROW migration discount that SAP offers usually does not survive the per-user economic comparison. Buyers who do the licensing math before committing to the path identify the divergence early. Buyers who accept the migration on the strength of the headline discount discover the divergence after sign.
The data assumption trap
Beyond the licensing economics, the data assumption is the second source of divergence. GROW is sized in tiers that include defined data volumes (database size, document volumes, transaction volumes). ECC estates of any maturity typically carry data volumes that exceed the standard GROW tiers, particularly in modules with long retention requirements (FI, MM, PP). The migration must either accept data archiving to fit within the GROW tier or accept a higher-tier GROW subscription that erodes the cost advantage.
The data assumption should be tested before the contract event with a sizing exercise against the actual ECC data volumes. The exercise should distinguish between active data (required for current process) and historical data (retained for compliance or analytical purposes). Active data must move into GROW; historical data can stay in the ECC system as a read-only archive or move to a separate analytical platform. The brownfield licensing risks piece covers the data-sizing framework.
The customisation question
GROW does not permit in-core customisation. ABAP modifications, custom objects in the standard namespace, and modified standard processes are not portable. The migration must retire those objects or replace them with BTP-based extensions that sit outside the GROW core. The replacement work is non-trivial; for mature ECC estates with substantial custom code, the replacement work often exceeds the migration savings.
The buyer-side decision is whether the custom code is still load-bearing. Code that supports a current process must be replaced; code that supported a historical process can be retired. The customisation audit that precedes the migration decision is the largest single determinant of feasibility. Estates with thin customisation can migrate to GROW. Estates with deep customisation cannot. The pharma migration case file illustrates the customisation-audit pattern.
The contract mechanics
Where the ECC-to-GROW migration proceeds, the contract mechanics are different from a normal ECC contract event. The existing ECC entitlement is terminated or repurposed; the GROW subscription begins on a new commercial baseline. SAP typically offers a transition incentive in the form of a discount on the GROW subscription or a credit against the residual ECC maintenance fees. The transition incentive is negotiable. The standard SAP offer at the start of the negotiation is usually meaningfully below the achievable position.
The credit-conversion structure
Buyers with significant residual ECC investment (recent perpetual licences, recent engine entitlements, recent maintenance prepayments) should negotiate explicit credit conversion against the GROW subscription. The conversion mechanics include the ratio at which residual investment converts into GROW credit, the application of the credit across years of the GROW subscription, and the treatment of the credit on termination of the GROW arrangement. None of these is standard; all are negotiable at 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.
What we recommend testing first
Before committing to an ECC-to-GROW migration the buyer should run three tests. The customisation audit, which classifies each in-core custom object as load-bearing, retirable, or replaceable, and quantifies the replacement cost. The data sizing test, which projects the ECC active data into GROW tiers and identifies the tier requirement. The per-user economic comparison, which compares the ECC licence cost under the current contract against the GROW FUE cost at the projected user mix. If all three tests show favourably the migration can proceed; if any one test shows unfavourably the migration economics are likely to disappoint. The GROW public-cloud restrictions piece covers the platform constraints in more detail.