Retiring Old SAP Components During S/4HANA Migration

Retiring Old SAP Components During S/4HANA Migration

Migrating to SAP S/4HANA isn’t just a technical overhaul—it’s a chance to retire old SAP components and eliminate costly shelfware in your software portfolio.

CIOs and CTOs can leverage the move to S/4HANA to optimize unused licenses, reduce ongoing maintenance fees, and negotiate a leaner, more efficient SAP contract that aligns with current business needs.

The Hidden Cost of SAP Shelfware

SAP shelfware refers to software licenses and modules you’ve paid for but aren’t actively using. These idle user licenses and add-on modules quietly consume budget through annual maintenance fees (typically ~20–22% of the license price every year).

Over time, organizations accumulate shelfware due to over-purchasing, changes in project scope, or mergers.

It’s common to find double-digit percentages of SAP users who haven’t logged in for months, or entire SAP components that have been purchased but never deployed.

For example, if a company owns $10 million in SAP licenses, even a 15–20% shelfware ratio means that $1.5–2 million of that investment brings no value, yet the company might still be paying $300–400,000 per year in support fees on it.

This is effectively wasted IT spend that could be redirected elsewhere.

Common shelfware areas include:

• Unused SAP Modules: Engines or extensions (e.g., legacy SAP CRM, SRM, PLM) that were bought in a bundle or for a project that stalled. If you adopted a different CRM or never fully implemented that SAP module, you’re paying maintenance for a capability you don’t use.
• Dormant Named Users: Employees who left or changed roles but still have assigned SAP user licenses. These inactive accounts are included in your license totals. It’s not unusual to discover hundreds of named-user licenses tied up in former staff or duplicate accounts across systems.
• Redundant Legacy Systems: Older SAP components or industry solutions that have been superseded by newer tools (either within S/4HANA or third-party solutions) but remain on contract “just in case.” Keeping these on the books means ongoing support costs for outdated functionality.

All of this shelfware represents real dollars on the table. Beyond direct costs, it also adds complexity, making compliance management more challenging and obscuring visibility into what your organization truly needs. Recognizing the scope of shelfware in your SAP estate is the first step to cutting it.

Read Budgeting for SAP S/4HANA License Transition Without Surprises.

S/4HANA Migration – A Chance to Clean House

The impending migration to SAP S/4HANA (with SAP’s ECC support ending in 2027) forces a rethink of your SAP licensing. This transition isn’t an automatic carry-over of your old licenses.

Moving to S/4HANA often means signing a new contract or license model, presenting a golden opportunity to clean house. Instead of a like-for-like renewal, you can restructure your SAP agreement from the ground up – shedding what you don’t need and optimizing for the future.

SAP’s programs encourage this. When migrating, you typically have two paths: stick with a product conversion (mapping old licenses to equivalent S/4HANA products) or go for a contract conversion (essentially tearing up the old contract and starting anew for S/4HANA).

In either case, don’t blindly “convert” everything. Use the migration as a strategic reset:

• Drop Unneeded Components: Identify legacy SAP products that won’t be needed in the S/4HANA era. For example, S/4HANA’s core may include functionality that used to require separate engines in ECC. If you have an older module (like SAP Business Warehouse Accelerator or an industry solution) that is obsolete or replaced by S/4 innovations, consider retiring that component instead of carrying it forward. This prevents the need to pay for licenses that S/4HANA renders redundant.
• Eliminate Idle Users: Similarly, right-size your user counts. Before migration, many firms run a usage audit and find, for example, that 500 out of 3,000 named users are effectively idle or have minimal activity. Rather than converting all 3,000 into S/4HANA user licenses, decommission the dormant 500. This ensures you only license active personnel in the new system, immediately reducing cost.
• Consolidate and Simplify: S/4HANA migration often coincides with business process changes. Take advantage of this to streamline applications. If you’re consolidating systems (for instance, retiring a separate SAP CRM instance in favor of S/4HANA’s customer management functionality), you can also consolidate licenses and drop overlapping ones.

In short, treat the migration as a contractual do-over. CIOs can align the new S/4HANA environment closely with actual business requirements, free of historical bloat.

SAP itself may offer incentives for early adopters (such as credits or extended maintenance on ECC during the transition). Still, those benefits are maximized if you’re coming to the table with a clear, pared-down vision of what you need going forward.

Retiring Old SAP Components During the Transition

Retiring old SAP components requires a combination of usage data analysis and input from internal stakeholders.

Start with a thorough license utilization assessment well before you sign any S/4HANA deal:

• Inventory All Licenses and Modules: List out every SAP product and user license your organization owns. This includes core ERP modules and additional components (such as SAP HCM, CRM, industry solutions, and third-party add-ons sold by SAP), along with the number and type of user licenses.
• Assess Business Relevance: For each component, ask, “Are we using this? Do we still need it in the S/4HANA era?” It’s common to find modules that were purchased for a project that never went live, or functionality that a business unit abandoned. For example, if you purchased SAP Supplier Relationship Management (SRM) years ago but later transitioned procurement to a cloud solution like Ariba or Coupa. SRM is a prime candidate for retirement.
• Engage Functional Owners: Talk to the business and IT owners of each SAP module. Confirm whether processes supported by that module will continue in S/4HANA. Many legacy components (like SAP APO for advanced planning or classic SAP HR on ECC) might be replaced by new S/4HANA modules or by third-party systems. If a module isn’t part of the future-state architecture, plan to sunset it.
• Analyze Usage Logs: Use SAP’s License Administration Workbench (LAW) or other tools to see actual usage. Identify unused licenses (e.g., named users who show zero activity, or engine metrics that are well below licensed levels). This data-driven approach highlights which user licenses and engine rights can be safely removed.

By doing this homework, you’ll compile a list of shelfware components to retire. Some will be straightforward (unused modules with no activity).

Others might require decisions (e.g., perhaps a module has low usage in ECC, and you must decide whether to carry it over to S/4 or drop it if the functionality will be handled differently).

The key is not to let obsolete software roll into your new environment. Every retired component is one less item to pay for and manage.

License Conversion Strategies and Shelfware Impacts

How you execute the migration contractually will also determine the fate of shelfware. SAP’s two conversion approaches offer different levels of flexibility in eliminating unused licenses:

• Product Conversion (Phased Approach): In a product conversion, you keep your existing SAP contract and simply swap certain products for their S/4HANA equivalents. This is a gradual, one-for-one exchange. The upside: you maintain all your original contract terms and discounts, and you can migrate in phases (with dual-use rights to run ECC and S/4HANA in parallel during the transition). However, product conversion is inherently limited to “converting what you have”. Shelfware remains an issue if it isn’t actively converted. Unused licenses that you choose not to convert will just sit on the contract unless you take separate action to terminate them. And because product conversion doesn’t allow you to fundamentally reconfigure your license mix, any modules you don’t convert may simply expire in value (you continue to pay maintenance, while shelfware remains unutilized). In short, product conversion is safe and conservative, but offers little relief for pre-existing shelfware beyond what you proactively remove on your own.
• Contract Conversion (Recontracting & Credit): Contract conversion is a wholesale license overhaul – you negotiate an entirely new S/4HANA agreement and trade in your existing licenses for credit. SAP calculates a credit based on the current net value of the licenses you surrender (often related to their original cost or current maintenance base). The big advantage here is flexibility: you can apply the value of any legacy license to any new S/4HANA product. This means you can monetize shelfware. For example, suppose you had a $500,000 SAP CRM engine on ECC that you never fully utilized due to contract conversion. In that case, you might use the $500,000 value as credit toward something you actually need (such as S/4HANA Advanced Analytics or additional ERP user licenses) instead of keeping an idle CRM license. It’s often referred to as a “milkshake” approach—blending the old and new license values into one pool. Contract conversion, therefore, directly enables turning shelfware into useful assets. The caveat: SAP will scrutinize your shelfware when granting credit. If certain licenses are not deployed, SAP may assign them a lower credit value (or sometimes zero). They may require that some portion of the new contract spend be incremental (e.g., you must increase annual maintenance by a minimum percentage). Negotiation is critical here to maximize credit for your past investments. In any case, contract conversion lets you drop what you don’t need and only include licenses that make sense for S/4HANA – effectively a “reset” of your license portfolio.

Whether you pursue product or contract conversion, plan your shelfware strategy upfront. If you have significant shelfware, contract conversion typically provides a better mechanism to address it (by trading it in or reallocating value).

Product conversion, on the other hand, might be chosen if you have minimal shelfware and want a simpler, low-risk migration of licenses.

Some enterprises even use a hybrid approach: performing a selective product conversion first (to maintain continuity on critical systems) and later doing a contract conversion for the remainder to clean up and optimize the portfolio.

The path you choose should align with your technical migration plan and risk tolerance, but always keep the end goal in mind: don’t carry waste into the new environment.

Quantifying the Benefits of Eliminating Shelfware

Retiring unused SAP components isn’t just housekeeping—it can yield substantial cost savings and value. Freeing up budget from shelfware can help fund your S/4HANA project or other innovation.

Consider a real-world style example:

Example: A company’s audit finds 20% of its SAP licenses are unused. That’s $2.6 million in shelfware value, costing over $0.5 million annually in support. By eliminating these unused licenses during the S/4HANA migration, the company can negotiate to apply the $2.6M value as a credit toward new S/4HANA licenses.

Ongoing support fees drop commensurately, avoiding over half a million dollars in yearly spend on shelfware. In effect, the organization frees up budget and ensures every dollar in the new S/4HANA contract is tied to active, needed functionality.

Even if your situation isn’t this dramatic, the savings from shelfware add up: terminating a single unused SAP engine module that costs $ 100,000 in maintenance per year is an immediate $ 100,000 back to the bottom line. Likewise, reducing your named user count by 500 could easily save six figures in annual support.

These savings can be redirected to critical project areas such as S/4HANA implementation services, training, or innovation initiatives – things that deliver real business value.

Additionally, an optimized license footprint reduces compliance risk, as you have fewer unnecessary licenses to track and fewer chances of misunderstandings during audits or true-ups. Ultimately, eliminating shelfware makes your SAP investment more efficient and transparent.

Avoiding Pitfalls When Retiring Software

While the benefits are clear, CIOs should approach shelfware reduction strategically to avoid common pitfalls:

• Don’t Cut Blindly: Before terminating a license or module, double-check with business owners that the functionality isn’t needed. An idle module today might have a planned use tomorrow. Coordinate shelfware retirement with your overall IT roadmap to ensure you don’t accidentally remove something that a business unit expects to leverage.
• Understand Termination Clauses: Review your SAP contracts for how and when you can terminate licenses. Typically, you can drop licenses to stop maintenance on them, but often only at specific times (e.g., contract anniversary or renewal). Some contracts may require notice periods. Plan these moves to align with your migration timeline and avoid penalties.
• Balance Credit vs. Maintenance Savings: If you’re doing a contract conversion, decide whether to include shelfware in the conversion for credit or terminate it beforehand. There’s a trade-off: terminating saves you maintenance dollars immediately. It removes unused items from consideration (which can strengthen your negotiation stance), but if you terminate too much, you reduce the pool of credit for new licenses. Assess which unused licenses SAP is likely to credit generously versus those they won’t value. In some cases, it may be better to drop licenses that SAP considers low-value before negotiating and focus on obtaining credit for the remaining licenses.
• Avoid Creating New Shelfware: It’s easy to over-provision in a migration. Companies sometimes overbuy S/4HANA licenses “just in case” or convert all existing users 1:1 into the new model even if many won’t be active. This simply creates a new generation of shelfware. To prevent this, right-size your S/4HANA contract: only purchase what you need based on current and projected usage. You can usually add more licenses later if needed, preferably under pre-negotiated pricing. Starting lean ensures you don’t pay for unused capacity.
• Watch for Indirect Use Changes: S/4HANA introduces new licensing metrics, such as Digital Access (for documents) or FUEs (Full User Equivalents), in cloud subscriptions. Be careful that, in pursuing shelfware removal, you don’t overlook indirect usage licenses that you still need in the new model. For example, if you drop a module because a third-party system will replace it, consider if that third-party will integrate with SAP. If so, ensure you have the right indirect access licenses (or document licenses) in S/4HANA to cover that integration. Failing to account for this could lead to compliance issues down the line.
• Leverage the Transition Period: Ensure your S/4HANA agreement includes dual-use rights or a transition window, allowing you to run both old and new systems in parallel. This is critical for a smooth migration, and it also indirectly helps with shelfware retirement – you might keep an old system running for a few months to verify that nothing critical was overlooked before fully decommissioning it. With proper provisions, you won’t have to pay extra licenses for that overlap period.

By planning carefully and negotiating with these considerations in mind, you can confidently retire old SAP components. The result will be a cleaner, cost-effective S/4HANA landscape, free from the drag of yesterday’s unused software.

Recommendations

• Conduct a Pre-Migration License Audit: Before negotiating any S/4HANA contract, perform a comprehensive SAP license audit. Identify all shelfware (unused modules, inactive users) so you have a clear list of what to eliminate.
• Engage Early with SAP on Conversion Options: Discuss contract conversion vs. product conversion with SAP well in advance. Use those talks to understand how your shelfware could be treated (credit or otherwise) and signal that you plan to optimize your licenses.
• Terminate Unused Licenses to Reduce Maintenance Costs: Where possible, exercise contract rights to terminate truly unused licenses before migration. Halting maintenance payments on shelfware immediately saves money and removes those items from the conversion equation.
• Negotiate Aggressively for Credits: For the licenses you do carry into a conversion, push SAP to recognize your past investments. Provide data on usage to support credit requests. Aim to apply the value of legacy purchases to new S/4HANA products you need, minimizing net new spend.
• Right-Size the New Environment: Don’t automatically replicate your old license counts. Scrutinize user roles and transaction volumes to purchase just what you need for S/4HANA. Consider phased additions if uncertain, rather than oversizing Day 1.
• Align Licensing with IT Roadmap: Ensure that any component included in the new contract has a justified place in your future architecture. If your strategy includes non-SAP solutions replacing certain functions, reflect that by not licensing similar SAP components in S/4HANA.
• Secure Transition Safeguards: Include dual-use rights and adequate transition duration in your S/4HANA agreement. This protects you from needing to rush the cut-off of old systems and allows verification that no necessary functionality was mistakenly dropped.
• Consult Experts if Needed: SAP licensing and contracts are complex. Consider involving a third-party SAP licensing advisor or software asset management expert to validate your shelfware analysis and support negotiations. An expert can identify hidden risks or opportunities (e.g., the impact of indirect access or policy changes) that CIOs and procurement teams should address.
• Communicate Internally: Inform finance and business stakeholders that the S/4HANA transition presents an opportunity to optimize costs. Create transparency around what will be retired and the reasons behind it. This helps avoid pushback, such as “we might need that module someday,” and builds consensus that shedding shelfware is a positive and necessary step.
• Monitor Post-Migration Usage: Finally, after migrating to S/4HANA, institute regular reviews of license usage. Ensure you’re realizing the expected savings and not accumulating new shelfware. Optimization should be an ongoing discipline, not a one-time event.

FAQ

Q1: What is “shelfware” in the context of SAP, and why should CIOs care?
A: Shelfware means SAP software licenses you’ve bought but aren’t using (or underusing). CIOs should care because shelfware wastes budget (through support fees on idle software) and clutters your contract. Eliminating shelfware can immediately cut costs and simplify your license compliance position. It ensures you’re only paying for software that delivers business value.

Q2: How can we identify which SAP components are truly unused or obsolete before migrating?
A: Start by analyzing system usage data and user logs – look for modules with no or minimal transaction activity and user IDs with no logins in months. Cross-check with business units to confirm whether those components or accounts are still needed. Common culprits include modules purchased as “insurance” or as part of bundles (such as an extra industry solution that was never implemented) and accounts of former employees. A formal internal license audit, or the use of SAP’s LAW tool, can highlight these gaps. Many companies find it beneficial to utilize a software asset management tool or service to gain a detailed understanding of license utilization.

Q3: What types of old SAP modules are often retired during an S/4HANA migration?
A: Typically, modules that have either been replaced by new S/4HANA functionality or by third-party solutions are on the chopping block. For example, legacy solutions like SAP SRM (supplier management), SCM/APO (supply chain planning), or older versions of SAP CRM might be retired if you plan to use S/4HANA’s built-in procurement, planning, and customer management capabilities (or if you’ve moved to alternatives like Ariba, IBP, Salesforce, etc.). Also, any unused Industry Solutions or niche engines that aren’t relevant to your future state can be eliminated. Essentially, if a module isn’t in the deployment roadmap in the future, it’s a candidate to drop.

Q4: Can we get financial credit for unused licenses when moving to S/4HANA?
A: Yes, if you go through SAP’s contract conversion program. SAP will evaluate the licenses you own and give you credit (a license value trade-in) towards the purchase of S/4HANA licenses. In theory, this can cover a substantial portion of the new license costs. However, SAP may not give full credit for shelfware that’s not in use or not applicable to S/4HANA. It’s negotiable – customers have secured significant credits, but you need to advocate for every dollar. Be prepared to demonstrate how existing investments align with new S/4HANA requirements. Note that if you choose a RISE with SAP subscription deal, you are also essentially trading in licenses (moving from owning to subscribing), so you should negotiate the subscription price in light of the licenses you have historically paid for.

Q5: What’s the difference between product conversion and contract conversion, in simple terms?
A: Product conversion is like a one-for-one swap – you keep your existing contract and just exchange individual products for their S/4HANA versions. It’s gradual and allows you to maintain old terms, but you can only swap what you have (no major reconfiguration). Contract conversion involves ripping up the old contract and setting up a brand new one for S/4HANA. You turn in all your existing licenses for credit and then purchase what you need anew. Product conversion is simpler but less flexible (shelfware that you don’t swap just stays unused). In contrast, contract conversion is more complex but allows you to apply the value of any license to any new product (great for repurposing shelfware value). Contract conversion can often be beneficial if you have a large number of unused or obsolete licenses, as it allows you to redesign your license mix from scratch.

Q6: If we terminate some unused licenses to save on maintenance now, do we lose the ability to use their value in the S/4HANA negotiation?
A: Potentially, yes – once a license is fully terminated (i.e., removed from your contract and maintenance stopped), it typically won’t count for conversion credit because you’re no longer “turning it in” to SAP (you already gave it up). That’s why there’s a balance to strike. If a license is truly not needed and SAP is unlikely to credit it (or if the maintenance savings are of higher value), terminating it early can be a smart move. But for licenses that you’re unsure about, or those SAP might credit well, you might keep them on contract through the negotiation to trade them in. Another approach is to negotiate a partial termination or reduction in maintenance via SAP’s policies (like their cloud extension policy) where you reduce maintenance costs when buying new cloud licenses. Each case is unique – evaluate the size of maintenance savings versus the potential credit to decide.

Q7: We’re considering RISE with SAP (S/4HANA as a cloud subscription). How does that impact our existing licenses and shelfware?
A: Moving to RISE with SAP means you go to a subscription model and essentially give up your perpetual licenses. In a RISE deal, your old licenses don’t carry over; instead, you negotiate a subscription fee for the bundle of S/4HANA services. Because SAP is aware that you have existing licenses, they often provide incentives or credits to ease the transition (for example, they might extend your ECC maintenance for a short period during migration or offer a discounted RISE subscription initially). However, if you’re not careful, you could end up “double paying” – you’ve already paid for ECC, and now you’re paying all over again for S/4. To avoid this, ensure that the value of your legacy investment is taken into account. Even shelfware licenses can give you leverage – for instance, you could say, “We own $X million of licenses, even if we didn’t use some, we expect a competitive subscription price that reflects our past spend.” Essentially, the more shelfware you have, the more you want to ensure SAP’s RISE pricing is aggressive since you won’t be using those old licenses in the future at all.

Q8: How can we prevent accumulating new shelfware once we’re on S/4HANA?
A: It comes down to governance and monitoring. First, when signing the S/4 contract, resist the urge to over-procure “just in case.” Buy what you need with maybe a buffer, but not 50% more users or an extra module that isn’t in the plan. Next, implement a process to regularly review license assignment and usage, at least annually, if not quarterly. Utilize SAP’s provided tools or third-party solutions to track active users and engine usage. When employees leave or change roles, re-harvest their licenses promptly. And if your business strategy changes (for example, if you decide not to launch a planned module), consider engaging with SAP to adjust your contract or drop that component (perhaps via a flexibility clause or at renewal). In short, treat licenses as assets to be optimized continuously. Set up an internal licensing team or assign responsibility to IT asset management to monitor and prevent shelfware from creeping back in.

Q9: Our finance team is worried about write-offs: “We paid for these licenses already, so isn’t dropping them a waste?” How to address this concern?
A: It’s true that there’s a psychological barrier in terminating something you spent money on. However, remind stakeholders that the money spent on shelfware is already gone (sunk cost) – keeping unused licenses around doesn’t recover that investment, it compounds the waste by incurring ongoing fees. By retiring shelfware, you stop wasting good money. Plus, in a contract conversion scenario, you’re not necessarily throwing it away – you are leveraging whatever value is left as credit toward something you’ll use (which salvages part of the sunk cost). It can help to frame it this way: “We’re freeing up funds to invest in things we do need (like new S/4HANA functionality or other projects) instead of perpetually funding unused software.” Any short-term accounting impact of terminating an asset is usually far outweighed by the cost savings and efficiency gains that will follow.

Q10: What if we discover additional needs after we’ve cleaned up – is there a risk we cut too much?
A: This is why the analysis phase is important. However, it’s better to err on the side of cutting the true dead weight and dealing with edge cases separately. If you realize, post-migration, that you need something you dropped, you can always approach SAP to purchase additional licenses or activate that module in S/4HANA. Yes, buying it later might incur a cost, but the goal is to avoid paying for it if you never end up using it. One mitigation strategy is negotiating price protections or options for certain licenses in your S/4HANA contract. For example, you might negotiate a clause that allows you to purchase additional users or a specific module at a pre-agreed discount within two years, if needed. That way, you feel safer not having to carry everything over. Additionally, using a phased migration approach can be beneficial – you might leave some lesser-used components on ECC (with minimal maintenance or in read-only mode) for a year as a safety net, and only if truly needed, do you license the S/4 equivalent. In summary, with good planning and a bit of flexibility negotiated, the risk of cutting too much can be managed, and the cost of an occasional add-on later will usually be far lower than the cost of holding a lot of unused software “just in case.”

Read more about our SAP Advisory Services.

Would you like to discuss our SAP services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit