SAP S/4HANA Migration Audits: Avoid Dual-Use Traps, FUE vs Named-User Licensing & Proper ECC Retirement Documentation
Migrating from SAP ECC to S/4HANA is a major undertaking that extends beyond technical upgrades – it’s also a complex licensing landscape. Enterprises often focus on project timelines and new features, but audit readiness during migration is just as critical.
Why? Because hidden licensing pitfalls – especially those related to dual-use rights, new license models like FUE, and retiring your old ECC system – can lead to compliance issues and unbudgeted costs if not handled proactively.
The good news is that with a bit of strategic planning and documentation, you can avoid SAP audit traps and turn your S/4HANA transition into a clean slate rather than a compliance nightmare.
This article breaks down the key areas to watch and outlines the steps to take, enabling you to migrate with confidence.
Why Migration Audit Readiness Matters
Migrating to S/4HANA doesn’t automatically eliminate SAP’s audit oversight.
SAP Audit scrutiny often heightens during an ECC to S/4HANA migration. SAP recognizes that customers are in a state of flux, running both old and new systems in parallel, and that’s when mistakes occur. If your licensing isn’t buttoned up, you risk:
- Dual-use license exposure: Running ECC and S/4HANA simultaneously can inadvertently result in double-counting user licenses or usage. Without explicit rights, SAP may consider this an unlicensed use.
- Outdated contracts and shelfware: Migration is when many discover they’re still paying for licenses or modules they don’t need. If you don’t reconcile these, you’ll carry inefficiencies into S/4HANA or face tough questions in an audit.
- Lost negotiation leverage: Once you’ve technically migrated, SAP has less incentive to be generous. Addressing licensing before and during migration keeps you in the driver’s seat while you still have something SAP wants (your S/4HANA business).
In real terms, being audit-ready means fewer surprises. For example, one Fortune 500 manufacturer learned this the hard way: they assumed their ECC users could continue running for months after the S/4 cutover – until an SAP audit flagged them for unlicensed use.
The result was a hefty bill that could have been avoided with better planning. Bottom line: A smooth migration isn’t just about going live; it’s about staying compliant throughout the entire journey.
Understanding Dual-Use Rights and Contract Conversions
One concept every ECC-to-S/4 migrator must grasp is SAP’s “dual-use rights.” This is SAP’s allowance for customers to use their legacy ECC system and the new S/4HANA system in parallel for a specified period, without incurring duplicate costs.
Dual-use rights are incredibly helpful – they let you do a phased migration or run pilots in S/4HANA while ECC is still live, without immediately doubling your license costs. However, they come with strings attached:
- Time limits and conditions: Dual-use isn’t indefinite or automatic. SAP’s policies (and your contract) define how long and under what conditions you can run both systems. It might be a set period (e.g., 12-24 months) or “until completion of transition.” If you drift beyond those terms, the extra usage can be viewed as non-compliant.
- Scope limits: Dual-use typically covers equivalent functionality. You can’t suddenly expand usage in ECC during migration or add new users there and claim it’s covered. Likewise, any use of ECC beyond what’s allowed (for example, keeping it running “just in case” long after you’ve gone live on S/4) could trigger audit findings.
The way you structure your S/4HANA licensing conversion plays a big role in dual-use rights. SAP offers two main approaches to move your licenses over, and they handle dual-use differently:
- Product Conversion (License Exchange): In a product conversion, you essentially swap your existing ECC licenses for S/4HANA licenses on a one-to-one basis, under your current contract. The benefit here is built-in dual-use rights – because you’re keeping your original contract active, SAP lets you run ECC and S/4HANA concurrently during the migration. All your existing discounts and terms carry forward. This approach is great for a phased rollout because it’s low-disruption: you convert modules or users in stages and have both systems live simultaneously. However, product conversion won’t reduce your total license count (any unused ECC licenses just become unused S/4 licenses), and SAP has been phasing this option out in favor of a full contract reboot. If you haven’t already secured the entitlement for product conversion, you may need to pursue the contract route now.
- Contract Conversion: This is a more radical reset – you terminate your old ECC contract entirely and sign a brand-new S/4HANA contract. SAP gives you credit for the investments you’ve made in ECC licenses (often a credit equal to a percentage of your original license value), which you can apply toward the new S/4 licenses. The big advantage is you get to right-size and reshape your entitlements. Shelfware or obsolete modules can be dropped, and you start fresh with only the licenses you need. The trade-off is that all the old contract perks or user types vanish; you’re under SAP’s latest licensing rules now. With contract conversion, dual-use rights are not automatic, as they are under an active ECC contract – you must negotiate the terms for any parallel use. Typically, SAP allows a period of dual-use, but it must be explicitly agreed upon and documented. And because your ECC contract is being retired, you’ll need to prove you aren’t still using those old licenses beyond the allowed transition period.
Regardless of the route you take, remember that ECC will eventually be retired. Dual-use is meant to be temporary. SAP’s auditors will expect to see that after a certain point, you shut down the old system. If you choose product conversion, that point might be when your phased migration is done (e.g., within a year or two).
With contract conversion, it could be an agreed date or milestone. Fail to retire ECC properly, and you risk compliance issues – either paying maintenance on a ghost system or getting hit for unlicensed use if it’s found running outside of your conversion terms.
Read about Legal and Contractual Defenses Against SAP Audits.
FUE vs. Named-User Licensing Models
As you transition to S/4HANA, you’ll encounter a new licensing model acronym: FUE, or Full Use Equivalents.
For veterans of SAP ECC, licensing was primarily based on named users – you purchased a specific number of each user type (Professional, Limited Professional, Employee, etc.) and possibly some engine metrics. In S/4HANA (especially with cloud offerings like RISE with SAP), SAP is shifting to the FUE model, which dramatically changes how user licenses are counted.
Named-user licensing (traditional model):
You assign each individual a license type based on their role. Every user is “named” on the license. For example, an HR clerk might be a Limited Professional User, a finance power-user is a Professional User, and a self-service employee just has an ESS (Employee Self-Service) user license.
Compliance in this model means making sure each person using SAP has the right license type for what they do, and you’re not exceeding the number of licenses you bought. Audits focus on user classification – SAP will review the transactions users executed and determine whether their license type covers those activities.
Full Use Equivalent (FUE) licensing (new model):
FUE is more of a consumption-based aggregate model. Instead of buying X of each user type, you buy a certain number of FUEs, which represent an overall capacity of usage. Different user roles consume a fraction of an FUE based on how heavy their usage is:
- 1 FUE usually equals one full-power user (often called “Advanced Use” in S/4HANA Cloud terminology). This is akin to a Professional user who can do everything.
- The lighter the role, the smaller fraction of an FUE it counts. For instance, SAP’s current ratios (example) are something like: 5 Core Users = 1 FUE and 30 Self-Service Users = 1 FUE. In other words, a basic employee self-service user might only count as 0.033 of an FUE, whereas a mid-level operational user counts as 0.2 of an FUE.
- You don’t have to pre-assign exactly how many of each type you’ll use; you just need to ensure the sum of all your users (weighted by their role) stays within your purchased FUEs.
The FUE model brings flexibility – it allows you to cater to different user types without rigid SKU counts, and you can adjust user roles without immediately purchasing new licenses as long as you have FUE headroom.
But it also introduces compliance complexities:
- Role creep risk: Since users can theoretically modify their actions, an audit may re-evaluate your users’ activities. If many of your “light” users end up performing heavier tasks, SAP could say you consumed more FUEs than you bought. Continuous role monitoring is crucial.
- Over-allocation risk: On the other hand, some companies over-buy FUEs as a precautionary measure. If you haven’t optimized your user-role mapping, you might assume you need more FUEs than necessary. We’ve seen cases where a company initially estimated their 1,000 users required 500 FUEs, but after optimizing roles and eliminating dormant accounts, they only needed 300. Analysis and tools are your friend here – don’t just convert your old named users to FUE blindly; study how many FUEs your usage truly equates to.
- Audit approach: Under FUE, SAP’s audit will likely involve reviewing the user list and their authorizations to calculate how many FUEs are used. This is a different process from the old count-the-users approach. Your compliance team needs to understand SAP’s FUE counting rules to avoid unpleasant surprises.
In summary, FUE vs named-user is a shift from counting people to measuring consumption. If you remain on-premise with S/4HANA and traditional licensing, you may still be on named-user licenses.
However, if you opt for newer contracts or cloud subscriptions, be prepared for the FUE paradigm. To stay compliant, ensure you categorize users accurately (e.g,. who truly needs “advanced” access vs. who can be a “self-service” user) and revisit these classifications regularly.
The goal is to align your license model with actual usage so you pay for what you use – and nothing more – all while avoiding any shortfall that an audit could catch.
How to Document ECC System Retirement
When it’s time to finally say goodbye to your old ECC system, don’t just pull the plug and celebrate.
How you retire your legacy system is a critical part of audit defense in an S/4HANA migration. Remember, SAP will want proof that you’re no longer using the software you said you would stop using.
Here’s how to document and execute ECC decommissioning in a way that keeps auditors satisfied:
- Plan a formal ECC decommission project: Treat shutting down ECC as its mini-project in your migration. Set a target date for when production ECC will go offline (or go read-only) and stick to it. Communicate this plan internally so that everyone is aware that, after December 31st, the old system should not be modified for live business.
- Freeze changes and access: In the lead-up to decommission, impose a change freeze on ECC. No new transactions or users should be added once you’ve cut over to S/4HANA. Many companies lock all standard users out of ECC once S/4 is live, leaving only a couple of admin accounts for emergency read access. This prevents well-meaning employees from falling back to the old system “just this once,” which could muddy the waters.
- Archive and extract necessary data: One reason companies hesitate to turn off ECC is the historical data. Solve this by archiving the data or extracting what you need for compliance purposes. SAP provides tools (like SAP Information Lifecycle Management and Data Archiving) to store data outside the live system. The key from a licensing perspective is that once archived, the ECC software isn’t actively used – accessing archived data shouldn’t require an ECC application license if done properly.
- Document the shutdown steps: Keep a log of the decommission process. For example, record the date when the production instance was stopped. Save system logs or screen captures that show services being halted. If you’re comfortable, write a letter or email to your SAP account rep stating, “As of X date, we have decommissioned our SAP ECC production system as part of our migration to S/4HANA.” Getting an acknowledgement from SAP can be golden – it sets a mutual understanding that ECC use has ended (so they can’t later claim you quietly kept using it).
- Retain evidence for the long term: It might be a year or more before you face an official audit post-migration. By then, people might forget details. Store the decommission documentation in a safe place (along with your S/4HANA contract and conversion paperwork). This should include any license conversion agreements, communication with SAP regarding the retirement of ECC, and internal sign-offs. During an audit, if SAP raises questions about the continued presence of ECC, you can produce a tidy file showing exactly when and how the old system was retired.
- Address non-production systems too: Don’t forget that ECC might exist in dev, test, or sandbox environments. Are you keeping any of those for historical reference? If so, clarify the status: perhaps you maintain an ECC sandbox for a year to compare data, but ensure it’s isolated, not used by end users, and note when you eventually delete it. Non-production systems can also be counted in audits if they have a large number of users. Best practice is to cleanse those as well – scrub users from the old dev/test systems or secure them so they cannot be used operationally accidentally.
Proper ECC retirement documentation is like an insurance policy. It demonstrates your compliance effort and makes it hard for an auditor to argue that you owe licenses for the old system.
In essence, you’re creating a paper trail that says, “ECC is done, here’s the proof,” which closes one big chapter as you start the next on S/4HANA.
Six Expert Recommendations for Migration Audit Defense
To ensure you don’t fall into any traps during your S/4HANA transition, consider these six best-practice recommendations.
They come from the hard-earned experience of many enterprises that have navigated migration audits successfully:
- Map Usage and Forecast Your S/4 Needs (use SAM tools): Before you even sign that S/4HANA contract, get a clear picture of your current SAP usage. Use Software Asset Management (SAM) tools or SAP’s measurement reports to map out how many users you have, what roles they use, and how that would translate under S/4HANA’s licensing (including FUE calculations if applicable). This upfront analysis helps you estimate the licenses or FUEs you’ll need in the new system and avoid overbuying. It also highlights any obvious compliance gaps in ECC that you should address before migrating (it’s better to clean house now than let SAP find the issues later).
- Establish a License Baseline with an Internal Audit: Perform an internal license audit of your ECC environment (and any other SAP systems you have) before migration. This baseline indicates your current position. Reconcile the number of active users against what you’re entitled to, and check that each user has the correct license type. It’s common to discover dormant accounts, mismatched license assignments, or engine metrics creeping up. Fix those issues or at least be aware of them. Entering an S/4HANA conversion with unresolved compliance issues is like moving into a new house with termites in the boxes – not a great idea. A cleaned-up baseline also positions you to negotiate contract conversion from a position of strength, with accurate data.
- Segregate ECC vs. S/4HANA environments: During the migration period, be very clear about which users and activities belong in ECC and which in S/4HANA. If possible, avoid overlapping usage. For example, once a business unit has migrated to S/4, promptly remove or deactivate their accounts in ECC. This prevents double-counting the same person in both systems during audit time. Also architecturally, ensure any new interfaces or add-ons are pointed at S/4, not ECC, to prevent accidental continued use of ECC. Think of it as two separate buckets: you want to keep ECC usage contained and gradually empty that bucket as you fill the S/4 bucket, without spilling over between them.
- Document Everything: Conversion Credits, Compatibility Packs, and Dual-Use Timelines – Keep meticulous records of all special arrangements in your migration. If SAP granted you conversion credits (e.g., “we credit 70% of your ECC license value toward new licenses”), document how that was calculated and what assumptions were made (such as you dropping certain products). If you are utilizing S/4HANA compatibility packs (temporary usage rights for classic ECC functionality in S/4HANA), note their expiration dates – many of these packs expire by end of 2025 or 2030 and can become an audit “time bomb” if you forget about them. And document the agreed dual-use period: when it starts, when it ends, and any conditions (e.g., “may run ECC and S/4 in parallel for 18 months for up to the same number of users licensed”). Having these in writing and easily accessible means you can answer any audit question with a paper trail, rather than just saying, “Well, we thought we were allowed.”
- Negotiate Key Conversion Clauses in Writing: Don’t rely on verbal assurances from salespeople – get important clauses into your S/4HANA conversion contract or an addendum. Specifically, negotiate for clear dual-use rights, conversion credit terms, and, if possible, some audit leniency. For instance, ask for a clause that acknowledges you’ll have X months of dual usage and that SAP will not require additional licenses for ECC during that time. If you’re moving to the FUE model, consider a clause that allows a true-up or adjustment after the first year, in case your initial FUE allocation was off – this can prevent punitive audit charges if your usage differs from projections. Pushing for these terms while SAP is eager to get you on S/4HANA is your best chance; once you sign, it’s harder to add protections. Enterprises that secure these clauses report far smoother audit experiences post-migration because the “rules of the road” were agreed upon upfront.
- Monitor for Stray ECC Use and Access Overlaps: Even after you think everything is in S/4, set up monitoring to catch any unexpected usage. This could be as simple as checking ECC user login logs weekly after cutover, or using scripts to alert if any background jobs or interfaces try to connect to ECC. Given the complexities of human nature and IT landscapes, there may be a rogue process or a team that didn’t receive the memo. Catch it and correct it quickly. The same goes for your S/4 environment – monitor license consumption continuously. If you see an unusual spike in users or a change in how people use the system (maybe everyone started using a new module that could affect your license counts), address it before it becomes an audit problem. In short, don’t wait for SAP’s audit team to tell you there’s an issue – find it yourself first.
Following these steps requires some effort, but it’s far less painful than stumbling into an audit pitfall unprepared.
Each recommendation above is aimed at ensuring that by the time SAP comes knocking to review your licenses, you’ve already done your homework (and perhaps even taken the class!).
Key Questions to Ask SAP During Negotiation
When negotiating your S/4HANA migration with SAP (whether it’s a new contract or an amendment), asking the right questions can save you a ton of grief later.
Use your negotiation phase to pin down answers – and commitments – on these critical points:
- “What are our dual-use rights, exactly?” – Nail down how long you can run ECC and S/4HANA in parallel and under what conditions. Is it time-bound (e.g., 18 months from contract signing)? Does it cover production only, or non-prod too? Get specifics in writing so there’s no ambiguity on when the grace period ends.
- “How will conversion credits work for us?” – If you’re doing a contract conversion, ask what percentage of your existing license value will be credited and how it’s applied. Also, clarify what happens if you need fewer licenses in S/4 than you had in ECC – do those extra credits just vanish, or can they be applied to other products or future growth? Essentially, ensure you understand the financial calculus of the swap so SAP doesn’t lowball the value of your sunk costs.
- “Can we carry over any unused licenses or get credit for shelfware?” – If you have a bunch of unused ECC licenses, ask if they can be converted to S/4HANA licenses (even if you’re not using them now, they could be useful later) or if you can get a maintenance fee reduction for retiring them. This is a negotiation point – SAP might not volunteer it, but it’s worth asking to optimize your license portfolio as part of the deal.
- “What about compatibility packs and transitional functionality?” – If some of your ECC functionality is not natively available in S/4HANA and you need to use compatibility packs (temporary solutions), discuss this upfront. Ask how long you can use those compatibility packs and whether they are included in the license or if there will be any additional cost after a certain date. You don’t want a surprise in 2026 that a feature you rely on suddenly requires a new license because the free compatibility period ended.
- “How will our named users map to FUEs (if applicable), and can we adjust later?” – If you’re moving to an FUE model, have SAP walk you through how your current users will translate to FUE consumption. Push for flexibility: For example, if, after six months, you discover that your FUE usage is trending higher than expected due to user behavior, is there a way to swap some users to a lower category or true up without incurring punitive costs? Essentially, you’re asking for a safety net while you get used to the new model.
- “Will SAP grant an audit grace period or resolution period post-migration?” – This one is a bit aspirational, but you might ask: given the big changes during migration, can SAP agree not to audit for, say, the first 6-12 months of our S/4 live usage, or at least agree to a remediation period if an audit finds issues? The goal is to get some breathing room to resolve any discrepancies. Also, discuss how disputes would be handled – for instance, if there’s a disagreement on user classification, can you escalate to SAP’s license compliance experts or have a mediation process? While SAP may not always grant a formal grace period, including friendly language in your contract stating that “SAP will work with Customer in good faith to address any unintentional compliance issues arising within the first year of transition” can be helpful.
These questions not only signal to SAP that you are a savvy customer (one less likely to be an easy audit target), but they also force clarity on potential gray areas before you sign. It’s much easier to negotiate protections up front than to argue about interpretations later during an audit.
Common Audit Pitfalls to Avoid
Even with preparation, companies often encounter common mistakes that can trip them up during SAP licensing audits during a migration.
Steer clear of these pitfalls:
- Don’t assume dual-use is automatic or unlimited. Simply migrating doesn’t entitle you to run two systems concurrently unless it’s agreed upon. Always double-check your contract and ensure it includes explicit dual-use terms. Assuming “SAP probably won’t mind” is dangerous – they will mind if it’s not in writing.
- Don’t ignore unused ECC licenses (shelfware) in the shuffle. If you have unused chunks of ECC licenses, don’t carry them forward blindly. Either retire them formally or use them as negotiating leverage for credits. If you skip this, you’ll continue paying maintenance on dead weight or miss out on credit value. Additionally, an audit may question why you have, for example, 500 Professional users licensed but only 300 active users, which can complicate your conversion discussions.
- Don’t misclassify users under the FUE model. When transitioning to FUE, be careful in how you categorize users (e.g., advanced vs. core vs. self-service). A common mistake is over-assigning too many as “Advanced” just to be safe, which inflates your FUE count (and costs). The other side is under-assigning (calling someone self-service who does more), which sets you up for compliance issues. Use data from ECC (transaction usage, roles) to inform these classifications accurately. If SAP’s audit algorithms find that many “Core” users executed advanced transactions, they might recalibrate your FUE usage upward.
- Don’t neglect to document the migration steps and license changes. We’ve hammered on documentation because it’s that important. One pitfall is having nothing to show when SAP asks, “How did you handle shutting down ECC?” or “Where is it documented that you dropped these engines from your contract?” If your key licensing people have left or memories have faded, you could be stuck. Avoid this by keeping a clear record now. A lack of documentation can turn a minor question into a major audit headache as you scramble to prove what was agreed upon.
- Avoid complacency during the transition. Some teams breathe a sigh of relief once S/4HANA is live and think the worst is over. In truth, the period right after go-live is critical. If you slack on license compliance, then it’s easy to let old habits (or systems) linger. Don’t let your guard down until ECC is fully decommissioned and all new licensing is verified as correct – and even then, maintain vigilance.
By being aware of these common missteps, you can double-check that you aren’t falling into the same traps. Think of it as learning from others’ tuition payments to SAP University… so you don’t have to pay the same fees.
Governance & Ongoing Compliance Monitoring
Congratulations – you’ve migrated to S/4HANA and (hopefully) dodged the major audit risks during the transition. But your work isn’t done. License compliance is an ongoing effort, and good governance will ensure you continue to reap the benefits of your clean start.
Here are some ongoing practices to keep your SAP house in order:
- Implement license usage dashboards and role controls: Put tools or processes in place to continuously monitor your SAP user license consumption. For example, regularly run SAP’s user measurement reports or use a third-party solution to track how many users of each type you have and how that compares to entitlements. Set up alerts for anomalies (like if someone assigns a bunch of new users the highest license level without approval). Ensure there’s a governance process for role design – avoid permission creep that could unintentionally elevate users to higher license tiers.
- Review FUE vs. actual usage regularly: If you’re on an FUE model, consider monthly or quarterly internal reviews of your FUE consumption. Compare the theoretical FUE count (based on current user roles) to what you purchased. If you’re nearing the limit, you can take action: perhaps some users can be downgraded in access, or maybe it’s time to budget for more FUEs before an audit forces the issue. In a named-user world, do a license reconciliation at least yearly (if not more often) – people join, leave, change jobs; your license allocations should reflect those changes.
- Conduct periodic internal audits (“mock audits”): Don’t wait for SAP’s official auditors to find a problem. At least once a year – and a few months before your next SAP audit is anticipated – run a full internal license audit. Use SAP’s License Administration Workbench (LAW) to consolidate usage across systems, check for duplicate users, and verify classification. Many companies even do this right after migration to ensure everything’s aligned. If you find any issues (e.g., a user without a proper license, or an engine metric over the licensed limit), remediate them immediately. This proactive approach turns audits from fire-fighting exercises into routine check-ups.
- Maintain your ECC retirement evidence in the long term: Keep the ECC shutdown file we discussed accessible for at least a couple of years. The same applies to any key communications with SAP regarding your license conversion. Corporate memories can fade with staff turnover, so ensure these documents are stored in a central repository that new licensing or compliance managers can easily access. It’s not uncommon that 2-3 years after a migration, SAP’s auditors ask something like, “We see an old ECC system ID in your SAP Support account – is that still used?” If you have the records handy to show it’s decommissioned, that line of questioning ends quickly.
- Stay informed about SAP licensing changes: SAP’s licensing policies are constantly evolving. New S/4HANA features or changes (such as the eventual phasing out of compatibility packs or new user types) can impact your compliance. Ensure that someone’s responsible for staying up-to-date with SAP announcements or engaging with your SAP user group for the latest updates. For example, if SAP changes the rules for digital access (indirect usage) or introduces a new conversion program, you want to be aware of it early and adapt if necessary.
- Engage stakeholders and maintain alignment: Licensing compliance shouldn’t be the sole responsibility of the IT or procurement team. Maintain a governance committee or, at the very least, a regular checkpoint with procurement, IT, and business owners. Review license usage vs. forecasts, upcoming contract renewals, and any planned changes (like adding a new module) that could impact licensing. When everyone’s aligned, you’re less likely to have, say, a situation where a business unit rolls out a new SAP add-on without telling IT, inadvertently requiring additional licenses.
By instituting strong governance and monitoring as an ongoing discipline, you ensure that all the hard work you did to smoothly and cleanly migrate to S/4HANA doesn’t unravel over time.
Think of it as maintaining good “license hygiene” – it keeps your SAP environment healthy, your costs optimized, and your compliance position solid.
That way, whenever the next SAP audit or true-up does come around, it will be a non-event – you’ll have all the answers and documentation at your fingertips. You can get back to leveraging S/4HANA’s innovations rather than fighting fires.
Read about our SAP License Audit Defense Service.
Read our SAP Audit Defense Case Studies.
