An SAP engine metric is, in principle, a measurement of business activity through a defined SAP system within a defined measurement period. In practice, the system in question is often one the customer thought they had decommissioned — sometimes years ago — but which is still installed, still discoverable by SAP's measurement tools, and still in scope for the audit. The handling of decommissioned and partially-decommissioned systems is one of the consistent failure points in engine-metric audits, and one that produces avoidable claim exposure.
This article walks through what decommissioning actually requires for licensing purposes, the patterns that produce continued exposure on systems the customer believed were retired, and the defence postures available in an audit.
What licensing decommissioning actually requires
From SAP's perspective, a system is decommissioned for licensing purposes only when three conditions are met. The first is that the system is shut down — the executables are no longer running and the database is offline. The second is that the installation is removed from any SAP measurement infrastructure — the system no longer appears in Solution Manager's system landscape directory, the LAW reporting infrastructure does not include it, and the licence administrator confirms its removal. The third is that the customer's contract administration reflects the change — the system has been removed from any system schedule attached to the contract, and any product-specific entitlement tied to that system has been reconciled.
Most customers complete the first step. Many complete the second. Few complete the third. The result is a system that is operationally shut down but contractually still in scope, which is the position that produces audit exposure.
The patterns that produce continued exposure
The first pattern is the partial-decommissioning pattern. The customer shuts down the production instance but leaves a development or QA instance running for documentation or migration-completion purposes. SAP's measurement infrastructure picks up the remaining instance, and the customer is metered against the engine on that instance — even though no business activity is being conducted there.
The second pattern is the read-only retention pattern. The customer wants to keep the legacy system available in read-only mode for compliance, audit, or analytical purposes. From SAP's licensing perspective, a read-only system is still a system; the licence position is not affected by the operational state.
The third pattern is the partially-migrated pattern. The customer has migrated most business activity to a successor system — typically S/4HANA — but a few business processes or interfaces remain on the legacy system. The engine metrics on the legacy system continue to register activity, sometimes substantial activity, even though the customer's view is that the system is in the process of being retired.
The fourth pattern is the contract-administration lag. The system is operationally retired, the technical decommissioning is complete, but the contract schedule has not been updated. A new contract, a renewal, or an amendment passes without removing the retired systems, and the entitlement persists on the contract for months or years after the operational decommissioning.
The audit defence for each pattern
For the partial-decommissioning pattern, the defence is documentary. The customer needs to produce evidence — change records, infrastructure documentation, shutdown logs — that the production activity has ceased and that any remaining instance is non-productive. SAP's standard position is that non-productive instances are not subject to engine metering, but the customer carries the burden of demonstrating the non-productive status.
For the read-only retention pattern, the defence is contractual. The customer needs to negotiate, ideally in advance, a contractual recognition that a read-only retention instance is licensed under a separate, lower-cost model — sometimes a flat archival licence, sometimes a reduced engine metric, sometimes excluded from metering entirely. This is a negotiation that should happen at the planning stage of the migration, not at the audit stage.
For the partially-migrated pattern, the defence is hybrid. The legacy system is still producing engine activity, so the customer's licence position needs to recognise that activity in the entitlement on the legacy system, while progressively shifting the entitlement to the successor system as the migration completes. Customers who run this transition without explicit contractual recognition often pay for both systems through the transition window.
For the contract-administration lag, the defence is purely operational. The customer needs to update the contract schedule to reflect the actual operational state, and any audit measurement of systems no longer on the schedule should be defended on the basis that those systems are not contractually in scope.
The S/4HANA conversion exposure
One specific pattern deserves attention. The S/4HANA conversion frequently leaves behind an ECC instance for parallel running, regression testing, or archival purposes. SAP's audit team has, in recent engagements, treated the retained ECC instance as a fully active system for engine-metric purposes, even where the customer's documented position is that the instance is non-productive. The customer's defence in this scenario rests on the contractual recognition of the conversion arrangement and the operational documentation of the non-productive status.
For more on this specific pattern, see our S/4HANA conversion of engines article and the S/4HANA topic page. For the broader migration framework, see our S/4HANA migration compliance service.
The hidden audit risk in retired BW and CRM systems
Two specific legacy products produce a disproportionate share of decommissioned-system audit findings. The first is BW — the SAP business warehouse — which is metered on a data-volume basis and which customers frequently retain in a read-only mode after migrating analytics to a successor platform. The second is CRM — the SAP CRM module — which is metered on a combination of users and engine activity and which has the highest residency rate among customers who have moved to a non-SAP CRM platform.
Both of these legacy systems are common audit findings, and both are defensible with the right documentation and contract posture. The customers who fare worst are those who assumed the retired product had no audit exposure and did nothing to document the retirement. See our BW engine metric article for more.
What to do now, before an audit
The right time to handle decommissioned systems is before the audit, not after the notification. Three operational steps make the difference. First, conduct an annual reconciliation between the operational system inventory and the contract schedule, with explicit retirement of systems that are no longer in use. Second, negotiate contractual recognition of any retained read-only or archival instance, with a defined licensing position for those instances. Third, maintain documentary evidence of the operational status of every system on the contract — production, non-production, retained, retired — so that the documentation is available when an audit notification arrives.
Customers who maintain this discipline find that the decommissioned-system question rarely produces audit exposure. Customers who do not find that it produces a disproportionate share of the eventual claim. For an applied example, see the manufacturer engine defence case file.