Written by Minami — Paddy & Water Inc. / Technology & Platform

The Truth About Structural Differences, Constraints, and Configuration That Private Cloud Veterans Need to Know

June 2026

Introduction: The Biggest Pitfall Is the Assumption That “It’s the Same SAP”

SAP S/4HANA Cloud Public Edition (hereafter, “Public Edition” or “PE”) is introduced as SAP’s latest cloud ERP. However, for engineers and consultants who have spent years building S/4HANA Private Cloud (on-premise or dedicated cloud) systems, the first wall they run into is confusion: “It’s the same SAP, so why is it so different?”

This article was written to resolve that confusion. It keeps general overview explanations to a minimum and instead focuses on the information that Private Cloud veterans can immediately put to practical use: differences in table structures, what customization is and isn’t allowed, differences in the data model, transaction constraints, and differences in technical configuration.

To state the conclusion up front: Public Edition is a SaaS designed on the premise that customers will use SAP’s standard processes through Fit-to-Standard. Most of what Private Cloud teams took for granted — ABAP customization, direct table access, and free-form Customizing — is sealed off. Accurately understanding the exact boundary of these constraints is what determines whether a Public Edition implementation succeeds or fails.

1. Functional Comparison for Manufacturing: Private/Public Differences by Business Area

This chapter organizes the functional differences between Private Edition and Public Edition by business area, with Japanese manufacturers — particularly engineer-to-order (ETO) and make-to-order producers — in mind. Clearly understanding what is and is not possible in each area — design, production planning, shop-floor logistics, and cost management — is essential when selecting an implementation model.

1.1　Design and Engineering (ECTR / PLM / PEO)

This concerns how CAD data (drawings) is connected through to the ERP’s manufacturing BOM and shop-floor work instructions. Whether engineering change orders (ECOs) reach the shop floor in real time has a direct impact on product quality and rework costs.

Business Requirement / Function	Private Edition	Public Edition
Direct CAD integration via ECTR	[Possible]　Various 3D CAD systems (e.g., SolidWorks) communicate directly with S/4HANA, automatically generating material masters and EBOMs.	[Not possible / restricted]　Tight, direct coupling is not possible. Integration with an external PLM occurs asynchronously as text (BOM data) via API or BTP.
EBOM-to-MBOM conversion	[Possible (PEO)]　Differences (structure, quantities) between the design BOM and manufacturing BOM can be visually compared on screen while converting and synchronizing.	[Not possible]　Because PEO is out of scope, conversion within the ERP is not possible. The MBOM must be fully built on the external PLM side before being fed into the ERP.
Attaching drawings/specifications (DMS)	[Possible, large-capacity support]　Drawing PDFs and similar files can be stored on a dedicated content server and linked to each document.	[Restricted]　Restricted to prevent core bloat. Managing links to BTP object storage or external storage (e.g., SharePoint) is the basic approach.
4M changes and electronic work instructions	[Possible (PEO)]　Linked to engineering change orders (ECOs), tightly governing shop-floor electronic instructions with 3D drawings and the specification of tools and skills.	[Not possible]　Only the standard “routing” is available. Limited to simple, text-based work instructions.

1.2　Project and Production-Lot (Seiban) Management (PS / CO)

This concerns differences in how procurement, inventory, and cost are tied to a “seiban” (production lot number) — the core mechanism of Japanese engineer-to-order (ETO) manufacturing. Hierarchical seiban management and cost accounting by seiban are Private Edition’s greatest strengths.

Business Requirement / Function	Private Edition	Public Edition
Hierarchical seiban management	[Possible (PS-WBS)]　Complex breakdown structures — parent seiban → child seiban → grandchild-level procurement — can be fully represented within the system.	[Not possible]　Hierarchical WBS for manufacturing is, in principle, out of scope. Restricted to flat, single-level management (MTO) at the SD (sales order line item) level.
Project inventory (inventory by seiban)	[Possible]　Inventory can be managed as fully segregated “inventory dedicated to seiban A-001,” including both valuated and non-valuated stock.	[Not possible]　Managing project inventory tied to a WBS is, in principle, not possible. Only “sales-order-specific segmented inventory” tied to the sales order is supported.
Inventory transfers between seiban (reallocation)	[Possible]　Stock transfer processing (document-based movement) — such as urgently diverting material from seiban A to seiban B — is supported as standard.	[Not possible]　Diverting or transferring sales-order-specific inventory to another order is either severely restricted or simply not accounted for within the standard process (Best Practices).
Actual cost accounting by seiban	[Possible]　Using the WBS as the cost collector, actual procurement and production costs and the allocation of overhead are aggregated to calculate the final landed cost.	[Restricted]　”Project cost management” aimed at service industries exists, but the actual-cost and allocation logic needed for manufacturing cannot be handled within the standard scope.

1.3　Production Planning and Detailed Scheduling (PP / PP-DS)

This concerns whether realistic production plans can be built that account for finite capacity — constraints on equipment and personnel. The presence or absence of the PP-DS engine is the single biggest technical dividing line between Private and Public.

Business Requirement / Function	Private Edition	Public Edition
Project MRP (seiban-based MRP)	[Possible]　MRP is run starting from the WBS (seiban), batch-generating “purchase requisitions and production orders tagged with the seiban” across all levels (e.g., via MD51).	[Not possible]　PS-driven MRP does not run. “Sales-order-specific MRP (MD50),” starting from the SD sales order, is used as a substitute.
Finite-capacity scheduling	[Possible (PP-DS)]　Recognizes the capacity limits of machines and tooling and can automatically level loads and optimize changeovers to the minute or second.	[Not possible]　The PP-DS engine is not included. Only day-/week-level “infinite-capacity MRP” (stacking up load while ignoring machine availability) is possible.
Simulation (multiple scenarios)	[Possible (PP-DS)]　Simulates on a Gantt chart how an existing plan would be affected if a rush order came in.	[Not possible]　Detailed visual simulation within the core ERP is not possible. The design philosophy is that broad supply-and-demand adjustment is handled externally, in SAP IBP.

1.4　Shop-Floor Logistics and Manufacturing Execution (EWM / MES / PM)

This concerns differences in the execution-layer systems that control the movement of a plant’s warehouses, automated equipment, and production lines. The difference in architectural philosophy between Embedded and Side-by-Side shows up vividly here.

Business Requirement / Function	Private Edition	Public Edition
Direct connection to material handling / automated warehouses (MFS)	[Possible (Embedded EWM)]　Transport instruction signals can be sent directly from within the ERP to plant cranes and conveyors (the PLC layer).	[Not possible]　Public Edition’s built-in warehouse management (a lightweight version) has no MFS. A separate external WMS or material-handling control system must be built and integrated.
Advanced warehouse execution (wave picking, etc.)	[Possible (Embedded EWM)]　Built-in support for wave picking across multiple orders combined, labor management for warehouse staff, and travel-path optimization.	[Not possible]　Limited to bin location management and simple goods-receipt/issue records. If advanced logistics execution is required, integration with an external, full-scale EWM is needed.
Cloud MES integration (SAP Digital Manufacturing)	[Possible]　Production orders are sent from S/4HANA, with shop-floor results (4M) linked bidirectionally in real time.	[Possible and recommended]　The “only standard scenario” for enhancing the MES area under Public Edition. Because the ERP side is deliberately lightweight, this integration becomes essential.
Linking unplanned repairs with production planning	[Possible]　When a machine breakdown or repair is registered in PM (Plant Maintenance), it is immediately reflected in PP-DS capacity data and the plan is automatically corrected.	[Restricted]　PM functionality exists, but because there is no detailed scheduler like PP-DS, automatic minute-level rescheduling is not supported.

1.5　Cloud Operations and Customization (BTP / ABAP)

This is a decisive area of difference in the system’s operational lifecycle and the rules governing add-on development. The constraints in this area have the greatest impact on the overall scope and cost of a project.

Business Requirement / Function	Private Edition	Public Edition
Modifying source code	[Possible]　Through traditional ABAP development, standard programs (CMOD/SMOD, BAdIs, enhancement spots) can be rewritten to inject custom logic.	[Absolutely prohibited]　Not a single line of standard code may be modified. Extension is limited to building a separate app on BTP or using the limited extension points that the standard provides.
Screen customization (GUI)	[Unrestricted]　Both SAP GUI and Fiori are supported. Custom add-on screens familiar to shop-floor users can be produced in volume, one per transaction code.	[Fiori only]　SAP GUI cannot be used. Screen changes are limited to what fits within Fiori’s standard templates, or a screen must be built entirely from scratch on BTP.
Impact of automatic updates	[Controllable]　Against an annual product release, the company decides the timing of its own version upgrades, allowing for thorough regression testing.	[Forced, automatic application]　Twice a year, the latest patches and features are applied on a semi-mandatory basis. Unless add-ons are kept Clean Core, the system will break.

1.6　The Architect’s Perspective: What These Differences Mean, in Summary

Looking across these five areas, what emerges is that Private and Public are fundamentally aimed at different pictures of what a company should look like. The question is not which is superior, but which one matches your own business model.

Private Edition: Digitalizing Shop-Floor Capability and Fine-Tuned Coordination

A robust framework in which the system itself can absorb — in a transformed but embedded way — the strengths of leading Japanese manufacturers: flexible response to engineering changes, the almost magical changeover skills of shop-floor planners, and the intricate, seiban-by-seiban cost management they rely on. Suited to companies that want to encode their own proprietary know-how into the system and maintain a competitive edge.

Public Edition: Digitalizing Standardized, Simplified Operations

An agile, extremely low-operating-cost framework in which a company sets aside its own particular preferences and fits its operations thoroughly into the world’s standard best practices. Because the ERP core (the “plain white rice”) is never touched, the company can keep automatically benefiting from the latest AI features (Joule) and new functionality twice a year. Suited to companies that prioritize speed and agility and are looking toward global rollout.

A hybrid configuration — “start with Public and migrate only certain manufacturing functions to Private” — is theoretically possible, but in practice it is rare, given the cost and complexity of such a migration. During the pre-implementation planning phase, it is a prerequisite for success that management, the IT department, and shop-floor staff share an understanding of these differences and jointly decide what to give up and what to protect.

2. Fundamental Architectural Differences: What Is Multi-Tenant SaaS?

Differences in the Underlying Structure of Private Cloud and Public Edition

In Private Cloud, a single company has exclusive use of a single SAP system (ABAP Application Server). The database schema, too, is dedicated to that one company, giving a high degree of freedom for ABAP development, table changes, and Customizing changes.

Public Edition is a multi-tenant SaaS in which a single SAP system is shared across multiple companies (tenants). SAP centrally manages the system infrastructure, the ABAP core, and upgrades, and, in principle, tenant-specific code changes or direct database manipulation are not possible.

• Code line: In Public Edition, all tenants share the same ABAP code (standard code). SAP carries out mandatory upgrades four times a year, on a quarterly basis.

• Tenant separation: Each tenant is separated by client. This is the same “client” concept as in Private Cloud, but the physical database layer is shared infrastructure.

• Scope of customization: Within Configuration (IMG settings), only the settings that SAP has explicitly permitted can be changed. IMG items that are not permitted are not even displayed in the first place.

System Landscape: A Mandatory Three-System Landscape

In Private Cloud, in addition to the three systems — Development (DEV), Quality Assurance (QAS), and Production (PRD) — companies are free to add sandbox systems, training systems, and the like. Public Edition provides the following configuration as its standard.

• Starter System: Used for Fit-to-Standard workshops early in an implementation project, to confirm SAP’s standard processes. Configuration made here does not persist.

• Quality System: Used for testing and user acceptance testing (UAT).

• Production System: The live, production system.

The biggest surprise for Private Cloud veterans is that there is no Development (DEV) system at all. There is no “development system” to serve as the venue for custom ABAP development; instead, the ABAP Environment on BTP (ABAP Cloud) becomes the venue for extension development. The traditional ABAP transport regime — promoting code via transport requests (DEV → QAS → PRD) — does not exist.

3. ABAP and Customization: What Can and Cannot Be Done

The Blanket Prohibition on ABAP Customization

The single most important fact that Private Cloud engineers need to know first: in Public Edition, ABAP customization of the SAP core (standard code) — user exits, BAdI implementations, enhancement spots, modifying function modules, or writing directly to standard tables — is not possible under any circumstances.

• User exits: The USER_EXIT_* and EXIT_*-style exits heavily used in Private Cloud. These are not provided in Public Edition.

• Classic BAdIs: The “classic BAdIs (interface implementations via SE18)” used in Private Cloud cannot be used. Some functionality can be substituted using Key User Extensibility, but not all of it.

• ABAP Dictionary changes (SE11): Adding fields to standard tables or creating new tables is not possible. Custom tables — the traditional approach of creating Z-tables in SE11 — are also not possible.

• SE80 (ABAP Workbench): SE80 exists, but saving changes to standard objects results in an error. Viewing only is possible.

Permitted Extensions: Key User Extensibility and Developer Extensibility

Extending Public Edition is limited to two official channels.

Key User Extensibility

Extensions that business users (key users) can configure through the Fiori UI without any ABAP coding.

• Custom fields (Custom Fields and Logic): Defines additional fields on standard objects (sales documents, purchase orders, business partners, etc.). Defined through the Fiori app “Custom Fields and Logic (F3484).” Added fields are stored in an Extension Table managed by SAP — the standard table itself is never changed.

• Custom logic (business logic): Within the “Custom Fields and Logic” app, implementations of “business logic (BAdIs)” can be written using an ABAP editor within Fiori. However, the ABAP that can be used is restricted to what conforms to ABAP Cloud (Released APIs only).

• Custom CDS views: Custom fields can be added to existing CDS views as extensions, intended for use in reporting and analytics.

• Page layout changes: The screen layout of Fiori apps — showing/hiding fields, making them mandatory, grouping them — can be changed with no code.

Developer Extensibility (Side-by-Side Extensions)

Side-by-side extensions built using the ABAP Environment, CAP, or Build Apps on BTP. This approach never touches the Public Edition core; instead, a custom app is developed on the BTP side and calls Public Edition’s APIs.

• Released OData APIs (SAP API Business Hub): Public Edition accepts data operations from external systems only through SAP’s standard OData APIs. Operations not included among the Released APIs — such as specific business logic or direct access to specific tables — cannot be performed even via the API.

• RAP (RESTful ABAP Programming Model): A configuration in which a RAP-based custom app developed in the BTP ABAP Environment calls Public Edition’s APIs.

4. Differences in Table Structure and the Data Model

The Universal Journal (ACDOCA): A Core Shared with Private Cloud

S/4HANA’s Universal Journal (table ACDOCA) is the core data model shared by both Public Edition and Private Cloud. The architecture in which all journal-entry data from FI, CO, and ML (Material Ledger) is stored in the single ACDOCA table is identical in Public Edition.

However, there are the following differences regarding the ACDOCA table structure.

• Custom extension fields: In Private Cloud, Z-fields such as “ACDOCA-ZZFIELD” can be added directly to ACDOCA via SE11. In Public Edition, direct addition is not possible; Key User extension fields are instead stored in an extension table (such as ACDOCA_E). Reports and CDS views reference this extension table via a join.

• How tables are accessed: In Public Edition, custom ABAP cannot execute direct SELECT statements (ABAP Open SQL) against standard tables. In principle, all data access must go through CDS views or Released APIs.

The Alternative to Custom Tables: The Extensibility Table Mechanism

In Private Cloud, Z-tables — arbitrary custom data tables defined in SE11 — can be created freely. This approach does not exist in Public Edition; the following alternatives are used instead for storing custom data.

• Key User Custom Objects (Custom Business Objects, or CBOs): Custom data objects (equivalent to tables) are defined with no code in the Fiori app “Custom Business Objects.” Fields, key structures, and relationships (links to standard objects) can be defined, and data can be managed through an automatically generated Fiori screen. However, they do not offer the same degree of freedom as Z-tables — for example, flexibility in joins, index definition, and bulk data processing performance.

• Managing custom data in HANA Cloud (on BTP): For large-scale custom data, a practical approach is to store it in HANA Cloud on BTP via a CAP app, with integration to Public Edition handled through APIs.

Whether Key Tables Can Be Accessed

This section summarizes how access methods change under Public Edition for the key tables that were routinely referenced in Private Cloud.

• MARA/MARC/MARD (material master): Direct SELECT is not possible. Access is through published CDS views such as “I_Material,” “I_MaterialPlant,” and “I_MaterialStock.” Access via Released OData APIs such as “API_MATERIAL_DOCUMENT_SRV” and “API_PRODUCT_SRV” is standard.

• KNA1/KNB1 (customer master): Accessed through CDS views “I_Customer” and “I_CustomerCompanyCode.” The OData API “API_BUSINESS_PARTNER” is the standard integration API.

• LFA1/LFB1 (vendor master): Consolidated into the unified Business Partner (BP) model. CDS views “I_Supplier” and “I_SupplierCompanyCode” are used.

• VBAK/VBAP (sales order header/items): CDS views “I_SalesOrder” and “I_SalesOrderItem” are used. CRUD operations are performed via the OData API “API_SALES_ORDER_SRV.”

• EKKO/EKPO (purchase order header/items): CDS views “I_PurchaseOrder” and “I_PurchaseOrderItem” are used, along with the OData API “API_PURCHASEORDER_PROCESS_SRV.”

• BSEG (FI line-item table): In S/4HANA, BSEG survives as a compatibility view. It can still be accessed in Public Edition, but for performance reasons, referencing ACDOCA via a CDS view is recommended.

• T001/T001L (company code/storage location): These configuration tables can be viewed as Customizing settings, but direct SELECT from custom ABAP is not possible.

5. Differences in Customizing: What Can and Cannot Be Configured in the IMG

Changes in How Customizing Is Accessed

In Private Cloud, all Customizing settings can be freely accessed via SPRO (the IMG, or Implementation Guide). In Public Edition, SPRO exists, but the Customizing items displayed are restricted to only “allowed Customizing” — a curated set that SAP has selected.

IMG items that are not permitted simply do not appear in the SPRO tree at all. Private Cloud veterans frequently have the experience of “that setting item just isn’t there.”

Customizing That Can and Cannot Be Configured, by Major Area

FI (Financial Accounting)

• Configurable: Company code definition, fiscal year variants, posting period variants, the chart of accounts (adding/changing G/L accounts), payment terms, dunning settings, tax code definitions (limited), and basic bank master settings.

• Not configurable / restricted: Creating new document types (only standard types may be used; custom types cannot be added), adding custom posting keys, detailed customization of the Financial Closing Cockpit (FCC), and advanced changes to account determination rules.

SD (Sales and Distribution)

• Configurable: Sales organizations, distribution channels, basic definition of product hierarchies, partial configuration changes to standard order types, basic delivery type settings, basic billing type settings, custom additions to pricing procedures, and adding condition types (within a certain range).

• Not configurable / restricted: Freely adding new sales document types (in principle, only SAP standard types are allowed), custom delivery-split rules, output-management action settings (which have moved to the new BRF+/Form Template approach), and detailed changes to availability check settings.

MM (Materials Management / Procurement and Inventory)

• Configurable: Purchasing organizations, purchasing groups, partial configuration changes to material types, basic movement type settings, some vendor evaluation criteria, adding valuation classes (limited), and basic MRP type settings.

• Not configurable / restricted: Adding custom movement types (new Zxxx-style movement types) is not possible; adding user-defined stock types, custom MRP calculation algorithms, and detailed changes to the rules for automatically updating purchasing info records.

PP (Production Planning)

• Configurable: Plant definitions, work scheduling parameters, MRP parameters (reorder points, lot sizes), basic work center category settings, and production version settings.

• Not configurable / restricted: Freely adding custom production order types, adding custom statuses for Shop Floor Control, and embedding custom MRP calculation routines are not possible.

CO (Controlling)

• Configurable: Cost center hierarchies, profit center hierarchies, internal order types (some standard ones), primary/secondary cost elements, activity type definitions, and WBS element settings (PS).

• Not configurable / restricted: Detailed customization of costing variants, changes to custom account determination, and freely adding CO-PA characteristics (subject to a set limit and an approval process).

The Configuration Change Process: The “Manage Your Solution” Fiori App

The primary interface for Customizing settings in Public Edition is the Fiori app “Manage Your Solution (F2700).” It corresponds to SPRO in Private Cloud, but the settings displayed are narrowed down for Public Edition.

• Configuration change procedure: “Manage Your Solution” → “Configure Your Solution” → select the business area → select the activity (setting item) → open the configuration screen and make the change.

• Applying changes: Customizing changes in Public Edition are applied to the production system via a “Change Request.” This corresponds to a transport in Private Cloud, but SAP automatically checks the consistency of the change before applying it.

• Background settings (background job scheduling): Background jobs (the equivalent of SM36) are managed through the Fiori app “Manage Scheduled Jobs (F2373).” Directly defining jobs via SM36 is not possible; schedules are set based on SAP’s standard job templates.

6. Transaction Codes and Fiori: Changes in Screen Operation

Availability of SAP GUI Transactions

In Public Edition, the primary interface for business processing has shifted to Fiori. SAP GUI has not been abolished entirely, but the transaction codes available for use are severely restricted.

Major Transactions That Remain Available (Partial List)

• SE16N/SE16 (table browser): Read-only access to a published range of tables and CDS views; updates are not possible. Since Z-tables do not exist, the targets are standard tables and CDS views.

• AL11 (file system browser): On BTP infrastructure, access to the file system is restricted. File integration is, in principle, done via SFTP/API.

• SU01 (user management): Creating users and assigning authorization roles is possible. However, authentication standardly relies on integration with IAS (Identity Authentication Service), so SU01 alone may not be sufficient.

• SM30 (table maintenance): Only permitted Customizing tables can be changed. Since Z-tables do not exist, it cannot be used for that purpose.

Major Transactions That Are Unavailable or Restricted

• SE11 (ABAP Dictionary): Viewing standard tables is possible; changing or creating tables is not.

• SE80 (ABAP Workbench) / SE38 (ABAP Editor): Viewing standard programs only. Changing them or creating custom programs is not possible.

• SPRO (the full IMG): Displays only the IMG narrowed down for Public Edition.

• SM36/SM37 (background job management): Direct job definition is not possible; the Fiori app “Manage Scheduled Jobs” is used instead.

• ST05 (SQL Trace) / ST12 (ABAP Trace): Performance analysis tools. In Public Edition, access for standard users is restricted; these are positioned as administrative tools used by SAP’s support team.

• CMOD (enhancement management) / SE19 (BAdI Builder): BAdI management for custom implementations. Not usable in Public Edition (replaced by Key User Extensibility).

Constraints on Customizing the Fiori Launchpad

In Private Cloud’s Fiori Launchpad, tile groups and catalogs can be freely customized using tools such as SAP_UI_BC_MC (Fiori Launchpad Content Manager). In Public Edition, customization is possible via “Manage Launchpad Settings (Fiori),” but the business catalogs that serve as the source of tiles are defined by SAP standard only, and adding custom business catalogs is restricted. Adding tiles for custom Fiori apps is done via “SAP Build Work Zone” on BTP.

7. Differences in Authorization Management

Role-Based Access Control: The Shift to a Business-Role-Centric Approach

In Private Cloud, PFCG (the Profile Generator) is used to finely define single roles, composite roles, and profiles. In Public Edition, authorization management shifts to an approach centered on “business roles.”

• Business roles: Defined as SAP-standard business roles (e.g., “Accounts Payable Accountant,” “Warehouse Operator”). Each business role is composed of a combination of business catalogs (sets of Fiori apps) and restriction types (filters on organizational values).

• Customizing business roles: Custom business roles can be created by copying SAP standard business roles. Business catalogs can be added or removed, and restriction type values (company code, plant, sales organization, etc.) can be set.

• PFCG has not been abolished: PFCG itself still exists, but in Public Edition, the traditional approach of creating roles directly in PFCG and assigning them to users is not recommended. Managing business roles through the Fiori app “Maintain Business Roles” (in the F2700 series) is the standard.

Authentication and Mandatory Integration with IAS

In Public Edition, integration with “SAP Identity Authentication Service (IAS)” is a prerequisite as the authentication foundation. In Private Cloud, local authentication (password management via SU01) was the mainstream approach, but in Public Edition, the identity and authentication of all users are managed through IAS to achieve single sign-on (SSO).

• Active Directory (Azure AD / Entra ID) integration: The company’s IdP and IAS are linked via SAML federation, allowing single sign-on to Public Edition using the company’s AD account.

• Restrictions on local users (SU01): Technical users (for background jobs and API integration) continue to be managed via SU01, but managing general business users locally through SU01 is discouraged.

8. Changes in Output Management

Moving Away from the Traditional NACHRICHTEN Approach

In Private Cloud, document printing, EDI, and email sending were managed via the output management framework known as NACHRICHTEN (messages) — based on NAST and condition tables. In Public Edition, this approach is positioned as “legacy output management,” and migration to the new approach is required.

The New Approach: Based on BRF+ and Form Templates

• Business Rules Framework plus (BRF+): The rules that determine output channels (print, EDI, email, electronic signature, etc.) are defined in BRF+. This corresponds to Private Cloud’s condition tables (NAST), but the UI has moved to Fiori, allowing more flexible condition definitions.

• Form Templates (Adobe Forms / SAP Forms): Printed forms are defined using Adobe Forms on Adobe Document Services (ADS). Private Cloud’s SAPscript and SmartForms are deprecated; migrating existing SAPscript/SmartForms to Adobe Forms is required.

• “Maintain Output Channels”: Output channel settings are managed through the Fiori app “Maintain Output Channels (F2679).”

The effort required to change output management tends to be underestimated as a project cost. If existing forms — invoices, purchase orders, shipping instructions, and the like — were created in SAPscript/SmartForms, a full migration design to Adobe Forms is required, and the impact is greater for companies that had done extensive form customization.

9. Differences in Interfaces and Integration

Changes in the Role of IDocs

In Private Cloud, IDocs (Intermediate Documents) have been widely used as the standard means of integration with legacy systems, other SAP systems, and EDI. IDocs can technically still be used in Public Edition, but for new designs, integration via OData/REST APIs (through SAP Integration Suite) is recommended.

• Recommended migration from IDocs to the new approach: Plans should be made to migrate existing IDoc integrations to OData API + BTP Integration Suite (iFlows). Support for IDocs is not being discontinued, but new functionality and extensions will be concentrated on the API-based approach.

• RFC (Remote Function Call): In principle, RFC calls from external systems are not possible. Released OData APIs and, in some cases, BAPI wrapper APIs are used as substitutes for RFC.

The Mandatory Use of BTP Integration Suite (iFlows)

SAP’s recommended architecture is for all integration between Public Edition and external systems to pass through an iFlow in BTP Integration Suite (Cloud Integration). Since direct database connections and direct RFC connections are blocked off, API-based integration is the default.

The pattern heavily used in Private Cloud — batch file integration via custom ABAP programs (FTP → ABAP processing → database write) — is replaced in Public Edition with the pattern: SFTP server → iFlow (file retrieval and transformation) → OData API (feeding data into Public Edition).

Changes to Print Output: Cloud Print Management

In Private Cloud, printing is managed via the SAP spool system and an SAP print server (such as CUPS). In Public Edition, integration with “Cloud Print Manager (Fiori)” or an external cloud printing service (such as SAP Document Management Service or OpenText) is required. Configuring direct printing to in-house printers requires additional setup in Public Edition.

10. The Practical Impact of Mandatory Quarterly Upgrades

The Upgrade Cycle and Change Management

The most significant operational characteristic of Public Edition is mandatory quarterly upgrades — four releases a year. SAP automatically updates every tenant’s system to the new version. This is a fundamentally different operational requirement from Private Cloud’s model of planned version upgrades once every few years.

• Preview System: About three weeks before the production upgrade, the same changes are applied ahead of time to the quality assurance system (the Preview Period). During this window, the impact of the changes is checked and regression testing is carried out.

• Notification of changes: SAP publishes the content of each quarterly release in advance — new features, deprecated features, and Customizing changes — via the “What’s New Viewer” on help.sap.com. The operations team needs a structure in place to regularly check these notifications and plan its response to each upgrade.

• The necessity of test automation: Running regression tests every quarter cannot be sustained with manual testing effort alone. Test automation — via SAP Cloud ALM’s Test Suites functionality or an external test automation tool (such as Tricentis Tosca or Worksoft) — is effectively mandatory.

Responding to Deprecated Features

Alongside new features, each quarterly release also announces functions that are being deprecated. Deprecated functions are given an advance-notice period (typically around two years), but the function is disabled once the deprecation date passes.

Examples of deprecated functions that Private Cloud veterans should be especially aware of include SAPscript/SmartForms, classic BAdIs, and NACHRICHTEN-based output management. These already carry deprecated status, and when implementing Public Edition, designing a migration to the new approach is essential.

11. SAP Cloud ALM: How It Differs from Private Cloud ALM

The Positioning of Cloud ALM

SAP Cloud ALM (Application Lifecycle Management) is the implementation and operations management tool for Public Edition. It is a separate product from SAP Solution Manager (SolMan), which is used in Private Cloud, and is provided as a BTP service.

• Implementation management: Projects, phases, tasks, fit-gap analysis, and test case management are all handled within Cloud ALM.

• Change management: Propagating Customizing changes from the quality assurance system to production is managed through Cloud ALM’s “Change and Transport Management.”

• Operations management: System monitoring, job monitoring, and alert management are carried out in Cloud ALM — the equivalent of SolMan Monitoring in Private Cloud.

• Test management (Test Suites): Managing, executing, and recording the results of regression test and UAT test cases is done in Cloud ALM.

The shift from SolMan to Cloud ALM is not merely a tool migration; it involves a change in process and mindset as well. Custom settings and custom monitoring configurations from SolMan cannot be carried over to Cloud ALM.

12. Points Often Overlooked When Designing a Migration from Private Cloud

Pre-Migration Checklist: 10 Items to Confirm

• ①ABAP customization inventory: Catalog all ABAP customizations in the current system (user exits, BAdIs, ABAP reports, Z-tables) and determine the replacement approach under Public Edition for each — Key User extension, BTP extension, retirement, or a change in business process.

• ②Form inventory: List every SAPscript/SmartForm and estimate the scope and effort of migrating it to Adobe Forms. For companies with a large number of forms, this becomes the single largest line item of effort.

• ③IDoc/RFC inventory: Create a complete list of interfaces and design the migration to OData API + iFlow.

• ④Checking output management’s dependency on NAST: Confirm how many output settings rely on NACHRICHTENSTEUERUNG (condition-table-based routing) and draw up a plan for migrating to the BRF+ approach.

• ⑤Customizing gap analysis: Identify which current Customizing settings cannot be configured in Public Edition, and consider either a business process change or an alternative measure.

• ⑥User count and licensing: Public Edition is licensed on a per-user (named user) basis. Unlike Private Cloud, it is not concurrent-user licensing, so an accurate estimate of the number of active users is required.

• ⑦Test strategy: Plan a test automation strategy for handling quarterly upgrades from the earliest stage of design.

• ⑧Carrying over organizational structure values (company code, plant, etc.): Migration worksheets (migration templates) are provided for setting up existing organizational structure values in Public Edition.

• ⑨Migrating background jobs: Job definitions from SM36 are migrated to the Fiori app “Manage Scheduled Jobs.” Custom ABAP jobs cannot be migrated, so a replacement such as BTP Process Automation is needed.

• ⑩Data migration tools: Data migration for Public Edition uses SAP’s standard “Data Migration Cockpit (LTMC/LTMOM)” or the “Data Migration to SAP S/4HANA Cloud” tool. However, the migration objects supported may be fewer than in the Private Cloud version of the Data Migration Cockpit. Early consideration of target data and migration methods is necessary.

This concludes the article.