SAP's clean-core doctrine says your custom ABAP moves out of the ERP. The only open question is what platform the living apps get rebuilt on. Marcus — Kinetech's AI Mendix developer — reads your Z-code, your data dictionary, and your usage statistics directly, and rebuilds the apps worth keeping as governed Mendix applications: SAP-connected, BTP-deployable, and proven with evidence at every release.
01 · The clock
ECC 6.0 EHP 0–5 has been unsupported since December 31, 2025. EHP 6–8 mainstream maintenance ends December 31, 2027; extended maintenance — at roughly 9% higher fees — runs only to December 31, 2030, and SAP has publicly refused further extension. The much-discussed 2033 option is a RISE-only transition package for select customers, not a general reprieve.
02 · The differentiator
Everything needed to understand a custom ABAP application is machine-readable inside your system — and SAP ships the tools that inventory it. Marcus works from those exports: no discovery workshops asking users to remember what a 2009 Z-transaction does.
| SAP artifact | What Marcus extracts | Where it lands in Mendix |
|---|---|---|
| Z-namespace via abapGit | Plain-text export of custom programs, classes, function modules (some object types skip with warnings — we flag them, not hide them) | Business-logic inventory; microflow candidates |
| DDIC (SE11) | Z-tables, structures, domains, relationships | Domain-model entities and associations |
| Dynpro screens | Screen inventory, field layouts, module-pool wiring | Pages and navigation |
| ABAP reports & module pools | Selection screens, business rules, validations | Microflows, validation rules, filtered views |
| Authorization objects (PFCG/SU24) | Roles, auth checks, who-can-do-what | User roles and entity access rules |
| Custom Code Migration app + ATC | SAP's own per-object inventory with usage data | The kill / keep / rebuild triage that scopes your quote |
Why this matters: remediation vendors make old ABAP S/4-compatible. Assessment tools score it. What has not existed is a developer that reads the inventory and then does the rebuild — outside the core, per clean-core doctrine, with every app tested per role and delivered with published evidence. That's Marcus.
03 · How a migration runs
The first deliverable is a triage, not code: SAP's own usage data typically shows a majority of custom objects never run. You approve what gets rebuilt before anything is built.
The same four approval gates that govern every Marcus engagement govern each rebuilt app — held by you:
The extracted specification of each Z-app — what it does, who uses it, what carries forward — approved by you before a line of the model is written.
The translated security model — authorization objects and roles mapped to Mendix roles and access rules — presented in plain English for sign-off.
Modern, branded design directions presented before pages are generated. Your users finally leave SAPGUI gray behind — you pick what they land on.
Each app reaches you only after all quality gates pass; it goes live only when you accept it, evidence in hand.
04 · The date
Here is the commitment we will put in writing. The assessment does not end with a range — it ends with a date, sized from your actual extracted complexity. Miss that date and the assessment fee comes back. We can promise a date because we never quote a calendar before reading your source.
The assessment names the date. Miss it, and the assessment fee comes back.
That is a real term, not a slide. It is affordable to us for one reason: the clock below starts only when a complete artifact pack is in our hands, and it pauses only for your own approval gates.
| One custom-ring application (a Z-transaction set) | Complete artifact pack → UAT-ready |
|---|---|
| Compact — ≤20 Z-objects, one transaction family, ≤2 BAPI or OData touchpoints | 3–4 weeks |
| Departmental — 20–80 Z-objects, Dynpro or Web Dynpro UI, 3–6 SAP touchpoints | ~45 days typical |
| Load-bearing — 80+ Z-objects, enhancement-point sprawl, Z-tables holding real business state | 10–16 weeks |
| Each further custom-ring app on the same core | 30–40% faster |
Sizing model, not a price list — the assessment reads your actual source and returns one date. Bands assume a single rebuild boundary agreed at the scope gate.
The date is only honest if the inputs are complete, so here is the whole list up front. Nothing on it is unusual, and most of it exists already.
Three approval gates are yours: scope, permission ratification, design sign-off. We answer each within three business days. Time beyond that on your side moves the date by exactly that much — and nothing else does.
Production cutover on your change calendar. SSO and network provisioning by your IT. Third-party licenses or vendor contracts we don't control. Remediation of source-data quality problems the assessment flagged. Anything added after the scope gate.
Functional parity against the approved specification, running on your migrated data in a parallel environment, with production security enforced and tested per role, all nine quality gates green, and documentation published. Your users click through it.
SAP's own clean-core doctrine is what makes this a project rather than an argument: the custom ring is supposed to come out of the core, and this is what taking it out looks like. What moves a date here is not the ABAP — it is the SAP-side integration surface. If the BAPIs and OData services the new app needs are not released yet, the person who can release them is on the critical path, and the assessment names them.
05 · Why Mendix
Rebuilding your custom ring in Mendix is not an anti-SAP move. It is the clean-core doctrine, executed — on a platform with a deeper SAP pedigree than any other low-code option.
06 · Straight talk
| Area | The honest position |
|---|---|
| Your data | Stays in S/4. Rebuilt Mendix apps read and write through OData and BAPI/RFC — the ERP remains the system of record. We are not migrating your general ledger. |
| Heavy batch & core logic | Set-based batch jobs and logic that genuinely belongs in the ERP stay in ABAP — either standard or as clean-core-compliant extensions. Marcus rebuilds applications, not your posting engine. |
| GRC & segregation of duties | For finance-critical apps with deep GRC/SoD requirements, in-stack integration is thicker than what a side-by-side app can offer. We say so in the triage and leave those in the SAP stack. |
| abapGit coverage | Some object types export with warnings rather than cleanly. The extraction report lists exactly what was read and what needs a manual look — flagged, not hidden. |
| The dead ~60% | Unused code gets decommissioned, not migrated. The triage proves which is which with SAP's own usage data — you pay to rebuild what the business runs, nothing else. |
| Your S/4 program | We are not your conversion SI and don't pretend to be. This workstream clears the custom-code barrier alongside your program — it doesn't replace it. |
07 · Quality & security
Watch real build evidence land on the live Build Console, and see the delivery lifecycle at our interactive explainer.
08 · Engagement & pricing
AI-read inventory of your Z-objects with usage data, a kill / keep / rebuild triage, complexity and risk flags — and one representative SAPGUI transaction rebuilt as a working Mendix app against OData, so you judge the approach on your own estate.
Credited toward onboarding if you proceed.
Each app quoted from its actual extracted complexity — not a day-rate guess. Built, tested per role, documented, and delivered through the approval gates with published evidence.
Best for the first wave of blocking Z-apps.
For a custom ring of 20+ living apps: a Marcus instance works your rebuild backlog continuously through your S/4 program. Priced on what the work is, how many lanes run in parallel, and how fast you need it — always with Kinetech engineer review and an escalation SLA.
Bring your own Claude access: roughly 15–25% off the monthly.
Every figure here is an indicative range; your actual range is confirmed in writing before anything is charged. On bundled plans, heavy build months may incur metered usage beyond the included allowance; your quote states the allowance plainly. Your applications, models, and repositories are contractually yours.
09 · The questions you should ask
For simple forms and approvals, SAP Build may genuinely be your answer — and the triage will say so where it's true. For the complex multi-role apps that actually block conversions, compare what each platform gives you for the money: Mendix brings a full domain model, workflow engine, role-based security, and native mobile in one governed application — and still deploys to BTP with principal propagation, so the SAP-stack architecture argument is satisfied either way. BTP capacity gets consumed in both cases; what differs is how much application you get per unit of scarce skills and budget.
Ask them precisely what "handling" means. In most programs it means automated remediation — making old code compatible so the conversion completes — billed at day-rates. That's necessary work, and it leaves every screen looking and behaving as it did in 2009, with the same code going back near the core that clean-core doctrine says should leave. The departmental UX lane is the one SI programs consistently deprioritize; ASUG's 2025 data showing customizations as a 44% barrier suggests how well that's going.
Authorization objects and role assignments are readable from the system; Marcus maps them to Mendix user roles and entity access rules, you ratify the translated model in plain English before build, and per-role tests — including negative tests — prove the enforcement. For apps with deep GRC/SoD integration in finance processes, we're direct: in-stack is thicker, and the triage will recommend those stay in the SAP stack. We'd rather lose those line items than hand-wave your compliance.
In your ERP, where it belongs. Rebuilt apps consume S/4 through OData and BAPI/RFC as governed clients — no shadow database, no second master. Reference data cached for performance is declared in the spec you approve.
Because it isn't a general extension — it's a RISE-only transition package for select customers, inside a subscription commitment. If you qualify and sign, you've bought runway and lock-in together, and the custom-code problem is still waiting at the end of it. The clean-core work has to happen in every scenario; doing it deliberately now, while ECC still runs, beats doing it inside a deadline crunch later.
The rebuilt apps are standard Mendix — visual models with 100% in-model documentation, in your repository. ABAP developers who know the business logic pick up Mendix far faster than a new hire picks up twenty years of Z-code; several of your senior people will likely become the review-and-extend owners. And the original ABAP remains in your system until you retire it — nothing is destroyed.
The extraction report itself tells you — abapGit flags object types it can't export cleanly, and the triage lists what needs human eyes. Beyond that, every rebuilt app is driven end-to-end per role against the spec you approved before acceptance. The failure mode isn't silent loss; it's a flagged item on a list you've seen.
10 · Next step
Pick a custom transaction your users live in, a report with real business rules, and the one everyone's afraid to touch. We'll run the extraction and return the scored specs — kill, keep, or rebuild, with a fixed price for each rebuild — inside two weeks. Judge the approach on your own estate, not on a slide.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · Live Build Console
You are reading Your platform — deeper detail on step 4, Why now?.
That is the pressure. What it costs to answer it is not one number — three things move it.