RISE with SAP: Tips to streamline SAP Cloud Licensing

No. RISE with SAP should be viewed as a broader transformation framework rather than a simple infrastructure migration.

For organizations running SAP ECC or older ERP environments, the move can involve application modernization, business-process redesign, integration changes, data transformation, security controls, and changes to how the ERP environment is operated. The appropriate transition path depends heavily on the starting environment and the organization's transformation objectives.

For example, SAP identifies different approaches for existing S/4HANA environments, ECC systems, and third-party ERP platforms, ranging from system conversion and selective data transition to new implementation. The choice should therefore be based on business and technical requirements rather than treating every migration as a lift-and-shift project.

The decision largely depends on the degree of standardization, process differentiation, customization, and control an organization requires.

Public Edition is generally suited to organizations willing to adopt standardized cloud processes and operate within a more prescriptive SaaS model. Private Edition provides greater continuity for organizations with complex processes, existing SAP investments, or requirements that make a more controlled transition appropriate.

The decision should consider factors such as:

• Complexity of existing business processes
• Extent of custom development
• Regulatory and data requirements
• Integration landscape
• Geographic operating model
• Need for differentiated processes
• Desired pace of standardization

Organizations should evaluate the target operating model before selecting the deployment model, rather than selecting the cloud edition solely on infrastructure considerations.

A clean core means keeping the central ERP platform as close as practical to the standard SAP software while moving differentiated functionality into appropriate extension mechanisms.

This matters because extensive modifications to the ERP core can make upgrades, testing, integrations, and future innovation more complicated. SAP's current modernization guidance emphasizes moving toward a clean-core cloud foundation, while industry research also identifies clean core as an important strategic consideration for SAP ERP leaders.

A clean-core strategy does not mean eliminating every customization. Instead, organizations should determine which custom developments are genuinely business-critical, which can be replaced by standard functionality, and which should be redesigned as extensions.

Existing customizations should be assessed individually rather than automatically carried into the target environment.

A typical assessment categorizes custom developments into several groups:

1. Retain – functionality remains necessary and has a valid role in the target architecture.
2. Replace – standard SAP functionality can meet the requirement.
3. Redesign – the business requirement remains, but the technical implementation should change.
4. Retire – the customization no longer provides sufficient business value.

This assessment is particularly important for heavily customized ECC environments. SAP now provides tooling intended to analyze custom ABAP developments and determine how they should be handled during modernization.

The objective should be to preserve valuable business capabilities without unnecessarily reproducing technical debt.

Moving the ERP platform to the cloud does not eliminate the need for integration architecture. In many cases, it makes integration governance more important.

Organizations should inventory interfaces connecting ERP with systems such as:

• CRM and customer platforms
• Manufacturing and shop-floor systems
• Warehouse management
• Banking and payment platforms
• E-commerce systems
• HR applications
• Tax and regulatory services
• Data warehouses and analytics platforms
• External suppliers and business networks

The migration is therefore an opportunity to rationalize integrations, retire obsolete interfaces, establish consistent API and event-driven patterns, and reduce point-to-point dependencies.

A successful RISE program should produce an explicit target integration architecture, not simply reproduce the existing interface landscape in a new hosting environment.

It changes the responsibility rather than eliminating it.

Cloud services can shift portions of infrastructure management and technical operations away from the customer. However, the customer remains responsible for areas such as business-process ownership, data governance, identity and access management, integration decisions, testing, compliance requirements, and organizational adoption.

This creates a potential shift in the IT operating model: fewer resources may be required for traditional infrastructure administration, while greater emphasis may be placed on enterprise architecture, data, security, integration, vendor management, and business transformation.

Organizations should therefore define their post-migration operating model before going live.

Cloud ERP security should be evaluated as a shared-responsibility model.

Organizations need to establish which security controls are provided by SAP and which remain customer responsibilities. Areas requiring particular attention include:

• Identity and access management
• Privileged access
• Segregation of duties
• Interface authentication
• Data classification
• Encryption requirements
• Logging and monitoring
• Regulatory retention requirements
• Third-party integrations
• Business continuity and disaster recovery
• Security testing and incident response

Moving ERP workloads to the cloud can change the control environment, but it does not remove governance obligations. Security and compliance requirements should therefore be incorporated into the migration architecture rather than addressed after implementation.

Data quality is one of the most significant determinants of migration complexity.

Organizations should not treat migration as a technical exercise of transferring every available record into the target environment. Instead, data should be assessed according to business value, legal requirements, operational requirements, reporting needs, and retention policies.

Key activities typically include:

• Master-data cleansing
• Duplicate identification
• Data ownership definition
• Historical-data assessment
• Archiving strategy
• Data mapping
• Reconciliation
• Validation of migrated balances and transactions

The target system should contain the data required to operate and govern the business—not simply a copy of everything accumulated in the legacy environment.