SAP Public Cloud vs. Private Cloud: Customization Isn’t Dead—It Just Grew Up

If you’ve been around SAP long enough, you’ve probably heard the same dramatic warning whispered like a prophecy: “In SAP Public Cloud, you can’t customize anything. Everything must be built in BTP. Clean core means no enhancements. Prepare for a life of standard-only despair.”

Let’s put that myth to rest.

Clean core is recommended in SAP Private Cloud. Clean core is mandatory in SAP Public Cloud. But mandatory clean core does not mean “no customization.” It means customization done responsibly—in ways that don’t break upgrades, don’t modify SAP’s underlying code, and don’t leave your system in a state that future consultants describe as “creative.”

And here’s the part most people miss: You can still do almost everything you used to do. You just do it differently.

SAP Public Cloud gives you a modern toolbox—Key User Extensibility, Cloud BAdIs, CDS-based analytics, SAP Build, and Integration Suite—that replaces the old user exits, Z transactions, and custom reports. The tools are different, but the outcomes are remarkably similar.

The Modern Public Cloud Customization Landscape

Public Cloud customization isn’t a single technique—it’s an ecosystem. You still build custom apps, enhance processes, add fields, create analytics, and integrate with partners. You just do it through clean-core mechanisms.

For custom applications and entirely new business processes, SAP Build and SAP Business Application Studio let you create full-fledged apps that look and feel like modern Fiori experiences. These apps connect to S/4HANA through released APIs and events, giving you the same functional reach you once achieved through Z transactions—without modifying SAP’s core.

For analytics, Core Data Services (CDS) and Custom Analytical Queries let you build cubes, KPIs, dashboards, and drilldowns. You can extend standard data sources with custom fields or build your own analytical models entirely. And yes—you can publish them as Fiori tiles, just like any other app.

For process enhancements, Key User Extensibility and Cloud BAdIs replace the old user exits and implicit enhancements. You can inject logic during document processing, validate data, apply custom blocks, enrich EDI payloads, or extend UI screens—all without touching SAP’s underlying code.

And for integrations, SAP Integration Suite handles transformations, mappings, partner-specific logic, and API orchestration. Instead of hardcoding partner quirks inside SAP, you push them to the middleware layer, keeping your ERP clean and upgrade-stable.

In short: Public Cloud doesn’t eliminate customization—it modernizes it.

Four Real Examples (Short, Practical, and Focused on Approach)

1. Adding a Custom Field to a Standard Report

In ECC or Private Cloud, you’d enhance the underlying structure, modify the CDS view, or adjust the ALV layout.

In Public Cloud, you simply create the field using the Custom Fields app, enable it for the analytical data source, publish it, and add it to the report layout. No backend code. No modifications. Same outcome: a new field in a standard report.

The method changes. The capability doesn’t.

2. Adding a Custom Check During Sales Order Save

In ECC, you’d use a user exit to validate demand and apply a custom hold.

In Public Cloud, you implement the logic through a Cloud BAdI in the sales order finalize phase. You read historical demand through released CDS views, compare it to the incoming order, and apply a custom block or trigger an approval workflow.

The logic still runs during order save. It’s just implemented through clean-core hooks instead of core modifications.

3. Partner-Specific UoM Conversions During EDI

In ECC, you’d modify the outbound IDoc using a user exit.

In Public Cloud, you choose the right clean-core approach depending on the complexity:
• Maintain ISO codes for standard UoM alignment
• Use Cloud BAdIs to adjust inbound or outbound EDI payloads
• Or push partner-specific mappings to Integration Suite

The transformation still happens. It simply happens in a cleaner, more maintainable place.

4. Building a Completely Custom Tooling Application

Imagine that you needed a custom tooling life process in SAP. You want to set up some custom master data, track tooling degradation over time at the time of goods movement, and have the ability to report on tooling life expectancy at any time. This is where the difference between ECC and Public Cloud becomes most interesting.

In ECC, you’d build:
• Custom master-data tables
• Custom transactions to maintain them
• User exits during goods receipt to track usage
• Custom ALV reports to monitor tool lifespan

It worked—but it also meant deep modifications, custom code everywhere, and upgrade considerations every time SAP released a new patch.

In Public Cloud, the architecture shifts, but the capability remains.

You start by defining your custom master data model using released extensibility frameworks. If the data needs to live inside S/4HANA, you create Custom Business Objects—complete with their own UI screens, validations, and lifecycle management. If the process is more specialized or workflow-heavy, you build a dedicated SAP Build app that handles the master-data maintenance with a modern Fiori UX.

To enhance existing processes—like goods receipt—you use Cloud BAdIs. These hooks let you read your custom master data, update usage metrics, trigger workflows, or apply business rules, all without modifying SAP’s underlying code.

For reporting, you build a custom CDS view that exposes the tool lifecycle metrics, then layer a Custom Analytical Query on top to define the KPIs, drilldowns, and filters. And yes—you can publish that query as a Fiori tile. It becomes a first-class citizen in the Launchpad, just like any SAP-delivered analytical app.

The result is the same: A fully custom business process, complete with master data, logic, and analytics. But the implementation is cleaner, modular, upgrade-safe, and visually modern.

The Real Difference

SAP Private Cloud lets you customize almost anything—including modifying SAP objects. SAP Public Cloud lets you customize almost everything—except modifying SAP objects.

That’s the distinction.

Public Cloud forces you to use:
• Released APIs
• Released CDS views
• Key User tools
• Cloud BAdIs
• BTP extensions

It’s not less powerful. It’s just more disciplined.
And most organizations benefit from that discipline.

Final Thought

The myth that “Public Cloud means no customization” is outdated. The reality is far more interesting:

Public Cloud doesn’t eliminate customization—it modernizes it.
It forces you to build smarter, cleaner, and more maintainable solutions. And it gives you a toolbox that’s more capable than ever.

If you embrace the clean-core mindset, you’ll find that Public Cloud doesn’t limit innovation—it accelerates it.

If you’d like to learn more, reach us at www.contax.com or info@contax.com.