The Clean Core Remediation Factory: draining a portfolio-scale ABAP backlog on AWS
How SAP programs turn thousands of cloud-readiness findings across dozens of packages into a governed, parallelized remediation line, with an exemption workflow, an executive roll-up, and a CI gate that stops new debt, using Claude Opus 4.8 on Amazon Bedrock.
Series: AI Assisted SAP ABAP workflows using Kiro Agents (3 articles)
- 2The Clean Core Remediation Factory: draining a portfolio-scale ABAP backlog on AWS This article
Your program dashboard says 47 custom packages. Somebody exports the ABAP Test Cockpit (ATC)
cloud-readiness findings and the number lands in the steering committee deck: just over nine
thousand. The room goes quiet. Fixing one package beautifully in a proof-of-concept last month
was impressive. Forty-six more like it, under a go-live date, is a different kind of problem.
cloud-readiness findings and the number lands in the steering committee deck: just over nine
thousand. The room goes quiet. Fixing one package beautifully in a proof-of-concept last month
was impressive. Forty-six more like it, under a go-live date, is a different kind of problem.
Fixing one object well is a craft question, and it is solved (that is the readiness assessment
post , where a single object gets read, classified, and its findings explained). Draining a whole
portfolio is a different beast. It is a throughput question, a governance question, and a
reporting question all at once, and those are the ones that actually sink Clean Core programs.
post , where a single object gets read, classified, and its findings explained). Draining a whole
portfolio is a different beast. It is a throughput question, a governance question, and a
reporting question all at once, and those are the ones that actually sink Clean Core programs.
This post is about that second beast. Not "how do I fix one object" but "how do I run remediation
like a factory": lots of objects moving at once, a paper trail an auditor will accept for the
findings that have no fix, a roll-up an executive can actually read, and a gate that stops new
problems from arriving while you drain the old ones. The engine is agentic AI on AWS, Anthropic
Claude Opus 4.8 on Amazon Bedrock, driven by Kiro CLI. There is a hands-on workshop at the end.
like a factory": lots of objects moving at once, a paper trail an auditor will accept for the
findings that have no fix, a roll-up an executive can actually read, and a gate that stops new
problems from arriving while you drain the old ones. The engine is agentic AI on AWS, Anthropic
Claude Opus 4.8 on Amazon Bedrock, driven by Kiro CLI. There is a hands-on workshop at the end.
This post assumes you already know abapctl exists (if not, start with the intro article,
Bring your SAP development workflows into the agentic era using abapctl ),
and that you have already assessed your code (see the readiness post for how one object gets classified and its findings explained). Here we are not re-teaching the single-object loop. We are scaling it into a governed production line.
The problem: a portfolio doesn't fail one object at a time
Meet Rajiv, a remediation program lead running the S/4HANA readiness track for a company with a
decade of custom ABAP across dozens of packages. His pain is not finding defects. ATC already did
that, and an assessment pass already sorted every object into SAP's A/B/C/D Clean Core levels. His
pain is the shape of the work once you try to do it at scale:
decade of custom ABAP across dozens of packages. His pain is not finding defects. ATC already did
that, and an assessment pass already sorted every object into SAP's A/B/C/D Clean Core levels. His
pain is the shape of the work once you try to do it at scale:
- He can't sequence it. Nine thousand findings is a flat list. Which packages are almost clean
and which are wall-to-wall blockers? Without an order, teams pick by gut and burn the runway on the wrong packages first. - He can't just add people. Ten contractors produce ten dialects, ten different replacement
choices, and one giant review bottleneck. Throughput does not grow with headcount. It flattens
out at whoever is doing the reviews. - Some findings have no fix, and no home. A chunk of every backlog is "not-released API, no
quick fix, and no good replacement yet." Today those live in a spreadsheet tab calledwont_fixthat no auditor will ever sign off on. - The bucket has a hole in it. While the team bails water, other developers keep committing
code against the same deprecated patterns, so the backlog refills behind them.
That is four separate problems: sequencing, throughput, governing the un-fixable, and inflow.
None of them is about the quality of a single diff. They are all about running the line.
None of them is about the quality of a single diff. They are all about running the line.
The capability: remediation as a governed production line
The factory has four stations. All of them are either read-only or transport-gated, and all of
them are built on the same assess, fix, review primitive from the single-object post, just scaled
out.
them are built on the same assess, fix, review primitive from the single-object post, just scaled
out.
Station 1: the portfolio roll-up (sequencing). The assess step runs ATC's cloud-readiness
variant across every custom package and sorts each object into its Clean Core level. Because it is
read-only and fast, you run it across the whole estate and get a heat map: package D-density,
ranked high to low. Rajiv finally has an order. Hit the dense-D packages first, leave the clean
ones alone, and re-run every sprint to watch the total D count fall. This is the same assessment
from the readiness post, just pointed at 47 packages instead of one, and rolled up for a
committee.
variant across every custom package and sorts each object into its Clean Core level. Because it is
read-only and fast, you run it across the whole estate and get a heat map: package D-density,
ranked high to low. Rajiv finally has an order. Hit the dense-D packages first, leave the clean
ones alone, and re-run every sprint to watch the total D count fall. This is the same assessment
from the readiness post, just pointed at 47 packages instead of one, and rolled up for a
committee.
Station 2: parallel remediator agents (throughput). This is what makes it a factory. Instead
of one agent walking a package one object at a time, a pool of remediator agents each take a
single object in a sealed context and run the full fix loop at the same time. Each one grounds its
fix in SAP's released-API catalog, makes the smallest change that resolves the finding, and gates
it (syntax, ATC re-check, and unit tests, with no level regression) under a transport before it
sticks. The sealed context per object is the trick that makes running them in parallel safe. No
agent can smear state across objects, so every diff is independently reviewable and independently
reversible.
of one agent walking a package one object at a time, a pool of remediator agents each take a
single object in a sealed context and run the full fix loop at the same time. Each one grounds its
fix in SAP's released-API catalog, makes the smallest change that resolves the finding, and gates
it (syntax, ATC re-check, and unit tests, with no level regression) under a transport before it
sticks. The sealed context per object is the trick that makes running them in parallel safe. No
agent can smear state across objects, so every diff is independently reviewable and independently
reversible.
Station 3: the exemption workflow (governing the un-fixable). Some findings genuinely have no
code fix: a not-released API with no successor yet, a modification that has to stay, a pattern SAP
hasn't cloudified. The agent does not fake a fix, and it does not dump these in a spreadsheet. It
turns each one into an exemption request with the evidence already attached (the finding, the
replacement search that came up empty, and the reason) and routes it to an approver who can grant a scoped, expiring ATC exemption. The un-fixable findings become documented and auditable instead of quietly ignored.
code fix: a not-released API with no successor yet, a modification that has to stay, a pattern SAP
hasn't cloudified. The agent does not fake a fix, and it does not dump these in a spreadsheet. It
turns each one into an exemption request with the evidence already attached (the finding, the
replacement search that came up empty, and the reason) and routes it to an approver who can grant a scoped, expiring ATC exemption. The un-fixable findings become documented and auditable instead of quietly ignored.
Station 4: the CI pre-merge gate (stopping inflow). Because assess is read-only and repeatable,
it drops into the pipeline as a pre-merge check. A commit that would add a new Level D finding
fails the build before it merges. The hole in the bucket is plugged, and the backlog can only
shrink.
it drops into the pipeline as a pre-merge check. A commit that would add a new Level D finding
fails the build before it merges. The hole in the bucket is plugged, and the backlog can only
shrink.
The factory in action: one line item on the portfolio
Everything below came from pointing the line at a live S/4HANA development system (SID
client 100) with the
Take the package
S4H,
client 100) with the
ABAP_CLOUD_READINESS variant. Read-only and preview-only, nothing written.
Take the package
ZSFLIGHT as one line item on Rajiv's portfolio of 47.Station 1 output. One read-only assess sorted all 143 objects into
top of the "do first" list. That one line is what a steering committee can act on, and multiplied
across 47 packages it becomes the program's running order.
A: 26, B: 0, C: 1,
D: 116. In the executive roll-up, ZSFLIGHT lands in the red band at 81% D and sorts near the
top of the "do first" list. That one line is what a steering committee can act on, and multiplied
across 47 packages it becomes the program's running order.
Stations 2 and 3, at the object level. A single Level D object here,
need real work (the readiness post walks through exactly how that split is read). For the factory,
the interesting thing is not the one object, it is the arithmetic. That 6-versus-31 shape,
multiplied across 116 D objects and then across 47 packages, is the program plan:
ZCL_SFLIGHT_BOOKING_DAO, carries 37 findings that split roughly 6 cheap auto-fixable to 31 that
need real work (the readiness post walks through exactly how that split is read). For the factory,
the interesting thing is not the one object, it is the arithmetic. That 6-versus-31 shape,
multiplied across 116 D objects and then across 47 packages, is the program plan:
- The cheap, auto-fixable findings are what the remediator pool clears in bulk at Station 2,
each one gated, many in flight at once. - The real-work findings that have a sanctioned replacement also go through Station 2, one
grounded rewrite at a time. - The ones where the replacement search comes up empty become exemption requests at Station 3, routed to an approver with the evidence attached, not buried.
So the readiness split you already measured per object becomes, at portfolio scale, the mix of
bulk auto-fix, grounded AI rewrite, and exemption committee work that Rajiv has to staff and
sequence. That is the number the whole program plans against.
bulk auto-fix, grounded AI rewrite, and exemption committee work that Rajiv has to staff and
sequence. That is the number the whole program plans against.
You just watched one package's finding mix turn into a staffing and sequencing plan. You can
drive the same portfolio line against a sandbox in the workshop linked below.
Performance at scale
Real figures from the same live dev system (read-only and preview-only). Test setup: SID
client 100, package
S4H,
client 100, package
ZSFLIGHT (143 objects), single automation host.| Metric | Value | Source |
|---|---|---|
| Portfolio assess (per package) | 143 objects classified in about 15 seconds (~10 objects/sec) | measured |
| Re-run cost | read-only and repeatable, safe every sprint and in CI | measured |
Finding mix (sample ZCL_SFLIGHT_BOOKING_DAO) | 6 auto-fix vs 31 replacement-or-exemption of 37 | measured |
| Remediator concurrency | objects fixed in parallel, sealed context each (typically 3, capped at 4) | design |
| Portfolio throughput | roughly per-object model latency divided by concurrency, summed over the D backlog | model |
The assess station is fast enough to treat as a continuous portfolio signal, a nightly heat-map
refresh rather than a quarterly milestone. Fix-station throughput is the dial you actually tune.
With concurrency N, the elapsed time for a package is roughly (D objects times per-object time)
divided by N. Raising N trades inference spend for wall-clock time, which is exactly the lever a
deadline-bound program wants.
refresh rather than a quarterly milestone. Fix-station throughput is the dial you actually tune.
With concurrency N, the elapsed time for a package is roughly (D objects times per-object time)
divided by N. Raising N trades inference spend for wall-clock time, which is exactly the lever a
deadline-bound program wants.
How to run it
- Prerequisites: the abapctl on an automation host, Kiro CLI, an AWS account with Amazon Bedrock access, and a DEV or sandbox SAP connection.
- Baseline the portfolio: run assess across every custom package (read-only) to get the
A/B/C/D executive roll-up ranked by D-density. - Run the line: launch the remediator pool over the top packages. Each object previews with
--dry-run, commits under a transport you name, and is gated before it sticks. Un-fixable
findings queue as exemption requests. - Close the door: wire assess into CI as a pre-merge gate so new Level D findings fail the
build.
Clean Core Factory Architecture
Build it in your landscape
In both shapes, Kiro CLI and the abapctl run on an automation host (an EC2 instance or CI runner for
batch throughput), models are called through Amazon Bedrock, and all SAP traffic is HTTPS to the
ADT REST endpoints of a DEV or sandbox system. Never production.
Pattern A: AWS-native (self-managed SAP on AWS). You own the VPC and the SAP system. The
automation host reaches the DEV ADT endpoint directly, pulls the SAP password from AWS Secrets
Manager at runtime, and reaches Bedrock over a VPC endpoint (PrivateLink) so model traffic stays
private and in-region. Scale the remediator pool by sizing the host or fanning out across CI
runners.
automation host reaches the DEV ADT endpoint directly, pulls the SAP password from AWS Secrets
Manager at runtime, and reaches Bedrock over a VPC endpoint (PrivateLink) so model traffic stays
private and in-region. Scale the remediator pool by sizing the host or fanning out across CI
runners.
Pattern B: SAP RISE on AWS. SAP operates the landscape in its own account. You run the
automation host in your account and reach the DEV ADT endpoint over the RISE-provided connectivity path (no direct DB or OS access, since the factory only needs the ADT REST surface). Bedrock inference stays in your account. What differs: the network path is a shared design with SAP, data-egress governance matters more at portfolio scale (thousands of objects of ABAP source cross into your account for the model to read, so document what leaves and where it is processed), and identity spans SAP-managed access plus your AWS IAM.
automation host in your account and reach the DEV ADT endpoint over the RISE-provided connectivity path (no direct DB or OS access, since the factory only needs the ADT REST surface). Bedrock inference stays in your account. What differs: the network path is a shared design with SAP, data-egress governance matters more at portfolio scale (thousands of objects of ABAP source cross into your account for the model to read, so document what leaves and where it is processed), and identity spans SAP-managed access plus your AWS IAM.
Which model, and what it costs
The model. The reasoning runs on Claude Opus 4.8 on Amazon Bedrock via Kiro CLI. At portfolio
scale its value is the lowest deferral rate. Every finding it clears on its own is one fewer item
in the reviewer and exemption queues, and those queues are the real bottleneck.
scale its value is the lowest deferral rate. Every finding it clears on its own is one fewer item
in the reviewer and exemption queues, and those queues are the real bottleneck.
| Model on Bedrock | Relative cost/token | Deferral rate | When to pick at scale |
|---|---|---|---|
| Claude Opus 4.8 (standard) | $$$ | Lowest | Deadline-bound programs: most autonomous throughput, smallest review queue |
| Claude Sonnet-class | $$ | Higher | Large backlogs where inference spend dominates and you can absorb more reviews |
| Amazon Nova or Haiku-class | $ | Highest | Bulk, mechanical-heavy packages: cheapest per token, most human deferral |
Because the gate checks every change no matter which model made it, a cheaper model never ships
wrong code. It just defers more. At portfolio scale that makes the model choice a
cost-versus-throughput dial. Cheaper models cost less per token but grow the human queue that
gates your calendar.
wrong code. It just defers more. At portfolio scale that makes the model choice a
cost-versus-throughput dial. Cheaper models cost less per token but grow the human queue that
gates your calendar.
What it costs. Illustrative. Confirm on the
Amazon Bedrock pricing page and the AWS Pricing Calculator .
Unlike a single-object post, the number that matters here is per-object times backlog size. Budget
on the order of tens of cents to a couple of dollars per object at the premium tier. A 116-object
D package is low-tens to low-hundreds of dollars of one-time inference, and a 9,000-finding,
roughly 47-package portfolio still lands in the low thousands of dollars. That is a rounding error
against the hundreds of developer-weeks it reallocates. Assess itself is near-free ADT calls, so
running it continuously across the estate costs essentially nothing.
Amazon Bedrock pricing page and the AWS Pricing Calculator .
Unlike a single-object post, the number that matters here is per-object times backlog size. Budget
on the order of tens of cents to a couple of dollars per object at the premium tier. A 116-object
D package is low-tens to low-hundreds of dollars of one-time inference, and a 9,000-finding,
roughly 47-package portfolio still lands in the low thousands of dollars. That is a rounding error
against the hundreds of developer-weeks it reallocates. Assess itself is near-free ADT calls, so
running it continuously across the estate costs essentially nothing.
Alternatives, and when to choose them
- SAP's native tooling: ATC plus the Custom Code Migration app, and the S/4HANA Custom Code Migration Agent (Joule for Developers, ABAP AI). First-party and integrated. Choose the AWS and Kiro plus Bedrock path when you want an open, scriptable line that runs in your own account, lets you pick the model and the concurrency, and wires the exemption workflow and CI gate into your governance. Plenty of programs use both: SAP for planning and checking, the factory for the labor.
- Rules-based converters. Fast on high-volume mechanical patterns. Prefer the factory when the
backlog needs replacement reasoning, drift judgment, and an auditable exemption path for the
findings rules engines simply skip. - Throw contractors at it. Still the right call for a small, gnarly backlog. It stops scaling
the moment findings run into the thousands and the reviewer becomes the constraint.
Security & SAP authorizations
Point the line at DEV or sandbox only, and promote through your normal transport and QA path. SAP
passwords come from AWS Secrets Manager at runtime, never on disk or in logs. Reach Bedrock over
VPC endpoints. Every mutation is transport-scoped and recorded in the SAP audit trail and a local
log. The gate plus automatic rollback are the safety net, so keep them mandatory.
At factory scale the authorization surface grows past single-object remediation in two ways:
transport volume (the pool creates and releases many transports) and exemption authority (someone has to be allowed to grant ATC exemptions).
transport volume (the pool creates and releases many transports) and exemption authority (someone has to be allowed to grant ATC exemptions).
| Action in the line | SAP authorization (typical) | Tier |
|---|---|---|
| Reach ADT REST and run ATC checks | active /sap/bc/adt ICF services, ATC execution auth | read |
| Read source, metadata, business data | S_DEVELOP (ACTVT 03), S_SERVICE | read |
| Write and activate objects (parallel fixes) | S_DEVELOP (ACTVT 01/02, activate) | mutating |
| Create and release many transports | S_TRANSPRT | mutating |
| Grant and manage ATC exemptions | ATC exemption maintenance authorization | mutating (governance) |
Start with a read-only user across the whole portfolio. The roll-up alone is worth it, with zero
write risk. Add the mutating and exemption authorizations only for the fix and governance
stations, scoped to the packages in flight.
write risk. Add the mutating and exemption authorizations only for the fix and governance
stations, scoped to the packages in flight.
Try it yourself
You have seen the line: a portfolio roll-up that ranks the estate, parallel remediators that clear
the mechanical majority, an exemption workflow that makes the un-fixable auditable, and a CI gate
that stops new debt. Now run it end to end in a sandbox:
the mechanical majority, an exemption workflow that makes the un-fixable auditable, and a CI gate
that stops new debt. Now run it end to end in a sandbox:
AI Assisted SAP ABAP workflows using Kiro Agents , start with Use Case 2: Clean Core Remediation Factory.
- You'll build: a parallel assess, fix, review line against sample packages, an exemption route
for no-fix findings, and a pre-merge readiness gate. - You need: an AWS account with Amazon Bedrock access and a dev or sandbox SAP connection. The workshop walks you through setup.
- New here? Start with the readiness assessment post first, then come back to scale it. RISE
customer? The same line applies. You connect over your RISE-provided path.
Wrap-up
A portfolio does not stall because you can't fix an object. You can. It stalls because nobody
sequenced the estate, throughput flattened out at the reviewer, the un-fixable findings had no
audit trail, and new debt kept arriving. Run remediation as a governed factory on AWS, with
parallel agents on Claude Opus 4.8, a portfolio roll-up, an exemption workflow, and a CI gate, and
the backlog goes from a headcount crisis to a supervised production line that only ever shrinks.
sequenced the estate, throughput flattened out at the reviewer, the un-fixable findings had no
audit trail, and new debt kept arriving. Run remediation as a governed factory on AWS, with
parallel agents on Claude Opus 4.8, a portfolio roll-up, an exemption workflow, and a CI gate, and
the backlog goes from a headcount crisis to a supervised production line that only ever shrinks.
Series: AI Assisted SAP ABAP workflows using Kiro Agents (3 articles)
- 2The Clean Core Remediation Factory: draining a portfolio-scale ABAP backlog on AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article