SAP License Transfer Options: Moving Licenses Within Groups and Post-Merger

Introduction – Why License Transfer Rules Matter

Insight: SAP licenses don’t automatically follow your organization when it changes — and that can turn an M&A integration into a licensing minefield. SAP’s restrictive transfer policies often clash with modern corporate realities like mergers, acquisitions, spin-offs, and internal reorganizations.

If you assume licenses will freely move with a business unit or new owner, you risk serious compliance surprises and added costs. The inability to freely transfer licenses can lead to unexpected audit penalties or the need to pay for new licenses that you technically already own.

This is why understanding SAP’s transfer terms is critical before any corporate change or system consolidation. For more insights, read our guide SAP True-Downs & License Transfers: Reducing Your License Footprint.

In practice, a merger or reorganization can invalidate your existing license terms overnight.

For example, post-merger companies have inadvertently paid double maintenance on overlapping SAP licenses, wasting hundreds of thousands of dollars per year, simply because contracts weren’t consolidated.

A spun-off division might suddenly find it has no rights to the SAP system it’s been using, unless a new agreement is put in place. These scenarios make it clear: license transfer rules matter, and proactively managing them can save your organization from a licensing nightmare.

SAP’s Standard Position on License Transfers

SAP’s standard license agreements are highly restrictive on transfers. A typical contract clause might state: “Licenses are non-transferable except within wholly-owned subsidiaries or affiliates of the Licensee.” In plain terms, you cannot freely assign or move SAP licenses outside the original contracting company’s corporate group.

Here are SAP’s key rules on transfers:

• No resale or external transfers: You are not allowed to sell, rent, or otherwise transfer SAP licenses to any unrelated third party. Perpetual licenses might belong to you, but contractually, you can’t put them on a secondary market.
• Internal transfers within the group only: Licenses can only be moved between entities that are part of the same corporate family (usually defined by >50% ownership or “wholly-owned” status). For instance, a parent company can reallocate licenses to a subsidiary it owns, but not to a joint venture it only partially owns (without SAP’s permission).
• SAP consent required outside affiliates: If you want to transfer licenses to an entity outside your immediate corporate group (e.g., after a divestiture or to a sister company under a different parent), SAP’s prior written consent is required. In practice, this usually means negotiating a new agreement for that situation.

From SAP’s perspective, these strict transfer rules protect its commercial interests.

They prevent a gray market of used SAP licenses and ensure SAP maintains control of the customer relationship (and the maintenance revenue stream). By restricting transfers, SAP preserves its pricing integrity – companies can’t shuffle licenses around or resell them to avoid buying new licenses at full price.

It also ensures that each legal entity running SAP is an approved SAP customer, simplifying support and compliance from SAP’s perspective. While these reasons make business sense for SAP, they can feel very limiting for customers whose organizational structures evolve over time.

At a glance: Can you transfer SAP licenses?

Checklist – Reviewing Your SAP Contracts: To understand your transfer rights and limitations, make sure to:

• Review the “Assignment/Transfer” clauses in your SAP agreements. Note the exact wording about transfers and assignments.
• Confirm the definition of “affiliate” in your contract. It will define which entities are considered part of your corporate group (typically majority-owned entities).
• Identify the legal license holder for each SAP contract. Is it the parent company, a specific subsidiary, or a regional entity? Licenses usually belong to the named licensee (and its affiliates, if allowed).

Read about SAP licenses in merger and acquisitions, Licenses in Mergers & Acquisitions: How to Manage SAP Entitlements During Corporate Change.

Internal License Transfers – Within Corporate Groups

Transferring SAP licenses within your corporate group (e.g., between a parent company and its subsidiaries) is generally allowed under SAP’s rules – as long as those entities remain under the same ultimate ownership.

In simpler terms, if your company owns 100% of Subsidiary X, you can usually move or consolidate SAP licenses with Subsidiary X. The key is that the licenses stay “in the family” of the original licensee.

Common internal transfer scenarios include:

• A parent company is consolidating licenses that were initially purchased by its subsidiaries (bringing all SAP users under one master agreement).
• A shared services center or central IT hub is taking over SAP systems from multiple regional affiliates, effectively pooling the licenses under one entity.
• Regional offices or divisions are transferring their SAP user licenses to the global headquarters as part of an IT centralization initiative.

Even though these internal transfers are allowed, they are not entirely automatic. You should follow a clear process to execute them smoothly:

Process for an internal license transfer:

1. Notify SAP of the intended internal transfer. While you might not need formal approval if it’s within defined affiliates, it’s wise to inform SAP account management. Hence, they are aware the licenses will be used under a different entity in your group.
2. Update systems and records to reflect the new license holder. SAP will need to update its entitlement records (and you should update any installation or system licensing keys if they are tied to a company code). Essentially, make sure SAP’s systems show the licenses under the correct entity after transfer.
3. Maintain continuous support under the same contract. Ensure that the entity receiving the licenses is covered by the same maintenance agreement or a transferred support contract. You don’t want a gap where licenses move but support isn’t in place – that could jeopardize your support coverage or compliance.

Risks to watch out for: Even internal moves can get tricky if each subsidiary has its own SAP contract or license pool. There could be confusion about which licenses are moving and whether any license limitations exist (user types, geography, etc.).

Additionally, changing the named license holder might require new license keys or migration of systems to a different customer ID in SAP’s support portal, which needs coordination to avoid downtime.

Always double-check with SAP that support and audit records reflect the new structure. If not handled properly, internal transfers could lead to temporary compliance issues (for example, if SAP thinks a subsidiary is still using licenses after they were moved to the parent).

Best Practice: “Maintain one legal contracting entity per SAP landscape to avoid future transfer complexity.” In other words, wherever possible, designate a single corporate entity (usually the parent company) to hold all SAP licenses for your group.

This minimizes the need for internal transfers and makes it much easier to manage licenses when reorganizing. It also simplifies negotiations with SAP, since you’re dealing with one master agreement rather than many scattered contracts.

Transfers During Mergers and Acquisitions

Mergers and acquisitions present some of the most challenging scenarios for SAP license management. Corporate M&A activity can quickly tangle SAP licensing if not addressed proactively. When two companies become one, or one company acquires another, what happens to their SAP licenses?

Mergers:

If two companies that both run SAP merge, their license estates need to be consolidated. SAP will not simply let the combined company use both sets of licenses freely without formal action. Typically, SAP will require the merged entity to either sign a unified contract or re-baseline the licenses under one of the existing agreements.

The process often involves migrating one company’s users onto the other’s license agreement or negotiating an entirely new agreement that covers the new, larger organization. One risk here is overlap and duplication – for example, each company had 500 SAP user licenses, but post-merger the combined company might only need 800 users total (not 1,000). Until contracts are merged and excess licenses dealt with, you could be paying maintenance on those extra 200 unused licenses. (SAP’s annual maintenance is about 22% of license value, so paying support on redundant licenses can burn significant money.)

It’s not uncommon to see a merged firm inadvertently paying double maintenance fees because both legacy contracts stay active. On the flip side, a merger is an opportunity to renegotiate: the larger combined spend might secure deeper discounts.

For instance, two separate contracts, each with ~25% discounts, could be consolidated into one deal at 50% off the list price, thanks to the higher volume – a valuable negotiation angle if you use the merger to strike a new deal with SAP.

Acquisitions: In an acquisition, one company (the acquirer) buys another. If the acquired company uses SAP, you can usually bring those SAP licenses into the acquirer’s existing framework or agreement once the acquisition is finalized. Since the acquired company becomes an affiliate of the acquirer, internal transfer is possible.

However, SAP will still insist on paperwork: you’ll need to show legal proof (e.g., a letter or documentation of the merger/acquisition) and likely sign an amendment or new order form to formally transfer those licenses under the parent’s account. An important point is that transferred licenses retain their original licensing terms – the metrics, license types, and support fees that the acquired company had will carry over.

They don’t automatically convert to the acquirer’s metrics or discount levels. This can create some complexity: you might inherit a different user classification or metric (e.g., Company B was licensed by employee count, Company A by named users), and you’ll have to reconcile those.

Still, merging them into your agreement is typically allowed as long as you go through the proper steps with SAP. Be aware that SAP may use this event as an opportunity to “reset” or upsell, for example, by pushing the combined company to migrate to S/4HANA or Cloud subscriptions as part of consolidating contracts.

Divestitures / Spin-Offs: When you divest a business unit or spin off a part of the company that uses SAP, SAP licenses do not automatically go with that new entity. In fact, SAP’s standard stance is that the spun-off entity has no rights to the parent company’s licenses once it’s no longer an affiliate.

The usual outcome is that the new standalone company must negotiate and purchase its own SAP licenses. Often, the parent company can arrange a Transitional Use Agreement or Transition Services Agreement (TSA) so the divested unit can keep using the parent’s SAP system for a short period (commonly 6–12 months) after separation.

This gives the new entity time to implement its own SAP instance or migrate to another system. But after that grace period, the new company is on its own. This can be a huge cost: the newly independent entity may have to re-buy licenses for the same software it was just using. And likely, they won’t get the same volume discount the parent had.

For example, if the parent enjoyed a 50% discount on SAP pricing due to its size, the smaller spin-off might only get a 15–20% discount, meaning it will pay substantially more per license.

All of this needs to be factored into divestiture planning because it can significantly impact the deal’s financial outcome. (It’s not unheard of for a spin-off to face a multi-million dollar SAP bill to establish its own environment.)

Checklist – M&A License Transfer Planning:

• Conduct SAP license due diligence before any merger or carve-out. Inventory all SAP contracts, license types, and usage in both the buyer and target (or the part being sold). Identify conflicts (like different licensing metrics or overlapping users) early.
• Identify overlap or redundancy in entitlements. Post-merger, where will you end up with too many licenses? Plan to eliminate or repurpose duplicates. Before divestiture, determine which licenses the departing unit uses and how you’ll cover those (new contract or termination).
• Plan the new licensing structure before Day 1. Don’t wait until after the deal closes to figure out how the combined entity (or separated entity) will be licensed. Negotiate with SAP in parallel to the M&A process so that upon closing, you have a clear path: whether it’s a unified contract for the merged company or a transition agreement for the spin-off. Get any necessary SAP consents or new agreements signed, effective on the closing date, to stay compliant.

License Transfers Across Borders or Entities

Geography can add another wrinkle to SAP license transfers. Even within the same corporate group, moving licenses across country borders or between different regional entities isn’t always seamless.

SAP often treats each legal entity (especially in different countries) as a separate customer for contracting purposes, unless you have a global agreement in place. This means a license transfer from, say, a European subsidiary to a US parent company might technically be “internal,” but still requires coordination and possibly SAP approval due to the cross-border aspect.

Cross-border considerations: If your SAP licenses were originally contracted in one country’s entity, transferring them to an affiliate in another country may raise questions around local compliance and support.

SAP’s local subsidiaries (SAP UK, SAP Germany, SAP US, etc.) usually want to keep their share of the business, so moving licenses internationally might require the involvement of both local SAP offices.

Additionally, ensure there are no export control or legal restrictions on transferring the software usage to another jurisdiction (some SAP products with encryption or certain industry solutions could have export considerations). While these cases are rare, it’s worth checking if any specific clause in your contract restricts usage to a certain country or region.

Contractual workaround – “Global License Pool” clause: The best way to handle internal transfers across borders or entities is to bake flexibility into your contract upfront. Savvy customers negotiate a global transfer or license pooling clause as part of their SAP agreement.

For example, you might add language such as: “Licensee may assign or allocate licenses across any affiliate under common ownership or control, globally, without SAP’s prior written consent.” This kind of clause essentially pre-approves internal license reallocations.

With it in place, you can shuffle licenses between subsidiaries or move users from one country’s entity to another without having to ask SAP each time or worry about breaching the agreement. It gives your organization the freedom to respond to reorganizations or regional shifts instantly.

Benefits of a global license pool clause: First, it simplifies internal license management by treating your entire enterprise as one license pool instead of siloed buckets per country.

Second, it reduces the need for SAP’s intervention whenever you reorganize. You won’t need to negotiate mid-term contract changes just because, for example, your French subsidiary’s users will now be served by a data center owned by the German entity. This saves time and legal hassle, preventing SAP from charging a fee or renegotiating terms for a simple internal change.

Checklist – Ensuring Cross-Entity Flexibility:

• Negotiate global usage rights at renewal time. When your SAP contract is up for renewal or expansion, request a clause that allows license sharing among all wholly-owned affiliates worldwide. If SAP resists, emphasize how frequently your organization changes and that this flexibility is a must-have.
• Document cross-border usage internally. Keep clear records of which affiliate is using what licenses, especially if you allocate licenses to another country’s division. In an audit, you’ll need to demonstrate that all usage was by authorized affiliates. Good documentation will prevent misunderstandings with SAP auditors.
• Centralize entitlement tracking. Use a centralized SAM (Software Asset Management) tool or process to track SAP licenses across all your entities. When licenses move from one entity to another, update your records immediately. A single source of truth for license inventory can help avoid both compliance issues and duplicate purchases.

Prohibited Transfers – Resale or External Assignment

One thing SAP is unequivocal about: you cannot resell or externally transfer your SAP licenses. No matter how much you paid for those perpetual licenses, SAP’s contract terms forbid turning around and selling them to another organization.

A typical clause in SAP agreements states: “Licensee shall not resell, rent, lease, sublicense, or otherwise transfer the Software or any rights granted herein to any third party.” In short, your SAP licenses are for your internal use only, forever.

Implications of this prohibition: Even though you “own” perpetual licenses, you can’t treat them like property to be sold second-hand. For example, if you decide to discontinue an SAP system and have 100 unused user licenses, you’re not allowed to auction them off to another company.

In some jurisdictions (like the EU), there are legal theories that software licenses can be resold, but SAP has effectively closed the door operationally. If you attempted to sell your licenses to a third party, SAP would likely refuse to recognize the buyer as a valid customer (denying them support and updates) and could terminate your support agreement for breach of contract.

In practice, there is no real secondary market for SAP licenses because the buyer would end up with unsupported software. SAP’s strict maintenance and authorization processes make external transfers practically impossible, even if local law hints at a right to resell. Customers should view their SAP licenses as a long-term investment in use, not an asset to liquidate.

So what do you do if you have excess SAP licenses or you plan to leave SAP entirely? The hard truth is you won’t recoup money by selling licenses. Instead, focus on minimizing ongoing costs.

For unused licenses, you might negotiate a shelfware give-back or reduction in your next renewal (SAP sometimes allows a partial credit or swap for other products, though they won’t refund you). If you’re exiting SAP, your best bet is to terminate maintenance on those licenses (per the contract’s notice period) so you stop paying annual support.

That way, you save the 22% per year going forward. Trying to resell externally is not worth the legal fight and will be blocked by SAP’s policies.

Customer Tip: If you plan to decommission SAP or have surplus licenses, focus on ending maintenance or trading licenses back to SAP for credit, rather than attempting an external resale — SAP contracts make external transfers non-viable.

In essence, negotiate with SAP (or third-party support providers) to optimize costs, but don’t waste effort on selling licenses on the side.

M&A License Management Scenarios (Examples)

To illustrate how these rules play out, here are a few common M&A and restructuring scenarios and how license transfers are handled:

• Scenario 1 – Consolidation: Company A acquires Company B, and both were running SAP. Post-acquisition, Company A decides to consolidate B’s SAP environment into A’s. SAP agrees to merge Company B’s licenses into Company A’s master agreement. The combined entity then has a single contract covering all users. SAP rebaselines the maintenance fees based on the new total license count. (For example, if A was paying $1 million and B $500k in support annually, the new baseline might be $1.5 million for the unified contract, adjusted for any volume discount changes.) The benefit is a unified license pool and the potential elimination of duplicate licenses. However, note that SAP will ensure no “credit” is lost, as they often won’t allow you to drop licenses without purchasing something of equivalent value or paying a fee. Careful negotiation is needed to truly capture savings from consolidation.
• Scenario 2 – Spin-Off: Company C is divesting a business unit (“DivCo”) that runs on C’s SAP system. Since DivCo will become an independent company, SAP’s rules say DivCo cannot keep using C’s licenses once it leaves. During deal negotiations, Company C arranges a Transitional Services Agreement so DivCo can continue accessing the SAP system for 9 months post-separation. During that time, DivCo must implement its own SAP instance and sign a new license agreement with SAP under its new name. Company C retains its original licenses (perhaps to use elsewhere internally) but might end up with a surplus if that division represents a significant portion of users. DivCo, being smaller, likely pays more (per license) on its new contract than C did. This scenario is where surprise costs often hit – the carved-out business suddenly faces a hefty new SAP licensing expense as part of becoming independent.
• Scenario 3 – Shared Service Center: A global group decides to centralize SAP operations in one shared service center (SSC) entity. Previously, each region (Americas, EMEA, APAC subsidiaries) had its own SAP contract and licenses. Now, the group wants the SSC (say, an affiliate in one country) to host and manage one SAP system for all. SAP approves the internal transfer of all regional licenses into the SSC’s name, consolidating the contracts. The SSC becomes the single license holder and provider of SAP functionality back to the divisions. Because this is an internal realignment, the license counts and types don’t change — they’re just pooled. Maintenance is now paid by one entity (SSC) but continues uninterrupted for the same licenses. This centralization often uncovers duplicate entitlements that can be cleaned up, simplifying future audits (one central audit rather than many). SAP may require documentation for each transfer, but since ownership hasn’t changed (all entities were under the same parent), it’s routine paperwork. The organization benefits from easier administration and possibly better volume leverage going forward.

Checklist – M&A Scenario Best Practices:

• Include SAP license audits in due diligence. When merging or divesting, always audit the involved SAP environments. Know exactly what licenses exist, how they’re used, and any shortfalls or excess. This prevents nasty surprises post-deal (like finding out 200 extra users are unlicensed).
• Request transitional access agreements in writing. If a carve-out needs to keep using the parent’s SAP temporarily, get a written agreement with SAP for that specific scenario. Don’t rely on informal understandings. Define the scope (which users, which system, and how long) to cover the interim period.
• Maintain compliance until final cutover. For both parties in a split or both sides of a merger, ensure each entity stays compliant during the transition. That might mean restricting cross-access to systems until contracts are merged, or making sure the divested unit stops using the parent’s SAP once the TSA ends. Both the seller and buyer should avoid any “license vacuum” period where a system is used without proper rights.

Negotiating Transfer Flexibility Into Future Contracts

Given SAP’s rigid default rules, the best time to address license transfer issues is before you face an organizational change. When you negotiate new contracts or renewals with SAP, push for clauses that grant you more flexibility down the road.

It’s much easier to get these terms upfront (when SAP is trying to sell you something) than later (when you’re asking for an exception during a merger).

Here are a few best-practice contract clauses to consider adding to your SAP agreements:

• Affiliate Use Clause: “Licenses may be used by any affiliate under common ownership or control of Licensee.” – This clarifies that any current or future subsidiaries you control can use the software. It prevents nitpicking over whether a newly formed or acquired subsidiary is covered.
• Global Transfer Clause: “Licenses may be reallocated or reassigned within Licensee’s group of companies without SAP’s prior consent.” – This explicitly gives you the right to shuffle licenses internally as needed. With this clause, you won’t need to ask SAP every time you want to move licenses from one entity to another inside your organization.
• Successor Entity Clause: “In the event of a merger, acquisition, or corporate reorganization, all licensed rights and obligations shall transfer to any successor or new entity that inherits substantially all of Licensee’s business operations.” – This ensures that if your company merges into another or changes its name, the SAP licenses go along for the ride automatically. It blocks SAP from arguing that a change of control terminates your license rights.

Including clauses like these can save you enormous headaches. They preempt many of the consent requests you’d otherwise owe SAP during M&A or restructurings.

Note that SAP may resist broad language, so you might have to compromise on wording, but even a softened version (like requiring notice instead of consent) is better than nothing. The goal is to embed flexibility so that your SAP investment adapts to your business, not the other way around.

Checklist – Building Flexibility into SAP Contracts:

• Review and update contract language at each renewal. Don’t just roll over your SAP agreement—take the opportunity to add or strengthen clauses that allow affiliate usage, transfers, or assignments to a new entity. What wasn’t negotiable in the past might be negotiable now, especially if SAP wants to sell you more products.
• Ensure new affiliates are automatically covered. If your company is growing (organically or via acquisition), make sure your contract’s affiliate definition and usage rights extend to those new additions. Avoid any requirement that you must “notify within X days” or get approval for each new affiliate’s usage; try to make it blanket coverage.
• Avoid narrow, country-specific restrictions. Push back on any contract terms that tie licenses to a specific region or subsidiary. If SAP presents you a deal limited to “SAP UK Ltd can use these licenses in UK only,” negotiate it to be usable by your global organization. The more globally applicable your contract, the less you’ll have to untangle later.

5 Key Facts About SAP License Transfers to Remember

1. Internal transfers are only free within the same corporate group. You can move SAP licenses around internally, but only among entities you wholly own/control. The minute an entity leaves your group, those licenses can’t go with it without SAP’s blessing.
2. SAP approval is needed for any cross-company reallocation. Whether it’s moving licenses to a sister company, a new parent after a merger, or across-country affiliates, assume you need SAP’s consent (or at least notification) unless your contract explicitly says otherwise.
3. External resale of SAP licenses is forbidden. No matter the circumstance, you cannot sell or give your SAP licenses to a third party outside your organization. Perpetual doesn’t mean transferable – SAP will block any attempt to resell licenses.
4. M&A events demand a proactive licensing strategy. Don’t wait for SAP to catch you. During mergers, acquisitions, or divestitures, plan out how SAP licenses will be handled. Proactively negotiate contract changes or new agreements before users start swapping systems. Documentation and communication with SAP are key to staying compliant.
5. Negotiate transfer and successor clauses in advance. The best time to get flexibility (global usage, affiliate transfers, successor rights) is when you’re signing or renewing your SAP contract. If you wait until after a merger or reorg, it’s too late – you’ll be stuck with the default rules. Having those clauses upfront can save you from licensing gridlock when your company evolves.

Read about our SAP Advisory Services

fredrik.filipsson

Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizations—including numerous Fortune 500 companies—optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.

See Full Bio