Locations

Resources

Careers

Contact

Contact us

SAP S/4HANA Licensing

S/4HANA Compatibility Scope Matrix – How to Identify and Map At-Risk Functions

S4HANA Compatibility Scope Matrix – How to Identify and Map At-Risk Functions

S/4HANA Compatibility Scope Matrix – How to Identify and Map Your At-Risk Functions

Many SAP S/4HANA systems still rely on “compatibility scope” items from the old ERP without anyone realizing it. These hidden functions, enabled by temporary compatibility packs, are essentially a ticking clock in your IT landscape.

As the end-of-2025 expiry for most compatibility pack usage looms (with a few extensions to 2030), identifying these at-risk functions early is critical.

The S/4HANA compatibility scope matrix serves as your roadmap for identifying and mapping potential problem areas before they impact your business.

Read our comprehensive guide to S/4 Hana Compatibility packs.

By proactively auditing your system’s compatibility scope now, you can avoid last-minute surprises, reduce compliance risk, and strengthen your hand in planning and negotiations for the road ahead.

Why This Topic Matters

Many enterprises don’t discover their reliance on compatibility scope items until it’s almost too late.

Compatibility pack usage often goes unnoticed because it runs quietly in the background – everything “works” in S/4HANA, so teams assume they’ve fully migrated.

But when the temporary usage rights expire (most at the end of 2025), any unaddressed compatibility scope items could suddenly leave critical processes unsupported. This isn’t just a technicality; it’s a serious business risk.

Failing to plan for the compatibility scope expiry can lead to compliance problems (using unlicensed software features), lost support, or even system downtime if SAP disables these functions in future releases. Moreover, addressing these items under time pressure tends to be costly and disruptive.

On the flip side, knowing exactly which SAP compatibility scope items are in use gives you a strategic advantage. You can incorporate their remediation into your S/4HANA migration or upgrade plans well in advance.

You also gain negotiation leverage with SAP and other vendors – for example, when planning new licenses or extensions, you’ll approach the conversation armed with data about what legacy functions you need to replace or upgrade.

In short, shining a light on your compatibility scope usage now helps you avoid unpleasant surprises and ensures a smoother path to a fully supported S/4HANA environment.

S/4HANA Compatibility Pack Expiry Dates Explained

Understanding the S/4HANA Compatibility Scope Matrix

So, what exactly is the S/4HANA compatibility scope matrix? In simple terms, it’s a catalog or list of all the transitional SAP ERP functions that SAP has allowed to run temporarily in S/4HANA.

Think of it as a mapping of legacy components to their status in S/4HANA.

Each “compatibility scope item” is an old module or feature (from SAP ECC 6.0 and earlier) that lacks a like-for-like replacement in early S/4HANA releases, so SAP has granted a grace period to continue using it. The compatibility scope matrix details each of these items, including their technical IDs and expiration dates for usage rights.

SAP defines these compatibility scope items as a bridge – a way to enable customers to transition to S/4HANA without immediately reimplementing certain niche or complex functions. However, they come with an expiration date.

Most compatibility pack items are set to expire on December 31, 2025, after which you legally cannot use them (and SAP will stop supporting them).

A few specific items have extended rights through 2030 due to their complexity, notably Customer Service (CS), Logistics Execution and Transportation (LE-TRA), and Production Planning for Process Industries (PP-PI).

Additionally, customers on RISE with SAP or SAP S/4HANA Private Cloud Edition have an extension to 2030 for all compatibility packs as part of their contract. But outside of those exceptions, the clock is ticking.

The matrix not only outlines the timeline but also often indicates the modern S/4HANA equivalent or replacement for each legacy function.

For example, it might indicate that SAP Transportation Management replaces classic LE-TRA (the old transportation module) in S/4HANA, or that certain ERP HR functions should transition to SuccessFactors or a newer HR solution.

By studying this compatibility scope matrix, your team can understand which functions in your system are “at risk” of expiration and what the target replacement or solution is. It’s essentially the foundation of an S/4HANA compatibility scope analysis – helping you map out how to go from old to new before the deadline hits.

How to Detect Compatibility Scope Items in Your Landscape

Identifying the scope of compatibility usage in your own SAP landscape requires some detective work. Fortunately, SAP provides tools to make this easier.

Here’s a step-by-step approach to perform a compatibility pack usage check and find any active compatibility items and their dependencies:

  1. Run an SAP Readiness Check: Start with the SAP Readiness Check service (available via SAP for Me or as a program run in your system). This comprehensive scan will analyze your S/4HANA system (or your ECC system if you’re planning a conversion) and flag any active compatibility scope items through a dedicated compatibility analysis. The Readiness Check report includes a section specifically for compatibility pack usage, showing which classic functions or transactions are being used in your environment. This gives you an initial inventory of at-risk functions. In short, the SAP Readiness Check compatibility findings serve as a baseline list of the compatibility scope items in use.
  2. Use the Simplification Item Check: Next, run the Simplification Item Check (S/4HANA). This tool examines your system configuration and data against SAP’s Simplification List, which includes information about deprecated or changed functionality in S/4HANA. The Simplification Item Check will identify items that fall within the compatibility scope or are not the “go-forward” solution. For instance, it might flag that you are using a deprecated table or configuration that ties to a compatibility function. This helps pinpoint any configuration or master data elements that need attention as part of your S/4HANA compatibility scope remediation.
  3. Scan Your Custom Code: Hidden usage can lurk in custom ABAP code. Use SAP’s Custom Code Analyzer or ABAP Test Cockpit with the S/4HANA compatibility checks to perform an SAP custom code compatibility scan. This will scan your custom programs for any calls to obsolete transactions, function modules, or tables that belong to compatibility pack components. For example, you might find a custom report that still calls an old LE-TRA transaction code or reads a table that will be retired. By catching these, you can plan to adjust your custom code in parallel with removing the compatibility item.
  4. Leverage SAP Early Watch and Usage Stats: As an additional measure, review your system’s usage statistics or run an SAP Early Watch Alert report. These can show you which transactions and programs are used frequently. It’s a quick way to spot if users are still executing any compatibility scope transactions. (For example, transaction codes starting with “VL” for old shipping or “IW” for legacy service orders indicate that those legacy functions are in use.) Early Watch reports sometimes have specific sections for compatibility pack usage, which help track your progress in retiring these items over time.

By combining these tools, you gain a multi-angle view of where compatibility scope items are hidden in your landscape. Don’t rely on just one method – cross-checking results will ensure nothing slips through.

If the SAP Readiness Check flags certain items, confirm them with a deeper dive via the simplification check and then see if any custom code references those areas. This thorough detection phase will identify all SAP compatibility objects and processes that need remediation.

Commonly Overlooked High-Risk Compatibility Items

Through audits and migration projects, several compatibility scope items emerge as the usual suspects that companies overlook. Here are some of the most common “hidden” compatibility functions that might be quietly running in your S/4HANA system:

  • LE-TRA (Legacy Transportation Management): Many companies continue to process shipments using LE-TRA, the legacy ECC Logistics Execution Transportation module, which is part of the compatibility pack in S/4HANA. It’s easy to miss because it’s deeply embedded in order delivery processes and still works in S/4HANA. However, LE-TRA is meant to be replaced by the newer Transportation Management solution. If you haven’t explicitly moved to SAP Transportation Management, assume LE-TRA is in play and on borrowed time (extended to 2030 for some, but ultimately to be retired).
  • CS (Customer Service module): The classic CS module for handling customer service orders, repairs, and installed base management often lurks in manufacturing and utilities companies that migrated to S/4HANA. SAP’s strategic direction for service management in S/4HANA differs (e.g., S/4HANA Service, integration with CRM/CRM Service, or Field Service Management), so the old CS is a compatibility item. It’s commonly overlooked because service processes may continue as usual after a technical S/4 upgrade, with nobody realizing that those transactions (like IW32 for service orders) are legacy. CS has extended usage to 2030, but organizations should plan its replacement well before then.
  • PP-PI (Production Planning for Process Industries): Process manufacturing firms (such as chemicals and pharmaceuticals) that have migrated to S/4HANA may still utilize PP-PI functions (for recipes and process orders) in compatibility mode. PP-PI is a core part of many older industry solutions and is one of the items allowed until 2030. The reason is that fully replacing PP-PI with new S/4 functionality or alternative solutions can be a complex process. Nonetheless, it remains a high-impact area to address, since process industries can’t afford disruption in their manufacturing execution. Checking if you’re on a compatibility version of PP-PI versus an updated S/4 process manufacturing solution is key.
  • Classic Human Resources (HCM) components: Some organizations run HR and payroll on their S/4HANA system using a compatibility pack (since S/4HANA’s core doesn’t include full HCM). Suppose you have not migrated to SAP SuccessFactors or a separate SAP HCM solution. In that case, you may have an HCM Compatibility Pack in place that enables the old HR modules to function temporarily. This is extremely high-risk after expiry because no company can operate without payroll or HR systems. SAP offered an “HCM for S/4” option (as a sidecar) for those not transitioning to SuccessFactors, but either way, the old integrated HR modules in S/4 are on borrowed time. Ensure you identify any use of classic HR master data or payroll programs that are running in compatibility mode.

(Other examples can include classic Warehouse Management (WM) if you haven’t moved to Extended Warehouse Management, or older finance add-ons like classic Treasury or Travel Management if those were carried into S/4HANA. The key is to look at any area where you did not implement the new S/4-native solution.)

These high-risk items often go unnoticed during the initial S/4HANA migration because the system doesn’t break – the compatibility pack makes it seem like business as usual.

We’ve seen enterprises surprised by, for example, a transportation process still running on old code or a service team still using transaction codes that S/4HANA was supposed to phase out.

Identifying these early lets you focus your remediation efforts on the areas of greatest business impact.

Documenting and Prioritizing Findings

Once you’ve identified the compatibility scope items in your landscape, the next step is to document everything and prioritize the necessary actions.

A structured SAP compatibility scope inventory will serve as the foundation of your migration and risk mitigation strategy. Here’s how to approach it:

  • Create a Compatibility Items Inventory: List every identified compatibility scope item or component in use. Include details like the module or function name (e.g., “LE-TRA Transportation”), what business process or transactions it involves, and which systems or business units are impacted. This inventory essentially serves as your internal S/4HANA compatibility scope mapping tool, tailored to your specific enterprise needs.
  • Assess Business Criticality: For each item on the list, determine its criticality to your operations – essentially performing an SAP compatibility item risk assessment. Is it supporting a core, high-volume process (like shipping or billing)? Or is it a minor, rarely used function? Mark those high-impact scope items clearly – these will be your top priorities for remediation because they carry the most risk.
  • Evaluate Replacement Complexity: Identify the path forward for each compatibility item and gauge the effort to migrate. Some functions may have straightforward replacements (e.g. enabling an S/4HANA native feature or switching to a new module) while others might require a larger project or even a third-party solution. Note whether an item’s remediation is a quick configuration change, a full implementation project (as with adopting a new Transportation Management system), or something in between.
  • Prioritize and Sequence: Based on criticality and complexity, rank the items and align them with your overall S/4HANA migration or upgrade timeline. High-risk, high-impact items should be tackled first. For example, if both an old transportation module and an old finance report are in use, the transportation module (affecting physical deliveries) likely comes first. Build these into your project roadmap so that each compatibility pack dependency is resolved well before the 2025 deadline (or 2030 for those extended few).
  • Use Findings in Vendor Negotiations: Your compatibility scope inventory is also a valuable tool when discussing terms with SAP or other software vendors. If you need to license a new solution (such as SAP TM to replace LE-TRA or a third-party product for a specialized function), knowing exactly what you must replace puts you in a stronger negotiating position. You can approach SAP with a clear list of needs, which can facilitate discussions on license conversions, extensions, or additional support. Likewise, suppose you’re considering compatibility pack migration planning (such as moving to RISE with SAP to gain more time). In that case, your documented findings will justify why you might need that extension and what it will cover.

By thoroughly documenting and categorizing these at-risk functions, you make the problem tangible and manageable.

It transforms an abstract risk into a concrete to-do list. This clarity ensures that nothing is forgotten during the rush of a migration project, and it keeps everyone – from IT to business stakeholders – on the same page regarding what needs to be fixed and by when.

Six Expert Recommendations with Insights & Tips

To further reduce risk and ensure a smooth transition away from compatibility packs, consider these expert tips:

  • Run Multiple Checks – Don’t rely on a single SAP tool or report. Double-check your findings by using multiple analysis methods (e.g., Readiness Check, Simplification Check, custom code scan). If one tool misses something, another might catch it. This redundancy ensures you identify all hidden compatibility pack dependencies.
  • Prioritize High-Impact Scope Items – Not all compatibility issues are equal. Focus your energy first on the compatibility scope items that pose the greatest business risk. If a scope item underpins a core business process, allocate resources to remediate it as soon as possible. Lower-impact items are still important, but shouldn’t distract from the critical ones that could bring operations to a halt if left unaddressed.
  • Involve Business Process Owners Early – Don’t treat this as purely a technical cleanup. Bring in the business owners of the processes tied to each compatibility item. They can help assess whether the functionality is still needed, test new solutions, and plan for any process changes. Their buy-in and understanding are crucial, since retiring a compatibility pack function often means adopting new business processes or tools (which may require training and change management).
  • Cross-Check with Custom Code Analysis – Incorporate results from your custom code scans when planning remediation. If an old function is used in custom programs or reports, just implementing a new module won’t solve everything – you’ll need to adjust that code too. By cross-checking, you avoid “post-migration surprises” where a function that uses a retired feature silently breaks after the switch. In short, align your custom development remediation with the removal of each compatibility item.
  • Track Progress in a Central Register – Maintain a central tracker or register (even a simple spreadsheet or project management tool) that lists all compatibility scope items and their current status of remediation. Update it regularly as you make progress (e.g., “Replacement solution implemented and live” or “In testing phase” for a given item). This prevents loss of visibility throughout a long migration program. It also provides a single source of truth that management and project teams can review to ensure that nothing slips through the cracks.
  • Review Quarterly Until Expiry – Technologies and project priorities can change, so it’s wise to review your compatibility scope status regularly – say, quarterly – up until the deadline. New issues can emerge (for example, if the business reactivates a function you thought was retired, or a new enhancement inadvertently uses a deprecated component). A periodic S/4HANA compatibility item audit keeps the focus on final decommissioning. It also reminds stakeholders each quarter of the ticking timeline, maintaining urgency. Think of it as continuous compatibility pack dependency analysis: you’re regularly checking if any legacy dependencies remain and ensuring your plan is on track.

By following these practices, you can significantly reduce the risk in your S/4HANA environment and avoid scrambling at the last minute. Each recommendation above is based on hard-learned lessons from real-world SAP programs.

Governance & Continuous Monitoring

Treat compatibility scope management as an ongoing governance issue, not a one-time project. Even after you’ve identified and planned remedies for all your at-risk functions, it’s important to embed these checks into your regular IT operations.

Ensure that any new project or system upgrade in your S/4HANA landscape includes a comprehensive review of compatibility scope.

For instance, if you apply a major S/4HANA update or introduce a new business process, verify that you aren’t unknowingly re-introducing any legacy components. A simple checklist item, such as “compatibility scope impact,” for every change can go a long way.

Maintain alignment between IT and business teams by establishing clear ownership for retiring each compatibility item. You might set up a small working group that meets periodically to review the S/4HANA compatibility scope remediation progress.

This group ensures both technical and functional aspects are covered – IT can drive the technical solution, while business owners confirm that the new process meets their needs.

Continuous monitoring is also key. Leverage tools like SAP Early Watch Alerts on an ongoing basis to catch any usage of deprecated functions.

If someone inadvertently starts using an old transaction (perhaps as a workaround), you’ll want to identify it immediately and take action. By having monitoring in place, you enforce the rule that compatibility pack functions are off-limits well before the official expiration.

Finally, keep communication open with SAP about this topic. SAP’s guidance (through updates to the compatibility scope matrix or official notes) can evolve, and staying informed will help you adjust your plans. For example, if SAP announces an alternative solution or extends a deadline for a particular item, you can incorporate that into your strategy.

With strong governance and continuous oversight, your organization won’t slip back into risky habits. You’ll gradually transition entirely to supported S/4HANA functionality and maintain it in this state.

In the end, mapping out your at-risk functions and proactively replacing them not only avoids a compliance crisis but also drives you to modernize processes and maximize the value of your S/4HANA investment.

Read about our SAP Advisory Services.

SAP S 4HANA Compatibility Packs – Deadlines, Risks & How to Plan Ahead

Would you like to discuss our SAP Advisory Services with us? Get in touch!

Name
Author
  • Fredrik Filipsson

    Fredrik Filipsson is a seasoned IT leader and recognized expert in enterprise software licensing and negotiation. With over 15 years of experience in SAP licensing, he has held senior roles at IBM, Oracle, and SAP. Fredrik brings deep expertise in optimizing complex licensing agreements, cost reduction, and vendor negotiations for global enterprises navigating digital transformation.

    View all posts