Migrating a legacy application to RAP

What to prepare

• The vertical business slice to migrate: display, change, or action. One small use case is better than the whole application.
• Data sources, keys, status fields, and write paths so query logic and behavior are not mixed.
• Target assumptions for the RAP layer, such as read-only projection, managed behavior, unmanaged save, or initially only an encapsulated service class.

Recommended workflow

1. Provide contextProvide core logic, data access, and existing types. For the first step, a vertical slice is better than the whole application because it keeps the architecture decision reviewable.
2. Describe the task preciselyAsk for a migration outline plus one concrete first code change. The target structure should separate query logic, business rules, persistence behavior, and tests even if full RAP artifacts are not created yet.
3. Review the changeCheck that the proposed structure uses SAP and RAP terminology correctly and does not force a premature full rewrite. Look for places where legacy transactions do not map directly to RAP behavior.

Example prompt

The prompt should plan modernization while still producing one reviewable first step.

Analyze the legacy report ZREP_APPROVAL_MONITOR as a candidate for a later RAP application.
Suggest a target structure with service class, query logic, and test strategy.
As a first step, create only the encapsulated read logic and matching unit tests.

Review checklist

• Are query logic, business rules, and persistence behavior separated enough to build RAP artifacts on top later?
• Are implicit LUW, commit, or locking assumptions from the legacy code made visible?
• Is the first code step small enough to accept safely before making a modeling decision?