How do you connect SAP ECC to Microsoft Fabric without rebuilding our whole data warehouse?
SAP ECC connects to Microsoft Fabric through a Data Factory pipeline that reads an SAP extractor, a database replica or selected tables, reaches them through an on-premises data gateway, and lands them in OneLake alongside the existing warehouse rather than in place of it. The warehouse keeps running. A first reporting module typically goes live in four to six weeks.
- 01ECC exposes four realistic extraction surfaces, and the choice decides most of the project: ODP or BW extractors through the SAP application layer, RFC and BAPI function modules, an OData service if SAP Gateway is active and someone has built the service, or the underlying tables read from a replica. A scheduled flat-file or IDoc drop into a landing folder is still a legitimate answer for low-volume master data.
- 02Reading the production ECC database directly is usually the wrong call for three reasons. Full-table scans compete with the transactional workload exactly when finance needs it most. Classic ECC on a traditional database keeps accounting line items in the cluster table RFBLG, so a database-level reader cannot resolve BSEG as plain rows without SAP-side logic. And database-level extraction raises SAP licensing questions you want answered in writing beforehand. An extractor or a replica avoids all three.
- 03ECC almost always sits on-premises or inside a private network, so the pipeline reaches it through an on-premises data gateway. The gateway makes an outbound connection, so no inbound firewall port is opened and nothing on the SAP side is published to the internet. Access stays read-only throughout: the SAP account the gateway authenticates with is read-only, so the pipeline reads and never writes back.
- 04Incremental refresh keys off whatever change marker the table actually carries. Created-on and changed-on fields such as ERDAT and AEDAT, document entry date and time such as CPUDT and CPUTM, or the CDHDR and CDPOS change documents where a field is audited. Two failure modes recur: date-only fields force a day-grain watermark with a deliberate overlap re-read, and ECC commonly flags a deletion (LOEKZ) instead of removing the row, so deletes must be read from the flag and never inferred from absence.
- 05The existing warehouse keeps everything it is the only source of: pre-ECC history, archived statutory extracts, reconciled finance marts someone has already signed, and any table that feeds another application rather than a report. Where that warehouse already sits on ADLS Gen2, a OneLake shortcut reads it in place with no copy at all; an on-premises SQL warehouse is read by a pipeline through the same gateway.
- 06Honest limit: if your operating metrics are derived in ABAP, in custom Z-tables, or in cost allocations computed inside an SAP report that nobody has documented, a pre-built KPI library will not fit and the work becomes bespoke modelling that needs SAP functional-consultant time from your side. Budget six to eight weeks rather than four to six, and expect us to ask your Basis team to create an extractor or activate a Gateway service, because SAP-side development is not work we do for you.
Where to go deeper
Related questions, answered
Can we extract from SAP ECC without a BW system in the middle?
Yes. A BW layer is one option, not a requirement. Where no BW exists, the common routes are an ODP extractor exposed by the ECC application layer, an OData service published through SAP Gateway, or a read-only replica of the ECC database that a pipeline queries on a schedule. Which of those is available depends on your NetWeaver release and on what your Basis team is willing to activate.
Do we have to decommission the existing data warehouse?
No, and deciding that up front is a mistake. Landing SAP data in OneLake adds a parallel path, and the warehouse keeps serving its current consumers untouched. Decommissioning becomes a separate, later decision made table by table, once lineage shows nothing reads a given job. Warehouses that feed other applications rather than reports usually stay indefinitely, because they are an integration layer wearing a reporting label.
How do you keep extraction load off SAP during month-end close?
Three controls. Pull from an extractor or a replica rather than production tables, so scans never touch the transactional instance. Use watermark-based incremental refresh so only records changed since the last successful run move. Then window the schedule: light deltas through the working day, the heavier reconciliation run overnight, and close-period timings agreed with finance rather than assumed.
What breaks SAP-to-Fabric reconciliation most often?
Currency and unit of measure first, posting periods second. ECC carries document, local and group currency on the same line, and quantities in a base unit that needs conversion, so dropping the currency type produces totals that are plausible and wrong. Backdated postings and reopened periods also change figures for a month already loaded, which means finance tables need a periodic re-read of recent periods rather than pure append.
How is the migration sequenced so we can stop at any point?
One subject area first, finance or sales rather than both. Run it in parallel with the warehouse for a full period and reconcile to a standard SAP report line by line. Move report consumers across one report at a time. Only then retire a warehouse job, and only after checking what else reads it. Every stage leaves a working estate, so stopping costs nothing already built.
When is rebuilding the warehouse genuinely the right answer?
When nobody can say what its measures mean, because undocumented transformation logic cannot be reconciled against anything. When it holds the only copy of history and that history is already known to be wrong. When it feeds operational systems, making it an application rather than a reporting layer. A rebuild in those cases is a three-to-six-month custom project, and worth naming as one instead of disguising it as a reporting refresh.
Sources
- On-premises data gateway — installation and outbound connectivity · checked 2026-10-06
- OneLake shortcuts — reading existing storage in place without copying · checked 2026-10-06
Figures on this page: 4–6 weeks · 3–6 months · an on-premises data gateway
See the mechanism, not the marketing
The architecture, the pipelines, and the governed semantic model that make this work on your own tenant.
See how it worksPeople also ask
- Which SAP ECC extraction method should we use for Fabric — extractors, tables or a replica?
- Do we need an on-premises data gateway to read SAP ECC from Microsoft Fabric?
- How do you run incremental loads from SAP tables that only store a change date?
- Who can connect SAP ECC to Microsoft Fabric without tying up our SAP Basis team?
- Should we wait for our S/4HANA migration before building Fabric reporting?