Consequences of Moving from SAP Maintenance to Third‑Party Support

Moving from SAP Maintenance to Third‑Party Support

Introduction

Moving from SAP’s official maintenance and support to a third-party provider is a significant decision for any enterprise.

SAP’s standard support agreements provide regular software updates, patches, and direct vendor assistance – but at a high recurring cost and with obligations tied to SAP’s roadmap.

In recent years, many SAP customers have explored third-party support as a way to reduce costs and gain flexibility. This article looks at the implications of switching from SAP support to third-party support. It is written for IT decision-makers and SAP licensing professionals.

It covers the impact across major SAP products (ECC, S/4HANA, BusinessObjects, etc.), licensing consequences of ending SAP maintenance, and global legal, financial, and compliance considerations.

We also discuss specific risks (like shelfware, indirect access, and audits) and how leading third-party providers like Rimini Street and Spinnaker Support operate in this space. Finally, we provide Recommendations to help you make an informed decision and manage the transition effectively.

SAP Official Support vs. Third‑Party Support

SAP’s Official Maintenance comes with a bundle of services and obligations. Customers typically pay an annual fee (around 20–22% of the software license value each year) for SAP Enterprise Support or Standard Support.

In return, SAP provides software updates and upgrades (new versions, enhancement packs), security patches, fixes for known issues, access to the SAP support portal/knowledge base, and the ability to log support tickets with SAP’s help desk.

Official support also means alignment with SAP’s product roadmap – for example, customers on SAP ERP 6.0 (ECC) are encouraged to upgrade to S/4HANA by the given deadlines as SAP’s maintenance timelines end.

By contrast, independent companies unrelated to SAP provide Third-Party Support (3PS). These providers offer maintenance and technical support for SAP software after you opt out of SAP’s support.

Key characteristics include significantly lower annual fees (often 50% or more savings compared to SAP’s fees), indefinite support for older versions (no forced upgrades), and often more personalized service (including support for custom code and tailored fixes).

However, third-party support does not include new SAP software versions or official SAP patches. You essentially “freeze” on your current SAP software version, and the third party takes over support for that static environment.

The table below summarizes the main differences:

In summary, SAP’s support ensures you are always current with the latest fixes and features, but locks you into a costly annual fee and SAP’s upgrade timeline.

Third-party support gives cost relief and flexibility to run your SAP system on your terms but without direct access to SAP’s intellectual property updates or future innovations.

The decision to switch must weigh immediate savings against potential limitations down the road.

Impact on Different SAP Products

Not all SAP products are alike, and the consequences of moving to third-party support can vary across SAP’s portfolio.

Here, we consider major product categories – SAP ECC (ERP and Business Suite), SAP S/4HANA, SAP BusinessObjects, and other SAP offerings – to highlight unique considerations when switching support.

SAP ECC (SAP ERP 6.0 and Business Suite)

SAP ECC 6.0 (part of the SAP Business Suite) is the core ERP system many enterprises run for finance, logistics, HR, etc. SAP has committed to mainstream support of ECC 6.0 (with the latest Enhancement Packs) until 2027, with optional extended maintenance (for a premium fee) to 2030.

After that, SAP’s official support for ECC ends, pushing customers to migrate to S/4HANA. Many ECC users are evaluating third-party support as an interim or long-term solution:

• Continued Use of Stable System: If ECC meets business needs, third-party support allows you to continue running it beyond 2027 without SAP support. A third-party provider can supply bug fixes and tax/regulatory updates even after SAP’s support window closes. This can “buy time” if you’re not ready to migrate to S/4HANA.
• No New SAP Functionality: By leaving SAP support, you forgo any new Enhancement Packs or updates SAP might release. (SAP isn’t releasing new functional updates for ECC beyond what’s already out, so this may not be a big loss.) You’ll also lose SAP’s support on unexpected new issues, but third-party vendors specialize in supporting mature products like ECC.
• SAP Business Suite Components: The broader Business Suite (CRM, SCM, SRM, etc.), which runs on the ECC platform, is similarly approaching the end of its life. Third-party support is a common consideration to keep these systems running in a steady state. A third-party can support the whole stack if you have an integrated ECC + CRM scenario. Ensure the provider covers all modules you use.
• Future Upgrade Path: Be aware that if you choose to implement S/4HANA in the far future, you will likely have to license it anew or pay reinstatement fees (since you won’t have an active SAP support contract to “convert” your ECC licenses to S/4). We discuss licensing impacts in detail later, but this is a key consideration for ECC customers who think of third-party support as a “holding pattern” before S/4HANA.

SAP S/4HANA (On-Premise)

S/4HANA is SAP’s next-generation ERP. Like ECC, customers using S/4HANA on-premise (with a perpetual license) are entitled to SAP support.

Moving S/4HANA to third-party support is less common today, but does occur:

• Rapid Innovation vs. Stable Core: S/4HANA is still evolving, with annual releases and new features. If you leave SAP support, you’ll be frozen on your current S/4HANA version. You won’t receive new functionality or improvements that SAP delivers in future releases. Companies that adopted S/4HANA to take advantage of continuous innovation may find this trade-off too steep. However, if your S/4HANA deployment is stable and you don’t plan to upgrade for several years, third-party support can maintain it in the interim.
• Bug Fixes and Patches: SAP regularly issues S/4HANA patches (support packs). If you are off maintenance, you lose access to these. Third-party providers would need to address any new bug you encounter on their own. Over time, if your version is outdated, some issues might emerge that SAP fixed in newer releases – your provider must solve them independently. Ensure any provider you consider has specific experience with S/4HANA support and a process to deliver fixes and performance tuning.
• Cloud Versions Not Eligible: Importantly, if you are on S/4HANA Cloud or RISE with SAP (subscription services), third-party support is not an option. In cloud SaaS models, SAP owns the software and provides support as part of the subscription; you cannot separate the two. Only on-premise S/4HANA (which you license like traditional software) can be supported by a third party. So, if your long-term plan involves moving to SAP’s cloud, a stint on third-party support may be a short-term strategy at best.
• License Considerations: S/4HANA’s license model (and Digital Access documents model for indirect use) still applies even if SAP isn’t supporting you. Remember that any indirect use or extra user count still needs proper licensing (we will cover this later). Third-party support doesn’t exempt you from S/4 license rules.

SAP BusinessObjects and Analytics

SAP BusinessObjects (BOBJ) is an analytics and business intelligence platform (for reporting, dashboards, etc.).

Many enterprises run BusinessObjects BI 4.2 or 4.3 on-premise. SAP’s focus has shifted to cloud analytics (SAP Analytics Cloud), and while SAP still supports BOBJ, innovation is slowing.

Consequences of switching BOBJ to third-party support include:

• Mature Product Maintenance: BusinessObjects is a fairly mature, stable product. Third-party support can provide bug fixes, enhancements, or workarounds as needed. If SAP releases fewer updates, the gap left by not having SAP support is smaller. A third-party can also support your entire BI environment (e.g., integration with databases, drivers, etc.).
• Compatibility and Upgrades: One thing to watch is compatibility with other technology. For example, if you upgrade your database or OS, SAP would handle ensuring BusinessObjects remains compatible via patches in their support. A third-party provider must help you certify and adjust for such changes. Ensure they have a strategy for keeping up with third-party dependencies (like new versions of web browsers for web-based BI tools, Java updates, etc.).
• Licensing: BusinessObjects licensing is usually separate (concurrent user or CPU-based licenses). If you drop support, you will perpetually have the right to use your BusinessObjects licenses. Still, you won’t get any new version of SAP that might be released in the future (if, say, a BusinessObjects 4.4 came out, you wouldn’t be entitled to it without SAP maintenance). Given SAP’s roadmap, many customers are considering whether to stick with BusinessObjects or move to other tools – third-party support can extend the life of BOBJ. At the same time, you evaluate alternatives without paying SAP.

Other SAP Products (HANA, BW, etc.)

Beyond the core applications, consider other components:

• SAP HANA Database: If your SAP systems run on the HANA in-memory database, you likely pay maintenance on HANA licenses as well. Third-party support providers offer support for SAP HANA database issues and performance tuning. By leaving SAP support, you’d rely on the third party for HANA patches or workarounds. Verify that your provider has expertise and can supply updates for critical HANA bugs or security vulnerabilities. (If you run on a third-party database like Oracle or MS SQL, that database has its support contract separate from SAP, so you’d keep Oracle support for the DB even if the SAP application is on third-party support).
• SAP Business Warehouse (BW) and Others: SAP BW, CRM, SCM, and other modules of the Business Suite are typically covered under the same SAP maintenance agreement as ECC. A third party can cover all of these together. Ensure no product is left out – for example, if you use SAP Solution Manager (SolMan) for system monitoring, note that without SAP support, SolMan itself might not get updates (including SAP’s Maintenance Optimizer functions). Third-party providers may not directly support Solution Manager, but they often help you find alternatives for its functionality.
• SAP Industry Solutions or Niche Products: If you use an industry-specific SAP solution (like IS-Retail, IS-Utilities, etc.) or lesser-known products, check with potential third-party providers whether they support those. Providers like Rimini and Spinnaker generally support a wide range of SAP modules and add-ons, but very new or niche products might not be covered. Getting an explicit list of what is included in their support agreement is crucial.
• Cloud and SaaS Products: As mentioned, any SAP Cloud solutions (SuccessFactors, Ariba, Concur, etc.) are subscription-based and cannot be switched to third-party support. Those must remain under SAP’s support as part of the service. If you have a hybrid landscape (on-prem ERP but cloud HR, for example), you might end up with a mix of your on-premise software with a third-party and cloud software with SAP. This can complicate vendor management, but it is manageable if planned.

Licensing Implications of Not Renewing SAP Support

One of the most critical questions is: What happens to your SAP licenses when you stop paying SAP support? The good news is that in most cases, SAP software licenses are perpetual, which means:

• You retain the legal right to use the SAP software you have already licensed indefinitely, even if you end the maintenance contract. SAP cannot revoke your license to run the software you’ve paid for as long as you abide by the license terms (user counts, usage scope, etc.).
• However, ending support freezes your entitlements. You lose the right to download or implement any new releases, patches, or upgrades to newer versions released after your support termination date. Your licenses become “locked in time” at the version level you last maintained.

Important licensing and contract considerations include:

• No New Versions or Additional Licenses: If you do not renew support, you cannot later ask SAP for an upgrade or new module under that old contract. For example, suppose you own SAP ECC 6.0 and go off maintenance before S/4HANA. In that case, you do not automatically get rights to S/4HANA later – you would have to purchase S/4HANA licenses anew (likely at a discount that SAP negotiates, but not the free uplift that active maintenance customers might get). Similarly, while you keep existing licenses, if you suddenly need more user licenses or an additional SAP product, SAP may refuse to sell you additional licenses unless you reinstate support (or sign a new agreement). This can limit your ability to expand the usage of SAP software in the interim. Many companies on third-party support adopt a “no growth” stance for their SAP footprint or plan to license any needed expansion under separate deals in the future (often at significant cost).
• Reinstatement and Back Support Fees: If you leave SAP support and later decide to return to SAP’s maintenance program, be prepared for hefty fees. SAP’s policy typically requires you to pay all the back-dated maintenance fees for the period you were off contract, plus a penalty (e.g., a reinstatement fee, often around 10–20% of the fee) to rejoin. In practice, if you were off support for 3 years and want SAP support again, you might be billed for those 3 years of fees you “skipped” plus a surcharge. These costs often negate any savings you achieved by leaving, so rejoining is usually not economically attractive. Essentially, SAP makes it financially painful to “pause” maintenance and return later. (An alternative is purchasing brand new licenses, which can be even more expensive and may raise other issues like needing to migrate data.)
• Support Contract Termination Terms: Check your SAP contract for termination clauses. SAP support agreements auto-renew yearly. Typically, you must give written notice (often 3 months before the renewal date) if you intend to terminate support. Missing that window could lock you in for another year of payment. For example, many SAP customers have a December 31 renewal; if you don’t notify SAP by September 30, the contract will auto-renew through the next year. Third-party providers often remind customers about this because timing the switch is important. Always confirm the notice period required and send a clear, timely termination notice to SAP if you choose to switch.
• Partial Termination and Shelfware: Historically, SAP had an “all-or-nothing” stance on support – you had to keep paying maintenance on your entire SAP license portfolio, even if you weren’t using parts of it. This created the “shelfware” problem, where customers paid for unused licenses. In recent years, SAP (under pressure from user groups) introduced some flexibility for partial termination of licenses: you may be able to terminate (drop) certain unused licenses from your contract so you stop paying maintenance on them while keeping maintenance on the rest. This is something to consider before leaping to third-party support. For instance, if your only reason to drop support is that you have 30% of your licenses unused, you might negotiate with SAP to terminate that portion and reduce fees, while continuing support on the licenses you use. However, not all contracts allow this easily, and SAP often ties partial termination to purchasing new licenses or other concessions. If you go to third-party support, by default, you stop paying maintenance on all licenses (effectively a 100% termination). You still own the shelfware licenses, but none have active support. The upside is you save cost on all of it; the downside is if you needed to re-enable any component, you’d face the reinstatement situation above. In summary, going off support effectively makes the shelfware issue moot from a cost perspective (no maintenance on anything). Still, you should inventory what you truly need to be supported when negotiating with a third party (they may base fees on which products you want them to support).
• Loss of SAP Support Portal Access: Once your SAP maintenance ends, your company’s S-User IDs for SAP Service Marketplace/Launchpad will typically lose authorization to download software and patches or to submit support tickets. Ensure that before termination, you download any last patches, support packages, installation files, or documentation you might need for your existing systems. Third-party providers cannot legally provide you with SAP’s proprietary patches released while you were a customer if you failed to download them; they must recreate solutions independently. So, a common practice is to build an internal archive of SAP Notes and patches for your system just before your support lapses – to have those on hand. (Be mindful of legal boundaries: any use of SAP’s intellectual property after support ends should be discussed with legal counsel. Generally, applying a patch obtained during active support, even after you leave, can be a grey area. Most third-party providers prefer to avoid using SAP’s code patches and instead develop their fixes to stay on the right side of IP law.)
• License Compliance Continues: Ending support does not mean SAP no longer has any say in your use of the software. Your SAP license agreement’s terms and conditions remain in force. Crucially, SAP typically retains the right to audit your software usage to ensure you aren’t violating license terms (e.g., using more users than licensed or using the software for an unauthorized purpose). The frequency or likelihood of an audit might change (more on that in the audit risk section), but contractually, you should assume SAP can audit you even if you are not a current support customer. You must adhere to user counts, processor counts, named user definitions, and other metrics in your license. Suppose you expand usage beyond what you purchased. In that case, SAP can demand you license the excess (and potentially pay back maintenance on it, since technically, you should have been paying support on any unlicensed use). In short, you are still bound by your SAP license contract requirements even when SAP isn’t providing support. Self-policing and software asset management are important (see Compliance section below).

Legal and Compliance Considerations

Switching to a third-party support provider raises important legal and compliance questions. While cost and service factors are attractive, enterprises must remain on solid legal ground and comply with all agreements and regulations.

Legality of Third-Party Support

Is it legal to have someone other than SAP support your SAP software? The answer is yes – third-party support is legal if it complies with software license laws and contracts. As the licensee, you have the right to hire external experts to help you maintain your licensed software. However, there are a few legal points to be mindful of:

• Intellectual Property (IP) Concerns: The third-party provider must not infringe SAP’s intellectual property rights when delivering support. In practical terms, they cannot, for example, take SAP’s copyrighted source code or patches and redistribute them without permission. Instead, reputable providers develop their fixes or guide customers to implement solutions. This was at the heart of major lawsuits in the industry. Oracle (another ERP vendor) sued Rimini Street, claiming Rimini illegally downloaded Oracle’s support materials for clients. That case (which concluded in 2018–2019 after appeals) largely confirmed third-party support as a valid business but also set boundaries – it affirmed that support providers must operate within the law (Oracle won judgments for certain improper practices, and Rimini had to adjust its methods). SAP itself was involved in an earlier case years ago (SAP’s subsidiary TomorrowNow provided third-party support for Oracle customers and was sued, resulting in SAP paying a large settlement). The lesson is to choose a third-party provider with a strong legal track record. For example, Rimini Street and Spinnaker Support are very careful now about compliance – they only use materials that customers are authorized to provide and do not access SAP’s systems unlawfully. When you sign up with a provider, review the indemnification clauses. Top providers would indemnify (protect) you if SAP claimed the support activities violate IP – essentially, the provider takes on the legal risk.
• SAP Contract Restrictions: Review your SAP license and support agreements for third-party support or termination clauses. SAP generally does not forbid you from leaving or getting help elsewhere, but there could be clauses about notice period, or use of SAP proprietary tools. One thing to check is the use of SAP Solution Manager (included with support contracts) – if you use SolMan for things like maintenance planner or EarlyWatch Alerts, you might lose rights to those tools once-off support. No clause says “you may not use third-party support” (that would be unenforceable in many jurisdictions as anti-competitive), but do ensure you aren’t violating, say, any terms of using SAP’s support portal or software downloads after your contract ends.
• Regional Legal Differences: Globally, the legal environment can vary. In the EU, software directives grant customers certain rights, such as the right to correct errors (which could be interpreted as allowing third parties to create fixes) and the right to resell perpetual licenses under some conditions (which relates to shelfware). Europe has generally believed that once you buy software, the vendor cannot lock you into their services. Contract law tends to govern in the US and elsewhere – your license agreement terms are key. So, ensure your legal counsel reviews what obligations survive after termination of maintenance.
• Vendor “Retaliation”: It’s worth noting that while not a legal measure, SAP (like other vendors) may not look kindly on customers leaving its support fold. There have been reports and perceptions that vendors might respond with aggressive tactics (audits, strict enforcement of contract terms, or tougher stances in future negotiations). While this isn’t a lawsuit scenario, it is a legal consideration in the sense of how strictly SAP will enforce every letter of the contract once you’re not a paying support customer. Prepare for a more arms-length and potentially adversarial relationship with SAP’s license compliance team.

Software License Compliance

Even after moving to third-party support, license compliance remains the customer’s responsibility.

It becomes even more crucial to actively manage because you won’t have SAP’s support team to fall back on if an audit or issue arises:

• User and Package Licensing: Continue to track your named users and package licenses (engines) usage against what you own. Without SAP support, you might not get the usual gentle reminders or true-up processes, but SAP’s audit clause still allows them to check. Use internal Software Asset Management (SAM) tools or consultancies to periodically run license measurement (SAP’s LAW tool or third-party tools). It’s wise to do an internal audit at least annually. Identify any over-deployment early and address it (either by restricting use or planning to purchase additional licenses) rather than letting SAP discover it first.
• Indirect Access (Digital Access): One compliance hot spot is indirect access – when non-SAP systems or users use SAP data/functionality indirectly. SAP now has a Digital Access model (charging per document for indirect use in some scenarios). However, many customers still have traditionally named user metrics that don’t cover third-party interfaces. When you leave SAP support, you must be vigilant about any new integrations you implement. For example, if you connect a new e-commerce platform to pull data from SAP or a robotic process automation (RPA) tool to update SAP records, these could trigger license requirements. Ensure you have the appropriate licenses for such usage. Third-party support providers often advise on this (some have licensing experts to help you avoid indirect access pitfalls). Still, they cannot magically license SAP software for you – you might have to negotiate a license with SAP if new indirect usage arises. Plan integrations carefully or use middleware that minimizes direct calls to SAP if possible. In short, indirect access compliance is still your burden; being off support doesn’t mean SAP can’t audit those connections.
• Audit Preparedness: Assume SAP may invoke its right to audit your software usage. Legally, you’ll need to cooperate (within reason) as per your contract. To prepare: maintain meticulous documentation of your entitlements (licenses purchased, proof of purchase), how you assign licenses to users, and any third-party systems connected. Suppose you’ve reduced users or modules since leaving support, and document that, too (so you can prove you’re not using certain licenses). When you’re off support, an audit can be a bit tense – you won’t have a dedicated SAP account manager to negotiate with, and SAP’s audit team will strictly pursue any compliance gap. Some companies engage independent licensing advisors or attorneys to interface with SAP during audits, especially after moving to third-party support. The goal is to resolve any findings by purchasing the needed licenses without undue penalties (maintenance back-charges might be disputed in such cases since you weren’t under support, but SAP could argue you still owe maintenance for an unlicensed use period).
• Global Regulatory Compliance: Another aspect of “compliance” is keeping your SAP system compliant with laws and regulations (tax laws, financial reporting rules, data privacy, etc.). Under SAP support, SAP delivers updates for new tax codes (e.g., GST changes, payroll tax updates, EU VAT changes) in their support packs or notes. After moving to a third-party, ensuring legal compliance with the software’s functionality falls to you and the provider. The major third-party providers have teams that monitor global regulatory changes in various countries and create equivalent update scripts or notes for their clients. For instance, if a country releases a new e-invoicing mandate and SAP issues an OSS note, a third-party support provider would write an update to enable your system to comply. When evaluating providers, ask about their coverage for all regions you operate in. Do they track legislation in, say, Brazil’s tax system, India’s GST, EU’s SAF-T requirements, etc.? Compliance updates are mission-critical – failing to implement them could mean legal penalties from governments or an inability to do business in that region. You may also need to allocate internal testing resources for these third-party delivered updates, just as you would test SAP’s updates, to ensure they work correctly in your system.

Security and Patching

Security is a compliance issue, too; many industries require up-to-date security patching. When you leave SAP support, you stop getting SAP’s security notes and patches. Third-party support must fill this gap:

• Security Patches: Top third-party providers have security research teams that analyze SAP vulnerabilities (sometimes based on public disclosures or their findings) and develop fixes or mitigation instructions. They might not have the source code for the SAP kernel, but they can often recommend configuration changes, custom code tweaks, or provide code snippets to close a vulnerability. Questioning a potential provider on how they handle security updates is essential. For example, if a new SQL injection flaw is found in SAP NetWeaver, what will they do? Some providers issue proprietary patches; others might argue that isolating the system or using firewall rules can mitigate the risk. Ensure their approach meets your company’s security policy. Also, check if they have any certifications or third-party audits of their processes (some may have ISO certifications or the like).
• Compliance Standards: If your company follows standards like SOX IT controls, ISO27001, or others, document how third-party patching is handled as part of your compliance evidence. Auditors will want to see that you still have a mechanism for timely security updates. While SAP won’t be supplying them, an argument can be made that a dedicated third-party might even respond faster in some cases (since SAP often bundles patches monthly). Nevertheless, you should have SLA commitments from your provider for critical security issues.

Contractual and Global Issues

• Support Contract with Third Party: When you sign with a third-party support provider, that contract will have its terms. Typically, you’ll have an annual or multi-year agreement for a fixed fee. Ensure that it includes a clear scope of what products are supported, service level agreements (response times for critical issues), confidentiality (they will be accessing your system details), and an indemnification clause for IP (as mentioned). Also, clarify if they will support any new customization you add later or new integrations. Often, yes, as long as it’s within your SAP environment, but it’s good to confirm.
• Global Support Coverage: If you operate globally, check if the provider has 24/7 support and multi-lingual capabilities if needed. SAP has a large global support network; a third-party might be smaller, but leading ones have follow-the-sun support centers. For example, Rimini Street has support engineers in many countries who cover local time zones and languages. Spinnaker Support similarly touts global coverage. This matters if a critical issue occurs in your Asian subsidiary’s system during the day – you want the provider to respond quickly, even if it’s 3 AM at their HQ.
• Data Privacy: If you will share SAP system data or allow a third-party to access your systems remotely, consider data privacy regulations (GDPR, etc.). Your SAP system may contain personal data (employees, customers). Ensure the support provider has appropriate data protection agreements and measures since they may access or store some data (like error logs). Reputable providers will have no problem signing a Data Processing Agreement (DPA) and demonstrating compliance with privacy laws.

Financial Impact of Switching to Third-Party Support

From a financial perspective, moving to third-party support can yield significant savings and cost reallocation opportunities, but there are also some financial risks to consider.

Here are the major financial considerations:

• Immediate Cost Savings: The most obvious benefit is the reduction in annual support fees. SAP’s maintenance fees (especially Enterprise Support at ~22% of license value per year) add up to millions for large customers. Third-party providers typically charge around 50% of SAP’s support costs (some vary, but savings of 50% or more are common). For example, if you paid $2 million/year to SAP, a third-party might charge around $1 million, saving you $1M annually. Over five years, that’s $5M saved, which can be redirected to other IT initiatives or business projects. This substantial operating expense reduction attracts many CIOs and CFOs.
• Multi-Year Budget Predictability: SAP’s support fees tend to increase over time (SAP has in the past raised support fees by a percentage each year or tied increases to inflation indices). By contrast, third-party contracts often lock in a rate for the term of the contract (say a 3-year or 5-year term with a fixed annual fee). This provides budget stability – no unexpected hikes. In inflationary times or if SAP announces a general increase (as they did in recent years by up to 5%), a third-party contract insulates you from those increases. This predictability is valuable for long-term IT financial planning.
• Avoided Upgrade Costs (Deferral of CapEx): Another indirect financial benefit is avoiding or deferring the capital expenditure of a major upgrade. If you stay on SAP support, you may feel compelled to undertake a costly migration (e.g., ECC to S/4HANA) to stay in support compliance or to leverage what you’re paying for. Those projects can cost tens of millions in consulting, hardware, retraining, etc. Using third-party support to extend the life of ECC, some companies effectively postpone that huge investment. They might sometimes avoid it entirely if they transition from SAP to another solution in the long run. For example, a global retail chain might avoid a “multimillion-dollar upgrade” by using third-party support to keep its existing SAP ERP running smoothly for several more years – that example highlights the opportunity cost saved.
• Cost of In-House Expertise: It’s worth noting that third-party support does not mean you fire your SAP IT staff – you will still retain your Basis team and perhaps developers. However, you might reduce your reliance on expensive SAP consulting for support issues. Third-party providers include troubleshooting as part of their fee. In some cases, companies have been able to reduce internal support workloads (freeing those staff to work on new projects) because the third-party handles a lot of the break-fix and even routine maintenance tasks. This efficiency gain is hard to quantify but is a financial plus (it could reduce the need for overtime or additional hires). On the other hand, ensure you budget for internal efforts to interface with the provider and test their fixes.
• Potential Costs/Penalties:
  • Reinstatement / Lost Discounts: As discussed under licensing, if you ever need to return to SAP support or buy new SAP software, you may incur large one-time costs (back maintenance or full-price new licenses). Financially, you should almost consider that a sunk cost or unlikely scenario in your planning – many companies have a third-party support plan to avoid re-upping with SAP unless necessary. Still, it’s prudent to maintain a reserve or at least an awareness of the cost if business priorities change and an upgrade becomes critical.
  • Audit True-up Costs: If an audit finds you under-licensed, the financial hit could be licenses plus possibly prior period fees. While this would also be the case if you were on SAP support, the difference is that SAP might be less lenient with an off-support customer. You might not get any “goodwill” discounts. It’s important to proactively manage licenses to avoid a budget shock from an audit. Consider setting aside some contingency budget for license purchases, just in case, or having a plan (like dropping the use of certain components if faced with a big compliance bill).
  • Third-Party Contract Costs: The third-party support is a cost (albeit smaller than SAP’s). Typically, this is an annual opex. Make sure the contract is structured so that you don’t pay overlap (coordinate your end of SAP support and start of third-party, so you’re not double-paying in any month). Also, check if the third-party has any annual fee escalation or if it’s fixed. Most lock it in, but some might have a small annual inflation clause – negotiate that as needed.
  • Internal Tooling: After leaving SAP support, you might invest in some tools or services to help with license compliance or system health (things SAP offers like Solution Manager or EarlyWatch). For example, you might license a third-party monitoring tool for SAP systems now that SAP’s tools might not be fully available. These costs are usually minor relative to support fees but should be accounted for.
• Shelfware Savings: When you stop SAP maintenance, you immediately stop paying for maintenance on all that shelfware (unused licenses) that you might have been stuck paying for under SAP. If a portion of your SAP licenses were not actively used, that portion of the 20% fee is now saved entirely. Over the years, paying maintenance on shelfware is pure waste – third-party support can eliminate that waste. This can sometimes make the savings even greater than 50% effective because SAP might not have allowed you to drop those unused licenses from the maintenance base, whereas now you pay $0 for them. It’s a good practice to quantify this: e.g., “We had 1000 Professional User licenses but only 800 in use; we were paying maintenance on all 1000. Now, on third-party, we pay may be based on the 800 we need support for, or simply on the whole environment, but at half cost – either way, we’re not paying full price for unused capacity.”
• Long-Term Strategic Costs: Consider the opportunity cost of not investing that saved money into future-proofing. If you save $X million over 5 years by not upgrading or cutting support costs, ensure some of that is earmarked for the eventual next step (moving to S/4HANA, migrating to a different ERP, or modernizing your custom code). Some organizations make the mistake of viewing third-party support as just a cost cut; the successful ones use it as a financial strategy, for example, banking the savings to fund a digital transformation on their timeline. You might even create a fund with the saved money to invest in innovation (since one criticism from vendors is “if you cut support, you won’t be investing in new capabilities” – you can counter that by investing the savings smartly).

Shelfware, Indirect Access, and Audit Risk After Switching

In this section, we explore three interrelated issues often discussed when considering third-party support: shelfware licensing, indirect access, and license audit risk.

These are areas of potential risk or opportunity that require special attention post-switch.

Shelfware Licensing

“Shelfware” refers to purchased software licenses that sit unused (on the shelf). In an SAP context, companies often had more user or module licenses than deployed, yet they paid annual maintenance on the entire lot.

After moving to third-party support:

• Cost Relief: As noted, you stop paying maintenance on shelfware immediately. This is a positive – you’re no longer throwing money at unused licenses yearly.
• License Retention: You still own those shelfware licenses (assuming you didn’t formally terminate them). They remain part of your perpetual rights. If you need to start using some of that shelfware (e.g., you suddenly need to give access to an additional 50 users that you had licensed but never used), you can deploy them without needing to buy new licenses. Under SAP support, you could do the same without extra cost (since you already paid maintenance on them). Now, under third-party, you can also use them with no additional fee to SAP – one could argue it’s even better because you weren’t paying maintenance on them in the interim. Important: If you start using previously unused licenses, document it carefully to remain compliant (you’re allowed since you bought them, but if an audit comes, you must show those licenses in your entitlement).
• Termination vs. Preservation: Some companies formally terminate unused licenses when leaving SAP (to possibly get a smaller SAP support bill on any remaining items or to signal a clean break). Terminating means you give up those licenses entirely. Unless there is a clear reason to (like it was required to end the contract), you might not want to terminate; let the contract lapse. That way, the licenses are “inactive,” but they are still yours. There’s also a scenario: if you think you might sell those licenses to a third party (in regions where secondary markets are legal), keeping them could have resale value. In Europe, there’s a precedent for reselling used software. SAP licenses are typically non-transferable by contract, but European law has sometimes allowed it for other software. It’s complex and uncommon with SAP, but theoretically, shelfware could be an asset, not a liability.
• Maintenance of Unused Components: One consideration: third-party support agreements often let you choose which systems or products to cover. If you have shelfware that truly isn’t used in production (say, a module you aren’t using at all), you might not include it in the scope of the third-party support to reduce their fee. Be careful, though – if it’s not covered and you later start using it, you’d likely need to add it to the support scope (possibly at additional cost). Align what you tell the provider with your actual usage plans.

In summary, shelfware becomes a more neutral factor after switching: it no longer costs you money annually and gives you a little flexibility for future use.

Just manage it consciously – know what you have licensed versus what you use, so you don’t accidentally overshoot your rights, believing a shelfware license was available when it wasn’t.

Indirect Access Risks

Indirect access (indirect usage) is one of the trickiest areas of SAP licensing. It refers to scenarios where users or systems that aren’t directly logging into SAP still pull data from or push data into SAP, potentially requiring SAP licenses.

SAP has pursued license fees for this in several high-profile cases (e.g., the SAP v. Diageo case in 2017 spotlighted this issue).

How does moving to third-party support affect indirect access risk?

• Risk Remains the Same: Fundamentally, your risk of indirect access charges is determined by how you’ve architected your systems, not by who supports your software. Whether SAP or a third party supports the system, if you integrate a non-SAP system in a way that accesses SAP data without proper licensing, you’re non-compliant. So, the risk in terms of entitlement doesn’t increase simply because you switched support.
• SAP Auditing Focus: That said, there’s a perception that SAP might scrutinize indirect usage more closely if you’re not paying them maintenance. Indirect access has been a revenue lever for SAP, even for customers on support; SAP has used audits to charge for this. Some industry observers suggest that once a customer leaves SAP support, SAP could be more aggressive in auditing indirect usage to recoup revenue. In practice, SAP can audit any customer, and many say audits are inevitable for all. It’s hard to prove if off-support customers get audited more frequently since SAP doesn’t publish that data. Regardless, you should assume an audit will examine indirect usage.
• Mitigation Strategies: Before and after switching, take steps to mitigate indirect access exposure:
  • Consider adopting SAP’s Digital Access license model if it’s beneficial. Digital Access licenses SAP-defined document types (sales orders, invoices, etc.) are created indirectly rather than requiring a named user for every external user. At one point, SAP offered some incentives for customers to switch to this model. If you have it, ensure you understand how many documents you create. If you don’t, you likely still need named user licenses for any external access (which is a grey area – SAP often argues that any system or person using SAP indirectly should have a named user license).
  • Work with licensing experts (either internal or third-party consultants) to review each integration. Tools can monitor RFC connections, API calls, etc., to determine indirect usage volumes.
  • Suppose you find problematic indirect use (say a supplier portal that reads SAP data, but none of those suppliers have licenses). In that case, you have a few options: reduce or eliminate that integration, license it properly (maybe buying a lighter license type for those users if available), or ring-fence it (some companies put a buffer database so that external systems hit a copy of SAP data, not SAP itself – SAP has signaled “static read” access like that might not require a license, though interpretations vary).
  • Third-party support providers often offer advisory services on indirect access (for example, some have whitepapers on how to handle it). They may also guide you on contract language if you still have any negotiations with SAP or how to mitigate exposure technically.
• No Vendor Fixes Required: One relief is that indirect access is not a “bug” or something SAP would fix via support – it’s purely a licensing construct. So you’re not missing any SAP support help here. It’s all on the license management side, which you handle regardless of who supports the system.

Audit Risk and Management

The risk of a software audit tends to loom over any decision to leave vendor support. Vendors know that audits can uncover compliance issues that lead to revenue (in license purchases or penalties), and they have the right to audit per contract.

Let’s break down the audit situation:

• Audit Likelihood: Many in the industry say that SAP audits customers roughly every 2-3 years on average. If you have been a long-time SAP customer and have never been audited, consider yourself lucky and not immune. Once you move to third-party support, you might expect SAP to eventually initiate an audit if they haven’t recently. Some third-party support users report they were audited soon after switching; others have not seen an audit for years. It likely depends on SAP’s internal criteria. Being off maintenance could put you on a list, or SAP might focus audits more on customers who show signs of expansion or who refuse to migrate to new products.
• Preparing for the Worst: The best strategy is to assume an audit will happen and prepare as if it’s imminent. That means:
  • Run SAP’s license measurement programs (USMM, LAW) just as SAP would, and see the results. This shows how many users of each type are assigned, how many engines are consumed, etc. Clean up unnecessary user assignments (to reduce license counts).
  • Document any surplus licenses you have that cover any usage. If an auditor finds 100 extra users assigned and you indeed own 100 spare licenses, being able to immediately show that will close the issue.
  • Address any shortfalls proactively. If you discover, for example, that your HR self-service portal inadvertently lets 500 employees do something that technically needs an ESS user license. You only have 300 licensed, you have 200 unlicensed users. It may be cheaper to correct that now (either by buying more licenses from SAP before an audit when you have negotiating leverage or by restricting that access) than to be caught later.
  • Keep all relevant proof of licenses. When off support, SAP’s records might not be as meticulously updated about your entitlements (especially if you terminated some). You should maintain your archive of contracts, order forms, receipts, etc.
• Audit Process without SAP Support: Normally, during an audit for a current customer, SAP’s sales/account team might work with you to resolve findings, perhaps bundling a resolution as part of a new purchase or cloud deal (for example, forgiving some fees if you agree to a new contract). If you’re not a support customer, SAP has less incentive to be lenient – they might escalate quicker. In worst cases, if negotiations break down, SAP could invoke legal action to enforce compliance (though that’s rare; typically, it gets resolved commercially). Always engage your legal counsel and possibly a licensing expert firm when facing an audit demand. They can help ensure SAP strictly follows the contractual audit clause (for instance, scope and frequency – you can push back if SAP tries to audit too frequently or beyond the agreed scope).
• Using Third-Party Expertise: Interestingly, some third-party support vendors offer help with audits as part of their service or add-on services (since it’s in their interest that you stay compliant and happy). For example, they might do an annual license compliance review for you or guide an audit response. Rimini Street even has a “License Advisory Services” group to help customers navigate audits. This can be a valuable support, effectively replacing what you might have gotten from SAP’s license team (though SAP’s team’s job was to drive sales, not truly help you optimize). If provided, take advantage of these services – they can alert you to common audit “gotchas” (like engine metrics miscounting or users with multiple IDs causing double counting).
• Audit Frequency Post-Switch: One myth (sometimes spread by vendors) is “If you switch to third-party support, you will automatically get audited.” Some third-party providers refute this, saying an audit is just as likely if you stay. The truth is probably between the two: being off support might slightly increase focus, but any customer is fair game. So, do not let fear of audit deter you if everything else points to third-party support being beneficial – mitigate that risk by being prepared.

In summary, shelfware, indirect access, and audits are manageable issues. Shelfware becomes less of a cost concern after switching (a benefit), indirect access remains a licensing management point (neutral if handled properly), and audit risk can be mitigated by strong compliance discipline (with a possibility that SAP will come knocking, but that’s something you can handle with preparation and possibly outside help).

How Third-Party Support Providers Operate (Rimini Street, Spinnaker, etc.)

Now, let’s look at who these third-party providers are and how they deliver support. Rimini Street and Spinnaker Support are two of the most prominent companies in this space.

Still, there are others (e.g., Support Revolution, US-based firms like Hypercare, smaller regional providers, etc.). Understanding their business model and approach will help in assessing the switch.

Rimini Street

Rimini Street is the largest and best-known third-party support provider, supporting not just SAP but also Oracle, PeopleSoft, JD Edwards, and other enterprise software.

Key points about Rimini Street:

• Experience and Scale: Founded in 2005, Rimini Street pioneered third-party enterprise support. It is now a publicly traded company with a large global client base. Rimini claims to have hundreds of SAP clients and thousands of clients overall. Their scale means they have dedicated teams for each major product line (SAP, Oracle, etc.) and different regions.
• Services Offered: For SAP customers, Rimini Street supports SAP ECC, S/4HANA (on-prem), BusinessObjects, SAP BW, SAP CRM, SCM, and even the SAP HANA database. They also support the underlying technology stack (e.g., if your SAP runs on Oracle DB or Windows OS, they will help with issues that span those layers). Rimini’s support includes break-fix problem resolution, performance tuning, configuration help, and advisory services on interoperability. They emphasize supporting custom code – something SAP standard support doesn’t do (SAP usually tells you to reproduce the issue on vanilla code). Rimini will debug your custom ABAP if that’s causing a problem.
• Tax and Regulatory Updates: Rimini Street has a well-established process for delivering regulatory updates (for example, payroll tax changes for SAP HCM or financial compliance changes). They have a global compliance research team that monitors updates in over 200 countries. Clients receive these updates as part of the service, often delivered as custom transport files or manual instructions to implement in the SAP system. For instance, if a new tax law is effective next quarter, Rimini would issue a bulletin and an update package to ensure your SAP system reflects that law in its calculations/reports, just like SAP would via a support note.
• Support Model: Rimini touts an ultra-responsive model. They assign a Primary Support Engineer (PSE) to each client – a named individual with usually 10- 15+ years of SAP experience. This PSE is accountable for your issues end-to-end. They provide 24/7 support for critical issues with a 15-minute response SLA for Priority 1 cases. Many customers cite that one big improvement is not having to explain their landscape from scratch each time (as they often feel with SAP’s rotating support agents); Rimini’s engineer already knows their environment.
• Legal/Compliance Stance: Rimini is very cognizant of legal boundaries, given its history. They no longer, for example, download SAP support materials on behalf of customers (in the Oracle case, one issue was using customer credentials to fetch Oracle patches—now they avoid anything that could be construed as improper access). Instead, if a needed patch exists, they might guide the customer to use a right they have (if any), or more commonly, they create an alternative solution. Rimini’s contract includes indemnifying customers against IP claims, meaning if SAP tried to sue the customer for using Rimini’s services, Rimini would defend it. It’s worth asking for details of this indemnity and any limitations.
• Notable Metrics: Rimini cites metrics like average response time, client satisfaction ratings, etc. They often claim to resolve issues that the vendor had not and extend the software’s life by 15+ years beyond vendor support. Being a large company, they have significant R&D, security, and interoperability labs (e.g., they test SAP on new OS or third-party products to ensure client compatibility, something SAP might not do once the product is out of mainstream support).

Spinnaker Support

Spinnaker Support is another leading third-party provider, somewhat smaller than Rimini but well-regarded:

• Background: Spinnaker Support started around 2008. It initially focused on JD Edwards (Oracle) and later expanded to SAP and Oracle E-Business Suite. Spinnaker Support is a privately held company that emphasizes high-touch service and has a global presence (headquartered in the US, with offices in Europe and Asia).
• Services: Spinnaker offers SAP support for ECC, S/4HANA, Business Suite components, BusinessObjects, NetWeaver, and even Sybase databases (SAP ASE), among others. They also have a cybersecurity service component (advertising proactive security monitoring and solutions as part of their support). Like Rimini, they handle tax/legal updates worldwide and support custom code.
• Operation Model: Spinnaker’s model is also to provide named support engineers and a team that understands your environment. They often align resources by region – for example, a European customer might have support delivered out of their EMEA team for familiarity with local issues. Their SLAs are comparable (24/7 coverage for critical issues, etc.). One differentiator Spinnaker sometimes highlights is flexibility and a customer-specific approach, given that they are smaller than Rimini. Some customers choose Spinnaker if they want a more boutique experience or have had a good relationship with their team.
• Audit Advisory: Spinnaker has openly discussed that customers must be compliant and often provides guidance on navigating license issues. For instance, one of their VPs, as seen in the media, reminds customers about giving SAP notice to terminate and being prepared for SAP’s moves. They position themselves as a break-fix support entity and a partner in overall SAP strategy while you’re with them.
• Legal: Spinnaker has not been in high-profile legal battles like Rimini, which some view as a positive (less baggage). They appear to have operated more under the radar in that sense. But they, too, likely provide indemnification and careful processes. When evaluating, ask them about any disputes with SAP or how they ensure no IP infringement.
• Customer Base: Spinnaker has hundreds of customers (exact numbers aren’t always public). They have case studies of various sizes, including large enterprises and public sector clients. It’s useful to ask them for a reference in your industry to get comfort.

Other Providers

While Rimini and Spinnaker dominate a lot of the mindshare, other third-party support providers include:

• Support Revolution: UK-based firm providing Oracle and SAP third-party support. They often target EMEA customers, highlight their UK data centers, and perhaps offer a more cost-competitive option. They also publish educational content (for example, debunking myths around third-party support).
• UrbanFootprint (formerly TomorrowNow): Actually, TomorrowNow ceased after the Oracle lawsuit, so scratch that—it’s not current.
• Various Niche Firms: Some SAP consulting firms offer “extended support” services that mimic third-party support on a smaller scale, particularly for local markets or specific SAP products. For example, a firm might specialize in supporting SAP Business One or older SAP R/3 systems for certain regions. Always vet their capabilities; smaller providers might not cover global regulatory updates as comprehensively.
• In-House as a Service: A few large companies have essentially built internal support teams and offered that model to peers (though not common). Generally, most will go with a professional firm like the above rather than rely on informal networks.

How They Address Common Issues

It might be helpful to illustrate how a third-party provider handles typical support scenarios compared to SAP:

• Example 1: Bug Fix – Suppose a batch job in SAP ECC fails due to a suspected bug in standard SAP code. Under SAP support, you’d file a ticket, maybe get a workaround or a confirmation of a bug, and wait for SAP to issue a correction note (which might take days or weeks or be in the next support pack). Under a third-party provider, you file a ticket with them; their engineer debugs the issue in your system (with your permission). They might already have a fixed script if it’s a known issue. If not, they may modify the code or devise a configuration change to resolve it. They give you that fix directly (since you are allowed to modify your own SAP code – the SAP license allows customer modifications). You implement the fix immediately rather than waiting for SAP’s next patch. The provider then documents it for the future if another client hits it.
• Example 2: How-to or Configuration Help – SAP standard support is sometimes criticized for not helping “how do I do X” questions; they tend to focus on break-fix. Third-party support is often more lenient in answering usage questions. For instance, if you ask, “We need to reconfigure our procurement workflow – can you advise?” a third-party engineer may guide you or provide best practices, effectively doing some consulting as part of support. That adds value for many customers (it’s like having an expert on call).
• Example 3: Performance Issue—If an SAP program is running slowly, SAP support might say “Consulting required” if it’s not a clear bug. Third-party providers, however, often analyze performance (SQL traces, etc.) and suggest tuning (like adding an index or adjusting a parameter) as part of support. Their marketing often highlights this proactive help.
• Example 4: Custom Modification – Let’s say you modified the SAP sales order screen with custom code and now after an upgrade (back when you were on SAP support) it doesn’t work properly. SAP would say they don’t support custom code; you must troubleshoot yourself or hire a consultant. A third-party support engineer will debug that custom code alongside the standard and help you fix it. They “own the problem” holistically. This is a big cultural difference in the support approach.

Providers and SAP’s Reaction

SAP is aware of these third-party providers. Over the years, SAP’s public stance has been relatively muted (compared to Oracle, which actively attacked Rimini Street). SAP has warned customers that third-party support could leave them unsupported for innovation and that only SAP can fully support their product.

But legally, SAP couldn’t shut them down. SAP’s more effective tactic to combat third-party support has pushed customers toward cloud/subscription models (like RISE with SAP) where third-party support isn’t possible, or offering incentives to stay (like slight discounts or flexible terms if the customer considers leaving).

Some customers have even used the possibility of third-party support as a bargaining chip with SAP—informing SAP that they might leave can sometimes bring SAP to the table with a better maintenance deal or added-value services.

Recommendations

Switching from SAP’s maintenance to third-party support is a major decision that should be carefully planned.

Here are clear, actionable recommendations for organizations considering or implementing this move:

• 1. Assess Your SAP Roadmap and Strategy: Look hard at your plans with SAP before deciding. If you are committed to migrating to S/4HANA or other SAP cloud products in the next 1-2 years, stay with SAP support until after that transition (since SAP will support you through it, and you’ll need upgrade support). However, if your strategy is to stay on current systems for 3+ years or you’re uncertain about SAP’s future in your landscape, third-party support can be a bridge. Ensure the move aligns with your IT roadmap and business goals. For example, if digital transformation for you means possibly replacing some SAP modules with best-of-breed systems, third-party support can give you breathing room to execute that plan cost-effectively.
• 2. Get a Precise Inventory of Licenses and Usage: Conduct a thorough SAP license audit internally (or with a consultant) before you notify SAP of anything. You need to know what you own (licenses, user types, engines) and what you’re using in reality. Reconcile these to identify any compliance gaps or surplus (shelfware). This knowledge is power – if you are short on licenses, you may quietly purchase additional licenses from SAP. At the same time, you’re still a customer (possibly negotiating a deal) to true-up before leaving. Fixing compliance issues while in an active relationship is often easier than during a hostile audit later. Conversely, identify shelfware that you won’t use; consider terminating those licenses from your contract if SAP allows (potentially lowering any last maintenance bill or having a cleaner situation). The bottom line is to go into the switch knowing your compliance position so there are no surprises.
• 3. Engage with SAP (if beneficial) to Negotiate Options: It can be wise to have an open dialogue with SAP before sending a cancellation notice. Some customers leverage the threat of third-party support to negotiate concessions. For instance, approach SAP saying you are evaluating third-party support due to cost – SAP might offer a discount, a flexible partial termination, or a different support tier (SAP does have a “Customer-Specific Maintenance” or lower-tier support options in some cases) to retain you. In the best case, SAP reduces your costs enough or adds enough value so that you can stay. In the worst case, they don’t budge, and you proceed to leave, but at least you tried. Be careful with timing: do this well before your notice deadline. And only reveal what you’re comfortable revealing; some customers keep it confidential, such as the third party they’re talking to, etc. Note that once you serve notice of termination, SAP’s sales teams may escalate their efforts either to win you back or to plan an audit, so controlling the narrative earlier can be beneficial.
• 4. Choose the Right Third-Party Provider: Not all third-party support vendors are equal. Issue an RFP or at least have deep discussions with a couple of providers (e.g., Rimini Street and Spinnaker Support at minimum) to compare offerings. Key criteria to evaluate:
  • Experience with Your SAP Products: Do they support all your SAP components? Ask for client references in your industry or using similar SAP modules.
  • Regulatory Coverage: If you operate in multiple countries or have industry-specific compliance needs (e.g., FDA compliance in pharma, SOX in finance), how will they ensure you remain compliant? Can they give examples of regulatory updates they delivered for clients?
  • Service Levels: Review their SLAs and make sure they have 24/7 coverage if you need it. Ask how they handle critical emergencies. Do they have a local presence or at least overlap with your business hours?
  • Transition Plan: A good provider should outline how they will onboard you. This includes learning your systems and documentation, picking up any pending issues from SAP, etc. A well-managed transition means you’re not in the dark on day 1, after SAP support ends.
  • Security and IP Practices: Have them explain how they obtain patches or fixes. Ensure they have policies to protect your systems and data. Also, ensure their support contract covers you if legal issues arise (indemnification).
  • Pricing: Of course, compare costs. But don’t just go for the cheapest; support quality is paramount because a major system outage can cost far more than you save. That said, negotiate the price as well – there may be wiggle room, especially if competing providers are bidding.
  • Flexibility: For example, if you divest a division and need to drop support for part of the landscape, can you adjust the contract? Or if you acquire another company running SAP, can they onboard those systems mid-term?
• 5. Time Your Exit Carefully: Align the end of SAP support with the start of third-party support to avoid gaps. Typically, you will schedule the third-party contract to begin the day after your SAP support expires. Ensure all internal stakeholders know the date – after that day, they should no longer contact SAP or apply SAP patches. Also, plan it for a low-risk period if possible (not during your peak season or just before a critical year-end close, for example). Many choose to have the switchover at the end of their fiscal year or quarter when the SAP contract naturally renews. Additionally, inform your internal helpdesk and users that from that point, support calls go to the new provider (some education might be needed so that nobody inadvertently files an SAP support ticket that goes unanswered).
• 6. Archive SAP Resources and Knowledge: Before contract end, download and save all relevant SAP documentation, notes, and patches for your system. Also, consider printing or saving any usage of SAP support tools that might go away (like SolMan data, Early Watch Alert history, etc.). If there are any SAP OSS notes that you think you might need (even if not implemented yet), it’s safer to download them now. Your third-party provider cannot directly use SAP’s proprietary fixes if you’re off support, but having them as the reference can be useful internally. Moreover, ensure your team has soft copies of all SAP training or config guides that are only accessible via SAP sites. Build an internal knowledge base of SAP materials before the door closes. Your new provider will also bring a lot of knowledge, but it doesn’t hurt to have SAP’s official manuals on hand.
• 7. Maintain Rigor in Change Management and Testing: Once on third-party support, you will still be getting fixes and updates (just from a different source). Treat these with the same (or greater) level of testing and governance as SAP patches. Your provider will give you code corrections or instructions, run them in a QA system, test the hell out of them, and only then move to production. This is no different than applying SAP notes, but teams should not slack psychologically because “it’s a trusted vendor fix.” Also, keep a log of all changes applied. This discipline will help in audits or if you ever transition to another solution.
• 8. Stay Informed and Engaged with the Provider: Manage the relationship with the third-party provider actively. Hold regular review meetings (monthly or quarterly) to discuss ticket metrics, upcoming regulatory changes, or any concerns. Treat them as a strategic partner, not just a vendor. Provide feedback on their support quality so they can adjust. The goal is to ensure you get the most value – remember, you left SAP for better/cheaper support, so demand excellence. Most providers aim for high customer satisfaction because references are crucial for them.
• 9. Continue License Compliance Efforts: We cannot stress this enough – keep an eagle eye on your SAP license compliance after switching. Implement a formal SAM program for SAP if you don’t have one. Do periodic mock audits. If your company’s compliance team or internal audit can help, involve them in periodically reviewing SAP usage. Being on third-party support is not a “get-out-of-jail-free” card for license rules. If anything, you want to be even more buttoned-up to avoid confrontation with SAP. If your provider offers a license advisory service, use it. Some might conduct annual usage reviews as part of their offering.
• 10. Plan for the Long Term: Third-party support can be an indefinite solution – some companies plan to stay on it until their SAP system is eventually decommissioned (perhaps in 10+ years). Others see it as a “maintenance vacation” for a few years to save money and then re-engage with SAP for a new product (like a fresh S/4 implementation or a different ERP). Either way, have a long-term plan. If indefinite, ensure you’re investing some savings into modernizing around the edges (e.g., maybe implement new analytics tools or an e-commerce platform that uses SAP in the back end – you can do that as long as you license properly). If it’s a temporary hiatus, keep assessing the market and SAP’s offerings. The tech world changes fast; maybe in 5 years, SAP’s cloud ERP will be more compelling, or a new vendor might be more suitable. Use the flexibility and savings you gain now to position your organization for that future decision.
• 11. Monitor SAP’s Policies: Keep an eye on any changes SAP makes to licensing or support policies that might affect you. Even though you’re not a current support customer, SAP might announce amnesty programs (e.g., some indirect access resolution initiative or a new licensing metric) that could be beneficial. Also, if SAP were to change its reinstatement policy or offer a path back, you’d want to know. You might connect via the SAP user groups (like ASUG or DSAG) or industry forums to stay informed. Third-party support doesn’t mean you exit the SAP ecosystem entirely; you still run SAP software, so staying informed is wise.
• 12. Document Everything: Finally, maintain thorough documentation of the transition: the end of the support letter from SAP, the start of the third-party contract, any communication with SAP about terminating, any pre-termination license purchases, etc. This paper trail can be vital if any disputes arise later (for example, if SAP tries to claim you owe maintenance beyond the termination date, you have proof of notice given, etc.). Also, document the baseline of your system at switch time (versions, patch levels) so it’s clear what state was “fully licensed and supported” at the moment of transition. This can help if there’s any question of what you were entitled to use later.

By following these recommendations, enterprises can significantly de-risk the move to third-party support and maximize the benefits.

Many companies have successfully made this transition, saving money and continuing to run their SAP systems effectively. It requires due diligence and ongoing management, but it can be very strategic when executed properly.