Know your S/4HANA readiness before you commit a date: AI-assisted ABAP assessment on AWS

This post is about readiness assessment only, the read-only part where you size the job.
Actually draining the backlog at scale is a separate story (that is the Clean Core Remediation
Factory post). It also assumes you already know abapctl  exists. If you don't, start with the
intro article, Bring your SAP development workflows into the agentic era using abapctl ,
then come back here.

The problem: you can't plan what you can't see clearly

• The list is flat. Three thousand findings all look equally urgent in a spreadsheet. Which
  packages are almost clean and which are wall-to-wall blockers? Without that, teams sequence the
  work by gut feeling and burn the calendar on the wrong things first.
• Every finding needs a translation. "Usage of not released ABAP Platform APIs" tells you
  something is wrong, but not whether it is a five-minute swap or a two-day rewrite. Somebody has
  to open each one and figure out what it really means.
• Effort is a guess. Because nobody has sized the findings, the estimate is a finger in the
  air. Eight months? Three? The honest answer is that nobody knows yet, and that is exactly what
  makes the date dangerous.
• The picture goes stale. Even if Anika triages everything by hand this month, developers
  keep committing code, and by next sprint her careful count is out of date.

The capability: an assessment that reads, explains, and ranks

Assessment in action: a real package on a live system

• 6 of the 37 are obsolete Open SQL that ATC ships an automatic quick fix for. These are
  cheap. When it is time to fix them, they are mostly a button press, and they are provably safe.
  For planning, treat them as bulk mechanical work.
• 31 of the 37 are "Usage of not released ABAP Platform APIs" with no quick fix offered.
  There is no canned rewrite. Each one needs somebody to find the sanctioned replacement, check
  that it returns the same data, and rewrite the call. For planning, treat these as the real
  work.

You just watched a package go from "3,412 scary rows" to "here is what is clean, here is what
blocks you, and here is the cheap-versus-expensive split." You can run this same read-only
assessment against a sandbox in the workshop linked below.

Performance at scale

How to run it

1. Prerequisites: the CLI on your automation host, Kiro CLI, an AWS account with Amazon
   Bedrock access, and a DEV or sandbox SAP connection.
2. Connect: point a connection profile at the DEV system's ADT endpoint, and supply the SAP
   password from AWS Secrets Manager at runtime, never from disk.
3. Assess: run assess across a package, or across every package, to get the A/B/C/D
   breakdown and the per-object findings. All read-only.
4. Read the report: the tool writes human-readable reports and per-object findings to disk.
   That is your plan input.

Build it in your landscape

Pattern A: AWS-native (self-managed SAP on AWS)

Pattern B: SAP RISE on AWS

• Network path is customer-owned in A, and a shared design with SAP in B.
• Data egress: even for a read-only assessment, ABAP source travels from the SAP-managed
  landscape to your account for the model to read. That is a governed decision, so document what
  leaves, where it is processed, and the region. On Bedrock, your prompts and completions are not
  used to train the base models and stay in your chosen region. Put that in the sign-off.
• Identity spans SAP-managed access plus your AWS IAM in B.

Which model, and what it costs you

What it costs

• The assessment itself is nearly free. Running assess is just ADT calls to your SAP system,
  a few seconds of compute, no model tokens at all for the raw classification.
• The model cost is only for explaining and sizing. When you ask the agent to explain
  findings and split them into cheap-versus-expensive, a class the size of
  ZCL_SFLIGHT_BOOKING_DAO with its finding list runs on the order of a few thousand input
  tokens and a small output, so pennies per object, dollars for a whole package.
• Non-model costs: the automation host (a small EC2 instance or a laptop) and normal AWS API
  usage.
• The point: getting a defensible, explained, ranked readiness picture costs about the price
  of a coffee in inference. Compare that to the days a team spends hand-triaging the same
  spreadsheet.

Alternatives, and when to choose them

• SAP Readiness Check and the Custom Code Migration app. These are first-party and give you
  the official readiness picture. Use them for the high-level program view and the sanctioned
  numbers. Choose the AWS and Kiro plus Bedrock path when you want the finding-by-finding
  explanations and effort split in plain language, scriptable, in your own account, and repeatable
  from a pipeline. Most teams use both: Readiness Check for the program story, the agent for the
  developer-level detail.
• Reading ATC output by hand. Maximum control, and honestly fine for one small package. It
  stops scaling the moment the finding count runs into the thousands, which is the whole reason
  Anika is stuck.
• Rules-based scanners. Fast at spotting known patterns. They tell you what is wrong but not,
  in plain words, how hard it is to fix or which sanctioned replacement applies. That reasoning is
  where the agent adds value.

Security, data, and responsibility

• Read-only, and non-production. Point the assessment at DEV or sandbox. It only reads, so
  there is no change to promote and nothing to roll back.
• Credentials. SAP passwords come from AWS Secrets Manager at runtime, never on disk, never
  in logs. Use least-privilege IAM for the automation host and a scoped SAP developer user.
• Private connectivity. Reach Bedrock over VPC endpoints. In RISE, reach ADT over the agreed
  private path.
• Data handling. ABAP source is sent to the model to read and explain. On Amazon Bedrock,
  prompts and completions are not used to train the base models and stay in-region. Still,
  classify your source and get data-egress sign-off, especially under RISE.
• Auditability. Every call is a read against your SAP system and shows up in the normal audit
  trail, plus a local log.

SAP authorizations you'll need

Try it yourself

• You'll build: a working read-only assessment against a sample package, and watch a wall of
  findings turn into a ranked, explained, sized plan.
• You'll leave with: a repeatable assessment you can point at your own DEV system and run
  every sprint, or even wire into a pipeline as a readiness check.
• What you need: an AWS account with Amazon Bedrock access and a dev or sandbox SAP
  connection. The workshop walks you through the setup, so no prior agent experience is required.
• RISE customer? The same assessment applies. You connect over your RISE-provided path.

Wrap-up and where to go next

• 📘 New to abapctl itself? Read the intro article, Bring your SAP development workflows into the agentic era using abapctl .
• 🧭 Run the assessment: AI Assisted SAP ABAP workflows using Kiro Agents  (start with Use Case 1: Readiness).
• 🏭 Ready to fix at scale? See the Clean Core Remediation Factory post in the upcoming blog post
• 📚 Background: SAP's Clean Core Extensibility whitepaper (the A to D model) and SAP Readiness
  Check.