SAP → DEX Framework
Stay on SAP, stay behind.
Move to DEX — start building.
Every company in your sector runs the same SAP modules, the same transaction codes, the same Fiori apps. Best-practice configuration is shared practice — it is exactly what the consultant sold the company across the street last quarter. Advantage comes from software only you can build. DEX framework is where that software lives: TypeScript, JSON descriptors, Postgres underneath, iteration measured in days.
Cost-driven angle instead? See SAP ERP Migration · All migrations
Why sameness is the problem
The SAP you run is the SAP your competitors run.
SAP's value proposition is best-practice configuration — a shared baseline every company in your sector will eventually match. That is the opposite of a moat. Four forces are compressing what remains of the headroom at the same time.
Best practice is shared practice
Your SAP consultant sold the same implementation to your biggest competitor. Transaction codes, authorization models, Fiori apps — tested, documented, and converging on a common baseline across the sector. The parts SAP does well are the parts everyone else also gets for free.
Your customizations are the slow ones
The only part of SAP that actually distinguishes you is the custom layer — Z-programs, BAdIs, user exits. Each change is a development + transport + UAT cycle measured in weeks. If iteration speed is where competitors beat you, SAP prices that speed out of reach.
2027 forces the question
ECC mainstream support ends in 2027; extended paid support runs to 2030. S/4HANA conversion is an 18–36 month program whether you want the new features or not. Once a program that size is on the roadmap, "is SAP the right destination at all?" is a fair question, not a radical one.
Talent gravity works against you
ABAP talent is retiring. New developers build in TypeScript, Go, Python — not in a vendor-specific 4GL. Every year, iterating on your SAP custom layer costs more while iterating on standard-stack custom software costs less.
The destination
DEX is where you build what SAP won't let you build.
DEX framework is a governed platform for the layer that actually differentiates you. Your Z-programs, BAdIs, and bespoke workflows get extracted, rewritten as TypeScript + JSON descriptors on Postgres, and land in a codebase where iteration is measured in days. The vanilla parts of SAP — the bits that were always going to look like everyone else's — either retire or get replaced once, cheaply, at the edges.
- Standard TypeScript on Postgres No proprietary runtime, no forked language. Your new application compiles, deploys, and runs the way any TypeScript service does.
- JSON descriptors, not black-box UI Every screen, workflow, and rule is a versioned JSON document. Diffable in git. Readable by humans and by auditors.
- Governed AI generation Generation is constrained to the framework's patterns. Output is auditable — every file has a traceable origin back to an extracted SAP rule.
- Generated code you own Every file lands in your repo. If DEX Elements vanishes tomorrow, you still have a working TypeScript application and the Postgres schema under it.
- Composable at the edges DEX owns the application layer. Kafka, dbt, Camunda, Airbyte plug in where you need event streaming, analytics, or long-running orchestration.
Full technical brief at /framework. Product overview at /product.
What replaces what
What differentiates moves to DEX. What commoditises moves to OSS.
Your custom application layer — the part that actually distinguishes you from competitors — lands on DEX framework where it can be iterated at standard-stack velocity. The layers below (warehouse, integration, event streaming) become open-source components: mature, proven, and identical to what your competitors will also use. Commodity plumbing stays commodity plumbing.
How the framework handles it
A port preserves the friction. DEX extracts the asset.
Half of SAP's custom-layer code exists because SAP made the obvious thing hard. Migrating without reconsidering just carries the friction over. The framework's four primitives — process mining, governed generation, agent workflows, retrieval — separate the logic worth keeping from the workarounds that existed only because of SAP.
Process mining on SAP exports — before any code is touched
BKPF/BSEG posting data, CDHDR/CDPOS change documents, and transaction logs feed a process-mining layer. The output is a ranked list of actual paths through your SAP system. High-volume high-variation processes surface first; the long tail of Z-programs nobody runs is flagged for retirement, not migration.
Governed ABAP → TypeScript — constrained, not free-form
The framework parses every Z-program, Y-include, and function module. Business rules land as JSON descriptors. TypeScript is emitted against the framework's fixed patterns — no folder layout, auth, logging, or deployment decisions for the AI to re-invent per file. The result is 5–10× more token-efficient than free-form generation and auditable rule-by-rule.
Agent workflows replacing hard-coded transactions
Transactions like ME21N, VA01, MIRO carry decades of conditional customizations. On DEX, those conditionals become declarative policies that drive agent workflows — the agent composes the steps, humans stay in the loop at the decisions that matter. Less code to maintain, more visibility into what the system is actually doing.
RAG over Z-code and SAP documentation
During and after the migration, the team queries a retrieval index over every Z-program, SAP Note, config table, and customization spec. Institutional knowledge survives even when the last ABAP developer on the engagement rolls off.
The path
Strangler fig, not big-bang.
The strangler-fig pattern — Martin Fowler, 2004 — applied to SAP. Each module runs on DEX alongside SAP through a shared integration layer. SAP shrinks module by module. Finance moves last, with a parallel-run period auditors can reconcile independently. There is no cutover weekend.
Read-only mirror + analytics decoupling
4–8 weeksCDC off the SAP underlying database into Postgres. Every downstream report, dashboard, and extract moves off SAP onto the mirror. SAP stays the system of record; analytics load comes off it on day one. First DEX surfaces — read-only dashboards — go live against the mirror.
- Analytics load off SAP
- Zero SAP-side risk
- First proof DEX runs on your data
Peripheral modules onto DEX framework
3–6 monthsHR, procurement, and master data typically move first: clean integration boundaries, lower audit risk, and high custom-code density. Each module's Z-programs are regenerated onto DEX. The old SAP module is decommissioned behind a feature flag once the DEX version holds.
- First module fully off SAP
- License seats reduced
- Strangler pattern proven end-to-end
Core finance — DEX with parallel-run period
6–12 monthsFI/CO migrates only after peripheral modules are stable. Parallel-run means every posting lands in both SAP and DEX for 2–3 close cycles. Auditors reconcile the two ledgers independently before cutover. No big-bang weekend, no rollback-plan theatre.
- Reconciled audit evidence
- SOX sign-off before cutover
- Financial core running on DEX
Decommission
2–4 weeksSAP licenses stop renewing. The old system archives to cold storage with a read-only query layer for the regulatory retention window (typically 7–10 years). DEX framework is the system of record.
- Licensing renewal halted
- Retention met without active SAP
- Team fully on DEX
The five questions auditors ask
"But SAP handles that." — so does this stack, explicitly.
Each concern has a concrete answer. Not because DEX is magical — because these are solved problems on the underlying stack.
Data sovereignty
HANA Cloud regions are fixed. On-prem or sovereign-cloud options are paid SKUs negotiated per tenant.
DEX framework and Postgres run wherever you can run a container — your VPC, on-prem, sovereign cloud. Residency becomes an infra choice, not a vendor negotiation.
Audit trails
CDHDR/CDPOS change documents are proprietary, per-table, and gappy for custom Z-tables.
Every DEX JSON descriptor and generated file is versioned in git. Event sourcing — the pattern Greg Young popularised and Martin Fowler catalogued — via Kafka plus an append-only store gives uniform change history across every entity.
SOX compliance
Controls documented against transactions and authorization objects. Custom Z-code can bypass them without leaving an obvious trace.
Controls become code — policy-as-code in OPA, segregation of duties enforced at the API gateway, every DEX deploy captured in git. Auditors get diffs, not Word documents.
Talent & support
Senior ABAP pool is retiring. Rates rise, availability falls, training paths are vendor-tied.
TypeScript, Postgres, Kafka, dbt — the largest talent pools in enterprise software. Commercial support available from multiple vendors per layer.
Vendor lock-in
S/4HANA forced migration, BTP pricing changes, mandatory cloud moves.
DEX-generated code is standard TypeScript in your repo. If DEX Elements disappears, you still have a working application and a Postgres schema. The exit path is the starting point.
What the math looks like
One worked example, line by line.
A composite mid-market profile. Not a promise — the shape of the numbers most deals land near. Your own figures come out of the assessment.
Mid-market manufacturer, 600 named SAP users. Custom estate: 180 Z-programs, 45 Z-tables, 12 major RFC integrations, BW on HANA for reporting. Currently on ECC, S/4HANA program sized at 24 months.
- SAP licenses — 600 users at negotiated rate$1.6M
- BTP, CPI, HANA, other SAP SKUs$450K
- SAP consulting retainer$600K
- In-house ABAP — 3 FTE blended$420K
- DEX platform subscription$180K
- Hosting (Azure VPC, mid-scale)$90K
- In-house TypeScript — 4 FTE (retrained team)$560K
- Dbt + Metabase + Kafka ops$40K
The $2.2M gap is not just a cost line — it is capacity. Roughly fifteen senior engineers' worth of annual build budget, re-deployable onto the software that makes you different from every competitor who is still running the same SAP you just left.
Honest caveats. This profile doesn't include industry-specific SAP content (banking core, highly customized SD pricing, validated life-sciences GxP) — those add complexity and extend timelines. Audit committees sometimes demand extended parallel-run windows for finance, pushing breakeven out by 2–4 months. Organisations without a functioning platform-engineering team typically need to build one before the migration pays off at this velocity.
Honest disclosure
When moving off SAP is the wrong call.
- Your SAP footprint is mostly vanilla. If you run SAP standard with only a handful of Z-programs, the migration cost probably exceeds the licensing you would save. S/4HANA on a tight vanilla scope is often the rational move.
- You have no platform-engineering capability and no appetite to build one. Owning your stack means owning its operations. Without a team that can run Postgres, a CI pipeline, and an observability setup, DEX framework's ownership story becomes a liability, not an asset.
- Regulated industry content you rely on. Banking core, insurance claims, pharma GxP — SAP's certified industry solutions encode decades of regulatory content. If that content is the reason you chose SAP, the case for leaving is weaker.
- M&A-driven consolidation inside an SAP-first group. If the parent mandates SAP, migrating a subsidiary off it is political, not technical.
Further reading
Underlying patterns and customer cases.
- From batch jobs to event-driven architecture — the integration-layer rewrite that comes with this kind of migration
- Vendor lock-in is the real cost of every shortcut — why ownership matters more than sticker price
- Staff augmentation vs. platform-led migration — the economics of platform-led work
- Governed AI in the next decade of enterprise software — the design thesis behind DEX framework
Stop configuring. Start building.
A discovery call isolates the custom layer where your advantage actually lives, names the first module to move, and sketches the 12–24 month path from shared SAP to a codebase only you run. Scoped plan, no commitment.