SAP BTP Extension Audit
A boundary-based audit for SAP BTP extensions that must remain safe across tenant onboarding, schema evolution, identity hardening, integration change, rollout, and S/4HANA lifecycle events.
When an audit is the right move
- Multiple incidents recur across different layers.
- First tenant or pilot worked, but rollout exposes divergence.
- Data replication, destination configuration, or identity propagation has become hard to govern.
- Teams can fix incidents locally, but cannot prove the extension remains structurally safe.
- The architecture must survive more than the current production state.
Audit scope
Runtime Boundary
Entry paths, AppRouter, Work Zone, CAP, CF/Kyma assumptions.
Identity Boundary
IAS, XSUAA, JWT, scopes, role collections, S/4 trust.
Tenant Boundary
Subaccount/subdomain, tenant isolation, routing, subscription assumptions.
Data Boundary
S/4 truth, HDI extension data, replicated, derived, or shadow truth.
Integration Boundary
Destinations, principal propagation, released APIs, and system contracts.
Lifecycle Boundary
Onboarding, migration, rollback, environment parity, and security hardening.
Output
- Boundary risk matrix.
- P1 structural risks.
- Failure-mode analysis.
- Explicit architectural conclusion.
- Go / No-Go / Re-Architect decision framing.
- Remediation direction without implementation takeover.
Audit vs troubleshooting
Troubleshooting fixes a failing step. An audit determines whether the extension is still structurally safe to evolve.
What to send
A one-page summary is sufficient to assess audit applicability. Use the intake template if that is faster than explaining the situation from scratch.