Typical SAP BTP extension failure patterns
These are recurring structural patterns — boundary and jurisdiction failures — not random bugs. If these sound familiar, the issue is likely no longer an implementation problem.
What these patterns have in common
Local correctness survives; global validity does not. Each pattern reflects a boundary or jurisdiction failure where individual teams can be right, yet the system remains wrong.
Implementation symptoms — intermittent failures, tenant variance, security blocks, rollout friction — are downstream of an unsettled contract across identity, tenant, data, integration, or lifecycle.
Recognize these as decision points. Treat them as triggers for an independent architectural verdict.
Works in Postman, fails in the real entry path
Requests succeed in direct testing but fail behind App Router, Work Zone, or other governed paths. Runtime, identity propagation, or routing assumptions do not match the architecture.
One tenant works, the next exposes the wrong architecture
Rollout reveals the tenant model or ownership truth was never stable. Per‑tenant variation exposes a missing contract at the boundary.
The demo passed, but the rollout model never existed
A proof‑of‑concept behaved correctly, but trust and lifecycle gates for rollout were never designed as a system. Implementation succeeded; governance did not.
Data was copied successfully, but ownership truth was not
Migrations move data but not the authority to change it. Conflicting writes or approvals indicate an unresolved data boundary.
The system is live, but no team can govern change anymore
Production runs and incidents are handled, but architectural changes cannot be legitimately approved. Local correctness exists; global authority does not.
Security hardening reveals the architecture was never governable
Maturing security posture exposes trust or isolation violations. Hardening uncovers invalid boundaries rather than code defects.
Every team is locally correct, but the architecture is globally wrong
Platform, application, security, and vendor narratives each make sense. The cross‑boundary contract is the defect.
Implementation succeeded, lifecycle model did not
Day‑2 change, onboarding, or deprovisioning breaks. The lifecycle boundary was never defined with jurisdiction and exposure in mind.
The architecture keeps pulling your strongest people back
Outages are not required. Changes repeatedly reactivate hidden dependencies and pull the same strongest people back into the old path. Fixes succeed locally, but confidence and capacity do not accumulate; stability is being preserved by expert intervention rather than governable architecture — this is structural, not staffing.
These are not implementation categories. They are verdict triggers. Stabilize the architecture; then continue implementation.
If several patterns coexist, the issue is likely no longer local.