Licenses in Mergers & Acquisitions: How to Manage SAP Entitlements During Corporate Change

Introduction – Why M&A Creates SAP Licensing Complexity

Mergers, acquisitions, and divestitures are where SAP licensing models collide — and where mistakes can cost millions. Corporate transactions disrupt the assumptions baked into SAP contracts.

Questions emerge immediately: Who legally owns each SAP license? Can entitlements move to a new entity after a sale or merger? What happens to maintenance fees and support continuity when organizations combine or split?

Without clear answers, an M&A deal can quickly stumble into licensing trouble. SAP agreements are tied to specific legal entities, not just “the business” in general. When you merge companies or carve one out, those agreements don’t automatically adjust to the new reality.

This makes SAP license compliance a critical due diligence item. A licensing misstep during corporate change can mean surprise costs, post-transaction audits, or even disrupted systems if SAP revokes support.

The takeaway: treat SAP license management as a core part of any M&A integration or separation plan. For more insights, read our guide SAP True-Downs & License Transfers: Reducing Your License Footprint.

By reviewing entitlements early and often during a deal, CIOs and procurement leaders can avoid compliance landmines and prevent vendors from exploiting the chaos. Corporate change is hard enough – you don’t need an unexpected SAP bill on top of it.

Understanding SAP’s Licensing Framework in Corporate Transactions

SAP’s licensing framework hinges on legal definitions. SAP licenses are granted to a specific contracting entity (“Licensee”), usually a company name. These rights do not automatically extend to other sister companies or a new owner. Usage by subsidiaries or affiliates is only permitted if the contract explicitly allows it. For example, some SAP contracts include an affiliate use clause for wholly-owned subsidiaries – but many do not. Always verify what your contracts say about affiliate usage and corporate changes.

Crucially, SAP licenses are non-transferable without SAP’s prior written consent. Standard SAP agreements include strict anti-assignment language, such as: “Licenses are non-transferable except within wholly-owned affiliates of the Licensee” or “In the event of corporate restructuring, the rights granted hereunder do not extend to successor entities without SAP’s approval.” In plain terms, you cannot simply hand off or share SAP licenses to a new company after a merger, acquisition, or divestiture. Any transfer of usage or ownership typically requires SAP to sign off – often with conditions attached.

Because of this framework, every M&A event demands a close reading of your SAP contracts. Key actions include identifying the official Licensee for each SAP agreement and mapping out which business units use which licenses. Many organizations are surprised to discover that an SAP system used across multiple divisions is legally tied to just one corporate entity. If that entity changes or splits, the licensing rights can be thrown into question.

Checklist:

• Identify the Licensee on each SAP contract: Know exactly which legal entity owns the SAP licenses.
• Review affiliate-use and transfer clauses: Determine if your agreements allow usage by affiliates or assignment during reorganizations.
• Map current SAP usage by entity: Document which parts of the business (subsidiaries, divisions) are accessing each SAP system, to pinpoint what would change if entities merge or separate.

Scenario 1 – Mergers (Two SAP Customers Combine)

Situation: Two companies – both running SAP – merge into one new entity. On paper, the businesses combine, but what about their SAP licenses?

Licensing Challenges: First, there will be overlapping entitlements and duplicate license metrics. Each company had its own SAP contract with user licenses and engine products. Now, as a merged firm, you might have, for example, 1,000 total users but 1,200 licensed users (because each side had licensed the same 600 employees separately).

Without adjustment, the merged company would be stuck paying maintenance on more licenses than it actually needs. There may also be conflicting contract terms, such as different discount levels, special provisions, or support fee percentages that SAP had negotiated with each company.

Finally, SAP tends to seize this moment to push for contract consolidation. They will often propose a new “merged” agreement to replace the two existing contracts. Beware: a new contract can reset pricing to SAP’s advantage (wiping out legacy discounts) or increase the maintenance fee base by recalculating it on a combined list price.

Best Practices: Before any IT integration, conduct a thorough pre-merger license inventory across both companies. Compare the entitlements and metrics side by side to identify overlaps. Which SAP modules or user types do both organizations own? Where are there duplicate licenses for the same product? This analysis arms you with facts to negotiate. If Company A and Company B each have 500 licenses for a given module, but the merged operation only needs, say, 800, you have 200 surplus licenses to address. Plan how to right-size the combined license portfolio so you’re not over-licensed post-merger.

Next, enter talks with SAP to craft a merged licensing baseline that retains the best of both legacy deals. Do not accept a “fresh start” contract at list prices. Instead, insist that the combined entity’s contract honors the original pricing and discount levels from both sides. Negotiation tip: push SAP to recognize each legacy discount structure rather than defaulting to a new, lower discount.

For instance, if one company enjoyed a 50% discount on SAP ERP users and the other had 45%, the merged deal should maintain those favorable rates for the respective quantities, or even improve on them, given the larger combined spend. The goal is to avoid the scenario where SAP uses the merger to erase your hard-won discounts. It is possible to achieve a unified contract without losing commercial benefits – but only if you proactively negotiate it.

Also, address maintenance fees in these merger discussions (more on maintenance below). If both companies were paying annual support, ensure SAP doesn’t double-dip on maintenance for overlapping licenses.

The merged support should ideally equal what you were paying separately, or less if you’re eliminating redundant licenses. All of this should be hammered out before fully integrating the SAP environments.

Checklist:

• Perform a pre-merger license reconciliation: Inventory and align both companies’ SAP entitlements to spot any duplicate or overlapping licenses.
• Identify duplicate products or engines: Pinpoint modules both firms own (e.g., two Business Warehouse licenses) and decide which to keep or consolidate.
• Negotiate a unified contract early: Work with SAP on a combined licensing agreement that preserves original discounts and support terms. Set the merged maintenance base in writing before you integrate systems.

Read about SAP license transfer options, SAP License Transfer Options: Moving Licenses Within Groups and Post-Merger.

Scenario 2 – Acquisitions (SAP vs. Non-SAP Target)

Situation: An SAP customer acquires another company. The acquired target may or may not be running SAP. This scenario splits into two paths:

If the Target Uses SAP: Determine quickly who owns the target’s SAP licenses and how they can be handled. In an acquisition, the target company’s SAP licenses remain with that legal entity (now your subsidiary). SAP’s default stance is that those licenses cannot simply be merged or transferred to the acquiring company without consent.

Review the target’s contract to see if it has an affiliate clause or change-of-control provision. If the target was part of a larger group previously, check whether their SAP licenses were under a parent agreement or standalone.

Your first option should be to see if the target’s SAP entitlements can be brought under your umbrella via existing contract terms. For example, does your own SAP contract allow newly acquired subsidiaries (affiliates) to use your SAP software? If so, you might choose to eventually migrate the acquired business onto your SAP systems and terminate the target’s separate system. However, migrating users over will likely require purchasing additional user licenses under your contract or formally transferring licenses.

Request SAP’s approval for a license transfer or consolidation as needed. In some cases, SAP may allow the acquired company’s licenses to be assigned to the parent (you) or converted into your contract metrics, but this is expected to involve negotiation.

If the contracts prohibit any transfer, SAP may require a relicense or a contract consolidation to continue using SAP in the new organizational structure. Be cautious: SAP could insist on a net-new license purchase for the acquired operations or upsell you to a larger license bundle.

Don’t simply accept that outcome without exploring alternatives (like keeping the target’s system running separately under a TSA, or leveraging the combined spend for a better deal).

If the Target Does Not Use SAP: In this case, you are extending your SAP environment to a new group of users (the acquired employees or business data). Even though no additional SAP contract comes with the target, there will be licensing impacts on your side. New users, new data, or new business processes from the acquired company likely mean you need more SAP licenses or new SAP modules to cover them.

Assess what additional usage will be required: for example, if 300 employees from the acquired firm will start using your SAP system, ensure you have or purchase the appropriate additional Named User licenses for them. If the acquisition brings in a business process that wasn’t in your SAP scope before (say the target company has a warehousing operation and you want to use SAP WM for them), you might need to license that SAP component where you hadn’t before.

The key here is leveraging the acquisition as a negotiating moment. Use the increased scope and spend to negotiate better pricing for the new licenses or even credits. You are effectively buying more SAP capacity – SAP sales will be keen to expand the footprint. This allows you to ask for volume discounts or to renegotiate some terms.

For instance, if you need 200 new SAP user licenses for the acquired staff, don’t just pay list price. Make the case that with the larger user count, you should get a better per-user price (benchmark what similar-sized SAP customers pay). You might also explore if SAP will credit some value for any legacy systems being replaced or give a migration discount.

Finally, notify SAP early about the acquisition’s licensing needs (without over-sharing strategic details). Bringing SAP into the conversation at the due diligence or early integration planning stage can help align contracts or at least set expectations.

It’s better to have SAP aware of changes than to surprise them post-close with a bunch of new users live on the system (which could trigger compliance concerns).

Checklist:

• Confirm the target’s SAP license situation: Does the acquired company have its own SAP contract? Identify license metrics and any restrictions or parent ownership.
• Check affiliate clauses in your contract: Determine if your SAP agreement permits usage by newly acquired entities, and under what conditions.
• Plan license alignment before integration: If integrating systems, engage SAP to either transfer the target’s licenses or procure additional licenses. Use the acquisition’s scale to negotiate favorable pricing or contract terms up front.

Insights to Avoid Shelfware, Contract Clauses on Termination & Shelfware: How to Prevent Paying Forever for Unused SAP Licenses.

Scenario 3 – Divestitures and Spin-Offs

Situation: A company is divesting or spinning off a part of its business into a new entity. Unlike a merger, here one organization becomes two (or more). The big question: can the departing business keep using SAP, or take some of the licenses with it?

Challenges: In most cases, divested entities cannot keep or use the parent company’s SAP licenses – at least not without SAP’s agreement. The SAP licenses remain with the original Licensee (the parent company).

From SAP’s perspective, the spin-off (let’s call it “SpinCo”) is a brand-new company with no rights under the parent’s contract once it’s fully separated. This means SpinCo typically must purchase its own SAP licenses under a new agreement if it needs to continue running SAP. SAP often enforces this by requiring the spin-off to sign a fresh contract, which can be a costly surprise built into the deal.

During the interim, there is also the issue of transitional access. The divested unit will still need systems to operate on day one after separation. Often, the easiest path is to allow it to continue using the parent’s SAP system for a short period after closing, under a Transitional Services Agreement (TSA). However, without permission, this scenario is technically unlicensed usage: SpinCo would be accessing SAP even though it’s no longer an affiliate of the parent.

SAP’s standard contracts forbid that, meaning both companies would be out of compliance. To avoid this, you must negotiate with SAP for a temporary usage arrangement. Typically, companies negotiate a TSA addendum allowing the spin-off to use the parent’s SAP environment for 6–12 months post-separation while they transition to their own systems. This needs to be formalized, as SAP otherwise could consider any continued use a contract breach.

Another challenge is what happens to the licenses left behind. The parent company (ParentCo) might have several SAP licenses that were originally supporting the divested business. After SpinCo leaves, those licenses could become shelfware – unused licenses that ParentCo still owns (and pays maintenance on).

Unless addressed, ParentCo could be stuck paying annual maintenance fees for SAP users or engines that are no longer in use by its remaining business. Reducing that maintenance burden is tricky (SAP doesn’t usually let you drop licenses mid-contract without penalty), but it should be part of the divestiture planning.

Best Practices: Treat SAP licensing as a line item in the divestiture financial model. If you’re selling a division, factor in the cost for that division to get its own SAP licenses (often in the millions) or for maintaining a TSA period. These costs can be negotiated between buyer and seller, but someone will have to pay SAP eventually – it’s better to account for it upfront than be shocked later.

Always notify SAP of the divestiture once it’s public and well before the closing date. Early communication opens the door to discussing options, such as transferring a subset of licenses to SpinCo (if contractually possible) or at least arranging the necessary new licenses and support for SpinCo with minimal downtime.

If you approach SAP proactively, you may have more leverage to negotiate things like credits for the parent’s surrendered licenses or a discounted package for the spin-off, especially if the spin-off might choose a different software vendor. Use that competitive tension wisely.

Secure a Transitional Services Agreement (TSA) with SAP that clearly defines how long the spin-off can use the parent’s system and under what conditions. Make sure there’s a hard cut-off date to motivate the new entity to migrate off and to limit your exposure. Also, plan for support: SpinCo will need its own SAP support contracts and systems by the end of the transition.

Finally, aim for a clean break. By the end of the TSA, SpinCo should be on its own SAP environment (or alternative system) with its own licenses, and ParentCo should have adjusted its license count (and ideally its maintenance fees) to reflect the smaller scope. Keeping a divested unit hanging on indefinitely is not only against contract terms but also a recipe for compliance issues down the road.

Divestiture Licensing Outcomes: Below is a summary of common scenarios in divestitures and how SAP licenses are handled:

Checklist:

• Allocate licenses before the split: Inventory which SAP licenses support the divested business vs. the remaining business. This helps define what SpinCo will need on its own.
• Notify SAP and plan TSA terms: Inform SAP of the pending separation and negotiate a formal Transitional Service Agreement for any continued SAP use by the new entity (duration, scope, fees).
• Include license costs in deal planning: Budget for SpinCo’s new SAP licenses or any fees for transferring licenses. Ensure the divestiture deal considers who pays for what (so neither side is caught off guard by SAP costs).

Handling Maintenance and Support During M&A

SAP maintenance and support fees are often the hidden cost driver during mergers or divestitures. While everyone focuses on licenses, the ongoing annual support can bite you if it’s not managed carefully.

Here’s why M&A scenarios make maintenance tricky:

SAP ties maintenance fees to the specific software licenses and the entity that owns them. If licenses move to a different entity or get combined, SAP may require new maintenance arrangements (often at higher rates).

Similarly, if you drop a portion of your users due to a spin-off, SAP will not automatically lower your maintenance. In fact, your per-license maintenance rate might even increase due to lower volume, unless you negotiate otherwise.

When two companies consolidate, SAP might attempt to re-baseline support costs. This could mean recalculating maintenance on a new, combined license list value (potentially erasing any caps or special low rates one company had).

Key tactics to manage maintenance:

• Negotiate continuity of existing maintenance rates: Don’t allow SAP to “uplift” your support fees just because of a merger. If Company A was paying 18% and Company B 22% of net license value, push to maintain the lower percentage for the combined estate, or at least prevent an increase beyond 22%. Get a written commitment that the merged maintenance percentage will not exceed the weighted average of the originals (or some favorable figure). In many cases, SAP’s standard support is 22% of the license net price per year – ensure they don’t use the situation to slip you into a higher support tier or recalculation at list price.
• Insist on no double maintenance charges: If both merging companies were paying support on similar licenses, the new contract should recognize overlaps so you’re not paying twice. For example, if each company paid support for 500 SAP user licenses, and post-merge,r you only need 800 users total, you should not continue paying maintenance on all 1,000. In negotiation, explicitly address how maintenance will be adjusted to account for retired or redundant licenses. SAP is historically resistant to reducing maintenance, but during M&A, you have leverage – use it to prevent wasteful duplicate fees. One strategy is to ask for a maintenance holiday or credit for a period, or a promise of no maintenance increase for a year or two post-merger, to offset the integration period costs.
• Align support contracts carefully: Check the support renewal dates and terms of each contract involved. It may be wise to co-terminate maintenance agreements or align them in a way that gives you a future opportunity to adjust. If you’re divesting, perhaps negotiate that the spin-off’s new support contract starts only when the TSA ends, so you’re not both paying for the same support simultaneously. If you’re merging, try to consolidate to one support contract to eliminate redundant minimum fees (SAP often has a minimum support fee per contract).

Always keep in mind that maintenance is a huge part of SAP’s revenue. They will try to protect it during changes. It’s up to you to scrutinize every line item. For instance, double-check any combined maintenance invoices after a merger – make sure the total isn’t mysteriously higher than the sum of the two before.

We have seen scenarios where a lack of attention led to a merged company unknowingly paying 15% more in support fees than the two predecessors, simply because the maintenance base was reset to list prices. Don’t let that happen.

Checklist:

• Compare maintenance rates and totals: Identify the annual support percentage and costs for each entity pre-M&A. Use this as a baseline to ensure the post-M&A maintenance doesn’t exceed it.
• Get maintenance terms in writing: As part of the deal with SAP, obtain a written agreement (amendment) that defines future maintenance fees, such as no increase in aggregate maintenance costs or no rate hikes due to changes.
• Maintain support access during transition: Ensure that SAP support user IDs and systems remain active throughout the merger or split. If accounts or customer numbers need merging, coordinate with SAP so that support entitlements (OSS access, support lines) continue uninterrupted for all users.

Legal and Compliance Risks During M&A

During the chaos of M&A, it’s easy to inadvertently step into an SAP compliance violation. The risks aren’t just financial – they’re legal.

Key pitfalls include:

• Unauthorized use of licenses: A very common risk period is between deal closing and IT integration. For example, after an acquisition, the acquired employees might start accessing the parent’s SAP system (or vice versa) before licenses are formally aligned. Or in a divestiture, the spun-off entity might keep using the parent’s SAP for a while. In both cases, if the contract doesn’t allow it (and it usually doesn’t without prior consent), this is unlicensed use. It may be a good-faith mistake, but SAP can audit and penalize it nonetheless.
• Duplicate or wasted maintenance payments: In the flurry of combining companies, some organizations accidentally pay maintenance on the same software twice or continue paying for licenses they no longer need. For instance, if two SAP environments merge but both legacy contracts are left running, you might be paying two sets of support fees where one would do. Alternatively, a parent company might unknowingly keep paying support for a divested unit’s licenses because it didn’t or couldn’t terminate them. These situations waste money and could violate terms if the usage doesn’t justify the support.
• Breach of non-transfer clauses or other contract terms: If M&A actions contradict the license agreement (such as assigning the contract to a new entity without approval, or exceeding usage rights during transition), you’re at risk of breach. SAP’s contracts often stipulate that any change of control or merger must be communicated and that SAP has the right to approve the continuance of the license. Not following these formalities gives SAP the upper hand to demand remedies (usually financial).

Risk Mitigation: Involve your legal team and software asset management (SAM) professionals early in the M&A process – ideally during due diligence. They should review all relevant SAP contracts for clauses about assignment, change of control, affiliate usage, and notify the deal makers of any constraints. Make SAP license compliance a line item on the M&A risk register so it gets proper attention alongside financial and operational risks.

Maintain clear, written communication with SAP about the transition. It’s often wise to inform SAP of the upcoming merger or separation (once publicly known) and discuss how to keep compliant, rather than doing everything quietly and hoping for the best. By having things in writing – whether it’s an email from SAP approving a temporary use, or a formal contract amendment – you create an audit trail that protects you if questions arise later.

Also, put internal controls in place. For example, if two companies are merging but systems aren’t yet consolidated, ensure that no user from Company B is given access to Company A’s SAP (or vice versa) unless you’ve accounted for it in licensing.

Similarly, for a divestiture, tightly monitor and disable access for spin-off employees at the separation date, except as allowed by any TSA agreement. These technical access controls go hand-in-hand with contractual compliance.

Finally, keep documentation of everything. If SAP grants any exception or you negotiate any special terms due to the M&A, file those letters or amendments where your SAM team can find them later.

Two years down the line, you don’t want to be scrambling to prove that SAP allowed a certain usage during the merger – have it in your records.

Checklist:

• Include SAP in the M&A risk assessment: Treat license compliance as a formal risk in the deal and assign someone to manage it.
• Review and follow contract rules: Double-check the change of control notification requirements and any consent needed from SAP before closing the deal.
• Document all communications: Save emails, approvals, and signed documents from SAP related to the merger or divestiture. They are your safety net if a compliance issue is raised in the future.

How to Negotiate with SAP During M&A

M&A events often put SAP’s sales team on high alert. They know you’re in flux and may need contract changes or new licenses – in other words, it’s an opportunity for SAP to reset the commercial relationship. This can actually be to your advantage if you approach it strategically. Here’s how to negotiate effectively with SAP during corporate changes:

Leverage the timing and SAP’s incentives: Remember, SAP has a strong incentive to keep your business and maintenance revenue through the transition.

They also fear the uncertainty – for example, in a divestiture, the spin-off might consider non-SAP systems, or in a merger, the combined entity might rationalize and drop some SAP products. Use this to your benefit. The fact that you could reduce spending or even move away from SAP in parts gives you leverage.

Make it clear (tactfully) that you are evaluating all options. SAP is more likely to offer concessions (like preserving discounts, offering flexible licensing models, or throwing in short-term rights) if it senses that otherwise it might lose out on future business.

Beware of the upsell: It’s common for SAP to use M&A discussions to pitch new products or a migration to their latest offerings.

For example, if you’re merging, SAP might push you to convert both companies onto S/4HANA or RISE with SAP (their cloud bundle) as part of a “consolidated deal.” This can sometimes bring benefits, but it can also be a tactic to increase your spend and lock you into a long-term commitment.

Evaluate these proposals critically. Don’t agree to a big new purchase or cloud subscription just because it’s presented as the easy way to solve a licensing merge. Only commit if it truly aligns with your IT strategy and the pricing is genuinely advantageous after thorough benchmarking.

Insist on legacy pricing continuity: One non-negotiable for your side should be that any new agreement honors the best pricing and terms you already have.

Tell SAP that the merger/acquisition should not be an excuse to roll back prior discounts or favorable conditions. If necessary, show them the math: demonstrate what you were paying per user or per engine before, and ensure the new proposal matches or improves on that.

In one negotiation, a client merged with another SAP customer; SAP’s first offer effectively reduced their overall discount from ~55% to 30%. By pushing back and referencing both legacy contracts, the client secured an outcome with approximately a 60% effective discount on the new combined license pool.

The lesson is to be skeptical of the first offer and ready to counter with data. Use market benchmarks too – if you know what similar-sized companies pay, bring that to the table.

Secure contractual protections for the future: Negotiate specific language to protect against future licensing traps. For example, push for a successor clause that clearly allows licenses to transfer to any future merged entity or buyer.

A sample clause could be: “In the event of a merger, acquisition, or corporate reorganization, all licenses and support entitlements shall continue for the successor or acquiring entity under the same terms, without additional fees or re-licensing requirements, subject only to written notice to SAP.” SAP may not readily agree to everything, but even a watered-down version (like SAP’s consent “not to be unreasonably withheld” for transfers) is better than silence on the matter. These clauses prevent SAP from holding you hostage at the next corporate event.

Also consider asking for price locks or most-favored pricing for a period after the M&A. If you know you’ll need more licenses as you integrate systems, get those rates locked in now as part of the deal. Essentially, bundle as much as you can into a one-time negotiation while you have leverage, rather than coming back piecemeal later when SAP has the upper hand.

Throughout the negotiation, maintain a unified front. Internally align your stakeholders on what the ideal outcome is – be it cost neutrality, specific new products, or contract flexibility. SAP will be looking for pressure points (like a project deadline or internal disagreement) to exploit.

Don’t reveal more than necessary about your timelines or internal debates. Keep the conversation focused on the commercial outcome you need to make the M&A a success without excess cost.

Checklist:

• Define your end-goal upfront: Know what you want from SAP (e.g. no net new cost, specific new licenses, cloud transition on your terms) before negotiations start.
• Use your leverage smartly: Time negotiations with SAP’s quarter/year-end if possible and remind them the business could rethink SAP usage (without making explicit threats).
• Get it in writing: Once you reach a deal, ensure all promises (discounts, transfer rights, future protections) are written into the contract or amendment. Verbal assurances mean nothing later.

Governance – Integrating License Management into M&A Due Diligence

Effective governance means embedding SAP license management into the M&A playbook, rather than treating it as an afterthought. This requires coordination between IT, procurement, and the M&A deal team at every phase:

Before the transaction (Due Diligence): As soon as an M&A event is on the horizon, conduct a thorough review of all SAP licensing involved. If you’re the buyer or merger partner, request information on the other company’s SAP licenses and usage. If you’re the seller, assemble a clear picture of which licenses are used by the part of the business being sold.

Evaluate compliance risks: Is the target using all licenses within rights? Are there any indirect usage or third-party access concerns? Identify any contractual landmines, such as a clause that a change of control might trigger. This pre-work can influence deal terms. For example, if a spin-off requires a fresh $5 million SAP license purchase, that cost can be negotiated into the sale price or covered by the seller. Uncover it early.

During the transition, make SAP license management a visible part of the integration/separation project plan. Assign a dedicated licensing workstream. This team should track which users and systems are being moved, and ensure proper licensing is in place at each step.

Maintain an audit log of changes – e.g., “X users moved from system A to system B on Date, licenses updated accordingly.” If any interim or shared system usage is occurring (like during a TSA or while waiting for contract consolidation), closely monitor that it stays within agreed boundaries.

Keep communication lines open with SAP, but also be mindful to only disclose what’s necessary. You want SAP’s cooperation, not unnecessary scrutiny. Often, involving a third-party licensing advisor or specialist can help manage this phase, acting as an intermediary with SAP to ensure compliance without giving away negotiating leverage.

Post-integration: Once the dust settles, consolidate all SAP license records into one unified repository. Merge the entitlement lists from the formerly separate entities and reconcile them against actual deployment. This is the time to true-up or retire any licenses for systems that were decommissioned.

Verify that the new organizational structure is accurately reflected in the contracts. If you merged companies, ensure there’s a contract stating the new entity name and its rights to all licenses. If you spun off a company, ensure that your records no longer count those licenses and that any retained “excess” licenses are noted (with a plan for their use or termination). Essentially, conduct a post-M&A license audit on yourself to confirm everything is compliant and optimized.

Additionally, update your internal processes to reflect any changes. For example, if two SAP teams merged, make sure they adopt a common license management process. If a company were divested, remove their access to your license management systems.

In the future, have a clear policy that any future M&A activity must loop in the SAM/licensing team from day one. Many companies formalize this by adding an item to the standard M&A due diligence checklist: “Review of software license contracts (SAP, etc.) and identification of required actions.” By institutionalizing it, you reduce the chance of overlooking it next time.

Checklist:

• Add SAP licensing to the M&A playbook: Ensure that every merger, acquisition, or divestiture process has a step to evaluate and plan for software license changes, especially SAP.
• Create a unified license inventory: After merging, combine license entitlements from all parties into one central record. After a divestiture, update the inventory to remove or flag licenses that were tied to the departed unit.
• Schedule a post-M&A compliance check: A few months after the dust settles, do an internal audit of SAP usage vs. entitlements in the new structure. This catches any stragglers or inadvertent compliance issues while you can still correct them proactively.

5 SAP M&A Licensing Rules to Remember

1. SAP licenses belong to legal entities – not to the business as a whole: When companies change, license rights do not automatically follow. Always re-establish who the valid license holder is after mergers or spin-offs.
2. You generally cannot transfer or assign SAP licenses without SAP’s consent: Unless you negotiated flexible terms upfront, any movement of licenses to a new entity requires written approval. Affiliate clauses help, but have limits – get SAP on board before sharing systems.
3. Divested units usually must relicense – plan that cost early: If you’re selling part of the business, expect that the new entity will need a fresh SAP agreement. Budget for it so it doesn’t derail the deal, and use transitional agreements to bridge the gap.
4. Maintenance fees won’t adjust themselves – negotiate continuity: M&A can inflate support costs if you’re not careful. Lock in maintenance terms in writing so that combining or splitting systems doesn’t lead to surprise increases.
5. Document everything and review licenses at each step: Before, during, and after an M&A event, keep meticulous records of SAP entitlements and usage. Have every agreement or SAP communication in writing. This diligence ensures you remain compliant and in control, rather than reacting to problems after they occur.

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