abap-cloud-migration · diff
git:20260417.b473266 to git:20260916.c1b7d5e
194 added, 53 removed. Audit A to A.
---
name: abap-cloud-migration
- description: Help with migrating classic ABAP custom code to ABAP Cloud including custom code adaptation, identifying unreleased API replacements, generating wrapper classes for unreleased objects, ATC Cloud Readiness checks, handling incompatible language constructs, and step-by-step migration workflows. Use when users ask about migrating to ABAP Cloud, custom code migration, cloud readiness, unreleased API replacement, wrapper pattern, ATC cloud checks, code adaptation, classic to cloud migration, S/4HANA cloud migration, or clean core compliance. Triggers include "migrate to ABAP Cloud", "cloud readiness check", "unreleased API", "replace with released API", "custom code adaptation", "wrapper for unreleased", "ATC cloud", "clean core migration", "move to tier 1", or "ABAP Cloud compatibility".
+ description: Help with migrating classic ABAP custom code toward higher clean core levels (Level A/B/C/D) including custom code adaptation, identifying released and classic API replacements, generating wrapper classes for non-released objects, ATC clean core and Cloud Readiness checks, changelog for SAP objects, handling incompatible language constructs, and step-by-step remediation workflows. Use when users ask about migrating to ABAP Cloud, custom code migration, cloud readiness, clean core level remediation, eliminating Level D, reducing Level C, non-released API replacement, wrapper pattern, ATC clean core checks, code adaptation, classic to cloud migration, or clean core compliance. Triggers include "migrate to ABAP Cloud", "cloud readiness check", "clean core level", "eliminate Level D", "reduce Level C", "non-released API", "replace with released API", "custom code adaptation", "wrapper for non-released", "ATC clean core", "clean core migration", "changelog for SAP objects", or "ABAP Cloud compatibility".
---
- # ABAP Cloud Migration Patterns
+ # ABAP Cloud Migration & Clean Core Level Remediation
- Guide for systematically migrating classic ABAP custom code to ABAP Cloud (Tier 1) compliance.
+ Guide for systematically raising the **clean core level** of classic ABAP custom code — eliminating Level D, minimizing Level C, and moving toward Level A (ABAP Cloud).
+ > **Terminology note**: the former 3-tier extensibility model is superseded by the clean core **level concept** (A, B, C, D). Migration is no longer "get everything to Tier 1" — it is "eliminate Level D, minimize Level C, accept stable Level B, target Level A for new work". See the `abap-cloud` skill for the level definitions.
+
## Workflow
- 1. **Assess current state**: Run ATC Cloud Readiness checks on existing code
- 2. **Categorize findings**: Group by finding type (unreleased API, language construct, etc.)
- 3. **Plan migration**: Prioritize by impact and determine replacement strategy
- 4. **Implement replacements**: Apply released API replacements or create wrappers
- 5. **Validate**: Re-run ATC checks and test functionality
+ 1. **Assess current state**: run ATC clean core checks on existing code
+ 2. **Classify findings by level**: priority 1 → Level D, priority 2 → Level C, priority 3 → Level B
+ 3. **Prioritize remediation**: Level D first (must fix), then Level C (minimize), then Level B (monitor)
+ 4. **Choose a transformation option**: retire · renovate side-by-side · renovate on-stack · adapt
+ 5. **Implement replacements**: released APIs, classic APIs, or wrappers with a single ATC exemption
+ 6. **Validate**: re-run ATC checks, verify no priority 1/2 findings remain, test functionality
## Migration Assessment
- ### Running ATC Cloud Readiness Checks
+ ### Running ATC clean core checks
- 1. In ADT: Right-click package → **Run As** → **ABAP Test Cockpit**
- 2. Use check variant `ABAP_CLOUD_READINESS` or a custom variant with cloud-relevant checks
- 3. Review findings in the ATC Results view
+ 1. In ADT: right-click package → **Run As** → **ABAP Test Cockpit**
+ 2. Use check variant `ABAP_CLEAN_CORE_DEVELOPMENT` (SAP-delivered) or build a variant from `ABAP_CLOUD_DEVELOPMENT_DEFAULT` including:
+ - `SYCM_USAGE_OF_APIS` — released/classic API classification, SQL on SAP tables, SAP form routines
+ - `SYCM_ALLOWED_ENH_TECHNOLOGY` — enhancement technology compliance
+ - `CI_SEARCH_CUST_MODIFICATIONS` — modifications
+ - `CI_CRITICAL_STATEMENTS` — critical statements
+ - `SLIN_SEC` — Code Vulnerability Analyzer (additionally recommended)
+ 3. Use `ABAP_CLOUD_READINESS` to verify ABAP Cloud rules before switching an object's language version
+ 4. Review findings in the ATC Results view
- ### Key ATC Check Messages
+ > If `SYCM_USAGE_OF_APIS` or `SYCM_ALLOWED_ENH_TECHNOLOGY` are unavailable, implement **SAP Note 3565942**.
- | Message ID | Description | Action |
- | ---------- | ------------------------------------- | --------------------------------- |
- | `NROB` | Use of unreleased number range API | Use `CL_NUMBERRANGE_RUNTIME` |
- | `BAPI` | Direct BAPI call | Use released RAP API or wrapper |
- | `DYNP` | Dynpro/screen usage | Replace with Fiori/UI5 |
- | `FUGR` | Unreleased function module call | Find released replacement or wrap |
- | `CLAS` | Unreleased class usage | Find released replacement or wrap |
- | `TABL` | Direct DB table access (not released) | Use released CDS view entity |
- | `LANG` | Incompatible language construct | Refactor to use modern ABAP |
+ ### ATC findings mapped to clean core levels
+ | ATC priority | Level | Finding | Action |
+ | ------------------------ | ----- | -------------------------------------------------------------------------------- | -------------------------------------------------- |
+ | **Priority 1 (Error)** | **D** | Object is modified | Remove modification; use a BAdI instead |
+ | | | Enhancement technology is not allowed | Delete enhancement; use a BAdI |
+ | | | Implicit or explicit enhancement (source code plug-in) | Delete enhancement; use a BAdI |
+ | | | Direct **write** access to SAP database tables | Use released or classic APIs |
+ | | | Call of form routines in SAP program | Use released or classic APIs |
+ | | | Usage of SAP object classified as `noAPI` | Use released or classic APIs; check successor info |
+ | | | Usage of critical ABAP statements | Use released or classic APIs |
+ | **Priority 2 (Warning)** | **C** | Direct **read** access to SAP database table/view | Use released CDS view or classic API |
+ | | | Usage of SAP object not classified as classic API (internal) and not released | Use released or classic APIs |
+ | **Priority 3 (Info)** | **B** | Usage of deprecated APIs | Use the successor |
+ | | | Usage of classic APIs | — acceptable, no action required |
+
+ Configure ATC transport settings so **priority 1 and 2 findings block transport release**.
+
+ ### Remediation priority
+
+ 1. **Level D — eliminate entirely**
+ - No modifications → use BAdIs
+ - No implicit or explicit enhancements → use BAdIs
+ - No direct write access to SAP DB tables → released or classic APIs
+ - No not-recommended (`noAPI`) APIs → released or classic APIs
+ - Remove critical ABAP statements → released or classic APIs
+ - Do not call form routines within SAP programs → released or classic APIs
+
+ 2. **Level C — minimize as much as possible**
+ - No direct read access to SAP tables → released or classic CDS views
+ - Replace SAP internal APIs with released or classic APIs
+ - If internal APIs are still needed, explore the **changelog for SAP objects** for incompatible changes
+ - Wrap remaining internal objects and create a single fine-grained ATC exemption
+
+ 3. **Level B — monitor**
+ - Adopt successors for deprecated API findings
+ - Monitor when SAP releases an equivalent API, then migrate to Level A
+ - Do not rewrite stable classic code without a business reason
+
+ 4. **Level A — sustain**
+ - Enforce with `S_ABPLNGVS` authorization and separate software components
+
+ ## Transformation Options for Legacy Code
+
+ | Option | When to apply | Typical tasks |
+ | ------------------------------------ | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+ | **Retire unused code** | ~60% of custom code in a typical ERP is not used productively | Collect usage data with `SUSG`/`SCMON` · analyze in Custom Code Migration app · remove/backup unused code · use the clone finder |
+ | **Renovate & innovate side-by-side** | Loosely coupled extensions better served on SAP Business AI Platform | Analyze dependencies in Custom Code Migration app · transfer code to BTP · adapt via ATC quick fixes |
+ | **Renovate & innovate on-stack** | Tightly coupled extensions/modifications worth reimplementing in ABAP Cloud | Analyze complexity for TCO drivers · make code ABAP Cloud compliant · replace non-released objects with released APIs · use only released extension points |
+ | **Adapt** | None of the above is feasible — minimum viable action | Adapt via readiness ATC checks, Simplification Database, ADT quick fixes (up to ~60% automation) · SQL Monitor · CDS/AMDP pushdown |
+
+ > Recommendation: leave behind as much legacy code as possible **during** the conversion — cleaning up afterwards costs significantly more.
+
+ ## Changelog for SAP Objects (Level C risk mitigation)
+
+ Custom code using internal SAP objects is not upgrade-stable by definition. Internal objects can change during an upgrade, a feature pack import, or even an SAP Note import.
+
+ Incompatible changes include:
+ - Deletion of objects (e.g., function modules)
+ - Renaming or deletion of function module parameters
+ - Incompatible changes to parameter types
+ - Renaming or deletion of methods in SAP classes
+ - Removal of fields from CDS views
+
+ Covered object types: `FUNC`, `CLAS`, `INTF`, `STOB`, `BDEF`.
+
+ **How to use it:**
+ 1. Download the Simplification Database file from the SAP Software Download Center (SAP Support Portal)
+ 2. Import it via transaction `SYCM`
+ 3. Run the changelog ATC check during development, or before the system upgrade like other simplification item checks
+ 4. Refactor affected usages toward released or classic APIs
+
+ Objects in the changelog are **not** automatically demoted to Level D — continued usage may be allowed depending on the change's scope and criticality.
+
## Common API Replacements
### Database Access
| Classic Pattern | ABAP Cloud Replacement |
| ------------------------- | ----------------------------- |
| `SELECT FROM mara` | `SELECT FROM i_product` |
| `SELECT FROM bkpf / bseg` | `SELECT FROM i_journalentry` |
| `SELECT FROM vbak / vbap` | `SELECT FROM i_salesorder` |
| `SELECT FROM ekko / ekpo` | `SELECT FROM i_purchaseorder` |
| `SELECT FROM kna1` | `SELECT FROM i_customer` |
| `SELECT FROM lfa1` | `SELECT FROM i_supplier` |
| `SELECT FROM t001` | `SELECT FROM i_companycode` |
| Direct table access | Use `I_*` released CDS views |
### Function Modules → Released Classes
| Classic FM | Released Replacement |
| --------------------------------------- | ---------------------------------------------------- |
| `GUID_CREATE` | `cl_system_uuid=>create_uuid_x16_static( )` |
| `CONVERSION_EXIT_ALPHA_INPUT` | `cl_abap_format=>alpha_input( )` |
| `CONVERSION_EXIT_ALPHA_OUTPUT` | `cl_abap_format=>alpha_output( )` |
| `POPUP_TO_CONFIRM` | Not available — use Fiori UI |
| `NUMBER_GET_NEXT` | `cl_numberrange_runtime=>number_get( )` |
| `BAPI_TRANSACTION_COMMIT` | Handled by RAP framework (no explicit commit) |
| `SO_NEW_DOCUMENT_ATT_SEND_API1` | `cl_bcs_mail_message` (send emails) |
| `READ_TEXT` / `SAVE_TEXT` | Not released — wrap or use custom persistence |
| `JOB_OPEN` / `JOB_CLOSE` / `JOB_SUBMIT` | `cl_apj_rt_api` (Application Jobs) |
| `ENQUEUE_*` / `DEQUEUE_*` | RAP draft / managed locking or `CL_ABAP_LOCK_OBJECT` |
### Language Constructs
| Incompatible Construct | Cloud-Compatible Alternative |
| ---------------------------------------- | ---------------------------------------------- |
| `CALL TRANSACTION` | Not available — use API or RAP |
| `SUBMIT ... AND RETURN` | Not available — use Application Jobs |
| `WRITE` / `SKIP` / `ULINE` (list output) | Not available — use Fiori UI for output |
| `CALL SCREEN` / `CALL SELECTION-SCREEN` | Not available — use Fiori/UI5 |
| `MESSAGE ... RAISING` | `RAISE EXCEPTION TYPE ...` |
| `CALL FUNCTION ... IN UPDATE TASK` | RAP saver class / managed save |
| `EXEC SQL` (Native SQL) | ABAP SQL or AMDP |
| `GENERATE SUBROUTINE POOL` | Not available — use strategy/factory pattern |
| `DESCRIBE FIELD ... TYPE` | RTTI: `cl_abap_typedescr=>describe_by_data( )` |
| `GET/SET PARAMETER ID` | Not available — use method parameters |
## Wrapper Pattern
- When no released API exists, create a wrapper class in Tier 2 (classic ABAP) and release it for Tier 1 consumption.
+ When no released API exists, create a wrapper class in a **classic ABAP** software component and release it for **ABAP Cloud (Level A)** consumption.
- ### Step 1: Create Wrapper Interface (Tier 2, released for Cloud)
+ **Wrapper level classification:**
+ - Wrapping a **classic API** (Level B object) → the wrapper is **Level B**
+ - Wrapping an **internal object** (Level C object) → the wrapper is **Level C**
+ - Wrapping a **not-recommended (`noAPI`) object** → **Level D**, do not build it
+ Wrapping also collapses N ATC findings into 1, so a single fine-grained exemption covers the usage. This is SAP's recommended practice for working with internal SAP objects.
+
+ ### Step 1: Create Wrapper Interface (classic ABAP, released for Cloud)
+
```abap
"Released for use in ABAP Cloud (C1 contract)
INTERFACE zif_text_handler
PUBLIC.
METHODS read_text
IMPORTING iv_id TYPE thead-tdid
iv_name TYPE thead-tdname
iv_object TYPE thead-tdobject
iv_language TYPE sy-langu DEFAULT sy-langu
RETURNING VALUE(rt_text) TYPE tline_tab
RAISING zcx_text_error.
METHODS save_text
IMPORTING iv_id TYPE thead-tdid
iv_name TYPE thead-tdname
iv_object TYPE thead-tdobject
iv_language TYPE sy-langu DEFAULT sy-langu
it_text TYPE tline_tab
RAISING zcx_text_error.
ENDINTERFACE.
```
- ### Step 2: Create Wrapper Class (Tier 2, released for Cloud)
+ ### Step 2: Create Wrapper Class (classic ABAP, released for Cloud)
```abap
- "Implementation uses unreleased FMs internally
+ "Implementation uses non-released FMs internally
"Released for use in ABAP Cloud (C1 contract)
CLASS zcl_text_handler DEFINITION
PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_text_handler.
ENDCLASS.
CLASS zcl_text_handler IMPLEMENTATION.
METHOD zif_text_handler~read_text.
- "Uses unreleased FM internally — OK in Tier 2
+ "Uses non-released FM internally — acceptable inside the wrapper
CALL FUNCTION 'READ_TEXT'
EXPORTING
id = iv_id
name = iv_name
object = iv_object
language = iv_language
TABLES
lines = rt_text
EXCEPTIONS
OTHERS = 1.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE zcx_text_error.
ENDIF.
ENDMETHOD.
METHOD zif_text_handler~save_text.
DATA ls_header TYPE thead.
ls_header-tdid = iv_id.
ls_header-tdname = iv_name.
ls_header-tdobject = iv_object.
ls_header-tdspras = iv_language.
CALL FUNCTION 'SAVE_TEXT'
EXPORTING header = ls_header
TABLES lines = it_text
EXCEPTIONS OTHERS = 1.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE zcx_text_error.
ENDIF.
ENDMETHOD.
ENDCLASS.
```
### Step 3: Release the Wrapper
In ADT, open the wrapper class properties:
1. Go to **API State** tab
2. Add **Use System-Internally (C1)** contract
3. Set visibility to **Use in ABAP Cloud**
- ### Step 4: Use in Tier 1 Code
+ ### Step 4: Use in ABAP Cloud (Level A) Code
```abap
- "Tier 1 (ABAP Cloud) code — uses released wrapper
+ "ABAP Cloud code — uses released wrapper
DATA(lo_text) = NEW zcl_text_handler( ).
DATA(lt_text) = lo_text->zif_text_handler~read_text(
iv_id = 'ST'
iv_name = lv_doc_name
iv_object = 'VBBK' ).
```
+ ### Step 5: Handle authorizations and exemptions
+
+ - Classic APIs often check **non-released authorization objects**, which cannot be used in ABAP Cloud. PFCG roles may mix released and non-released authorization objects.
+ - Provide `SU22` data for the wrapper when releasing it, and create `SU22` variants for each designated usage so roles can be maintained.
+ - Create a **single fine-grained ATC exemption** on the wrapper's internal usage rather than one per call site.
+ - **Retire the wrapper** once SAP releases the API — replace it and move the code to the ABAP Cloud software component.
+
+ ### Wrapper guidance by object type
+
+ - **CDS views**: create a custom CDS view on top of the non-released SAP CDS view and release it. Association targets and value help views may also need wrappers. If no SAP CDS view exists at all, wrap the database table.
+ - **Classes / interfaces**: wrap the non-released FM or class. Do **not** copy non-released data types (data elements, structures, table types) used in the signature — wrap them via `TYPES` declarations in the wrapper's public section, so only the wrapper needs releasing.
+
## Migration Strategy by Object Type
### Reports / Programs
```
Classic Report → Application Job class + CDS view + Fiori app
1. Extract data logic → CDS view entities
2. Extract business logic → ABAP Cloud class
3. Create Application Job catalog entry (CL_APJ_DT_CREATE_CONTENT)
4. Schedule via Fiori app "Application Jobs"
```
### Dynpro Transactions
```
Dynpro Transaction → RAP BO + Fiori Elements app
1. Identify CRUD operations → RAP behavior definition
2. Map screen fields → CDS view entity
3. Create service definition/binding
4. Generate Fiori Elements app
```
### BAPIs
```
BAPI → RAP BO with custom actions
1. Map BAPI parameters → CDS abstract entities
2. Implement as RAP actions or factory actions
3. Expose via OData service binding
```
### RFC Function Modules
```
RFC FM → Released API class or RAP service
- 1. If simple logic → Released ABAP class
- 2. If CRUD → RAP BO with service binding
- 3. If complex → Wrapper class (Tier 2)
+ 1. If simple logic → Released ABAP class (Level A)
+ 2. If CRUD → RAP BO with service binding (Level A)
+ 3. If complex → Wrapper class in classic ABAP (Level B or C)
```
- ## Finding Released Replacements
+ ## Finding Released and Classic Replacements
### In ADT
1. **Released Object Search**: `Ctrl+Shift+A` → Filter by "Released" APIs
2. **API State Filter**: In Project Explorer, filter by C1 release state
- 3. **ABAP Element Info**: Hover over unreleased object → see suggestion if available
+ 3. **ABAP Element Info**: Hover over a non-released object → see successor suggestion if available
### Using the Released Objects App
Fiori app **Released Objects** (`F5865`):
- Search by classic object name
- Filter by release state (C1, C2)
- View successor information
+ ### Using the Cloudification Repository
+
+ Determine an object's clean core level and successor:
+
+ - **Classic APIs (Level B)**: `objectClassifications_SAP.json` — viewer at https://sap.github.io/abap-atc-cr-cv-s4hc/?version=objectClassifications_SAP.json
+ - **Not recommended (Level D)**: filter the viewer for `state` = `noAPI`
+ - **Internal with successor (Level C)**: flagged `internalAPI`
+ - Anything unclassified and not released defaults to **Level C**
+
### Programmatic Check
```abap
- "Check if an object is released for ABAP Cloud
+ "Check if an object is released for ABAP Cloud (Level A)
SELECT SINGLE *
FROM i_apistateofrepositoryobject
WHERE ObjectType = 'CLAS'
AND ObjectName = 'CL_NUMBERRANGE_RUNTIME'
AND ReleaseState = 'RELEASED'
INTO @DATA(ls_state).
```
- ## Step-by-Step Migration Checklist
+ ## Step-by-Step Remediation Checklist
- 1. [ ] Run ATC Cloud Readiness check on the package/objects
- 2. [ ] Export findings and categorize by type
- 3. [ ] For each unreleased API usage:
- - [ ] Search for released replacement (CDS view `I_ApiStateOfRepositoryObject`)
- - [ ] If found: replace directly
- - [ ] If not found: create Tier 2 wrapper
- 4. [ ] For each incompatible language construct:
- - [ ] Refactor to cloud-compatible alternative
- 5. [ ] For Dynpro/ALV/list-based UIs:
- - [ ] Plan Fiori replacement (separate project)
- 6. [ ] Move migrated objects to ABAP Cloud language version package
- 7. [ ] Re-run ATC checks — all findings must be resolved
- 8. [ ] Execute regression tests
+ 1. [ ] Run ATC clean core checks (`ABAP_CLEAN_CORE_DEVELOPMENT`) on the package/objects
+ 2. [ ] Export findings and group by ATC priority → clean core level (P1=D, P2=C, P3=B)
+ 3. [ ] **Eliminate all Level D findings** (priority 1):
+ - [ ] Remove modifications → use released or classic BAdIs
+ - [ ] Remove implicit/explicit enhancements → use BAdIs
+ - [ ] Remove direct write access to SAP tables → released or classic APIs
+ - [ ] Replace `noAPI` object usage → check successor information
+ - [ ] Remove critical ABAP statements
+ - [ ] Remove calls to SAP form routines
+ 4. [ ] **Minimize Level C findings** (priority 2):
+ - [ ] Replace direct read access to SAP tables → released or classic CDS views
+ - [ ] Replace SAP internal APIs → released or classic APIs
+ - [ ] For unavoidable internal usage: wrap + single ATC exemption
+ - [ ] Import the changelog for SAP objects via `SYCM` and check for incompatible changes
+ 5. [ ] **Review Level B findings** (priority 3):
+ - [ ] Adopt successors for deprecated APIs
+ - [ ] Leave stable classic API usage as-is
+ 6. [ ] For each non-released API without a replacement:
+ - [ ] Create a wrapper in the classic ABAP component and release it for ABAP Cloud
+ - [ ] Provide `SU22` data and variants for the wrapper
+ 7. [ ] For each incompatible language construct: refactor to a cloud-compatible alternative
+ 8. [ ] For Dynpro/ALV/list-based UIs: plan the Fiori replacement (separate project)
+ 9. [ ] Move migrated objects to the ABAP for Cloud Development software component
+ 10. [ ] Run `ABAP_CLOUD_READINESS` before switching an object's language version
+ 11. [ ] Re-run ATC checks — no priority 1 or 2 findings should remain
+ 12. [ ] Configure ATC transport settings to block release on priority 1 and 2 findings
+ 13. [ ] Execute regression tests
## Output Format
When helping with migration topics, structure responses as:
```markdown
## Migration Guidance
### Current Code Analysis
- - Unreleased APIs found: [list]
+ - Current clean core level: [A / B / C / D] (lowest level used)
+ - Level D findings (must fix): [list]
+ - Level C findings (minimize): [list]
+ - Level B findings (monitor): [list]
- Incompatible constructs: [list]
- Estimated effort: [low / medium / high]
- ### Replacement Strategy
+ ### Remediation Strategy
- [For each finding: original → replacement with code]
+ [Ordered by level: D first, then C, then B]
+ [For each finding: original → replacement with code, target level]
### Wrapper Requirements
- [Objects needing Tier 2 wrappers]
+ [Objects needing wrappers, with the resulting wrapper level (B or C)]
+
+ ### Target State
+
+ - Achievable clean core level: [A / B]
+ - Residual exemptions required: [list with justification]
```
## References
+ - Clean Core Extensibility Whitepaper — the authoritative source for the level concept
+ - Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions (Version 2.3, August 2025)
- Custom Code Migration Guide: https://help.sap.com/docs/abap-cloud/abap-development-tools-user-guide/custom-code-migration
- ABAP Cloud API Release Info: https://help.sap.com/docs/abap-cloud/abap-rap/released-abap-objects
+ - Cloudification Repository: https://github.com/SAP/abap-atc-cr-cv-s4hc
- Wrapper Pattern: https://github.com/SAP-samples/abap-cheat-sheets/blob/main/19_ABAP_Cloud.md
- ATC Cloud Readiness: https://help.sap.com/docs/abap-cloud/abap-development-tools-user-guide/checking-abap-cloud-readiness
+ - SAP Note 3565942 — clean core ATC checks
+ - SAP Note 3578329 — classic technology classification
+
+ ## Detailed Reference
+
+ - **Remediation checklist**: Read `references/migration-checklist.md` for the full level-based remediation checklist, effort estimation, and rollback planning
+
+ ## Related Skills
+
+ - **abap-cloud**: Use for clean core level definitions, development models, and wrapper classification
+ - **atc-cloudification**: Use for configuring ATC clean core checks and level governance
+ - **released-abap-classes**: Use for finding Level A released API replacements
+ - **badi-enhancement**: Use for replacing modifications and enhancements with BAdIs
+ - **abap-sql-amdp**: Use for modernizing ABAP SQL and AMDP during migration