Getting SAP data out cleanly is a genuinely hard problem, and two deadlines just made it urgent. SAP ends mainstream support for legacy ECC at the end of 2027, and as of June 2026 it blocked the extraction method most third-party tools relied on. A lot of companies suddenly need a sanctioned way to get their SAP data into a modern lakehouse.
Portage Data is the engine I'm building for that. It lands a company's SAP data in their own lakehouse — Databricks, Snowflake, or Fabric — as clean, business-ready tables, and the data never leaves their cloud. The hard part is SAP's data itself: dates stored as text, amounts that mean nothing without a companion currency field, a single business entity split across header and line tables, a mandatory client column on every row. The engine decodes those quirks through a canonical type system, so each SAP quirk is decoded once and applied everywhere.
Two things make it a product rather than a script. The first is no forks. Every customer-specific variation — a custom field, a filter, a bespoke Z-table — lives in declarative config layered on top of untouched core models, so one improvement to the engine ships to everyone by version bump instead of forking per client. The second is trust. Every load proves the numbers in the lakehouse reconcile back to SAP, to the cent, and quarantines anything that doesn't rather than emit a silent wrong number. SAP data projects rarely fail on plumbing. They fail the first time a finance leader spots one wrong total and stops believing the system.
The working prototype builds that core: the config-driven medallion pipeline (bronze to silver to gold), the canonical SAP type system, the no-fork overlay merge, and the reconciliation that fails loud, in Python on Polars and Delta.