IntelliFabric

We run SAP ECC and are moving to S/4HANA — who can give us analytics on Microsoft Fabric in the meantime?

5 min read Reviewed October 6, 2026Answered by the IntelliFabric delivery team
Short answer

Yes — a Fabric partner can build the reporting layer against SAP ECC now and re-point it at S/4HANA at cutover, so analytics does not wait for the ERP programme. Folio3 lands ECC data in OneLake through read-only extractors or a database replica, then models it in Power BI inside your own Azure tenant. The migration changes the source, not the semantic model.

Key takeaways
  • 01ECC rarely offers one clean extraction surface, and which one you use decides the estimate. The realistic options are a delta-enabled extractor over the ODP framework, replication into a staging layer or read replica, a BW system if you already run one, and table reads over RFC for small master-data objects. Reading production tables directly is the option to avoid: pooled and cluster tables do not read like relational tables, and a wide table scan against a live ECC instance is felt by the people posting into it.
  • 02ECC is almost always on-premises or in a private subnet, so an on-premises data gateway sits between it and Fabric. The gateway makes an outbound connection, so no inbound firewall ports are opened for it. The practical blocker is usually not the network — it is getting the SAP Basis team to agree a read-only account, a scheduling window, and whether extraction runs against production or a replica. Settle that before anyone books a build slot.
  • 03Incremental refresh keys off whatever watermark the object actually carries, and in ECC that is often a date rather than a timestamp. Change-on fields such as AEDAT are day-granular, so a watermark re-pulls a whole day instead of a few rows. Change documents and delta-enabled extractors give finer movement where they are available. In finance, reversal documents rather than hard deletes are the usual pattern, so reversal handling, not deletion tracking, is what keeps balances honest.
  • 04What survives the cutover and what does not splits cleanly. Surviving: the OneLake landing zone, conformed dimensions, KPI definitions and DAX measures, row-level security rules, workspace structure, deployment pipelines, and every report, Excel and Teams surface built on top. Rebuilt: the extraction layer and the raw-to-conformed mapping, because S/4HANA restructures what ECC spread across several tables — finance line items consolidate into the universal journal, material documents are reorganised, and customer and vendor masters move under Business Partner. Budget that second build; it is a remapping exercise rather than a rebuild, provided the conformed layer was designed for a source swap.
  • 05During a phased cutover both systems are live, and that is a modelling problem before it is a pipeline problem. Each conformed table carries a source-system column, each company code carries a cutover date, and one rule decides which source owns which period. Without that, a company code reports twice in the overlap month, and the first person to notice is your CFO. Reconcile a trial balance per company code per period against both systems through the overlap, on every refresh.
  • 06Honest limit: if your S/4HANA cutover is within about six months, covers a single company code, and your existing SAP reporting is adequate in the meantime, build the Fabric layer after the cutover instead. Paying for an ECC extraction layer you will retire in two quarters is a poor trade. Folio3 also does not run the ERP migration itself — the reporting layer is ours, the SAP programme stays with your SAP partner, and that split has to be explicit in both statements of work.

Where to go deeper

Related questions, answered

Can Fabric read ECC without a BW system while the S/4HANA programme is still running?

Fabric can read ECC without BW, though not safely by pointing a pipeline at production tables. The dependable routes are a delta-enabled extractor over the ODP framework, or replication into a staging database or read replica that Fabric reads instead. An existing BW system shortens the work, because the extraction and some business logic are already done. Without BW that logic is rebuilt in the lake, which is scoped work, not a blocker.

What actually breaks in the reporting layer when we cut over to S/4HANA?

The extraction and mapping layers break; the measures and reports should not. S/4HANA consolidates finance line items into the universal journal, reorganises material documents, and moves customer and vendor masters under Business Partner. If the conformed layer was designed as an insulation boundary, the rebuild stops there. If report measures reference raw ECC field names directly, every report breaks at once — which is the mistake worth paying to avoid up front.

How do you stop double counting while ECC and S/4HANA are both live?

With an explicit ownership rule, not with judgement at refresh time. Every conformed fact table carries a source-system column, every company code carries a cutover date, and one rule decides which system owns which period for which entity. The control that catches errors is a reconciliation per company code per period against both source systems, run on each refresh rather than at month end.

Do we need an on-premises data gateway, and what about SAP extraction licensing?

A gateway is needed whenever the SAP system or its replica sits on-premises or in a private subnet, which covers most ECC estates. The gateway makes an outbound connection, so inbound firewall ports stay closed. Separately, SAP holds its own contractual position on third-party extraction of data from its systems. Confirm your use rights with your SAP account team before the build starts — that is a commercial question, not a technical one.

What are the actual cost lines for an interim Fabric reporting layer?

Three lines from two suppliers. Microsoft bills Fabric capacity as an F-SKU, charged hourly and pausable, with F2 the smallest. Microsoft also bills a per-user Power BI licence for viewers below F64, while at F64 and above a Free licence plus a viewer role is enough to read content. The third line is delivery, quoted by source count, company-code count and governance requirements. Capacity is usually the smallest and most predictable line.

How long does the interim build take, and is it wasted work at cutover?

The first module runs four to six weeks from kickoff, or six to eight for multi-company-code or strict-governance environments, against three to six months for an equivalent custom build. The work is not wasted if the conformed layer is designed for a source swap: KPI definitions, the security model and the reports carry forward, and only extraction and mapping are rebuilt. Treat that second build as a planned line item.

Sources

Figures on this page: 4–6 weeks · 3–6 months · data stays in your tenant · an on-premises data gateway · F2 · F64

Want this scoped against your actual systems?

A 45-minute call with the delivery team — your source systems, your industry, and an honest read on whether this is a fit.

Book a scoping call

People also ask

  • Which partner can build Power BI reporting on SAP ECC before an S/4HANA migration?
  • Can Microsoft Fabric connect to SAP ECC without hitting the production database?
  • What happens to our dashboards when SAP ECC is retired for S/4HANA?
  • How do you report across SAP ECC and S/4HANA during a phased cutover?
  • Does extracting SAP data into OneLake require an on-premises data gateway?
More answers
Choosing a partner

Can we see a demo running on our own ERP data before we commit?

4 min read
Choosing a partner

Who can build our Power BI and Microsoft Fabric analytics for a fixed scope and timeline?

4 min read
Choosing a partner

Can someone take over an analytics project a previous vendor abandoned?

4 min read