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

SAP ECC 6 (EHP6-8) leaves mainstream maintenance on 31 December 2027, with extended maintenance to 2030 at a premium and 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 platforms depend on. Analytics continuity is routinely the most under-planned workstream in the programme.

#Why Analytics Continuity Gets Missed

What this means for you: if analytics is a line item in someone else's plan, it has no owner, no test evidence, and no budget — and you will find that out during user acceptance testing.

SAP ECC (ERP Central Component), SAP's classic ERP suite, reaches the end of mainstream maintenance for ECC 6 enhancement packages 6-8 on 31 December 2027. SAP S/4HANA, its HANA-native successor, is where every conversion programme is heading.

The programmes 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".

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 programmes 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 than planning it at scoping.

The reason continuity is genuinely hard, and not merely neglected, is that a conversion changes all four layers the analytics estate stands on at once.

#What Actually Changes Underneath Your Reporting

What this means for you: four layers move simultaneously, and only one of them — the physical data model — is documented well enough to plan against without inspecting your own system.

#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. The difference is only discoverable by testing your own objects, not by reading release notes.

#BW Extractors Diverge

Classic BW extractors split after conversion: some continue as before, some behave differently against the simplified model, and some are deprecated in favour 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 rather than 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. It is only an opportunity if someone decides deliberately which reports move into the ERP and which remain in the warehouse; left undecided, you fund both.

#Downstream Feeds Ripple

Everything that consumes ECC data downstream — SLT replication, change data capture pipelines, lakehouse ingestion, planning systems — is coupled to source structures that just changed. Field lengths, table names, and semantics shift.

Reconciliation frameworks that compare "before" and "after" have to account for the model change itself, or they will report differences that are correct and differences that are defects in the same column. This is where conversions quietly break data platforms whose owners were never listed as stakeholders.

#Four Phases to Analytics Continuity

What this means for you: the playbook runs alongside the conversion programme from scoping, and each phase produces the evidence the next one needs — which is what makes it defensible to an auditor.

#Phase 1: Inventory every interface before the sandbox conversion

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 rather than against SAP's generic notes, because custom extractors are where the surprises live.

#Phase 2: Dual-run reporting against both worlds

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, on 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 what our migration factory practice industrialises: scripted comparisons and burn-down reporting instead of analysts eyeballing spreadsheets at two in the morning.

#Phase 3: Decide where the analytics estate lands

The conversion forces analytics work regardless, so decide deliberately where that work should land. 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.

#Phase 4: Decommission on a schedule, not on goodwill

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 licences and infrastructure behind it.

Programmes that skip phase four pay for the old estate and the new one indefinitely, and the next migration inherits the confusion.

#Where Should the Analytics Estate Land?

What this means for you: three postures are defensible, and the conversion is the cheapest moment to choose between them, because the evidence is already on the table.

SAP Datasphere is SAP's cloud data-warehousing and business-data-fabric service, positioned within SAP Business Data Cloud. Choosing between the second and third postures is a warehouse-migration decision in its own right, with its own four paths and its own readiness evidence — set out in full in the SAP BW to Datasphere 2027 decision guide.

Our SAP data intelligence practice designs the integration architecture for whichever posture wins, and our data platform building team handles the lakehouse side where the third posture is chosen.

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, before the sandbox conversion.

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

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

#What is the deadline for leaving ECC, exactly?

Mainstream maintenance for SAP ECC 6 (EHP6-8) ends on 31 December 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, because conversion programmes with a properly planned analytics workstream are multi-year efforts.

#When should analytics-continuity planning start?

At programme 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 in order to turn that run into evidence. Programmes that begin continuity work at the testing phase have already spent their cheapest discovery opportunity.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are planning an ECC-to-S/4HANA conversion and need the analytics workstream sized before it becomes an incident, book a discovery call.