The root cause is rarely the upgrade itself. It is architectural debt, a hidden “upgrade tax” caused by technical shortcuts taken years earlier. In most cases, the break isn’t caused by SAP; it’s caused by years of Z-cloned apps, direct table reads, and UI logic built outside SAP’s supported frameworks. 

For a CIO this isn’t just a development hurdle, it is a governance failure that erodes the ROI of the entire S/4HANA business case.

What Actually Changes (The Technical Shift)

Upgrading S/4HANA is no longer a simple database refresh. The move to the latest releases involves fundamental shifts in how SAP handles the UI:

• SAPUI5 Evolution: SAPUI5 is now updated continuously. If your apps depend on internal methods, every upgrade becomes a regression event—not a routine patch.
• The OData v4 Leap: SAP is pivoting from OData v2 to v4. Custom extensions built on legacy v2 services often require significant rework or total rewrites to maintain performance and compatibility.
• Clean Core Contracts: SAP has formalized Tier 1 Extensibility (C1 Contracts). Apps that bypass these “released” APIs are essentially reaching into the S/4HANA “basement”—accessing data through unreleased paths that SAP feels no obligation to keep stable.

The Invisible Cost: Technical Debt is an AI Tax

We are entering the era of the “Autonomous Enterprise,” where SAP Joule and Generative AI assistants navigate the ERP for the user. However, AI assistants rely on standard metadata and released APIs to understand business context.

If your Fiori landscape is a web of “Z-clones” and non-standard controllers, you aren’t just breaking your next upgrade—you are “blinding” your future AI. An AI assistant cannot effectively provide insights on a custom-cloned app that doesn’t follow the SAPUI5 standard.

CIO Perspective: Cleaning the core isn’t just about maintenance; it’s about AI-Readiness. Every app you bring back to “Standard” or “Fiori Elements” is an app that can immediately leverage SAP’s multi-billion-dollar investment in Business AI.

The Strategic Path: Extension Governance

Extensibility must be architecture-governed, not developer-driven.

1. The “Golden Path”: Fiori Elements

Freestyle UI5 offers flexibility but maximizes fragility. Fiori Elements should be the default for 80% of use cases. They follow SAP design templates and are automatically aligned with the SAP lifecycle.

Value: Standardization ensures your UI evolves with SAP, not against it.

2. Tiered Extensibility (Key User Tools First)

Before writing code, teams must exhaust Key User Extensibility (Custom Fields and UI Adaptation). These are “upgrade-proof” because SAP owns the compatibility layer.

3. Lifecycle Decoupling: Side-by-Side on SAP BTP

The S/4HANA core is your “System of Record”—it should be stable and governed. Your BTP extensions are your “Systems of Innovation”—they must be agile.

Value: By moving high-change apps to BTP, you ensure that a UI update in a customer portal doesn’t require a full regression test of your entire Finance core.

Embedded vs. Side-by-Side: The Decision Matrix

A CIO Maturity Checklist: Are You Upgrade-Ready?

Before your next upgrade, assess your landscape maturity:

1. The “Clone” Count: How many standard SAP apps were copied to the Z-namespace? (Each is a liability).
2. API Health: What percentage of our custom code uses Tier 1 / Released APIs versus direct table access?
3. Governance Gate: Do we have an Extension Review Board, or is the developer deciding where the code lives?

Modernization Gap: Are we spending more than 30% of our upgrade budget simply “fixing” what we already built?

The Strategic Message

The question for your leadership team is no longer: “Can we build this?” The question is: “Can we upgrade this safely in three years?”Clean Core is not about technical purity; it is a cost-containment strategy. Organizations that treat extension design as a strategic architectural decision will upgrade faster, innovate more safely, and stop paying the “upgrade tax” that stalls digital transformation.

About the Author

José López is a senior SAP technology leader with 20+ years of experience managing and optimizing mission-critical SAP environments. As Principal Director of SAP AMS, he leads end-to-end service delivery for large, complex SAP landscapes.

SAP S/4HANA 2023 marks a decisive step toward the intelligent enterprise vision. Beyond being another technical upgrade, it delivers a platform where automation, embedded analytics, and AI-driven decision support come together to simplify operations and improve business outcomes.

1. Smarter Processes Through Automation

SAP has expanded automation capabilities across core business functions, eliminating repetitive tasks and enabling continuous operations. Here’s how.

SAP Build Process Automation Integration

S/4HANA 2023 integrates natively with SAP Build Process Automation (BPA) on SAP BTP, allowing customers to design low-code bots that execute SAP transactions, validate data, and trigger workflow approvals. Examples include automatic journal posting approvals, purchase order release workflows, and background invoice verifications.

Situation-Handling Enhancements

New Situation-Handling Templates automatically alert users when events deviate from expected business rules, such as delayed production orders, migration job failures, or overdue inspections. This enables the following proactive response model: The system detects, informs, and suggests corrective actions before users notice an issue.

Predictive and Preventive Maintenance

Manufacturing and supply-chain processes now benefit from machine-learning models embedded in S/4HANA 2023 that forecast equipment failures or quality issues. SAP calls this Predictive Quality Inspection — leveraging HANA ML and AI Core services. This brings true autonomous maintenance closer to reality.

2. AI and Machine Learning in Core Finance

Financial departments gain from the following intelligent features that reduce manual reconciliation and speed up close cycles:

• Machine-Learning Intercompany Reconciliation (ICR): Automatically detects and proposes matches for cross-company postings.
• Predictive Cash Flow Forecasting: Learns from historical patterns to estimate future liquidity positions.
• Smart Accruals and Automated Adjustments: Rules and ML-based triggers generate accrual postings automatically.

Together, these features redefine the Finance function as data-driven and exception-managed, rather than transaction-driven.

3. Embedded Analytics and Citizen Reporting

The 2023 release brings a new level of flexibility in embedded analytics:

• Drag-and-drop measure ordering, autofill capabilities, and bookmark sharing in the multidimensional grid.
• The “Manage KPIs and Reports” app now allows business users to create and publish analytical apps without developer help.
• PDF export and transportable bookmarks streamline management reporting.

This self-service analytics experience reduces dependency on IT, empowering functional users to become citizen analysts.

4. Governance, Security, and Master Data Intelligence

Data privacy and compliance remain a cornerstone. The new Business Partner Data Controller concept within S/4HANA 2023 introduces up to 10 controllers per record with new authorization objects for fine-grained data governance (B_BUP_DCPA, B_BUP_DCPD).

For master data synchronization, SAP Master Data Integration (MDI) enables federated governance across S/4HANA, Ariba, Concur, and SuccessFactors — a key step toward enterprise-wide data harmonization.

5. Connected Work Experiences

SAP continues bridging business processes with collaboration tools. Examples include:

• Native Microsoft Teams integration, which brings chat, file sharing, and approvals directly into Fiori apps.
• SAP Concur integration, which automates expense reconciliation and approval chains.
• Unified Attachment Service, which allows versioning, line-item attachments, and Outlook shortcuts — reducing manual document management.

The result: A connected, collaborative user experience that blends ERP transactions with modern workplace tools.

6. User Experience and Fiori 3.0 Evolution

With S/4HANA 2023, SAP further refines the Fiori 3.0 Quartz theme, improving accessibility, personalization, and tile organization.

Users can now reorder measures, create favorites, and personalize spaces according to their daily tasks. The interface feels faster, cleaner, and more consistent, which is key for adoption success.

7. Why Version 2023 Matters

S/4HANA systems running on versions 2020 or 2021 will reach end of mainstream maintenance in 2026. Upgrading to S/4HANA 2023 not only extends support but also delivers immediate value in the following ways:

• Reduced manual effort via automation
• Predictive insights embedded in business processes
• Stronger security and compliance posture
• Seamless integration with BTP automation and analytics services

8. Apiphani’s Perspective

At apiphani, we see S/4HANA 2023 as the turning point between digital core modernization and intelligent enterprise enablement.

Our AMS and BASIS teams are already helping customers upgrade to 2023 FPS03, implementing automation use cases in Finance, Supply Chain, and Basis operations (e.g., automated transport handling, archiving, and health monitoring via SAP Build).

The message to our clients is clear. Don’t treat your upgrade as a technical event. Make it a foundation for automation and intelligence.

Final Thoughts

SAP S/4HANA 2023 is more than a version update. It’s a shift toward autonomous ERP operations. By leveraging embedded AI, predictive analytics, and low-code automation, organizations can move from reactive management to proactive optimization.

If you’re still on an earlier release, the upgrade path to 2023 isn’t only about compatibility, it’s about capability.

About the Author

José López is a senior SAP technology leader with 20+ years of experience managing and optimizing mission-critical SAP environments. As Principal Director of SAP AMS, he leads end-to-end service delivery for large, complex SAP landscapes.

Integrating non-SAP solutions into an SAP environment can be complex, especially in environments involving both cloud and on-prem systems.

This case study explores how apiphani successfully integrated an industry-specific non-SAP application for a client across three different environments: The client’s on-prem data center, RISE with SAP S/4 HANA on Azure Cloud, and the client’s existing AWS Cloud for Business Warehouse and Business Planning and Consolidation (BW/BPC).

Apiphani deployed and configured SAP HANA Smart Data Integration (SDI) with an SAP HANA sidecar to replicate data from a client S/4 HANA landscape to Powerplan, an industry-specific solution for utilities.

While this case study describes some of the specifics of the Powerplan set up, it is intended to describe the mechanics of the HANA sidecar and SDI elements of the solution and how it is applicable to any replication scenario.

Overview

Powerplan is software used by asset-intensive companies such as utilities that need to “stay ahead of accelerating tax and regulatory changes, and optimize compliance, strategic decision making and financial performance.”

Internally, the application contains Project, Asset, and Depreciation modules, each of which contain many master data attributes which are related to the General Ledger (GL).

The SAP SDI is used to replicate specific information from the S/4 HANA modules into a HANA sidecar database, where it can be converted by the Powerplan application and returned to SAP S/4 HANA as future state master data.

The process facilitates the outbound postings from Powerplan to SAP S/4 for capital asset-related activity as well as inbound integration for work breakdown structure (WBS) headers and transactions.

The master elements that need to be converted include:

• Company
• GL accounts
• Department

Powerplan supports either System Landscape Replication (SLT) or SDI to move the data between the S/4HANA systems and the Powerplan software. Since the client already had a functioning SDI environment working in conjunction with the BW/BPC environment, apiphani chose the SDI method.

The Solution as Architected

Apiphani deployed an SAP HANA SDI environment to allow data replication between RISE for SAP S/4 system on Azure Cloud and the Powerplan SAP HANA sidecars deployed in the client’s existing AWS Cloud. This involved configuring several HANA interfaces and replication tasks using the SDI agents and HANA sidecar virtual tables.

Apiphani created 32 replication tasks, one for each required table, filtering data by Company and Client.

Figure 1 – Solution Architecture

n Figure 1 we can see the integration of the three different locations: The customer’s on-premise VMware environment, RISE for SAP S/4 hosted in MS Azure, and the SAP HANA sidecars which apiphani deployed in the client’s existing BW/BPC AWS cloud environment.

The Solution as Implemented

Below are the steps we executed to make all this work:

• We installed two HANA sidecars. We created two tenants on the non-production sidecar, one for development and one for test, and created a single production tenant DB on the second sidecar.

• We increased the CPU and memory on the existing non-production SDI agent server to accommodate two more agents.
• We installed and configured the two new agents on the non-production SDI server and connected them to each tenant DB, DEV, and QAS.
• We installed and configured the production SDI agent and connected it to the PRD tenant DB.
• We created the Powerplan user on each of the S/4 HANA DBs, allowing access to the SAPHANADB schema containing the tables to be replicated while making sure to grant access to SELECT and TRIGGER on each.
• We used the CUSTOM_USER_ROLE_ADMIN user provided by the RISE team to create a second account. This second account had privileges to create custom roles; in this case we created a custom role that allowed the POWERPLAN user to select and trigger on tables under SAPHANADB schema.
• We then configured the Remote Data sources using the HANA Adapter type.
• Lastly, we created all the Replication Tasks, as shown below in Figure 2.

Figure 2 – Replication Tasks

Problems Encountered, and Solutions – Tips for You

Here are some issues that we encountered, along with the steps we took to resolve them. Both the issues and solutions are applicable to any replication scenario. We hope you find this information helpful.

Tip #1: Double-Check Roles and Permissions

When creating the replication task for table CSKT, we got an error message that was not at all friendly. It turned out to be related to a lack of authorization on the RISE S/4 side, although this was not immediately apparent.

In this specific case we did not grant TRIGGER for SCHEMA SAPHANADB. In case you encounter anything similar, check the Data Provisioning (DP) agent error log file (framework_alert.trc) located in /&AGENT_HOME/log for all low-level error messages.

Example:

[ERROR] [af0655b3-9254-4ded-a552-e8ebb5a25eab28968] HanaAdapterDelegate | ExceptionUtil.newAdapterException [] – Failed to add the first subscription. Error: Required privileges and/or roles not granted to the database user [POWERPLAN]. Missing privileges and/or roles are [TRIGGER ON [“SAPHANADB”.”CSKT”]]. Required privileges and/or roles not granted to the database user [POWERPLAN]. Missing privileges and/or roles are [TRIGGER ON [“SAPHANADB”.”CSKT”]].

Tip #2: Reset the Subscription After Making Changes to Replication Task Properties

If you want to change a replication task, either changing the client or any other property, the subscription needs to be reset first.

We received an error while activating the replication task as follows:

/powerplan/ACDOCA.hdbreptask:[powerplan:ACDOCA.hdbreptask] transaction rolled back by an internal error: sql processing error: Remote subscription powerplan:: ACDOCA.SUB_V_SAPHANADB_ACDOCA is Active. Reset the remote subscription and retry the operation.[:.] Rollback detected while activating objects of runtime “Replication task runtime”

Reset here: Mark the replication task and click reset, then save the replication task and execute in the editor.

Figure 3 – Subscription Reset

Tip #3: Watch Key Definitions

We generated duplicate records in the ACDOCA table, because when the target virtual table is created, the default behavior is to do so without a primary key.

This in turn prevented the selection of UPSERT as the remote subscription type. The fix is to create a Primary key matching the key that the source table has in the S/4 HANA system.

Figure 4 – Primary Key Definition

This allowed the selection of UPSERT and prevented having duplicate records in the target table.

A remote subscription of type UPSERT replicates data in real-time from a remote source object to a table on the local SAP HANA database.

Type UPSERT means that all types of data changes (inserts, updates, and deletions) are written to the target table with an UPSERT SQL command.

For keys that have been deleted from the remote source object, the statement writes the value D to column SDI_CHANGE_TYPE in the target table.

In other cases, the statement writes the value A to column SDI_CHANGE_TYPE. The commit timestamp of the transaction is written to column SDI_CHANGE_TIME.

More details about UPSERT can be found here.

Tip #4: Use the Truncate Table Upon Execution Option to Avoid Primary Key Violation Errors

If you see a primary key violation when running a replication task, we recommend that selecting option “truncate table on execution.” This will prevent primary key (PK) violation errors.

Other apiphani articles you may find helpful:

• SAP S/4 HANA – Paths to a Successful Transition
• The Role of ITSM in Engineering Business Outcomes
• Is RISE Enough?

Conclusion

This process served as a good illustration of how the SDI can be used to handle interfaces between RISE with SAP S/4 landscapes and other supported ancillary applications that are required to run the business. While the Powerplan application was the end target in this case, the SDI replication scenario is broadly applicable.

Key Points Summary:

1. Extending the existing SDI environment – including the DP agent servers – to handle this particular replication scenario worked well. We had already stacked four non-production DP agents on the existing server, and we increased the available resources before adding two more.
2. Placing both the development and quality assurance HANA tenants on a single HANA sidecar database instance saved costs without adding undo administrative complexity.
3. If faced with an opaque error message during replication, it may well be related to database permissions. Check the DP agent error log for more detail/clarity.
4. Changing any replication task property requires a subscription reset.
5. Be careful to match your primary key definitions between the source S/4 system and the HANA sidecar database. Any changes in table structure on the source side must also be reflected in the sidecar database.
6. In the same vein, use the “truncate table upon execution” option to clean out the sidecar database after a structure change to avoid primary key violation errors.