CIO Playbook: Managing IBM Licensing in Mergers, Acquisitions & Divestitures

Managing IBM Licensing in Mergers, Acquisitions & Divestitures

Executive Summary

Mergers, acquisitions, and divestitures can dramatically impact IBM software licensing. CIOs must navigate IBM’s strict policies – licenses are non-transferable by default – and ensure compliance through transitions.

This playbook, written in an independent licensing advisor tone, guides CIOs through organizational change with best practices, real-world scenarios, comparison tables, checklists, and recommendations.

Early engagement with IBM and third-party experts is emphasized to avoid costly compliance pitfalls and renegotiate Enterprise License Agreements (ELAs) when needed.

IBM Licensing Policies During Organizational Change

IBM’s licensing agreements include clauses that restrict the transfer of licenses between organizations. Key policies affecting M&A events include:

• Non-Transferability by Default: IBM software licenses cannot be freely transferred to another company without IBM’s explicit approval. If Company A acquires Company B, B’s IBM licenses do not automatically belong to A; formal transfer permission from IBM is required. Passport Advantage (IBM’s licensing program) defines a customer’s “Enterprise” (typically entities over 50% ownership). Any change in corporate structure can alter which entities are entitled to use the software.
• IBM Approval Requirements: Written consent from IBM is mandatory for any license transfer. This involves notifying IBM of the merger, acquisition, or divestiture and providing documentation of the resulting business change. IBM will review contract terms and may approve moving entitlements to the new owner or combined entity. Without approval, continued use by a new entity may be considered unlicensed usage.
• Sub-Capacity Licensing Impact: Many IBM products utilize sub-capacity (virtualization) licensing, which is monitored by the IBM License Metric Tool (ILMT). During transitions, changes in infrastructure or consolidation of data centers can affect sub-capacity entitlements. For example, if two companies merge IT environments, new virtual machine placements might increase PVU (Processor Value Unit) counts. ILMT must be deployed and updated across the new environment to maintain sub-capacity compliance. Failure to update ILMT within 90 days of the change or to generate accurate reports can result in the forfeiture of sub-capacity rights, which can force full-capacity licensing—a costly outcome.
• Enterprise License Agreements (ELAs): IBM ELAs are broad agreements covering multiple products enterprise-wide at a fixed price. Organizational changes can put ELAs at risk:
  • If two companies with separate ELAs merge, the combined usage may exceed the current terms, or certain products may overlap with each other. The ELA might need to be renegotiated or consolidated into a single agreement.
  • If a company under an ELA divests a division, that division loses coverage under the original ELA (since it’s no longer part of the original enterprise). The spin-off must obtain its licenses or an ELA, and the original company may need an ELA amendment to remove the divested unit.
  • IBM may use the opportunity to audit or introduce a new ELA that covers the new structure. Not renewing or making significant changes to an ELA often triggers audits, as IBM checks for compliance gaps once the blanket coverage is altered.
• Contractual Change Clauses: IBM Passport Advantage and other agreements often contain clauses about mergers or acquisitions. For instance, a change in control or ownership might require notifying IBM within a certain timeframe. These clauses dictate rights to continue using software and may require reaffirming that all entities using IBM software are correctly licensed under the agreements.
• Continued Maintenance and Support: If the acquired or divested licenses include IBM Software Subscription and Support, ensure that the support contracts are updated. The new owner may need to reestablish support contracts in their name after the transfer. IBM typically does not allow splitting support without a formal transfer; missing this could leave systems unsupported or out of compliance.

Impact Scenarios in M&A

Below are specific scenarios illustrating IBM licensing challenges during organizational transitions, with guidance on managing each:

1. Merger of Two IBM-Customer Companies

Scenario: Companies A and B, both IBM customers, merge to form a single organization. Each has IBM software deployed, including databases and WebSphere, under separate Passport Advantage agreements or Enterprise License Agreements (ELAs).

Challenges & Actions:

• License Consolidation: Each company’s licenses were purchased under separate entitlements. After merging, the new entity likely wants to consolidate these for efficiency. Action: Inventory all IBM licenses from both A and B. Engage with IBM early to discuss merging the Passport Advantage agreements or consolidating all entitlements under a single master account. IBM can help consolidate entitlements into a single agreement covering the new enterprise.
• Sub-Capacity Reassessment: Both A and B ran IBM software on their servers. After the merger, data centers may be consolidated, or workloads may be moved between environments. Action: Run ILMT across the combined infrastructure. Ensure that ILMT captures any new virtualized deployments. Recalculate PVU usage when combining server farms to avoid inadvertently exceeding licensed capacity.
• ELA and Contract Alignment: If either company has an ELA, determine how the merger affects those contracts. Action: Review ELA terms for change-of-control provisions. You may need to renegotiate a new ELA that covers the merged entity’s full software portfolio. The merged company can use its increased scale as leverage for better ELA pricing or broader product coverage.
• Transitional Use: Immediately after the merger, systems from both companies will run in parallel while they are integrated over several months. IBM licenses are typically tied to one enterprise, so using them across the pre-merger boundary is problematic without permission. Action: Request IBM’s approval for temporary transitional arrangements. IBM often permits the time-bound use of each other’s licenses to maintain operations during integration, sometimes via a written rider or interim license.
• Audit Preparedness: Mergers are a known audit trigger. IBM knows that when two companies merge, they might have overlapping licenses or confusion in entitlements. Action: Proactively document all steps taken – inventory lists, IBM communications, transfer approvals, ILMT reports – to demonstrate compliance. Consider a self-audit with a third-party licensing expert right after merger completion to identify any gaps and address them before IBM comes knocking.

2. Acquisition of a Company Using IBM Middleware/Cloud Pak

Scenario: Company A acquires Company C, a smaller firm that heavily uses IBM middleware (e.g., IBM WebSphere, DB2) and perhaps a modern IBM Cloud Pak solution. Company C’s software was licensed under its contracts.

Challenges & Actions:

• Entitlement Transfer: Company A wants to continue using Company C’s IBM software without interruption. Action: Immediately review C’s IBM contracts. Determine if those licenses are perpetual or subscription, and whether they were under Passport Advantage. Submit a formal request to IBM to transfer C’s licenses to A. This involves paperwork that is co-signed by both parties and requires approval from IBM. If IBM approves, C’s Proofs of Entitlement (PoEs) and support can be reissued under A’s account.
• License Gaps: If any of C’s IBM products were not fully licensed or if C was out of compliance (e.g., missing ILMT or over-deployed), A inherits a risk. Action: During due diligence, audit C’s IBM deployments. If shortfalls are found, negotiate with IBM before finalizing the acquisition if possible. IBM may allow purchasing additional licenses or adjusting an ELA to cover C’s usage as part of the deal.
• Cloud Pak Considerations: Cloud Paks are sold as bundles with container-based metrics, such as Virtual Processor Cores. They often include Red Hat OpenShift rights. Action: When acquiring a company using a Cloud Pak, ensure that either the existing Cloud Pak licenses are transferred or plan for a “trade-up” where A uses its own Cloud Pak entitlements to replace C’s deployment. Check if the versions align; sometimes older entitlements need to be upgraded to merge into an existing Cloud Pak license.
• Cost Optimization: After acquisition, A might have duplicate IBM capabilities (for example, both A and C have integration middleware). Action: Engage IBM or an independent advisor to see if consolidating licenses can reduce costs. Perhaps some of C’s licenses can be dropped if A has capacity under its existing licenses, or vice versa. Use the acquisition as an opportunity to rationalize the IBM software footprint.
• Support and Maintenance Alignment: If C had IBM support contracts, those need to be transferred or new ones under A. Action: Work with IBM to co-term maintenance renewals. Align support renewal dates and terms so that the acquired software is on the same renewal schedule as A’s environment. This makes future budgeting and ELA negotiations easier.

3. Divestiture of a Business Unit Using IBM Software

Scenario: Company A is divesting (spinning off or selling) Division X, which relies on various IBM software products. Post-divestiture, Division X will either become a new independent company or be acquired by another firm.

The question arises: What happens to the IBM licenses that Division X was using?

Challenges & Actions:

• Entitlement Ownership: Under IBM’s rules, licenses are typically owned by Company A (the original licensee) and are not automatically “sold” with Division X. Action (Option 1: Transfer): If Division X is to continue using the same IBM software, Company A must seek IBM’s approval to transfer those licenses to the new owner of Division X. IBM will evaluate if those transfers meet policy (often allowed if Division X becomes a separate legal entity and both buyer and seller agree). Action (Option 2: New Licenses): If transfer is not approved or feasible, the new entity or buyer must purchase new IBM licenses for Division X. Plan for this cost in the divestiture deal negotiations to avoid surprises.
• Scope of Divestiture: Often, not all of A’s IBM software used by X can be neatly carved out. For example, X might have been using a shared IBM instance or IBM software deployed on shared infrastructure. Action: Establish clear boundaries. For any shared systems, decide whether X will run in its environment after separation (requiring new licenses) or if A will continue to provide services under a transition services agreement (TSA). Note: IBM generally prohibits using licenses for the benefit of third parties without permission. If A will temporarily host services for X after the sale, IBM must approve this TSA arrangement.
• Passport Advantage Account Split: If Division X was not a separate Passport Advantage site, its entitlements are intermixed with A’s. Action: Work with IBM to identify which entitlements (part numbers and quantities) are allocated to Division X’s usage. IBM can then transfer those entitlements into a new account for X’s new owner, if approved. If Division X had its own Passport Advantage site, transferring it to the buyer is simpler (IBM can reassign the site under the buyer’s agreement).
• Compliance at Handover: Just as in acquisitions, any compliance issues travel with the divestiture. IBM will often hold the original company (A) responsible for any shortfalls up to the time of separation, and the new company will be responsible for any shortfalls after that. Action: Conduct an internal compliance check on Division X’s IBM usage before divestiture closes. Resolve any over-deployment (either by purchasing additional licenses or uninstalling excess) to give the new owner a clean slate. This protects A’s reputation and avoids post-sale disputes.
• Licensing NewCo (New Company): After the spin-off, Division X (NewCo) will likely need its own IBM agreements. Action: Advise NewCo to quickly establish a Passport Advantage agreement in its name and, if necessary, negotiate an Enterprise License Agreement (ELA) for its future needs. NewCo might initially rely on transferred licenses, but as a standalone, it should build its direct relationship with IBM.

Comparison of Licensing Implications: Merger vs. Acquisition vs. Divestiture

The table below summarizes key IBM licensing implications across these three scenarios:

CIO Checklists for IBM Licensing in M&A

Pre-Deal Planning Checklist

Before the deal (merger, acquisition, or divestiture) is finalized, CIOs and IT leaders should:

• Form a Licensing Task Force: Assemble a team including IT asset managers, legal counsel, procurement, and third-party IBM licensing specialists. Make this team responsible for all software licensing aspects of the deal.
• Inventory All IBM Software Assets: Catalog every IBM software deployment in scope. Include product names, version, quantities (e.g., PVUs, users), license type (perpetual or subscription), and current support status. Do this for both your organization and the other party in the deal.
• Review Contracts & Entitlements: Gather IBM Passport Advantage agreements, MLAs (Master License Agreements), ELAs, and Proof of Entitlements for all identified software. Pay special attention to any clauses about mergers, acquisitions, or change of control. Note which licenses are perpetual (owned) versus term (rented), as this affects transferability.
• Assess Transferability: For each IBM product, determine if transfer is allowed in principle. (Most do with approval, but some very old or special licenses might not.) Identify any geographic or entity restrictions (licenses might be restricted to use in certain countries or by specific subsidiaries).
• Check Compliance Posture: Conduct a quick compliance health check. Are all deployments within the entitled limits? Has ILMT been running properly for all sub-capacity products, such as WebSphere, DB2, and IBM Cloud Paks? Identify any compliance gaps now – these will need to be addressed either before the deal closes or immediately after.
• Engage IBM Early: Inform your IBM account manager (under NDA if needed) that a corporate event is planned. Early dialogue can open options: IBM might share its M&A licensing guide and assign specialists to help. Early engagement also demonstrates good faith, which can be valuable when negotiating contract adjustments later.
• Plan for Transitional IT: Outline how IT systems will be combined, separated, or cooperated during the transition. If, for example, the plan is for a divested unit to be supported by the parent company’s IT for six months, a plan for licensing is needed (likely a formal TSA with IBM’s blessing to avoid third-party use violations). Document these needs to discuss with IBM.
• Budget for Licensing Costs: Include a line in the deal budget for potential license purchases. M&A often reveals the need for additional IBM licenses, such as to cover a shortfall or to license a new environment after separation. It’s better to have funds earmarked than be caught off guard. Use worst-case compliance gap estimates to inform this number.
• Third-Party Expert Consultation: Before finalizing agreements, have an independent IBM licensing advisor review your plans. They can validate whether the approach is sound, identify hidden risks, and even suggest negotiation points with IBM, such as credit for redundant licenses or advice on converting separate licenses into an Enterprise License Agreement (ELA).

Post-Deal Execution Checklist

Once the merger, acquisition, or divestiture deal is completed and Day 1 of the new organization arrives, the CIO’s team should execute the following:

• Execute License Transfers: Immediately work with IBM to complete any agreed-upon license transfers. Ensure IBM provides written confirmation of entitlement transfers in Passport Advantage or via updated entitlement documents. Save these records.
• Set up New Accounts/Agreements: If a new entity has been created (e.g., a spin-off), ensure it has registered for IBM Passport Advantage and set up its account. If a combined entity were formed, rationalize whether both old PA accounts are retained or one is retired. Establish any new ELAs or contracts that have been negotiated and have them signed and in effect.
• Deploy and Align ILMT: Align your license tracking. If two IT environments are merged, unify ILMT into a single reporting system as soon as possible. If a business splits off, set up ILMT for the new environment separately. Run a fresh baseline report to confirm the current deployment vs entitlement count in the new structure.
• Monitor Usage Closely: In the chaotic early months of a transition, systems are constantly changing. Keep a tight watch on IBM software usage. If projects accelerate IBM deployments (such as new VMs or extra instances to support integration), ensure they are properly licensed. It’s easy to inadvertently deploy an extra IBM Database instance for testing without accounting for it. Have the licensing team review any IBM software installation requests during the transition period.
• Retire Duplicative Software (Merger specific): After merging, identify redundant IBM software and plan to decommission it to avoid paying for maintenance twice. For example, if both companies had a license for the same monitoring tool, decide on one and phase out the other. However, coordinate with IBM – if you drop licenses, it might affect your ELA commitments or support entitlements. Possibly schedule this for the next renewal cycle.
• Validate Support Coverage: Double-check that all IBM products in use are covered under a current support contract, either through the new combined support agreement or individual contracts. If any support was accidentally dropped due to the organizational change (common when contracts are tied to an entity that no longer exists), contact IBM to reinstate support and avoid a lapse. Lapsed support can incur hefty back-maintenance fees if not addressed quickly.
• Update Documentation: Maintain an updated license position document reflecting the post-deal state. Include how many licenses are owned, which agreement they fall under, what each is being used for, and any new license purchase made due to the deal. This document will be a lifesaver if an IBM audit occurs or when you need to optimize licenses in the future.
• Renegotiate as Needed: After a merger or acquisition, you may realize that the combined organization would benefit from a different licensing model, such as shifting to a concurrent user model or moving some on-premises licenses to IBM Cloud alternatives. Engage IBM to renegotiate terms if needed. Also, consider timing – many CIOs plan to renegotiate or renew an ELA a few months after a major M&A, once they have clarity on their needs, to right-size the contracts.
• Periodic Compliance Audits: Schedule an internal audit (or a third-party audit) 6-12 months after the transition. By then, systems will have settled. This audit will catch any compliance drift, such as an overlooked server or an admin who set up an IBM product outside of ILMT tracking during the hectic transition. Early detection allows remediation before IBM’s official auditors arrive.
• Knowledge Transfer & Training: If a new team (in an acquired company or a new spin-off) is now responsible for IBM licensing, ensure they are trained on IBM compliance basics (e.g., ILMT usage, counting PVUs, IBM’s definition of an “enterprise”). Share internal policies about software asset management. This prevents well-intentioned staff from making changes that inadvertently break compliance.

Proactive Engagement and ELA Considerations

Engage IBM Proactively: As reiterated, engaging IBM early and transparently is a cornerstone of success.

IBM is more likely to cooperate (and perhaps be lenient or creative in solutions) if you bring them into the loop before they discover a change through rumor or audit.

Early engagement can lead to:

• IBM is providing written guidance or even a dedicated team to assist with transfers.
• Possible short-term arrangements, like bridge licenses or temporary waivers, that keep you legal during transitional periods.
• Better positioning in subsequent negotiations – IBM account reps appreciate a heads-up and might advocate on your behalf for special approvals.

Revalidate or Renegotiate ELAs: After any significant organizational change, review your ELA (if you have one):

• Scope and Definition: Ensure the definition of the customer’s enterprise in the ELA covers any newly acquired entities. If Company B were acquired, are they explicitly named or covered by the >50% ownership rule? Update the contract as necessary to list new subsidiaries or exclude those that have been spun off.
• Entitlement Rebalancing: M&As can shift how much of each software is needed. You might be under-utilizing some licenses and over-utilizing others compared to your ELA’s original allocations. IBM might allow a one-time rebalancing of products in an ELA post-merger – for example, swapping surplus licenses of Product X for needed licenses of Product Y, to better fit the new usage.
• Financial Commitments: ELAs often involve committed spend or pre-paid amounts. A merger could increase your usage, possibly requiring an upsell to the ELA, whereas a divestiture might leave you paying for more than you need. Action: Negotiate with IBM to adjust the financial terms if the original assumptions changed drastically. This could be via an amendment or waiting until renewal, but flag it early.
• Termination or Initiation: Sometimes companies use an M&A event to exit an ELA (e.g., the acquired company had its ELA that they now want to terminate in favor of the parent’s agreements) or to sign a new one (to cover a broader set of licenses enterprise-wide). Work closely with IBM – early termination might incur penalties unless negotiated, and new ELAs can be timed to coincide with the integration for maximum value.
• Legal Review: Always involve your contracts or legal team to review any changes to agreements. Ensure any new terms (especially those introduced during renegotiation) don’t inadvertently lock you into unfavorable conditions long-term.

Audit Risks and Compliance Enforcement

IBM is known for active license compliance enforcement. M&A events raise several audit red flags:

• Unreported Entity Changes: If IBM isn’t formally notified of a merger or divestiture, it may still become aware of the change through press releases, industry news, or changes in purchasing patterns. Unreported changes are viewed negatively. IBM could suspect the new entity is using software without proper licenses and initiate an audit.
• Entitlement Gaps: During transitions, mistakes can occur – perhaps a license transfer was overlooked or a divested unit continued using a product for a while without a valid license. IBM auditors look for these gaps. They will audit the current enterprise and may also review historical usage around the time of the event to identify any periods of unlicensed use.
• Top Audit Triggers Relevant to M&A Include the Rapid growth of the install base, significant IT infrastructure changes, and non-renewal of an Enterprise License Agreement (ELA). These can all coincide with M&A. For example, merging two companies’ IT could double capacity without equivalent license growth (a red flag!), or a decision to drop an ELA due to a spin-off could prompt IBM to check compliance immediately afterward.
• Penalties: Non-compliance found in an audit can lead to hefty back maintenance fees, required purchase of licenses at list price, and in severe cases, legal action. If a divested unit used the parent’s software illegally after separation, both companies could face penalties: the parent for sharing licenses and the divested company for using unauthorized software. Thus, proper separation with IBM’s blessing protects both parties.
• Mitigation: The best defense is preparation. All the steps in this playbook – thorough inventory, IBM engagement, documentation, internal audits – serve to mitigate audit risk. If IBM does announce an audit, having clear records of what changed, when, and all communications with IBM can streamline the process and demonstrate control. It’s also wise to engage a third-party IBM audit defense expert if a formal audit happens soon after an M&A; they can interface with IBM’s auditors and ensure the scope is fair and the outcome is managed.

Recommendations for CIOs

Managing IBM licensing through organizational change is a high-stakes endeavor. CIOs should treat license management as a core part of the M&A strategy, not an afterthought.

Key recommendations include:

• Integrate Licensing into M&A Strategy: Make software asset evaluation a standard part of the due diligence process. Just as you review financials and HR liabilities, review software license liabilities and assets.
• Leverage Third-Party Licensing Experts: Independent IBM licensing advisors can provide an unbiased assessment of your compliance and help strategize the most cost-effective path. They often know IBM’s playbook, can foresee issues, and negotiate on your behalf. Engaging such experts at the planning stage and during post-merger integration will likely pay for itself by identifying savings or avoiding audit penalties.
• Maintain a License Compliance Culture: Organizational change often brings new teams and staff into the fold (or spins them out). It’s crucial to instill the importance of software compliance in IT management from the start of the new organization. Consider quick training sessions or briefings for IT admins about IBM rules in the new context.
• Budget and Plan for the Worst, Aim for the Best: Hope that IBM will be cooperative and that compliance checks find no issues, but budget as if you might have to purchase a chunk of licenses or settle an unexpected compliance bill. This conservative approach ensures the financial impact is planned. Then work diligently to avoid needing to spend it by achieving compliance and negotiating well.
• Document Everything: Keep a paper trail of communications with IBM, license transfers, approvals, and internal analyses. Not only does this help with audits, but it also aids knowledge transfer if personnel change. Future stakeholders should be able to understand what was done and why.
• Future-Proof Where Possible: When negotiating new or updated contracts with IBM around the M&A, try to include flexible provisions for future changes. For example, if you’re negotiating an ELA post-merger, see if you can get a clause allowing some license transfer rights in case you divest part of the business later. While not always granted, it never hurts to ask for clauses that cushion future M&A events.

In summary, a CIO must be both strategic and vigilant: strategic in using the M&A moment to optimize IBM licensing (eliminating waste and securing better terms), and vigilant in closing compliance loopholes.

IBM software is often mission-critical – keeping it properly licensed through corporate changes avoids business disruption and unplanned costs. By following this playbook and seeking expert help, organizations can navigate IBM licensing in transitions smoothly and emerge in a strong position for the next chapter.

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

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit