Implementing a Unified ECC & S/4HANA Reporting Model in SAP Datasphere

Why does Hybrid ECC and S/4HANA Reporting matter in SAP Datasphere? During an enterprise SAP S/4HANA transition, global organizations rarely migrate all business units, functional areas, or regions simultaneously. These phased rollouts create prolonged interim periods where operational and historical data must coexist across legacy SAP ECC instances and the new S/4HANA digital core.

To maintain uninterrupted global reporting and executive visibility, these distinct environments must be consolidated into a cohesive analytical layer. However, combining legacy ECC tables (such as BSEG, BKPF, or VBAK) with modern S/4HANA Core Data Services (CDS) views presents significant challenges. S/4HANA CDS views abstract underlying data structures, often embedding complex, multi-layered calculation logic and richer metadata than their legacy counterparts.

To overcome these structural and semantic discrepancies, organizations can implement a structured, layered data architecture within SAP Datasphere. This approach provides a scalable framework that ensures data integrity, continuous reporting validity, and minimal disruption throughout the migration lifecycle.

SAP Datasphere Architecture Overview: Inbound, Harmonization and Propagation Layers

To resolve these architectural differences, we isolate raw data ingestion, transformation logic and reporting consumption into dedicated, decoupled layers. Implementing a clean separation of concerns ensures that modifications in source systems do not trigger a cascading failure across your reporting landscape.

The recommended SAP Datasphere architecture consists of at least three layers: Inbound, Propagation and Reporting.

For this use-case an additional layer - Harmonization - is necessary. Let’s take a closer look at the three layers that require further explanation in face of this data unification challenge:

Source System Identification

A foundational requirement of a multi-source architecture is the explicit injection of a source system identifier, ideally at the absolute point of ingestion. Using SAP Datasphere Replication Flows, we populate a technical field named SRC_SYS_ID for every record landed in the Inbound Layer (e.g., 'SAPECC' or 'SAPS4').

This field acts as a discriminator across the entire data pipeline. It enables precise filtering, supports lineage auditing and prevents cross-system data collisions in downstream models where business keys might otherwise overlap.

Watch the recording of our webinar: "“Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

​Designing the Harmonization Layer for ECC Data

Because S/4HANA data arrives in the Inbound Layer already structured according to modern CDS business semantics, it serves as our blueprint design standard. ECC Data does not arrive in the same standardized and enriched data model, but in a rather crude form.

The Harmonization Layer (HL) focuses exclusively on transforming legacy ECC data to match this S/4HANA target standard. While SAP Datasphere supports Graphical Views, utilizing SQLScript views is highly preferred here due to the immense flexibility and complex scripting capabilities it offers.

Three core areas must be addressed within the HL:

• Structural Alignment: Legacy ECC fields must be explicitly mapped, renamed, and data-typed to mirror the corresponding S/4HANA CDS view fields exactly.

• Semantic Reconciliation: S/4HANA introduced fundamental architectural consolidations, most notably the Universal Journal (ACDOCA). The HL must utilize complex joins, filters, and calculated fields to replicate these modern business rules using legacy ECC underlying tables (e.g., combining BKPF, BSEG, and CO sub-ledgers).
• Modular Design: To ensure scalability, transformation logic should be broken down into reusable graphical or SQL views. Centralizing core logic prevents code duplication and simplifies future maintenance.

In the example shown below, ECC tables LIKP and VBUK are being used in an HL layer view in order to recreate the structure of the I_DeliveryDocument CDS view from S/4.

​Creating a Unified Propagation Layer Using UNION Logic

Once the legacy ECC data is structurally aligned within the HL, it shares an identical schema with the native S/4HANA Inbound Layer data. In the Propagation Layer (PL), these two streams are combined.

Because the underlying schemas are now perfectly identical, a UNION ALL operation can safely consolidate the datasets. The S/4HANA data goes directly from the Inbound Layer to the UNION node without requiring intermediate structural transformations, minimizing processing overhead.

To give an example, the relevant excerpt of the Delivery Document Propagation Layer view would look as such:

lt_deliverydocument = 
SELECT
    "s4"."DeliveryDocument",    
    "s4"."DeliveryDocumentType",    
    -- ... [Other fields] ...    
    "s4"."SRC_SYS_ID",    
    "s4"."UPDATE_DTTM"    
FROM "SD_IL_S4_IDELIVERYDOCUMENT" AS "s4"
UNION ALL
SELECT 
    "ecc"."DeliveryDocument",
    "ecc"."DeliveryDocumentType",
    -- ... [Other fields] ...
    "ecc"."SRC_SYS_ID",
    "ecc"."UPDATE_DTTM"
FROM "ECC_HL_DELIVERYDOCUMENT" AS "ecc";

After creating this unification of the two source system datasets, the main PL layer logic can be applied. For example the local tables of delivery header and item are joined on their respective keys as well as the SRC_SYS_ID field.

Dynamic Pipeline Flexibility

A major advantage of this design is its adaptability to changing project requirements. Because the streams are cleanly separated within an SQLScript model, the entire ECC data stream can be commented out or isolated instantly if a business unit migrates ahead of schedule or if reporting scopes change. This adjustment requires no structural (code/metadata) alterations to downstream views, Analytic Models or SAP Analytics Cloud (SAC) dashboards.

By commenting out the ECC part in the PL layer view, the data coming from the highlighted part is removed without affecting the schema of the PL view.

Managing Associations Between Facts and Master Data

Consolidating transactional data across disparate systems introduces significant risks when managing master data relationships. In multi-source landscapes, business identifiers frequently overlap. For example, Customer ID 100045 or Material ID MAT-99 might represent one specific entity in the legacy ECC system and an entirely different, unrelated entity within the new S/4HANA tenant.

To prevent incorrect cross-system data assignment, models must implement source-aware associations. Every association between a Fact view and a Master Data dimension view within the Propagation Layer must utilize a composite key consisting of both the unique business identifier and the SRC_SYS_ID.

This approach guarantees absolute data isolation. An ECC transactional record will associate strictly with its corresponding ECC master data attributes, while an S/4HANA record remains bound directly to S/4HANA master data attributes.

​How to Preserve Business Continuity During SAP S/4HANA Migration

Beyond technical alignment, this architecture delivers long-term operational continuity across all phases of the S/4HANA transformation: before, during and after the migration.

When a regional migration completes, you do not need to refactor your core application logic or reporting views. Data simply ceases to update from the legacy ECC instance and begins flowing natively through the S/4HANA path. The historical ECC data remains accessible within the model as an immutable analytical archive for multi-year comparative reporting.

Operational Enhancement: Control-Table Filtering

To maximize agility, you can enhance the logic with a lookup to a centralized configuration/control table. This allows data engineers to dynamically filter out or toggle legacy ECC data execution based on active migration waves, purely by updating a status value in the control table rather than modifying (commenting out) code.

Unified ECC and S/4HANA Reporting Model in SAP Datasphere: Our Conclusion 

Successfully supporting enterprise reporting during an SAP S/4HANA transformation requires more than simply connecting multiple data sources. It demands a scalable architecture that reconciles structural differences, preserves business semantics and provides a consistent analytical experience regardless of where the underlying data originates.

By implementing dedicated Inbound, Harmonization and Propagation layers in SAP Datasphere, organizations can establish a unified reporting model that remains stable throughout every phase of the migration journey. This layered approach not only minimizes disruption during phased rollouts but also simplifies future maintenance, improves data governance, and enables historical and operational reporting to coexist seamlessly.

From our use cases, several best practices consistently contribute to successful implementations:

• Enforce strict naming conventions across SAP Datasphere spaces and objects to improve maintainability, transparency, and collaboration between development teams.

• Capture the source system identifier (SRC_SYS_ID) at the point of ingestion to ensure reliable lineage, prevent key collisions, and enable robust cross-system associations.

• Keep transformation logic modular and reusable, allowing harmonization views to be maintained independently and reducing duplication across projects.

• Design for future extensibility. A well-structured Harmonization Layer makes it straightforward to onboard additional SAP or even non-SAP ERP systems in the future without redesigning downstream reporting models.

• Separate business logic from source-specific logic, ensuring that reporting models and SAP Analytics Cloud dashboards remain stable as source systems evolve or legacy environments are decommissioned.

Ultimately, this architecture provides organizations with a future-proof reporting foundation that supports hybrid ERP landscapes today while accelerating the transition to a fully modern SAP environment tomorrow.

Reach out to our team to discuss your transformation goals and discover how we can help you build a unified, future-ready analytics landscape.