Managing SAP Licensing During Mergers, Acquisitions, and Divestitures

Managing SAP Licensing During Mergers, Acquisitions, and Divestitures

Introduction

Mergers, acquisitions, and divestitures (M&A) can profoundly impact a company’s SAP licensing landscape.

In the rush to combine or separate businesses, software asset managers (SAMs) and SAP licensing professionals must ensure that SAP license agreements keep pace with corporate changes. Mismanaging licenses during M&A can lead to compliance violations, unexpected costs, or service disruptions.

This advisory article provides a comprehensive guide to handling SAP licenses in these scenarios, covering on-premise perpetual licenses (e.g., SAP ECC or S/4HANA on-premise) as well as cloud subscriptions (S/4HANA Cloud, RISE with SAP, SuccessFactors, Ariba, Concur, Fieldglass, etc.).

It explains SAP’s strict rules on license transfers, provides strategies for planning, and outlines pitfalls to avoid, all to empower customers to navigate M&A events without incurring unnecessary costs or risks.

Why It Matters: SAP’s licensing agreements are notoriously complex and usually tied to specific legal entities. When companies merge or split, those agreements don’t automatically adjust. Without proactive management, an otherwise successful M&A deal could face post-transaction headaches, such as having to buy duplicate licenses, losing volume discounts, or even failing an SAP compliance audit.

The good news is that with careful planning and negotiation, organizations can turn M&A situations into opportunities (for example, to renegotiate better terms or right-size their SAP investments) rather than allowing them to become costly compliance traps.

In the sections below, we’ll cover how SAP licenses can (and cannot) be transferred or combined, SAP’s standard positions on these matters, and best practices for SAM and procurement teams.

We’ll address both divestiture scenarios (spinning off or selling a business unit) and merger scenarios (combining organizations, whether both use SAP or not). Real-world examples, tables, and actionable tips are included to illustrate the risks and the negotiation opportunities available.

SAP’s Non-Transferability Rule and Its Impact

One fundamental principle to understand is that SAP licenses are generally non-transferable without SAP’s consent. SAP’s standard contracts contain strict assignment clauses preventing customers from assigning or transferring licenses to another entity without prior written approval from SAP.

In practical terms, this means that if you attempt to move SAP software rights from one company to another (such as to a spun-off entity or an acquiring company), you must involve SAP and likely negotiate new terms.

Key points about SAP’s license transfer restrictions:

• Perpetual On-Premise Licenses: These licenses are sold to a specific “Licensee” (your company, often defined to include majority-owned affiliates). By default, they cannot be sold, given, or assigned to a different company. Even in an internal reorganization or spin-off, splitting licenses between entities is not allowed unless SAP agrees. The original licensee remains the only party authorized to use the software, so a divested business that is no longer under the original licensee’s control would no longer have rights to use that SAP software.
• Cloud Subscriptions: SAP’s cloud services (SuccessFactors, Ariba, Concur, etc.) are contracted on a per-subscribing-entity basis and cannot be split or transferred without consent. Each subscription agreement is tied to a legal entity or its affiliates. If part of the business leaves, those users typically can’t simply continue using the service under the old contract. There is no concept of “partial assignment” of a cloud subscription. Instead, the separated entity would need its contract or a formal novation of the subscription to its name, subject to SAP approval.
• SAP Consent Requirement: If a company undergoing divestiture wants to transfer licenses to the new entity (or if an acquiring company wants to take over the acquired company’s SAP licenses), SAP’s approval is required in nearly all cases. Without explicit permission (usually documented through a contract amendment or new agreement), continuing to use SAP software in the new entity constitutes a breach of the license terms. SAP has enforced this by requiring companies to relicense software after an M&A, or risk compliance penalties. In essence, SAP uses contractual language to maintain control – you cannot assume that licenses “travel” from seller to buyer without SAP’s approval.

Example: A large manufacturer sold off one of its divisions to a private equity firm. The division had been using the parent company’s SAP ECC system. Post-closing, that division (now an independent company) kept accessing SAP, assuming the existing licenses covered them. In reality, once the divestiture closed, the division was no longer an affiliate of the original licensee, so it had no legal right to use the SAP software. SAP later audited the situation and determined that all usage by the new company was unlicensed. The result: the new company had to urgently purchase its own SAP license, and the parent company was technically in breach for “providing” access without SAP’s consent. This scenario could have been avoided by planning for license transfer or obtaining a temporary use agreement with SAP during the transition period.

The non-transferability rule is SAP’s standard position, but there are strategies to manage it in M&A events, as we will explore. First, let’s delve into divestitures and carve-outs, where this issue often comes up acutely.

Handling SAP Licensing in Divestitures and Spin-Offs

Divestitures (the sale or spin-off of a business unit or subsidiary) present a major licensing challenge: part of the organization will split off and form a new legal entity. If the original company (let’s call it ParentCo) has SAP licenses, can some of those licenses be transferred to the new entity (SpinCo)?

The default answer under SAP’s rules is “no, not without permission.” SpinCo cannot simply continue using SAP under ParentCo’s license unless certain steps are taken.

Licenses and Contract Implications for a Spin-Off

When a business unit using SAP is carved out, there are a few possibilities:

• SpinCo remains an affiliate of ParentCo: In some cases (e.g., a partial spin-off where ParentCo retains >50% ownership of SpinCo), SpinCo might still be considered an affiliate under ParentCo’s SAP contract. If the contract permits affiliate use, SpinCo could temporarily continue using the SAP system as a parent company affiliate. However, this is a temporary fix – usually the intent of a spin-off is full separation, and affiliate status (and thus shared use rights) may end after a transition period or further equity sell-down. Once SpinCo is no longer majority-owned by ParentCo, it ceases to be covered by ParentCo’s license rights. At that point, SpinCo needs its licenses.
• SpinCo is fully separated (no controlling stake retained): This is the common scenario in a divestiture – SpinCo becomes an independent or buyer-owned company. Under standard SAP contracts, all SAP rights remain with ParentCo (the original licensee) and do not automatically transfer to SpinCo. SpinCo must obtain new SAP licenses to legally run SAP software for its operations, unless it negotiates a different outcome. From SAP’s perspective, SpinCo is a brand-new customer. Even if SpinCo “inherited” servers or systems with SAP installed, it has no right to use them without a license in its name. This often comes as a surprise to business leaders, since they feel they “bought that part of the business, including its systems.” But without contractual transfer rights, SpinCo and ParentCo have to engage SAP to sort out licensing.
• Partial license reuse via consent: In limited cases, companies negotiate upfront (in the original license agreement) the right to assign or transfer certain licenses to a divested entity. If ParentCo had included a carve-out clause allowing the transfer of licenses in the event of a spin-off, then SpinCo could receive those licenses with SAP’s blessing, per the agreed-upon terms. Absent that, any transfer will require going back to SAP for consent, which usually involves fees or new purchase requirements. SAP may allow a one-time partial assignment as part of a settlement, but they typically prefer to sign a new contract with SpinCo.

The outcome of a divestiture of SAP licensing thus tends to be one of two options: SpinCo buys new licenses or SpinCo uses ParentCo’s licenses temporarily under a services arrangement until it purchases new licenses. Both have cost implications. We’ll discuss strategies to mitigate these costs next.

Negotiating Carve-Out and License Assignment Rights Upfront

The best time to address divestiture licensing issues is before they occur, when negotiating your original SAP contract or any renewal or extension. If your organization even remotely anticipates a possible future spin-off or sale, you should seek contractual provisions that protect you in that scenario.

Two key protections are:

• Transfer/Assignment Rights for Divestiture: Include a clause that explicitly allows the assignment of licenses or a portion of the agreement to a newly formed or divested entity. For example, language that says if a division is sold, the licenses proportional to that division’s usage can be transferred to the new owner, provided notice is given to SAP. SAP may be reluctant to agree, but large customers or those using strategic negotiation leverage have obtained such clauses. Even a narrow provision (e.g., one-time transfer of up to X users to a divested entity) is extremely valuable should a spin-off occur. It ensures the divested business can continue using SAP without an immediate repurchase. It also spares the parent from holding “shelfware” licenses it no longer needs.
• Carve-Out & Transition Use Clauses: At a minimum, negotiate a Transitional Use clause (sometimes called a “divested entity provision”) that allows the parent to continue providing SAP system access to the divested unit for a defined period after separation. This effectively legalizes the Transitional Services Agreement (TSA) period from a licensing perspective. For example, the contract might allow that “in the event of a divestiture, an entity that was formerly an affiliate may continue to use the SAP software for up to 12 months while operating under a TSA with the customer.” This gives the new entity time to get set up with its systems. Without this clause, the moment SpinCo is no longer part of ParentCo, any access ParentCo provides to SAP could be considered unlicensed third-party use. Including this carve-out for a temporary period avoids having to rush into a new SAP deal under duress.

Note: One legal advisory suggests it’s a “good idea to include a divested entity provision” in software contracts to allow limited TSA use by a spun-off entity, saving time and avoiding the need to obtain emergency consents​. Key terms to define are the scope of use (what systems can be used, by whom) and the duration of allowed use (e.g. 6, 12, 18 months) for the divested entity. Also clarify if any fees apply for this interim use and ensure the divested entity agrees to the original contract terms during the period. These details, if ironed out upfront, can significantly smooth a future separation.

If you missed the chance to negotiate these upfront, you still have options. You can try to amend your SAP contract proactively, once a spin-off is on the horizon (or as part of any contract renewal), to insert these rights.

This might involve some give-and-take with SAP (they may ask for a fee or a license purchase to grant it), but the cost could be far lower than an unplanned new implementation for SpinCo later on. It’s all about planning for corporate flexibility – something many companies overlook until they’re in the middle of a divestiture.

Temporary Solutions: TSAs and Partner-Hosted SAP Environments

No matter how well you plan, there’s often a transition period during which SpinCo is not fully independent in IT. Transitional Service Agreements are common, where ParentCo agrees to keep providing certain systems and services to SpinCo for a limited time after the separation.

With SAP systems, this means ParentCo might continue to operate the SAP environment and allow SpinCo’s employees to use it until SpinCo can migrate to its system. This raises the licensing issue: ParentCo’s SAP contract typically doesn’t automatically cover an entity that has been sold off.

Without proper arrangements, both ParentCo and SpinCo are at risk – ParentCo for providing unlicensed access and SpinCo for using SAP without a license​.

To handle this, there are a couple of approaches:

• Obtain SAP’s consent for TSA Use: Work with SAP to obtain a formal agreement allowing SpinCo’s use during the transition. SAP may issue a temporary license or amend ParentCo’s contract for the TSA period. Be aware that SAP may charge for this privilege. Some customers negotiate a fee for the extended use of licenses by the divested unit. It’s often cheaper than full re-licensing and buys time. This needs to be negotiated at or before closing the divestiture deal to avoid any legal gaps. If you have a pre-negotiated TSA clause, as discussed, this step is simpler: just notify SAP and follow the contract terms. If not, it may become an urgent negotiation when the deal is underway, which is not ideal for getting favorable terms.
• Use a Partner or SAP-Hosted Solution: Another tactic is to temporarily move the divested operations onto an SAP partner’s infrastructure. SAP has programs like SAP Partner Managed Cloud and SAP HANA Enterprise Cloud (HEC) where either a certified partner or SAP itself hosts the software and can effectively “lease” licenses as part of the service. For example, SpinCo might sign a short-term agreement with an SAP hosting partner to run an instance of SAP for its business. The partner, in theory, provides the necessary SAP licenses under their agreement with SAP, while SpinCo pays a subscription or hosting fee. This can act as a bridge if SpinCo needs a year or two before deciding on a long-term ERP solution. It avoids a rushed purchase of a perpetual license by using a subscription model to cover the interim. Caution: These arrangements must be carefully vetted – ensure SAP authorizes the partner and that the scope covers all required usage. Essentially, this is like outsourcing the SAP system during transition. It can be more costly month-to-month than owning licenses, but it offloads compliance to the provider for that period. SAP’s own HEC or RISE with SAP offerings could also be options, converting the environment into an SAP-managed cloud contract, which SpinCo can later take over.

The takeaway is that during the separation phase, do not allow shared system use to occur without a formal agreement or alternate licensing in place. It might be tempting, for simplicity, to let SpinCo continue logging into the same SAP system for a while.

But remember, as soon as SpinCo is a separate company, that access is no longer legally covered by ParentCo’s license. If SAP audits either company, they will quickly discover this. Always cover the transition with a TSA clause, a short-term license extension, or a partner arrangement to remain compliant.

Cloud Subscriptions in a Divestiture (SuccessFactors, Ariba, etc.)

Cloud SaaS products introduce their twist in divestiture scenarios. These products, including SuccessFactors for HR, Ariba for procurement, Concur for travel, and Fieldglass for external labor, are often integrated with the core SAP ERP, but separate subscription agreements govern their use.

Here’s how to handle them:

• New Tenants for New Entities: Typically, cloud services are provisioned on a per-customer basis. If part of your company splits off, that part will need to have its own tenant (instance) of the cloud service. For example, if ParentCo uses SuccessFactors for all employees, after the spin-off, you will likely create a new SuccessFactors instance for SpinCo’s employees. This ensures data separation and gives SpinCo control under a new contract. However, setting up a new tenant means migrating relevant data (such as employee records) and configurations from ParentCo’s system to SpinCo’s, which requires coordination and time.
• Contract Transfer or Re-sign: Can the existing cloud subscription be split or transferred to a new account? Generally not without SAP’s agreement. In some cases, if an entire business unit using the service is sold, SAP may agree to “novate” the contract – essentially swapping out the customer’s name with that of the new owner for that subscription. This might happen, for example, if a whole subsidiary with a distinct SuccessFactors contract is sold; SAP could agree to transfer that contract to the buyer rather than terminating it. But if it’s a shared contract (one environment serving the whole company), you can’t partially novate it. Instead, SpinCo must sign a new subscription for its new tenant. ParentCo might reduce its user count accordingly at the next renewal.
• Duplicate Subscription During Transition: There may be a period when SpinCo’s users continue to access ParentCo’s cloud system (e.g., using ParentCo’s Concur for expense reports) until SpinCo sets up its system. Like the on-prem TSA discussion, the cloud contract probably doesn’t allow providing service to a third party. You should discuss with SAP if a short-term arrangement is needed. Sometimes, the simplest path is to accelerate SpinCo’s contract and tenant acquisition and cut over as soon as possible, to minimize overlap.
• Billing and Term Adjustments: If ParentCo’s subscription user count drops significantly due to the divestiture, be prepared for the resulting financial impact. Many cloud agreements with SAP have minimum terms or volume commitments. For instance, if ParentCo had a 3-year cloud subscription for 10,000 SuccessFactors users and spins off 2,000 of them, it can’t just stop paying for those 2,000 mid-term. Those licenses remain contracted unless SAP agrees to a reduction. Sometimes, customers negotiate at renewal to adjust quantities, but they may lose volume-based discounts by reducing the numbers. The spin-off will be buying a smaller number of users on its own, likely at a higher per-user rate. It’s important to coordinate renewal timings – perhaps align SpinCo’s new contract to start when ParentCo’s current term ends, so that ParentCo doesn’t pay double. Spinco doesn’t pay for something it’s not using. In any case, involve SAP early to work out a plan, as cloud licensing is less flexible in the long term than on-premises licenses.

Practical example (cloud divestiture): A consumer goods company split off a subsidiary that shared the parent’s SuccessFactors instance. To separate, the parent company exported the subsidiary’s HR data and helped implement a new SuccessFactors tenant for the spin-off. SAP allowed the parent to continue administering the former employees on the original system for 3 months post-close under a written arrangement.

By month 4, the new SuccessFactors environment was live under SpinCo’s contract. The parent company reduced its subscription at the next annual renewal from 5,000 to 4,000 users, with SAP adjusting the pricing tier accordingly, which unfortunately resulted in a slight increase in the per-user cost.

The spin-off signed a fresh subscription for 1,000 users at a mid-market rate. Had this not been coordinated, the spin-off risked having no HR system on Day 1 or using the parent’s system without permission.

Risks of Shared SAP Infrastructure After a Split

It’s worth reinforcing the risks if licensing is not handled properly in a divestiture:

• Compliance Audits and Penalties: SAP frequently monitors customer developments like divestitures. Such events are known triggers for SAP to initiate a license audit​. If an audit finds that a divested entity continued to use SAP without its license or outside the bounds of any agreement, SAP can levy back-dated license fees and penalties. They might charge the parent for “illegal use” by the spin-off, or demand the spin-off pay for licenses retroactively. This can sour the post-deal relationship with SAP and result in substantial unplanned costs.
• Ongoing Support Cost for ParentCo: Without a transfer, ParentCo might be stuck with licenses that the spin-off was consuming. ParentCo will continue paying maintenance on those licenses unless it negotiates a reduction. SAP’s policy on maintenance is generally that it’s tied to the license perpetual rights, and reductions are not granted simply because you have excess licenses; you usually have to terminate licenses entirely to stop maintenance, which SAP may or may not allow annually (and often they don’t refund prepaid maintenance). This means ParentCo could pay for unused licenses for years. There have been cases where a parent had to pay millions in support fees for licenses that only the divested unit needed, effectively wasting money, because the contracts prohibited them from dropping them without penalty.
• Divested Company Locked Out: In a worst-case scenario, if no license solution is reached, the divested company could lose access to SAP systems. For instance, if the split was contentious or SAP refused to consent to any continued use, ParentCo might need to immediately cut off SAP’s access to SpinCo at closing to avoid a breach. SpinCo would then face an operational crisis, scrambling to implement a new ERP or revert to manual processes until it procures its own SAP environment. This “cliff edge” situation is rare; companies usually find an interim workaround. Still, it highlights the importance of negotiating transitional IT arrangements in the sale agreement and with SAP.
• Vendor Leverage (“Shakedown”): Unfortunately, software vendors see divestitures as a money-making opportunity. SAP knows that the parent and spin-off are under time pressure to separate their systems, and neither wants business disruption. If your contracts don’t allow what you’re trying to do, SAP can use the threat of non-compliance to push for a lucrative deal (for them). This could mean forcing the spin-off to purchase new licenses at list price, charging the parent a hefty fee to extend system access for a few months, or even bundling the situation into a larger sale (e.g. “We’ll allow this spin-off usage if you commit to buying S/4HANA licenses for both entities”). Being aware of this dynamic allows you to prepare and counter it by leveraging competition (perhaps the spin-off might consider a non-SAP solution) or by involving third-party advisors to negotiate firmly. The next section on recommendations will address how to maintain an upper hand in such talks.

Summary of Divestiture License Outcomes: The following table summarizes what typically happens to SAP licenses in various divestiture scenarios and what actions to take:

With divestitures covered, let’s turn to mergers and acquisitions, where the focus shifts to combining organizations and their respective SAP license pools.

Handling SAP Licensing in Mergers and Acquisitions

Mergers and acquisitions introduce the reverse problem of divestitures: instead of splitting a license estate, you combine two (or more) companies into a single corporate structure. This scenario can take several forms, each with its licensing considerations:

• Two companies that both use SAP merge (or one acquires the other).
• A company that uses SAP acquires one that does not, bringing new users onto the SAP system.
• A company that does not use SAP acquires one that does (the new owner inherits an SAP-dependent operation).
• A larger corporate merger where multiple ERP systems, including SAP, will be rationalized.

M&A can be an opportunity to optimize and even save on licensing, but only if managed shrewdly. It can just as easily be a situation where SAP demands a big check to “blend” contracts or cover expanded use.

Below, we explore these scenarios and guide how to navigate them.

Merging Two SAP Customers: Consolidation vs. Status Quo

If both entities in a merger have SAP licenses, you essentially have duplicate contracts and systems for a while. The end-state vision might be to consolidate onto a single SAP platform (to achieve operational synergies), but this takes time and careful license alignment.

Important considerations when both sides have SAP:

• Combined Use is Not Automatically Allowed: One might think, “Now that we’re one company, we can use each other’s SAP systems freely.” However, SAP’s standard terms prohibit the combined use of licenses across entities that were previously separate customers, unless SAP agrees in writing​. For example, if Company A and Company B merge to form one company, A can’t just let B’s employees start using A’s SAP system with A’s licenses (and vice versa) without addressing the contracts. Each original contract limited use to that original company (and its affiliates at the time). Post-merger, unless one contract is extended or assigned to cover the entire area, using it for the other’s users would violate the agreement. SAP is very strict here: even though your companies are legally merged, from a licensing view, you need to consolidate agreements before consolidating system usage.
• License Agreement Consolidation: You will likely need to negotiate a new, consolidated SAP agreement that covers the merged entity’s future usage. This could take the form of an amendment to one of the existing contracts to add the other entity, or a completely new contract that supersedes both old ones. SAP often prefers a new contract, especially if the merger presents an opportunity to move the customer to newer products or cloud subscriptions. This new agreement will not be free – it may involve the purchase of additional licenses or combining support contracts. The key is to approach this as a negotiation, leveraging the combined entity’s larger scale, rather than just accepting a bill for the sum of two contracts. We’ll cover negotiation strategies in the next subsection.
• Interim Period Operations: Immediately after a merger closes, it may not be feasible to integrate IT systems. Typically, each company continues to use its own SAP environment for some time. During this interim, keep usage separated by legal entity as it was before the merger. This means that Company A’s system is only used by A’s legacy employees, and Company B’s system is used by B’s employees, to stay within each license’s scope. You might interconnect the systems for data transfer, which is usually fine, but avoid any scenario where new cross-use occurs without licenses. If some employees’ roles change and they need access to the other system (common during integration), make sure to count those users against the appropriate license and perhaps purchase extra named-user licenses under that system’s contract if needed (or use one of the contract’s affiliate use provisions if they exist to temporarily cover the new users). Essentially, delay full system integration until you’ve sorted out the contract integration with SAP. If you need to provide cross-access earlier, consult SAP for a temporary solution (similar to a TSA concept but for a merger).
• Retiring Duplicative Licenses: In some merger cases, the combined company may end up with more SAP licenses than needed (e.g., both had licenses for 500 users, but after merging, you may have only 800 total users instead of 1000 due to eliminating redundant roles). Ideally, the new agreement with SAP should account for this efficiency,y so you’re not paying maintenance on excess licenses forever. However, SAP may not willingly credit or cancel licenses just because of a merger. One strategy is to negotiate an enterprise license or a flex agreement that covers all current usage and provides headroom for growth, thereby consolidating duplicates into a single pool. Another approach is to negotiate the termination of one contract’s maintenance in exchange for perhaps purchasing some net-new licenses on the other (a give-and-take deal). Be cautious: simply terminating licenses can be challenging; SAP’s policy typically doesn’t allow dropping licenses without penalty, unless you upgrade to something else. This is where expert negotiators or consultancies often assist, finding a way to optimize the combined entitlements.
• License Metrics and Product Overlap: Commonly, each company’s SAP contract has different metrics or even different bundles of products. One might have SAP ERP user licenses, the other might have an older Business Suite package or industry-specific engines, or one could already be on S/4HANA, while the other is still on ECC. Harmonizing these will require restructuring the license. SAP will look at it case by case – you might convert one side’s metrics to the other’s or move both onto a new metric structure (for instance, SAP might propose moving both to S/4HANA licensing model as part of consolidation). Use this as a chance to eliminate outdated metrics or unused products. Also, if one contract had more favorable terms (such as discounts or user definitions), try to carry those forward into the new combined deal.

Merger Example (Two SAP Customers): Company A (running SAP ECC on-prem, 1,000 users) acquires Company B (running SAP S/4HANA on-prem, 600 users). Each has a separate license agreement. After the acquisition, A decides to eventually integrate B into A’s ECC system (and later move to S/4HANA Enterprise). Initially, A and B continue to operate separately.

A informs SAP of the acquisition, and they start discussing a unified contract. SAP performs a review and notes that if B’s users were added to A’s system, it would exceed A’s license count, which is a compliance issue.

They negotiate a deal where they purchase an S/4HANA upgrade for all 1,600 users and receive a volume discount due to the larger combined number. As part of the deal, SAP allows B’s existing S/4HANA licenses to be credited against the new purchase (to avoid double paying) and agrees that B’s SAP system can be used for 12 months during the migration without extra charge.

In the end, Company A secures one modernized contract covering both, at a price better than A or B could get alone, and SAP sells an S/4HANA system. If A had not been proactive, SAP could have insisted that B’s usage under A’s contract be immediately licensed, which might have resulted in a rushed and less favorable purchase.

Acquiring a Non-SAP Company: Bringing New Users onto SAP

In this scenario, your company, which uses SAP, buys another company that was not an SAP customer (perhaps they used a different ERP or no comparable system). After the acquisition, you may want to integrate the new employees and operations into your SAP system.

From a licensing perspective, this is usually more straightforward because you’re essentially expanding your licensed user base rather than transferring between entities. Key points:

• Check your current SAP contract’s definition of “Named Users” and affiliate usage. Most SAP contracts allow the licensee and its majority-owned affiliates to use the software, provided they have purchased sufficient user licenses for them. If the acquired company becomes an affiliate (typically the case if you own it), you can add their users to your SAP system legitimately, provided you purchase any necessary additional user licenses. There is no separate contract needed for them; they are now part of your organization.
• The main task is to quantify what additional usage (users or functionality) the acquisition will require and then true-up with SAP. For example, if you acquired 200 new employees who need access, you might need 200 more User licenses of the appropriate types. Or if you want to start using an SAP module that the acquired company needs, such as SAP Retail or SAP CRM, which you haven’t used before, you may need to license that component.
• SAP might still treat this as an opportunity to sell you more. Suppose your contract has a price list for additional users. In that case, you can simply order what you need, keeping in mind the volume discount tiers. If the acquisition bumps you into a higher bracket, ensure you get better pricing. If not, SAP may want to renegotiate some terms, especially if the increase is large.
• Avoid Compliance Gaps: Don’t delay in assessing license needs. If the plan is for acquired employees to start using your SAP system right after closing, try to have an agreement with SAP in advance for the additional licenses to take effect on Day 1. If that’s not possible, set a very short timeline to get them licensed. Running significant unlicensed usage even within an affiliate is risky because SAP audits could catch the sudden spike in users. However, since the acquired company likely didn’t have SAP at all, you won’t be dealing with contract transfer issues – it’s just a straightforward purchase on your side.
• Consider the Integration Timeline: If you won’t integrate systems immediately (perhaps the acquired company will continue using its existing systems for a while), then you might not need additional SAP licenses until later, when you migrate them onto SAP. This gives you time to plan and possibly bundle that license purchase with a larger negotiation or your next annual license negotiation cycle for better terms.

Acquiring an SAP-Using Company as a Non-SAP Customer

This is the flip of the above: your company doesn’t use SAP (or uses a different system), and you acquire a company that runs its business on SAP.

Now, as the new owner, you have an operation relying on SAP software, but you don’t have an SAP license contract with the rights to use that software.

The acquired company likely had its own SAP agreement, but if that company is being absorbed or if its contract had change-of-control restrictions (common in SAP agreements), you’ve got issues to resolve:

• Check the Contract Terms: In many SAP contracts, a change of ownership or control of the licensee may be considered an assignment that requires SAP’s consent. If the acquired company remains a separate legal entity and you plan to keep it running as is, you might be able to keep its SAP contract in place but you must notify SAP of the change. SAP will evaluate if they allow the contract to continue with the new owner. Often, SAP will require a novation or a new agreement because the customer’s name is changing. There is a risk that SAP could even terminate the existing agreement if it had strict clauses (some agreements say they terminate upon a change of control, effectively forcing re-signing with SAP)​.
• Seek Consent and Novation: Ideally, as part of due diligence, you engage SAP (through the acquired company’s procurement or directly) to consent to the assignment of the SAP license to your company. In practice, SAP will usually consent if you negotiate certain updates, perhaps aligning the contract to your standards or bundling it with a purchase. They might, however, refuse to simply transfer on very favorable terms. For instance, if the acquired company had a steep discount or special deal, SAP might say those terms were exclusive to that company, and now that a new owner is in place, they want to revisit the pricing. Be prepared for SAP to propose a fresh contract where some discounts could be reduced or other terms normalized. From your side, push to maintain continuity – emphasize that you want to keep operating the acquired business without disruption and that you expect to inherit the rights that were paid for. If SAP senses you have no alternative (because that business runs on SAP and you need it to continue), they may play hardball. It’s wise to explore alternatives (could that business migrate off SAP to another system? It’s a big move, but it’s sometimes considered if SAP becomes too costly).
• Integration Plans: If you plan to merge the acquired business into your non-SAP IT systems, then you may only need to keep SAP running temporarily to extract data or run in parallel. In such a case, consider negotiating a short-term extension of the acquired company’s SAP license just for transition, rather than a full renewal. If you’re ultimately going to retire or replace SAP in that unit, let SAP know that’s the plan (they may still try to convince you to keep SAP, but you can leverage the possibility of discontinuing it to avoid expensive long-term commitments).
• Successor Liability for Compliance: Importantly, if you acquire a company using SAP, you inherit any compliance problems with that usage. If the acquired firm was out of compliance (e.g., unlicensed users, indirect use issues), SAP will hold the new owner responsible once you take over. Always perform an internal license audit during due diligence on the target’s SAP deployment. You don’t want a nasty surprise where, after the acquisition, SAP comes with an audit finding that, say, the acquired company was 100 users under-licensed or had misclassified user types, and now you have to pay for that. Ensure the purchase agreement with the seller addresses software compliance – possibly via reps and warranties or even escrow of funds if a known issue exists. This is part of “successor liability”: the concept that the new owner can be held responsible for the past owner’s license violations (because the usage continues under their watch). Mitigate this by cleaning up any compliance issues at deal time (have the seller resolve them with SAP or adjust the price accordingly).

Example (Non-SAP acquiring SAP customer): A retail chain that didn’t use SAP acquired a smaller competitor that ran SAP for its finance and inventory needs. The acquirer had no SAP contract. During negotiations, the seller and buyer jointly approached SAP to obtain permission for the buyer to use the SAP system after the acquisition.

SAP agreed not to terminate the seller’s license immediately upon a change of control, but only under the condition that the buyer enters a new license agreement for that SAP environment within 6 months. In those 6 months, the buyer had to either sign a new contract (with terms SAP proposed, which included moving to current pricing and support fees) or shut down use of SAP.

The buyer leveraged the fact that they could technically migrate the acquired stores to their non-SAP systems as an alternative, which pressured SAP to offer reasonable terms rather than exorbitant fees. Ultimately, the buyer signed a new deal for a smaller scope since they chose to migrate some functions off SAP and keep only finance on SAP for a year.

They also discovered the acquired company had been using a third-party e-commerce platform that indirectly accessed SAP without proper licenses – a liability that the seller had to cover by purchasing the necessary SAP engine before the acquisition closed (saving the buyer from inheriting that cost).

Combining SAP License Portfolios: Negotiation Opportunities

When merging license portfolios (whether through the merger of two SAP-using companies or the acquisition of additional users or products), there is an opportunity to negotiate better terms with SAP.

Vendors know that after an M&A, the combined organization often has a larger IT footprint and potentially a larger budget for new projects.

SAP, in particular, may try to upsell or push the customer toward its strategic offerings, such as S/4HANA and cloud subscriptions, during this time. Here’s how you can turn the situation to your advantage:

• Leverage Increased Scale for Discounts: As a bigger customer, you can demand better pricing tiers. SAP’s pricing for on-premises licenses typically has built-in discount brackets – the more you buy, the bigger the discount. If Company A had 1,000 users and Company B had 600, separately, each might have paid, say, a 50% discount off the list price. Now, as a 1,600-user entity, you might argue you deserve, for example, a 60% discount on any new net licenses. Use benchmarks of similar-sized SAP customers to support your case. For cloud, larger employee counts or spend might qualify you for more favorable subscription rates as well. The key is to negotiate as one entity, not two separate ones.
• Enterprise Agreements: Consider negotiating an Enterprise License Agreement (ELA) or a flexible consumption agreement after the merger. An ELA is typically a fixed fee for broad usage rights over a period, which can simplify compliance and potentially save costs if you plan to expand SAP usage. For instance, if both companies had plans to increase SAP usage, combining those plans under one multi-year ELA could get you a significant bulk discount and predictable costs. SAP has offered enterprise agreements or all-you-can-eat deals to some large customers, usually tying them to strategic products (like an ELA that includes a bundle of SAP solutions with unlimited use up to certain metrics). Post-merger might be the only time your organization is big enough to qualify or afford such a deal, and SAP will listen since they’d prefer to lock in the larger combined customer on a long-term agreement.
• Renegotiate Maintenance: Each of the merging companies was paying annual maintenance (support) fees to SAP, typically around 22% of the software license net value per year. After consolidation, you might negotiate maintenance on the combined contract in a way that recognizes any overlapping licenses. While SAP is notoriously rigid on maintenance fees, customers have had some success negotiating concessions during mergers, such as a temporary maintenance credit or a promise that support fees won’t increase even if licenses are consolidated. Especially if you are “trading in” some licenses (e.g., moving to S/4HANA from ECC, which usually involves getting credit for your existing investment), ensure that maintenance fees for the new contract are based on the incremental license spend, not double-counting what you already paid under both companies. If both companies had active maintenance, SAP is essentially getting paid twice. Upon merging, push for rationalization so that the support fee reflects the combined license footprint, possibly with a cap or discount.
• Exploit Contract Co-termination or Alignment: If one company’s SAP contract is up for renewal or additional purchases are needed, use the timing to align it with the merger negotiations. SAP sales teams often work on an annual or quarterly quota; if your merger means a big potential sale, engage them at a time you can maximize incentives (like end of quarter/year, or when S/4HANA adoption targets are in play). By combining all needed changes (user additions, new products, etc.) into one negotiation package, you might negotiate a more favorable master agreement. For example, rather than buying a bit now and a bit later for each side, do one large purchase – SAP might give extra discounts or free soft benefits (training credits, extended support, etc.) for a big deal. Just be cautious about overspending on things that aren’t needed; keep it aligned with actual business requirements.
• Be wary of “buy-up” pressure: SAP account reps may insist that the merged company must immediately “buy up” any license shortfall. For instance, if Company A was compliant on its own and Company B was compliant on its own, but if the merged operations result in more users accessing one system than are licensed, SAP will highlight that as a compliance issue to resolve. Don’t interpret this as you have no choice but to pay whatever SAP asks. Yes, you need to resolve the compliance issue, but how you do so is negotiable. Perhaps you can temporarily shift some users to the other system or agree on a phased approach for license growth. Use the merger as a rationale for a “true-up holiday” – request from SAP a grace period to rationalize licenses without audit penalties, in exchange for a planned purchase roadmap. In many cases, SAP would prefer a constructive plan to sell you more licenses over time than an antagonistic audit battle.

Successor Liability and Documentation Post-Transaction

After any merger or acquisition involving SAP, it’s crucial to document who owns what licenses and under what terms going forward.

With divestitures, documentation is about what was transferred (if anything) and the cutoff of usage. With mergers, documentation is about consolidation and possibly retiring one set of agreements.

Here are some best practices:

• Official Contract Assignments/Novations: If one company’s SAP contract is being assigned to the new combined entity or the acquirer, make sure SAP signs off on a novation agreement that clearly states the new customer name responsible for the licenses. Keep copies of this alongside the original contract. This is your evidence that, for example, “Company B’s licenses are now legally owned by Company A (or NewCo).” Without this, confusion over entitlements could arise years later.
• Amendments for Affiliate Use: In some cases, the easiest path in a merger is to designate one company’s contract as primary and have SAP amend it to add the other entity as an authorized affiliate. This can be a temporary solution if you’re not ready to fully merge the contracts. Ensure the amendment is explicit – e.g., “Company B, now a subsidiary of Company A, may use the software under Company A’s license.” This essentially extends coverage. However, watch out for any time limits or conditions in such an amendment, and clarify how maintenance payments will work if both entities were paying before.
• Inventory of License Assets: Post-merger, conduct a thorough inventory: list all SAP software licenses that Company A had and Company B had, including license metrics, quantities, and any special terms or discounts. This combined inventory is useful for verifying against any new consolidated contract to ensure that nothing was lost or double-counted. It also helps internal SAM tracking: you might have some overlapping entitlements (like both had licenses for SAP ERP Financials – you now have two sets of those licenses), which you may or may not need concurrently. Decisions can be made on whether to keep both (possibly running systems in parallel for a while) or eventually terminate one set.
• Successor Liability Acknowledgement: As mentioned earlier, if you acquire a company, you assume its compliance responsibilities. If SAP has any ongoing compliance discussions or an audit is in process, ensure that they are disclosed and addressed. It’s wise to have the seller confirm the status of SAP licenses in the purchase agreement, stating that “all use of SAP software is by the license, with no outstanding compliance issues”. If SAP claims later that there was past misuse, you might have recourse if that representation was false. In practice, though, once you own it, SAP will deal with you and expect you to fix any issues. So it circles back to doing your pre-merger audit or using a third-party to verify compliance of the target environment.
• Documenting Divestiture License Transfers: In a divestiture, if any licenses were transferred or duplicated, document the transaction. For example, if SAP allows you to transfer 100 user licenses to SpinCo, have that in writing (either as an amendment or a new contract for SpinCo). Also, adjust your records to show that the 100 licenses are no longer yours. Similarly, if SpinCo is allowed 6 months of use under TSA, document the start and end dates, as well as the terms agreed upon with SAP, in a brief letter or contract rider. Good documentation prevents disputes later (“Did SAP agree we could do that? Here’s the signed paper that says so.”).
• Shared Environments Post-Merger: Sometimes, post-merger, companies might run a shared SAP instance for a transitional period (especially if one company’s system is designated as the go-forward solution and the other is migrating into it). In effect, for a time, that system is serving two formerly separate license pools. If SAP has approved this (through contract changes or an interim agreement), keep a record of that approval. Also, maintain logs of which users from legacy Company B are using Company A’s system and vice versa, tied to the timeline of integration. This level of detail can be important in an audit to show you weren’t using more than licensed at any given time – you can demonstrate when users were added and that you purchased licenses at that point in accordance.

Real-World Examples of M&A Licensing Outcomes

Let’s illustrate how handling SAP licensing well (or poorly) can financially impact companies in M&A situations:

• Example 1: Spin-Off Saves Costs with Pre-Negotiated Clause – A global manufacturing conglomerate anticipated it might divest some non-core businesses. In its SAP enterprise agreement, it negotiated a clause allowing transfer of up to 15% of user licenses to a divested entity, provided the divestiture was to a standalone company (not a competitor). The new entity signed a direct support agreement with SAP. Two years later, they spun off a subsidiary. Thanks to this clause, they were able to transfer 300 of their 2,000 SAP user licenses to the new company. The new company only had to start paying SAP annual support for those licenses, at the same discounted rate the parent company enjoyed, avoiding a huge upfront purchase. The parent company, now with 1,700 users, simply paid maintenance on the remaining licenses and was able to terminate maintenance for those 300 transferred (with SAP’s agreement, since the new company picked it up). Both organizations avoided duplicate costs: the new company didn’t buy software it effectively already had, and the parent wasn’t stuck paying for users it no longer had. This proactive contract planning likely saved the two companies several million dollars compared to a scenario with no transfer rights.
• Example 2: Divestiture Without Rights – The Costly Aftermath – In contrast, a large energy company divested a division that relied on the parent’s SAP systems, without having any prior license transfer provisions. The deal was completed relatively quickly, and IT and licensing were an afterthought. Post-close, the parent had to keep providing SAP access via a TSA for the divested unit. SAP treated this as a compliance exception and charged the parent a “transition services fee” of 20% of the divested unit’s license value for a 12-month period of continued use. Meanwhile, the new entity had to negotiate a brand-new SAP license contract. Because they were a smaller entity on their own, the pricing they received was much higher, only a small discount off SAP’s list prices. They ended up purchasing a fresh SAP S/4HANA license for 500 users at a cost that was about 40% higher per user than the parent’s original pricing. The parent also wound up with too many licenses – it had 500 extra user licenses it no longer needed. It tried to drop those from support, but SAP’s policy didn’t allow a reduction during the contract term. In the end, the parent paid for unused licenses until the next renewal cycle and saw its support costs repriced higher because, with fewer users, it lost a volume discount tier. Overall, this lack of planning and contractual flexibility resulted in an estimated $5 million in combined extra costs (new purchases by the spin-off plus wasted support fees by the parent). This could have been mitigated by negotiating transfer rights or at least coordinating a shared-cost arrangement with SAP upfront.
• Example 3: Merger Leads to Enterprise Agreement – A Win-Win – Two mid-sized tech companies, each spending around $2 million on SAP licenses historically, merged to form a larger entity. They took the merger as an opportunity to overhaul their SAP landscape. Instead of keeping two contracts, they approached SAP with a proposal: they would commit to a 7-year enterprise subscription (RISE with SAP) covering S/4HANA Cloud and several SAP cloud products for the combined enterprise, consolidating and expanding their usage. Because this represented a strategic win for SAP (moving them to the cloud and achieving long-term lock-in), SAP provided very favorable terms: a 30% lower subscription rate than the combined amount they had paid before. They included some additional modules, such as SAP Analytics Cloud and SAP Cloud Platform services, at no extra licensing cost. The merged company benefited by eliminating the complexity of two license sets and likely saved money over the period, while also getting a modernized system. This negotiation was possible because the companies didn’t simply add up what they had and accept the status quo; they used the timing to rethink their SAP strategy and leverage their new size to get a better deal.
• Example 4: Failed License Integration – Paying Double. On the other hand, consider a case where a large corporation acquired a competitor of equal size. Both were heavy SAP users. Due to internal post-merger chaos, they failed to properly consolidate their SAP contracts or systems for over three years. Each division continued to run its own SAP environment and contracts, with no adjustments. During that time, some departments integrated and ended up needing access to both systems. They allowed some informal sharing of user logins without purchasing additional licenses, out of ignorance. When SAP eventually audited them, it found that about 200 users from Company A were using Company B’s SAP system, and vice versa, all of which were unlicensed. The audit resulted in a compliance bill of $1.5M for those accesses. Moreover, had they consolidated earlier, they could have reduced redundant licenses, as they had 10,000 combined named users licensed, while only 8,000 employees used SAP post-merger. Instead, they paid maintenance for those 2,000 excess users each year (roughly $ 500,000 per year wasted). After the audit, they finally sat down with SAP to unify contracts, but by then, they had lost leverage and were essentially dictated terms to become compliant. This case shows that failing to proactively manage licensing after a merger can lead to direct financial penalties and ongoing inefficiencies.

These examples underscore a theme: planning and proactive negotiation pay off, while neglect and assumption (“we thought we could just keep using it”) cost dearly.

Recommendations for SAM Managers and Procurement Teams

Successfully navigating SAP licensing through M&A events requires foresight, attention to detail, and savvy negotiation.

Here is a consolidated list of actionable recommendations:

1. Review SAP Contracts Early in M&A Planning: As soon as a merger, acquisition, or divestiture is on the table (even in early stages), conduct a thorough review of all relevant SAP license agreements. Identify any clauses on assignment, change of control, affiliate use, or divestiture. Understanding your contractual position will inform how you approach SAP – whether you have any flexibility or if you will need to request special permissions. Include both on-premise license contracts and cloud subscription agreements in this review.
2. Engage SAP (Carefully) and Set the Tone: It’s usually wise to inform SAP of major corporate changes – they will likely find out anyway. You don’t want them to feel blindsided; that can lead to aggressive auditing. However, do this after you have done some internal strategizing. When approaching SAP, frame the situation as one where you want to work together to find a solution that ensures business continuity. If it’s a divestiture, coordinate with the buyer or spin-off so that SAP sees a cooperative customer (or two) rather than a fragmented message. Often, presenting a united front (Parents and SpinCo together asking SAP for a fair solution) can yield a better outcome than each dealing with SAP separately. For a merger, have a clear integration plan and licensing wish-list (e.g., “we intend to consolidate systems and would like a new contract covering X users and Y products, here’s what we propose…”).
3. Negotiate Transition Services Rights in Advance: Don’t wait for a divestiture to happen; include TSA use rights and carve-out clauses in your software contracts proactively. Explicitly ask for: “In the event of a divestiture, permission for the Customer to provide SAP access to the divested entity for __ months” and “the right to transfer or assign licenses to that entity with SAP’s consent, not to be unreasonably withheld.” Getting this in writing up front can save enormous hassle later​. If you’re currently renewing or renegotiating with SAP for any reason (even unrelated to M&A), see if you can add these provisions now.
4. Include M&A Scenarios in Contract Negotiations: Similarly, when signing new cloud agreements (such as SuccessFactors) or any major SAP deal, include language about mergers and acquisitions. For example, ensure there’s a clause that the contract can be assigned to a surviving entity in a merger or to a buyer of your assets, with SAP’s consent not to be unreasonably withheld. This avoids SAP using a merger as an excuse to force a contract reset on worse terms.
5. Perform License Due Diligence in Corporate Transactions: If you are the buyer in an acquisition, always assess the target’s SAP licensing. Request copies of their SAP contracts and any recent audit reports. Evaluate if they are properly licensed or if they have any pending compliance issues. This due diligence should influence deal pricing or terms – if the target needs a costly SAP true-up, you may ask the seller to cover that or reduce the purchase price. If you’re divesting a unit, do the same due diligence on what parts of your SAP usage are attributable to that unit. Figure out how you will unwind those licenses (are they shared in a single system? Do you have enough granularity to know how many users belong to that unit?). Clarity on this will help you negotiate with SAP and set up the TSA appropriately.
6. Plan for Interim Operations and Document Them: If a transition period of shared system use is needed (which is common), plan it meticulously. Determine how long the shared access will last and for what specific functions. Document this in the Transition Services Agreement with the other party, and importantly, formalize it with SAP through a license agreement addendum or separate transitional license. By formalizing, you turn a potential compliance gap into an authorized use. Mark the end date on your calendar and ensure that by that time, the divested entity is cut off or on their system, or that you’ve extended the agreement if needed (with SAP’s approval). Don’t let transitional arrangements drag on for the undocumented.
7. Use Third-Party Expertise: Engaging an independent licensing advisor or a software licensing attorney can be extremely beneficial. They can analyze your contracts for hidden risks, help quantify your needs, and interface with SAP’s licensing team on your behalf. These experts often know what concessions SAP has given other clients in similar situations, which you can leverage in negotiations. Their cost is usually far lower than what you save in an optimized deal. For complex mergers or high-stakes divestitures, consider this “insurance.”
8. Explore Alternative Solutions as Leverage: During negotiations, it’s fair to let SAP know that you have options. In a divestiture, the new entity might consider using a competitor’s ERP if SAP’s proposal is too expensive; even if it’s unlikely, it’s a negotiating tactic. In a merger, if SAP pushes too hard for a big purchase, you might suggest that the combined company will delay SAP consolidation or evaluate third-party support (for on-prem) to reduce costs. Don’t threaten recklessly, but a gentle reminder that you’re not entirely captive can make SAP more reasonable. (For instance, there have been cases where a spin-off chose Oracle or Microsoft Dynamics instead of SAP because the SAP deal offered was not tenable – SAP is aware of this possibility.)
9. Mind the Maintenance and Cloud Renewals: Pay attention to support and subscription renewals during mergers and acquisitions (M&A). If splitting, try to co-terminate contracts or align end dates so you can potentially reduce licenses at renewal without incurring a penalty. If merging, try to consolidate maintenance payments so you’re not paying two minimum fees. And remember, if you drop volume (e.g., spin off a portion of users), your cloud renewal might increase unit pricing – negotiate upfront for price protections in such cases. It is possible to negotiate clauses that say if user counts decrease due to divestiture, discounts will remain the same, etc. It’s easier to get that before the event than after.
10. Implement Internal Controls Post-Deal: After the corporate transaction and licensing deals are finalized, ensure that your IT and SAM teams implement controls to prevent unauthorized use. For example, if two ERPs remain separate, put processes in place so that any user who needs access to both is properly licensed under both, and their access is properly recorded. If a spin-off occurs, closely monitor to ensure that no user accounts from the new company remain in the parent’s system after the TSA period. Essentially, enforce the boundaries that were agreed. This will keep you clean in SAP’s eyes when the next audit comes.
11. Keep Communication Open with the Divested or New Entity: If you divest a business, continue to maintain communication regarding any shared licensing concerns. Sometimes issues arise after separation (such as needing to access historical data in the parent’s SAP system). You may need to arrange limited read-only access or a data extract for the new company. Coordinate with SAP if such needs arise to ensure it is permitted, possibly by requesting a brief extension of use rights. A cooperative relationship between the separated entities can help avoid accidental compliance breaches. The same goes for merger integration teams: communicate clearly about what is allowed and what is not until licenses are unified.
12. Document Everything: Keep a well-organized paper trail, including copies of contracts, any SAP communications that grant permissions, and meeting notes from negotiations. If personnel change, those documents will be vital for their successors to understand what was agreed upon. Also, in any future disagreement with SAP, having written evidence of what was permitted can protect you. For example, if an SAP representative verbally says, “It’s okay for the spin-off to use the system for 3 months,” get that in writing (at least via email). Verbal assurances don’t hold up in an audit – only contractual terms do.
13. Think Long Term – Architect Your License Strategy: M&A events can be a catalyst to revisit your entire SAP strategy. Perhaps moving to the cloud (RISE with SAP) makes sense after merging systems, or maybe you decide to stick with on-prem for flexibility. Perhaps a spin-off is a chance for that entity to try a different ERP that fits better for its size. All these decisions have long-term implications on costs and agility. Weigh the options pragmatically. Don’t feel compelled to stick with a suboptimal licensing setup just because that’s how it was – use the change as an opportunity to improve. However, also be cautious of making hasty moves just because SAP offers a deal; ensure it aligns with your IT roadmap and budget stability.
14. Learn from Others: Many companies have gone through SAP-related M&A challenges. Leverage user groups, forums, or case studies (where available) to learn what worked or didn’t. SAP licensing is complex, and each case has its nuances. Knowing, for instance, that another firm negotiated a creative “carve-out license package” with SAP can give you the confidence to request something similar. The References below include some resources that discuss these scenarios – you can share them with your team or even with SAP reps to show that you’re informed about standard industry practices.

By following these recommendations, SAM and procurement teams can better protect their organizations during the turbulence of mergers, acquisitions, and divestitures. The overarching theme is proactivity – anticipating licensing needs and addressing them on your terms with SAP, rather than reacting to problems on SAP’s terms later on.

With good planning, an M&A event can be executed without compliance surprises and can even result in a more efficient licensing position than before.

Do you want to know more about our SAP Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit