Situation

A SAP BTP extension went live in limited form: one tenant, one entry surface, one set of identity and routing assumptions. Dashboards were green and the first context created confidence to proceed. What remained unproven was tenant truth at rollout scale — not code execution in the initial context.

Surface symptom

The next tenant exposed divergence. Subdomain‑based routing and destination resolution shifted; identity propagation differed across contexts; isolation and role assumptions no longer held; operating controls required different paths. One tenant had been proven; the architecture had not.

Why internal handling did not converge

Teams treated it as tenant‑specific drift. Near‑term motion copied roles, tweaked destinations, added path‑based rules, and created exceptions until the new tenant “matched” the first. This felt reasonable and sometimes worked — until a third context surfaced similar divergence. The second tenant had not introduced a new defect; it revealed that the original contract had never been valid beyond the first case. Local fixes restored motion, not architectural truth.

What the issue actually was

This was not mere tenant variance. It was a boundary failure across tenant model assumptions, identity/routing behavior, and lifecycle validity. The first tenant served as accidental proof in a favorable context; the architecture had not been validated for the operating model now required. In Boundary Model terms, the system passed a local runtime check and failed tenant and lifecycle truth.

What an independent verdict would need to clarify

Do not start by patching the second tenant. First decide whether the original architecture was ever legitimately fit for rollout.

• Whether the original tenant model was structurally valid or merely locally successful
• Which routing, identity, or isolation assumptions must be revised
• What must change before further onboarding continues
• Whether rollout should pause until the architecture becomes governable

Why this case matters

Some of the most expensive SAP BTP failures appear only after the first tenant. The second tenant proves the first never validated the architecture. Early success must not be mistaken for structural validity; pausing to decide this prevents expensive rollout rework.