S/4HANA by 2027: Protecting the Analytics Estate During Conversion

SAP ECC 6 (EHP6–8) leaves mainstream maintenance on December 31, 2027 — extended maintenance runs to 2030 at a premium, with a transition option beyond that available only through RISE with SAP. An ECC-to-S/4HANA conversion changes the data structures that BW extractors, operational reporting, and downstream data platforms depend on, yet analytics continuity is routinely the most under-planned workstream in the program. This guide covers what actually breaks and the phased playbook that keeps reporting running through cutover.

The Most Under-Planned Workstream in the Program

SAP ECC (ERP Central Component), SAP's classic ERP suite, reaches the end of mainstream maintenance for ECC 6 enhancement packages 6–8 on December 31, 2027. SAP S/4HANA, its HANA-native successor, is where every conversion program is heading. The programs themselves are ERP-led by construction: scope is defined in transactions, custom code, and business processes, and the plan is owned by people whose success metric is a working ERP on day one. Analytics enters that plan as a line item — "reporting: to be validated" — because analytics is a consumer of the system being changed, and consumers rarely get a seat when the producer is being rebuilt.

This is how conversion programs arrive at user acceptance testing with transactions passing and month-end reporting broken. The finance close still has to run during the conversion. Regulatory reports still have deadlines. Downstream data platforms still feed forecasting models. None of these consumers care that the conversion was on schedule; they care that Tuesday's numbers reconcile with Monday's. In our S/4HANA transformation work, we treat analytics continuity as a first-class workstream with its own plan, owner, and test evidence — because retrofitting it after the sandbox conversion has already surprised everyone costs far more.

The reason continuity is genuinely hard, and not just neglected, is that a conversion changes all four layers the analytics estate stands on at once: the physical tables, the extraction interfaces above them, the embedded reporting inside the ERP, and the feeds into everything downstream.

What Actually Changes Underneath Your Reporting

The Data Model Simplifies

S/4HANA's simplified data model consolidates financial line items into the universal journal (table ACDOCA) and removes many classic aggregate and index tables, with compatibility views standing in where they can. Any report, extractor, or replication feed built directly against replaced tables inherits that change — sometimes transparently through the compatibility layer, sometimes not, and the difference is only discoverable by testing.

BW Extractors Diverge

Classic BW extractors are not a uniform population after conversion: some continue as before, some behave differently against the simplified model, and some are deprecated in favor of newer interfaces. SAP's strategic extraction direction is CDS-based. Every custom extractor built on a replaced table is a defect waiting for its first delta run — which is why the extractor inventory is phase one of the playbook, not a testing afterthought.

Embedded Analytics Arrives

S/4HANA embedded analytics — operational reporting built on Core Data Services (CDS) views, SAP's semantic view-building framework, surfaced through Fiori — takes over much of the operational reporting that ECC estates historically pushed into BW. That is an opportunity to retire load-heavy operational content, but only if someone decides deliberately which reports move into the ERP and which remain in the warehouse.

Downstream Feeds Ripple

Everything that consumes ECC data downstream — SLT replication, CDC pipelines, lakehouse ingestion, planning systems — is coupled to source structures that just changed. Field lengths, table names, and semantics shift, and reconciliation frameworks that compare "before" and "after" have to account for the model change itself. This is where conversions quietly break data platforms that nobody listed as stakeholders.

Four Phases to Analytics Continuity

The playbook runs alongside the conversion program, starting at scoping — not at testing. Each phase produces evidence the next one depends on.

1. Assess Extractor & CDS Impact — Inventory every extractor, its base tables, and its downstream consumers, then map that inventory against the S/4HANA simplification impact for your conversion scope. Classify each interface: continues unchanged, continues with remediation, or replaced by a CDS-based successor. Do the same for direct-table consumers — replication feeds, custom ABAP reports, database links. The output is a remediation backlog with owners, sized before the sandbox conversion rather than discovered inside it. Our SAP BW warehousing team runs this assessment against the actual system, not against SAP's generic notes, because custom extractors are where the surprises live.
2. Dual-Run an Analytics Bridge — Through the conversion window, reporting must work against both worlds: the frozen pre-conversion baseline and the converted system. Build a reconciliation harness that compares key figures — trial balance, inventory positions, order backlogs — across both, automatically, every load cycle. Run it first against the sandbox conversion, where discrepancies are findings; then against production cutover, where they are incidents. This factory-style reconciliation discipline is precisely what our migration factory practice industrializes: scripted comparisons and burn-down reporting instead of analysts eyeballing spreadsheets at 2 a.m.
3. Make the Re-Platform Decision — The conversion forces analytics work regardless — so decide deliberately where that work should land. The realistic postures: convert the existing analytics stack in place, re-platform to SAP Datasphere (SAP's cloud data-warehousing and business-data-fabric service, positioned within SAP Business Data Cloud), or go lakehouse-first with SAP data integrated into a broader platform. The dual-run phase generates exactly the evidence this decision needs: which content is actually used, which extractors are worth remediating, and what the integration surface really looks like. Our SAP data intelligence practice designs the integration architecture for whichever posture wins.
4. Decommission Deliberately — Every conversion strands content: reports replaced by embedded analytics, extractors with no remaining consumers, reconciliation scaffolding that served its purpose. Retire it on a schedule with sign-offs, archive what audit requires, and shut down the licenses and infrastructure behind it. Programs that skip this phase pay for the old estate and the new one indefinitely — and the next migration inherits the confusion.

Where Should the Analytics Estate Land?

These postures are not mutually exclusive across an estate — finance may re-platform to Datasphere while supply chain goes lakehouse-first. What must be singular is the decision process: one owner, one evidence base, one integration architecture. Split the postures by domain if the evidence supports it; never split them by which team shouted first.

Frequently Asked Questions

Does an S/4HANA conversion break existing BW reporting?

Not wholesale — but selectively, and silently. Extractors and feeds built on tables replaced by the simplified data model can fail or return changed results, while others continue untouched. The only reliable answer is a per-extractor assessment against your conversion scope, validated by reconciliation runs against a sandbox conversion before production cutover.

What happens to BW extractors after the conversion?

They split into three groups: extractors that continue as before, extractors that need remediation because their base tables or semantics changed, and extractors that should be replaced by CDS-based extraction, which is SAP's strategic direction. Custom extractors built directly on replaced tables are the highest-risk group and should be inventoried first.

Can we keep our BW system after converting to S/4HANA?

Technically yes — a remediated BW continues to run against S/4HANA. But BW 7.5 has its own mainstream-maintenance end on December 31, 2027, with extended maintenance to 2030 at a premium. Keeping BW after the conversion means two maintenance clocks, not one, which is why the re-platform decision belongs inside the conversion program rather than after it.

What is the deadline for leaving ECC, exactly?

Mainstream maintenance for SAP ECC 6 (EHP6–8) ends December 31, 2027. Extended maintenance is available to 2030 at premium cost, and beyond 2030 SAP's transition option is available only through RISE with SAP, its subscription-based cloud offering. The practical deadline for starting is earlier than any of those dates: conversion programs with a properly planned analytics workstream are multi-year efforts.

When should analytics-continuity planning start?

At program scoping — before the sandbox conversion. The extractor and consumer inventory shapes the conversion test plan itself, and the reconciliation harness must exist before the first sandbox run to turn that run into evidence. Programs that begin continuity work at the testing phase have already spent their cheapest discovery opportunity.