The S/4HANA migration is a licence event whether the buyer treats it as one or not. The act of converting the contract carries a re-baseline implicit in the conversion mathematics: every user is re-classified under the new metric, every engine is re-measured under the new model, and every interface is re-assessed against the digital-access framework. SAP’s commercial team enters the conversation with a model of what those re-baselined numbers should be. The buyer who enters without one accepts the seller’s model by default. The mock migration audit is the structured exercise that produces the buyer’s model. It is conducted four to six months before cutover, while there is still time to act on the findings, and it treats the migration itself as if it were a formal SAP audit event. The discipline is a regular module in our S/4HANA migration compliance engagements.
Why mock and not real
The migration is not yet a real audit. There is no notification letter, no formal data request, and no commercial position to defend. The advantage is that there is also no opposing counsel, no deadline, and no risk to running findings to ground before they become defended. The mock audit borrows the discipline of the formal audit — the document set, the methodology, the evidence standard — and applies it in calmer conditions. The output is a baseline position the buyer can hold from the first conversation with SAP’s commercial team, supported by evidence that would survive challenge in a real audit.
The scope of the mock
The mock covers four areas: classification under the destination metric, engine consumption under the destination measurement, indirect access from third-party systems, and the FUE conversion mathematics. Each area maps to a real-audit testing pattern and produces a deliverable that doubles as the buyer’s position document.
Classification under FUE
The classification work re-runs the existing user-master population against the FUE-equivalent licence types in the destination contract. For most ECC-to-S/4HANA migrations, the equivalent set is Advanced Use, Core Use, Self-Service, and Developer, with FUE conversion ratios that compress Professional and Limited Professional into a smaller number of metric units. The mock applies the proposed ratios to the validated classification (the output of the transaction-history pull) and produces the projected FUE count. The projection is the buyer’s opening position. SAP’s opening position will typically be derived from the existing Professional count applied to a less favourable ratio. The gap is the negotiation target.
Engine consumption under destination measurement
S/4HANA replaces several ECC engine metrics with successor metrics that measure different things. The HR engine moves from a payroll-employee count to an active-employee count. Document-count engines are sometimes consolidated into broader bundles. The destination engine model must be applied to the actual usage data, not to the ECC entitlement, because the entitlement under ECC may have been over-bought or under-bought against the actual usage. The mock projects the destination engine entitlement against the projected usage at go-live plus three years.
Indirect access at cutover
Every interface that consumed indirectly under ECC will need to be re-pointed and re-licensed under S/4HANA, typically under the digital-access framework with document-counted licence units. The mock catalogues every interface, applies the document-count projection, and identifies the interfaces that will exceed the digital-access entitlement at cutover or within the planning horizon. See the digital-access pillar for the document-count methodology.
FUE conversion mathematics
The FUE ratios in the conversion contract are not always uniform across the user-type set. The mock works through the specific ratios in the proposed contract template and identifies which classifications produce favourable conversions for the buyer and which produce unfavourable ones. The output informs the reclassification work in the preparation phase: classifications that release more FUE per move are higher-priority targets.
The methodology document
The mock produces a methodology document that records the procedural choices made — the validation source for transaction history, the cut-off date, the role-collection version, the engine measurement source. The methodology document is the buyer’s answer to the audit team’s first question: how was the position derived. A position derived without a documented methodology is challengeable on procedural grounds before any of the substantive findings are addressed. A position derived with a documented methodology must be challenged on the merits, which is the productive ground for the buyer side. The methodology document is the most important artefact the mock produces, beyond the projected position itself.
SAP’s audit team will ask, in the first half-hour of the first meeting, how the buyer derived its position. A methodology document delivered at that moment changes the rest of the engagement.
The evidence standard
The evidence used in the mock must survive an audit. That means: transaction-history extracts from production systems (not from training or QA), measured engine outputs from the live USMM (not from estimates), and contract-text quotations from the actual contract document (not from summaries). The discipline feels heavier than the mock context requires. The point of carrying the discipline is that the same evidence can be re-used unchanged in the real conversation with SAP. Mock evidence rebuilt later under deadline pressure is rarely as clean as evidence built once in calm conditions. See the audit-defence pillar for the evidence-handling standard.
The findings register
The mock produces a findings register: a list of specific exposures identified, the quantum of each, the remediation available, and the timeline for remediation before cutover. The register is the action list for the rest of the migration runway. Common entries include over-classified users that can be re-baselined before cutover, dormant accounts that should be deleted before they become FUE-counted, integration accounts that need conversion to System or Communication types, and indirect interfaces that need re-architecture or formal digital-access entitlement.
The register typically runs to between forty and a hundred and twenty findings in a mid-sized estate. The aggregate quantum is consistent with the patterns seen across our 500+ engagements: an opening exposure projection that, when worked through the remediation register, reduces by 60-72% before cutover. The FUE conversion math article covers the calculation detail, and the pharma S/4HANA case file shows the pattern in practice.
The timing of the mock
The mock has to run early enough that findings can be remediated before the commercial conversation begins. In our practice the right window is four to six months before the planned cutover, which is typically six to nine months before the conversion contract is signed. Earlier than that the data is unstable (the migration project changes the system shape); later than that the remediation window has closed and the findings become documentation of exposure rather than levers for negotiation. The S/4HANA topic page covers the broader migration timeline.
The output the negotiation team uses
The mock produces, in addition to the methodology document and the findings register, a one-page position summary that the negotiation team carries into every meeting with SAP’s commercial side. The summary records the buyer’s projected FUE position, the engine entitlement projection, the indirect-access entitlement projection, the supporting methodology references, and the remediation completed against the original findings register. The summary is the buyer’s opening position. It is referenced in every meeting and updated as the negotiation evolves. The S/4HANA migration licence-risks paper covers the position-document structure in detail.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
Where to start
If your migration is six to twelve months from cutover, the mock should be in planning now. The classification and engine-measurement work has long lead times in older landscapes. The indirect-access cataloguing is the longest dependency and should begin first. The S/4HANA migration compliance service brief covers the full mock sequence and the typical effort by estate size.