The S/4HANA migration is the moment at which the entire SAP estate is re-baselined for the next contract cycle. Every system inside the perimeter at conversion is priced into the conversion offer. Every system outside the perimeter is not. The asymmetry is the entire economic argument for a disciplined pre-migration discovery exercise. Shadow ERP systems — the satellite SAP instances that grew up around the production system without being formally inventoried — routinely add five to eighteen per cent to a conversion baseline when they are surfaced by SAP’s pre-conversion analysis rather than addressed pre-emptively by the buyer. Pre-emptive discovery, disposal, or formal documentation of these systems is the single largest controllable input to the conversion economics.
What counts as a shadow system
Shadow ERP is a deliberately broad term. It includes test and development systems that became quasi-productive, training systems that never closed, business-unit-specific instances inherited through acquisitions, regional rollouts that were paused mid-deployment, archive systems running ECC for historical reporting, and sandbox environments that grew real master data over time. The common thread is that the system carries an SAP installation number and counts toward the contractual licence footprint, but no current business owner regards it as a strategic asset and no migration plan treats it as in scope.
The licence consequence varies by contract vintage. Older SAP contracts typically licensed by system; the shadow system carries its own user count and engine entitlements. RISE and S/4HANA contracts aggregate across the estate; the shadow system contributes Named Users to the aggregate Full Use Equivalent (FUE) count even when no production work runs through it. In both cases the licence cost is real and continuing, and the conversion offer prices the existing footprint into the new contract unless the footprint changes first.
The three origin stories
The first origin story is the project sandbox that did not close. A 2018 implementation project stood up a test system, the project closed, the system remained, and over five years a small population of users continued to access it for quasi-production reporting work. The system never appeared in the IT asset register, but it appears in SAP’s system-identifier catalogue, and the conversion analysis will surface it.
The second origin story is the inherited system. An acquired company brought an SAP system into the buyer’s portfolio, the integration plan called for migration into the central system within twelve months, the integration slipped, and the acquired system has now been running parallel for three years. The original commercial position assumed the inherited system would close; the actual position keeps it open and licensed.
The third origin story is the archive system. An old ECC system was decommissioned for transactional purposes but kept running for legal-retention reporting. The system runs a handful of users a quarter, but it carries its installation footprint and its engine entitlements, and the conversion analysis treats it identically to a production system unless the licence position has been formally restated.
The detection routine
Detection has three sources. The SAP installation-number catalogue (accessible through the SAP support portal under the customer master data) lists every SAP system the buyer has registered. The internal IT asset register lists every system the IT organisation manages. The network discovery scan lists every system actually reachable on the corporate network. The three lists overlap incompletely. Systems that appear in the installation-number catalogue but not in the IT asset register or the network scan are the prime shadow candidates. Systems that appear in the network scan but not in either of the other two are the rarer but more interesting cases of completely undocumented installations.
What the catalogue reveals
The installation-number catalogue is the authoritative SAP-side record. SAP cannot easily challenge the existence of a system that does not appear in the catalogue, and the catalogue is the source SAP’s conversion team will use to construct the baseline. Pulling the catalogue early in the discovery exercise — before the conversion offer is constructed — gives the buyer the same source data as the SAP team and an equal footing for the baseline conversation. See the license compliance assessment service brief for the catalogue-pull methodology.
The disposal options
Once detected, each shadow system has four disposal options. Decommission entirely, transferring any required historical data to a non-SAP archive. Migrate the workload into the primary system before the conversion and decommission the satellite. Document a formal sunset plan with a defined end date and exclude from the conversion baseline. Convert in scope as a deliberate retained system. The four options have different licence economics; the choice depends on the system’s actual business utility and the cost of the workload migration.
The first three options remove the system from the conversion baseline. The fourth option preserves it. The conversion offer’s sensitivity to which option is chosen is significant, frequently in the high six or low seven figures over the contract term in mid-market estates and an order of magnitude higher in large enterprises. See the RISE conversion economics piece for the dollar mechanics.
The shadow system you disposed of in month minus eighteen of the conversion costs zero. The shadow system SAP discovered in month plus three of the conversion costs the full RISE-FUE equivalent for the contract term. The window between those two states is the entire pre-migration discovery opportunity.
The archive question
Archive systems are the most common shadow category and the most operationally complex to dispose of, because legal-retention obligations attach to the data even when the operational utility has expired. The standard pattern is data extraction to a third-party archive tool (Opentext, IXOS, or equivalent) followed by SAP system decommissioning. The work is non-trivial — six to twelve months of project time in most cases — but the licence benefit recurs for the contract term and is often the largest single line item in a pre-migration optimization plan. The SAP ECC topic page covers the archive options in more depth.
The USMM consequence
Shadow systems contribute to the USMM consolidation through the LAW if they are configured for it, and they contribute outside the consolidation if they are not. Either way, the named users on them feed the contractual baseline. The pre-conversion discovery exercise should include a USMM run on every detected shadow system, with the results consolidated through the LAW for visibility. The LAW consolidation pitfalls piece covers the consolidation mechanics and the common errors.
Where RISE changes the picture
The RISE bundle prices FUE consumption rather than priced Named Users in the classical sense. A shadow system inside the RISE perimeter consumes FUEs at the contracted ratio. The disposal economics are denominated in FUEs rather than Named Users, but the direction is identical. See the SAP RISE topic page and the CPG conversion baseline case file for the FUE pattern in practice.
The standard timeline
Detection takes four to six weeks for the catalogue work and another two to four for the network reconciliation. Disposal of the detected systems — decommissioning, workload migration, archive extraction — takes between three and twelve months depending on the data-retention complexity. The whole exercise should begin at least eighteen months before the planned conversion date. Estates that begin discovery later compress the disposal options — some systems can no longer be decommissioned in time, and the conversion baseline includes them by default.
What the research supports
The S/4HANA conversion economics paper sets out the pre-migration discovery methodology in full, with the cost-benefit comparison across the four disposal options and the timeline template by estate size. The methodology is what we apply at the start of every conversion engagement.
— 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
Pull the SAP installation-number catalogue for the customer master. Pair it with the IT asset register. The gaps between the two are the candidate list for discovery work. The S/4HANA migration compliance service brief covers the full sequence.