Situation

A SAP BTP extension copied or derived data from S/4HANA to support local processing, reporting, or workflow speed. Early implementation benefited from autonomy and apparent simplicity. The copied data became useful enough that more behaviors began to rely on it.

Surface symptom

The extension still functioned, but change became dangerous. Teams could no longer answer cleanly which system held authoritative truth after corrections, backfills, schema changes, or reconciliation events. Lifecycle evolution slowed because every change risked invalidating locally accumulated meaning.

Why internal handling did not converge

The data copy had always worked technically, so teams treated later tension as process debt or data-quality cleanup. Some argued for more synchronization. Others proposed operational controls. The discussion did not converge because replication success had become the wrong measure. The core issue was ownership truth and reconstructibility, not copy mechanics.

What the issue actually was

This was a data and lifecycle boundary failure. The extension had created shadow truth that could not be cleanly governed across future change. Replication had moved information, but not authority. As a result, lifecycle evolution froze around a data model that no longer had a trustworthy source of truth.

What an independent verdict would need to clarify

• Which system owns truth for each business object under change, not just under read access.
• Whether the copied model remains reconstructible after corrections and version change.
• Which data behaviors must move back toward released-system authority.
• What must be decided before the extension accumulates more shadow obligations.

Why this case matters

Some data boundary failures are invisible until the organization tries to evolve the extension. If the architecture cannot explain how truth survives change, the issue is no longer just replication design. It is whether the extension can remain compatible with clean-core and lifecycle reality.