Consider a hypothetical order-control requirement already approved for an SAP migration. Its existing implementation reads SAP data, applies a validation and blocks an invalid posting. Moving that code into an external application might satisfy an architectural preference while leaving the essential question unanswered: can the proposed design still enforce the control at the required transaction boundary?
A SAP clean-core extension strategy should preserve necessary business behavior through supported mechanisms, not assign every extension to a separate runtime. SAP’s extensibility guidance distinguishes tightly coupled extensions from loosely coupled applications and directs them toward different implementation options. For architects and migration sponsors, the practical deliverable is a disposition record for each capability: what happens to the existing implementation, why that placement fits, and which unresolved dependencies prevent approval.
Separate the retained capability from its existing code
Approval of a business capability is not approval to migrate its current implementation unchanged. The ERP customization approval worksheet establishes the preceding decision: approve the requirement before selecting the implementation, and account for continuing ownership, interfaces, testing and support. Here, assume the requirement has passed that test. The task is to determine how it should work in the target SAP environment.
Start the disposition record with a business description rather than an object list. Name the process owner, the required outcome and the acceptance condition. Then attach the existing technical dependencies: custom objects, modifications, enhancement implementations, data reads and writes, scheduled processing, interfaces and downstream consumers. Ask the technical team to demonstrate how those dependencies contribute to the approved outcome.
Use explicit dispositions for the implementation:
- Retire: remove a redundant implementation while preserving the approved capability elsewhere. If the capability itself is no longer necessary, return that decision to the business owner.
- Replace with standard: demonstrate that target functionality and configuration satisfy the acceptance condition, then remove the bespoke implementation.
- Adapt within the SAP core: identify a supported extension mechanism that fits the required proximity to data, transactions or application behavior.
- Move side-by-side: establish that supported remote access and a separate operational lifecycle fit the requirement.
- Blocked: retain a provisional choice with an accountable owner for the unresolved issue, rather than presenting an architectural preference as an approved design.
Keep technical findings separate from the disposition decision. For any analysis report used in SAP custom-code migration, record its scope, target assumptions and documented limitations. Require the team to explain each finding’s business consequence. A technical finding should inform the decision; it should not substitute for the process owner’s acceptance or prove that a replacement preserves the required behavior.
Make deployment, release and interface support approval conditions
The target product name alone is too imprecise for an extension record. Specify whether the proposed deployment is Public Edition, Private Edition or on-premises, together with its release and relevant components. Then require current, target-specific documentation for the proposed mechanism. Do not carry a mechanism’s approval from another deployment or release into this decision without checking its applicability.
SAP’s ABAP extensibility guidance directs tightly coupled scenarios toward key-user or on-stack developer extensibility. Its examples include jointly changing customer and SAP data with transactional consistency, extending an application’s UI or data model, and implementing an application extension point. This supports considering an on-stack solution. It does not establish that the required extension point exists for your particular application and target.
For an on-stack candidate, ask whether the requirement fits an available key-user mechanism or requires professional developer implementation. Make the team identify the actual extension point and every SAP object the design consumes. If it proposes ABAP Cloud, require evidence of the applicable language restrictions, permitted dependencies and released-object requirements in the target environment. Avoid approving a design merely because its proposal uses the right terminology.
Apply the same discipline to SAP released APIs. Record the exact interface, required operations, permitted consumption model, release status, applicable compatibility contract and documented restrictions. A read interface is not evidence of a supported write operation. Where the design depends on an event, verify the event’s meaning and required follow-up access rather than treating notification as a complete business integration.
Resolve these dependencies alongside the migration timetable. Use the SAP ECC maintenance-runway register to connect target and interface decisions to the wider transition plan. Keep an unresolved API or extension-point dependency visible as a delivery blocker, with a decision owner, rather than hiding it inside a general development estimate.
Let the transaction boundary decide the first placement hypothesis
Placement becomes clearer when the process owner states what must succeed or fail together. SAP identifies side-by-side extensibility on SAP BTP as the default for loosely coupled applications that use replicated data or remote APIs and do not require custom data and core data to change transactionally together. That distinction is more useful than a blanket instruction to move custom code off the core.
Hypothetical: validation before a posting
Suppose a required control must reject an invalid business transaction before posting, using the transaction’s current values. Treat an on-stack implementation as the initial candidate because the requirement calls for close transactional coupling. Approval still depends on finding a supported extension point with the necessary data and execution timing. Neither this scenario nor the general placement guidance confirms that such a point exists.
Ask the team to demonstrate an accepted posting, a rejected posting and the resulting business state. If it proposes a remote validation instead, require a precise account of what happens when the response is delayed or unavailable. The process owner must accept the waiting behavior, failure policy and control coverage across all relevant posting paths. A successful remote call alone is not a sufficient acceptance test.
Hypothetical: external document-review workflow
Now suppose an external team reviews supporting documents after a record is created, and the business accepts a pending state while review continues. Side-by-side placement is a reasonable initial candidate if the review need not commit atomically with the original SAP transaction. Before approval, verify supported access to the record, the required update operation and the allowed communication pattern in the exact target.
Test what happens if review completes after cancellation, an update is rejected, a response is lost or the same completion is submitted again. Require the design to explain duplicate handling, reconciliation and authorized recovery. If the requirement changes so that review must prevent the original posting, reopen placement. The transaction requirement has changed, not merely the integration detail.
Complete the disposition matrix with operating evidence
An architecture diagram is not enough to assign ongoing responsibility. SAP’s extensibility selection guidance distinguishes lifecycle management integrated with the core for ABAP custom development and key-user extensions from the separate lifecycle management of side-by-side extensions. It attributes side-by-side lifecycle stability to stable APIs and events, not simply to separation from the core.
Translate that distinction into accountable work. Ask who releases the extension, who checks compatibility with the SAP target and who accepts the complete business workflow after either side changes. Do not approve an assumed reduction in upgrade work or cost simply because the implementation moves elsewhere.
| Record field | Required evidence or decision |
|---|---|
| Capability and business owner | Approved outcome, acceptance condition and owner authorized to accept changed behavior. |
| Current dependencies | Technical inventory linked to actual process paths, data access and downstream consumers. |
| Target and disposition | Deployment, release, relevant components and retire, replace, adapt, move or blocked decision. |
| Supported mechanisms | Target-specific documentation for extension points, APIs, events, release contracts and restrictions. |
| Transaction and latency | What must commit together, permitted waiting behavior, data freshness and measured acceptance results. |
| Failure and authorization | Identity model, business permissions, rejected operations, duplicate handling and recovery authority. |
| Monitoring and lifecycle | Exception detection, reconciliation owner, deployment responsibility, upgrade tests and remediation owner. |
| Prerequisites and blockers | Runtime, connectivity, entitlement and commercial checks; unresolved issues with accountable decision owners. |
For authorization, require tests of both allowed and denied actions, including background execution where relevant. For monitoring, ask the team to show how an operator distinguishes successful message transfer from successful business completion. Identify who reconciles a mismatch and who can authorize corrective action.
For a side-by-side proposal, confirm the selected runtime and services, their prerequisites, operating ownership and applicable entitlements before authorizing implementation. Keep those checks attached to the disposition record. A technically plausible placement should remain provisional until the organization can support and operate it.
Approve migration work only when the blockers are explicit
Turn each approved disposition into a migration work package: remove obsolete dependencies, configure the replacement, adapt the supported extension or build and connect the external application. Include data treatment, authorization changes, exception procedures and business acceptance in that package. Do not close it solely because code compiles or an interface returns a successful response.
Record what would change the recommendation. A demonstrated standard capability may eliminate bespoke work; a missing supported write operation may block side-by-side placement; an atomicity requirement may favor an on-stack candidate; and an unowned recovery process should prevent operational approval. Keep the reason for the decision inspectable so a changed assumption triggers review.
Before approving the next extension work package, complete its disposition record with the process owner and technical maintainer, then resolve the blocker most likely to change placement. If you need help evaluating SAP custom-code migration work or implementing the selected approach, discuss your requirements with Digiventi’s SAP functional and technical specialists.
