How do you turn software acquisition diligence into closing instructions?
Use a finding-to-document list: identify the affected product or contract, the evidence, the person resolving it and the proposed signing or closing response. A technical report and a purchase agreement should not describe different businesses.
- Start with one material dependency. For a major customer, code component, hosted service or data set, record the exact legal entity and the agreement or ownership record behind it. Link the technical finding to that record rather than marking the whole product “cleared.”
- Separate the reviewer decisions. Have the technical team explain the operating consequence; counsel reviews ownership, contractual restrictions and the proposed transaction steps. A repository login demonstrates access, not the scope of the seller’s rights.
- Resolve the document mismatch. If a customer order permits use of a feature but the underlying third-party license is unclear, put both records in the same issue. Ask who will obtain clarification, what evidence will close the issue and whether the signing plan needs to change.
- Carry the result into the closing set. Identify the relevant schedule, consent, assignment, covenant or other proposed response with counsel. Record who checks the final document and who confirms the technical handoff; confirm completion from the executed document and the completed handoff.
For the underlying request list, use the existing SaaS acquisition legal due diligence checklist. The Copyright Office’s ownership and transfer provisions explain why rights documentation deserves a separate review from source-code access.
For transaction-specific legal scope, use Request Engagement Assessment. Share your role, transaction stage, open decision and next deadline; arrange confidential document sharing after intake.
1. The Technology Deal Landscape
Technology and software M&A has expanded into one of the most active segments of the deal market, driven by the continued migration of enterprise operations onto cloud and SaaS platforms, the acceleration of AI integration across virtually every software category, and the competitive pressure that forces established technology companies to acquire rather than build. Strategic acquirers, including large technology platforms and software conglomerates, pursue acquisitions to expand product portfolios, acquire engineering talent, and eliminate competitive threats. Private equity sponsors build software platforms through sponsor-backed roll-up strategies that aggregate related SaaS or vertical software businesses under a common parent, then drive value through operational improvements, cross-selling, and multiple expansion at exit.
A SaaS purchase-price review can examine trailing revenue, annual recurring revenue, net revenue retention, gross margin, customer acquisition cost and payback period. Each measure needs a defined calculation and supporting records. Counsel can then connect the financial assumptions to customer renewal and termination rights, documented IP ownership and data-use permissions. A weakness in those rights may change the price a buyer is willing to pay or the protections it requests in the purchase agreement.
The buyer profile shapes the legal strategy in meaningful ways. A strategic acquirer integrating an acquisition into an existing product line cares most about IP ownership, product integration feasibility, and engineering team retention. A PE sponsor building a platform cares about ARR quality, customer concentration, contract durability, and the scalability of the go-to-market model. A financial buyer taking a company private from public markets has additional securities law obligations during the process and must coordinate tender offer mechanics or merger agreement execution with public company board processes. Understanding which type of buyer is at the table and what that buyer's post-closing plan is shapes the negotiating posture for founders and management teams who are structuring their own exit and retention arrangements.
2. Deal Structure Options
Technology acquisitions are structured through four principal mechanisms: stock purchases, asset purchases, statutory mergers, and reverse triangular mergers. Each has distinct consequences for tax treatment, third-party consents, liability allocation, and the mechanics of transferring IP and customer contracts. The optimal structure for a given deal depends on the tax objectives of the parties, the composition of the target's liabilities, the assignability of its key contracts, and whether the target has multiple classes of equity that complicate consent mechanics. There is rarely a universally correct structure: the parties negotiate the structure as part of the broader economic package, and each party's counsel must understand the implications of each option before committing to a form.
A stock purchase is the simplest structure from an operational perspective. The buyer acquires all of the outstanding equity of the target entity, which continues to exist as a going concern with all of its contracts, licenses, permits, and relationships intact. Customer contracts, IP licenses, and vendor agreements remain with the target entity; review change-of-control, deemed-assignment and consent provisions before relying on continuity. The disadvantage of a stock purchase is that the buyer acquires all of the target's liabilities, known and unknown, including pre-closing tax exposures, litigation claims, and regulatory violations. For a target with a complex liability profile, buyers may prefer an asset deal even at the cost of greater transactional complexity.
A reverse triangular merger, in which a wholly owned subsidiary of the buyer merges into the target and the target survives as a subsidiary of the buyer, is the most common structure for acquisitions of venture-backed companies with multiple stockholder classes and institutional investors. The reverse triangular structure avoids the need to obtain individual consents from every stockholder because the merger is approved by the board and majority stockholders under state corporate law, with dissenters' rights as the available remedy for non-consenting minority holders. From a contract-assignability standpoint, a reverse triangular merger is treated as a stock purchase in most contexts because the target entity survives the transaction and its legal identity is preserved, though certain contracts specifically address merger transactions and must be reviewed on their own terms.
3. IP Ownership and Chain of Title
Establish intellectual property ownership from the actual creation and assignment records. Under 17 U.S.C. section 201, initial ownership includes a distinct rule for works made for hire. Works created by employees within the scope of their employment qualify as works made for hire under Section 101, with the employer treated as author and owner unless a signed written agreement provides otherwise, but this doctrine does not apply to independent contractors unless the work falls within one of the statutory categories of specially commissioned works and a written work-for-hire agreement is in place. In practice, many software companies engage contractors to write code without executing proper work-for-hire or assignment agreements, which means those contractors may own copyright in material portions of the product as a matter of law.
Founder IP assignments present their own category of risk. In the formation period of a technology company, founders frequently write code and develop inventions before the company is formally incorporated and before employment agreements or IP assignment agreements are in place. Unless each founder has executed an assignment agreement transferring all pre-formation IP to the company, a founder who departs before or at closing may retain ownership of foundational technology. The same analysis applies to any development work performed by founders during periods when they were not formally employed by the company. IP diligence must trace the development history of each material component of the product back to the inception of the company to identify these gaps.
Remediating chain-of-title defects before closing requires locating former employees and contractors, negotiating and executing retroactive assignment agreements, and in some cases compensating individuals who have legal leverage based on their prior development contributions. A nunc pro tunc assignment is an assignment that is executed after the fact but provides that the transfer is effective as of an earlier date, and it is the standard mechanism for correcting historical gaps in IP assignment chains. Where former contributors cannot be located or refuse to cooperate, the parties must assess the severity of the defect and address it through purchase price adjustment, escrow, or specific indemnification provisions rather than relying on R&W insurance, which will typically exclude known title defects. For a detailed treatment of IP ownership issues in technology acquisitions, see the companion guide to IP diligence in technology M&A.
4. IP Diligence Scope
IP diligence in a technology acquisition covers four primary categories: patents, trademarks, copyrights, and trade secrets. Patent diligence assesses whether the target holds issued patents or pending applications that are material to its competitive position, whether those patents are valid and enforceable, whether any are subject to encumbrances such as security interests recorded with the USPTO, and whether any third-party patents present freedom-to-operate risk for the target's core products. Freedom-to-operate analysis, which assesses whether the target's products or processes would infringe valid, enforceable claims in third-party patents, is a distinct exercise from the review of the target's own patent portfolio and requires specialist patent counsel to conduct properly.
Trademark diligence covers the target's registered trademarks and service marks, common law trademark rights in unregistered marks used in commerce, domain names, and any pending trademark applications. For software companies with established brand identities, the trademark portfolio can be a significant component of value, particularly if the brand has recognition in enterprise markets where switching costs are high. Trademark diligence should confirm that the target's marks are properly registered in all relevant classes and jurisdictions, that the registrations have been maintained with timely affidavits of use, and that there are no pending oppositions, cancellation proceedings, or third-party claims that could impair the value of the marks post-closing.
Trade secret diligence focuses on whether the target has implemented reasonable measures to protect confidential technical information, which is a legal prerequisite for trade secret protection under the Defend Trade Secrets Act and state law equivalents. Key indicators of adequate trade secret protection include confidentiality and non-disclosure agreements executed with all employees and contractors who have access to proprietary technology, access control systems that limit exposure of sensitive code and data to those with a legitimate need, and documented information security policies that address trade secret handling. A target that has not maintained these protections may have forfeited trade secret status for code that would otherwise qualify, which weakens the IP protection layer available to the acquirer post-closing.
5. Open Source Software Compliance
Open source software licenses govern the use, modification, and distribution of open source components, and compliance with those licenses is a material legal obligation in every software acquisition. The open source license landscape divides broadly into permissive licenses and copyleft licenses. Permissive licenses, including MIT, Apache 2.0, BSD 2-Clause, and BSD 3-Clause, impose minimal obligations on downstream users, typically requiring only that the original copyright notice and license text be included in distributions of the software. Permissive licenses can allow incorporation into proprietary products, subject to their attribution, notice, patent and other terms; verify the license and the actual use of each component.
Copyleft analysis depends on the exact license version, the covered work, modifications, linking or combination, and how the company conveys or makes the software available. The Free Software Foundation's GNU license FAQ distinguishes private use, distribution and mere aggregation. Under AGPL version 3, modified versions offered for remote network interaction carry a corresponding-source offer requirement. Have counsel and engineers establish the component boundary and actual deployment before concluding that a proprietary product must be disclosed.
An OSS audit can use software composition analysis alongside engineering and legal review. Black Duck is a software composition analysis product used here to identify third-party components and their license risk. FOSSA is a software supply-chain analysis platform used here to inventory dependencies, identify licenses and prepare compliance reports. These tools scan the target's codebase to identify open source components, match them against known license databases, flag copyleft components, identify license compatibility conflicts, and generate a bill of materials for legal review. The audit output should be reviewed by counsel with experience in open source licensing to assess the severity of any compliance issues, determine whether remediation is feasible before closing, and draft appropriate representations, warranties, and indemnities to address residual risk. For a detailed treatment of open source compliance in acquisitions, see the guide to open source software compliance in M&A.
6. SaaS Customer Contract Review
SaaS customer agreements are the primary revenue asset in a software acquisition, and their legal terms directly affect the durability of the ARR the buyer is paying to acquire. Contract review in a SaaS transaction focuses on several categories of provisions: anti-assignment and change of control clauses that could require customer consent or trigger termination rights, uptime service level agreements and the financial consequences of SLA failures, audit rights that allow customers to audit the vendor's security controls or data handling practices, data portability and deletion obligations upon contract termination, and renewal and termination mechanics that determine how reliably revenue renews without active re-selling effort.
Change of control provisions in enterprise software agreements are frequently drafted broadly and with significant consequences. Some agreements give the customer a right to terminate immediately upon a change of control without cause or penalty. Others require the vendor to obtain the customer's prior written consent before closing the transaction. Still others merely require notice within a specified period after closing, with no right to terminate. The distribution of these provisions across the customer base, particularly for large enterprise customers who represent a disproportionate share of ARR, can be a decisive factor in deal structure and purchase price. Buyers typically require the seller to represent that no key customers have exercised or are entitled to exercise termination rights as a result of the transaction.
Uptime SLAs deserve specific attention because they create financial obligations that can affect post-closing economics. Enterprise SaaS agreements commonly include SLA credits for downtime measured over monthly or quarterly periods, with credit amounts scaled to the severity and duration of the outage. A target with a history of SLA credits or pending credit claims has a contingent liability that must be assessed and either disclosed in the purchase price adjustment mechanism or addressed through specific escrow. Audit rights and security review provisions in customer agreements also have operational implications post-closing: customers who retain the right to conduct security audits or review the vendor's SOC 2 reports will do so, and the acquirer must be prepared to satisfy those obligations consistently with its own information security standards. For a detailed analysis of SaaS contract issues in acquisitions, see the guide to SaaS customer contract assignment in M&A.
7. Data Rights and Privacy Compliance
Data privacy is a mandatory diligence category in any technology acquisition where the target collects, processes, or stores personal data. The applicable legal framework depends on the geographic scope of the target's users and customers. GDPR governs the processing of personal data of individuals in the European Economic Area and imposes obligations including lawful basis documentation, data subject rights fulfillment, privacy notice adequacy, data processing agreement execution with processors, data protection impact assessments for high-risk processing activities, and risk-based personal-data breach notification obligations. CCPA and CPRA govern California residents' personal information and impose disclosure, opt-out, deletion, and correction rights, as well as restrictions on the sale or sharing of personal information for cross-context behavioral advertising. State comprehensive privacy laws in Virginia, Colorado, Connecticut, Texas, and a growing number of other states add additional compliance layers that must be mapped against the target's user base.
HIPAA applies to technology companies that function as business associates of covered entities by providing services that involve the use or disclosure of protected health information. A SaaS platform that serves healthcare providers and processes clinical data on their behalf is a business associate, and the business associate agreements it has executed with its covered entity customers are both compliance obligations and contractual assets that must be reviewed in diligence. SOC 2 Type II reports, which assess the adequacy of a company's security, availability, processing integrity, confidentiality, and privacy controls, are standard diligence deliverables for enterprise software companies and provide the buyer with a third-party validated assessment of the target's security posture as of the audit period.
Data portability and data transfer mechanics at closing require separate analysis. Personal data transferred from the target to the buyer in connection with the acquisition is itself a data transfer subject to applicable privacy law, and in some jurisdictions it requires notification to data subjects or, in the case of sensitive categories of data under GDPR, specific legal basis analysis. Post-closing, the buyer must ensure that the personal data it receives is covered by its own privacy notices and legal bases for processing. Where the buyer's privacy framework is materially different from the target's, a transition period may be required during which the target's privacy notices and consent mechanisms remain operative while the buyer's framework is implemented. Buyers with EU operations must also assess whether data transfers between the target and their existing operations require Standard Contractual Clauses or other GDPR transfer mechanisms.
8. Security Representations and Warranties
Cybersecurity representations and warranties in technology M&A have become progressively more detailed as buyers have developed a clearer understanding of how security failures create post-closing liability. A well-drafted security rep package addresses the following: the target has implemented and maintained an information security program that meets industry standards for companies of its size and in its industry; the target has not suffered a security breach that resulted in unauthorized access to personal data or proprietary systems, or if it has, all affected individuals have been notified as required by applicable law and all regulatory reporting obligations have been fulfilled; the target's systems are not subject to known malware, ransomware, or other malicious code that could affect their operability post-closing; and the target's security controls have been audited and the findings remediated on a documented timeline.
Security reps interact with data privacy reps in ways that create overlapping coverage in the purchase agreement. A breach that constitutes both a security failure and a privacy violation may implicate multiple representations simultaneously, and the indemnification mechanics must be structured to avoid inadvertent limitation of recovery through the interaction of different rep packages with separate baskets, caps, and survival periods. Buyers should ensure that the security and privacy representations are drafted with sufficient specificity to cover the scenarios they are actually concerned about, rather than relying on general "compliance with applicable law" representations that may not pick up the specific obligations most relevant to the target's business.
Penetration testing results, vulnerability scan reports, SOC 2 auditor findings, and prior incident response documentation are all material diligence items that should be requested and reviewed before the security representations are finalized. Where the diligence process reveals that the target has known unpatched vulnerabilities or open remediation items from a prior SOC 2 audit, those findings must be disclosed in the schedules to the purchase agreement or addressed through a pre-closing covenant requiring remediation before closing. The purchase agreement should also address the target's obligations to notify the buyer if it discovers a security incident between signing and closing, because a material breach occurring in the signing-to-closing gap can affect the buyer's obligation to proceed to closing under the conditions precedent.
9. Source Code Escrow Arrangements
Source code escrow arrangements deposit a copy of the vendor's source code with a neutral third-party escrow agent under terms that define the conditions under which the beneficiary is entitled to receive and use the code. In an acquisition context, source code escrow is most commonly relevant to the target's relationships with third-party software vendors whose products are embedded in or integrated with the target's platform. If a critical third-party vendor becomes insolvent, is acquired and discontinues the product, or materially breaches its support obligations, a source code escrow release gives the target (and, post-closing, the acquirer) the ability to maintain the software independently. Diligence should identify all third-party software components that are critical to the target's product and confirm whether source code escrow arrangements exist for those components.
Escrow release conditions are the most operationally significant term in an escrow agreement. Common release triggers include the vendor's filing for bankruptcy or insolvency protection, the vendor's ceasing to provide maintenance and support for the escrowed software, the vendor's being acquired and the acquirer discontinuing the product, or the vendor's material breach of the license agreement. The scope of the license granted to the beneficiary upon release is also critical: a release license limited to maintaining the software for the beneficiary's own internal use is significantly less valuable than one that permits the beneficiary to modify, sublicense, and deploy the software in a commercial product. Beneficiaries should also verify that the deposited materials are current and complete through escrow verification procedures conducted at the time of deposit and periodically thereafter.
Source code escrow also arises in the context of the target's own customer relationships. Enterprise customers who license the target's software for on-premises deployment frequently negotiate source code escrow as a condition of the license, providing them with continuity assurance in the event the vendor fails. These customer-facing escrow agreements are contractual obligations that survive closing and must be honored by the acquirer. The purchase agreement should include a representation that all existing source code escrow obligations have been properly performed, that the deposited materials are current as of a specified date, and that the escrow accounts are in good standing with the applicable escrow agents.
10. Third-Party Dependency Analysis
Modern software products depend on a complex ecosystem of third-party APIs, infrastructure providers, payment processors, identity platforms, and data enrichment services. Each dependency introduces legal and operational risk that must be assessed in diligence. API dependencies in particular can be fragile: third-party platforms frequently change pricing, alter API terms, deprecate functionality, or restrict access to data that the target's product relies on. Where the target's core functionality depends on a single third-party API without a long-term contract at defined pricing, the buyer is acquiring a product that may change materially if that provider alters its terms or access policies post-closing.
Cloud infrastructure concentration risk is a related concern. A target that runs entirely on a single cloud provider under the actual provider agreement under contracts that are terminable by the provider with limited notice may face operational disruption if the provider exercises that termination right or changes its terms in ways that affect the target's cost structure. Diligence should review the cloud provider agreements, the committed spend and discounting arrangements that affect the target's hosting cost basis, and whether those agreements are transferable to the acquirer's existing cloud infrastructure relationships. Payment processor agreements deserve equivalent attention: payment processing relationships are subject to the processors' card network compliance requirements, and processors can suspend processing capabilities for merchants that violate those requirements.
The assignability of third-party dependency agreements is often overlooked in favor of the more prominent customer contract assignability analysis. Vendor agreements with API providers, hosting platforms, data licensors, and specialized software tools frequently contain anti-assignment provisions that mirror those found in customer contracts. Where a critical vendor agreement restricts assignment, the acquirer must either negotiate a consent from the vendor before closing or accept the risk of operating in breach of the agreement post-closing until a new agreement can be executed. For dependencies that are difficult to replace, obtaining vendor consent before closing is strongly preferable to relying on the vendor's willingness to contract post-closing on commercially reasonable terms.
11. Cybersecurity Incident History Diligence
A target's cybersecurity incident history is a material diligence topic because past incidents reveal both the adequacy of the target's security controls and whether the target has properly fulfilled its post-incident legal obligations. Buyers should request incident history over a period selected against legal, contractual and operational exposure, including any unauthorized access to systems or data, ransomware attacks, phishing compromises of employee accounts, credential exposure, data exfiltration events, and any events that triggered breach notification obligations under state data breach statutes, GDPR, or HIPAA. Evaluate each prior incident, its remediation and the seller's disclosures against the negotiated representations and remedies. Available claims depend on the agreement, applicable law and proven facts.
Post-incident notification obligations must be verified for each historical incident. State data breach notification statutes in all 50 states require notification to affected individuals and state regulators within specified timeframes when personal information is compromised. Under GDPR Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach, unless it is unlikely to result in a risk to individuals. Article 34 separately governs communication to affected people where the breach is likely to result in a high risk, subject to its exceptions. HIPAA requires notification to affected individuals, the Secretary of HHS, and in some cases the media, within specific timeframes depending on the number of affected individuals. Failure to provide required notifications creates ongoing regulatory exposure that survives closing and becomes the buyer's problem unless identified and addressed in the purchase price or indemnification structure.
Ongoing regulatory investigations or enforcement actions arising from prior cybersecurity incidents must be identified before closing because they can create material liabilities that are not reflected in the target's financial statements. The purchase agreement should include a representation covering the absence of material pending or threatened governmental investigations relating to cybersecurity or data privacy, and the disclosure schedule should itemize any known investigations or inquiries. Where an investigation is ongoing, the parties must negotiate the appropriate escrow or holdback to address the potential liability, and the indemnification provisions should clearly allocate responsibility for pre-closing incidents to the seller regardless of when the regulatory action is finally resolved.
12. Export Controls: EAR and ITAR
The Export Administration Regulations, administered by the Department of Commerce Bureau of Industry and Security, control the export, re-export, and in-country transfer of dual-use goods, software, and technology. EAR applies to software that has a commercial use but may also have military applications, including encryption software, network security tools, and software containing certain controlled algorithms. Any software classified under an Export Control Classification Number other than EAR99 is subject to license requirements for export to certain countries or end-users, including countries subject to comprehensive sanctions and entities on the Entity List, Denied Parties List, or Specially Designated Nationals list. EAR compliance diligence should confirm that the target has classified its software products accurately, applied for any required licenses, and maintained records of exports and re-exports as required by the regulations.
The International Traffic in Arms Regulations, administered by the Department of State Directorate of Defense Trade Controls, govern the export and import of defense articles and defense services listed on the United States Munitions List. Software or technology companies that develop products for defense applications, or that incorporate technology derived from defense research programs, may find their products subject to ITAR jurisdiction. ITAR compliance is significantly more demanding than EAR compliance: ITAR registration is required for any entity that manufactures or exports defense articles, ITAR licenses are required for most exports and re-exports of controlled items, and the definition of "export" under ITAR includes disclosure of controlled technical data to foreign nationals within the United States, which affects routine engineering hiring and collaboration practices.
Encryption software is subject to specific EAR controls under Export Control Classification Number 5D002, and most commercial encryption is eligible for a license exception under EAR Section 740.17 subject to a one-time review and reporting requirement. Diligence should confirm that the target has properly classified its encryption functionality, completed any required BIS reviews or notifications, and maintained records of those filings. For companies that employ foreign nationals with access to controlled technology, the deemed export rule under EAR and ITAR requires that access by a foreign national to controlled technology be treated as an export to the foreign national's home country, which may require a license unless a license exception applies. This analysis affects hiring decisions and internal access controls and must be factored into integration planning.
13. Founder and Key Employee Retention
Founder and key engineering talent retention is among the most consequential deal issues in a technology acquisition because the value of a software company is frequently inseparable from the people who built it. A strategic buyer integrating a new product depends on retaining the engineers who understand the architecture and can continue development during and after integration. A PE sponsor building a platform depends on the founding team to continue growing revenue and managing customer relationships while the sponsor installs professional management infrastructure. Retention structures must therefore be designed not only to keep key people in their seats but to align their economic interests with the success of the combined business over the integration period and beyond.
Equity rollover is the primary mechanism for aligning founder incentives with acquirer success in PE transactions. Founders roll a portion of their deal consideration into equity of the acquiring entity, typically at the same valuation used in the acquisition, and that equity participates in the value created between the acquisition and the PE sponsor's exit. The rollover percentage, the form of equity (common, preferred, options, or profits interests), the governance rights associated with the rolled equity, and the treatment of the rolled equity on a future exit are all negotiated terms that vary significantly by deal. For founders who are rolling over a meaningful portion of their proceeds, the economic and legal terms of the rolled equity can be as significant as the upfront cash consideration.
Non-compete agreements for founders and senior technical leaders are a standard component of the retention package in most technology acquisitions, subject to significant variation in enforceability by state. California, Minnesota, North Dakota, and Oklahoma effectively prohibit post-employment non-compete agreements for employees, while other states permit them subject to reasonableness requirements relating to geographic scope, duration, and legitimate business interest. For founders who live or work in non-compete-hostile jurisdictions, buyers rely more heavily on non-solicitation agreements, vesting cliff structures, and the financial alignment created by rollover equity to achieve the same retention function. Employment counsel in the relevant jurisdiction must assess the enforceability of any non-compete before it is included in the closing documentation as a material deal term.
14. Earnouts Tied to ARR or Technical Milestones
Earnouts are contingent consideration arrangements that make a portion of the purchase price payable to the seller based on the achievement of specified performance targets after closing. In technology acquisitions, earnout metrics commonly include annual recurring revenue targets, net revenue retention thresholds, gross margin floors, or specific product development or integration milestones. Earnouts are most frequently used when there is a valuation gap between what the buyer is willing to pay based on current performance and what the seller believes the business will be worth once certain milestones are reached, allowing the parties to bridge the gap by making future value contingent on future performance.
ARR-based earnouts require precise definitions of the metric that will be measured. ARR is a company-defined operating measure outside GAAP, with definitions varying, including or excluding professional services revenue, multi-year contracts at full contract value or annualized, contracts under notice of termination, and revenue from customers in bankruptcy. The purchase agreement must define exactly how ARR is calculated, who performs the calculation, what the adjustment process is if the parties dispute the measurement, and what accounting principles govern the calculation. A loosely defined ARR metric will produce disputes at each earnout measurement date, and those disputes are expensive and corrosive to the post-closing relationship between the parties.
Technical milestone earnouts require an equally precise specification of what constitutes achievement of the milestone. Qualitative milestones (the product "achieving general availability" or "completing integration" with an acquirer platform) are almost always disputed because the parties have different operational perspectives on what those terms mean in context. Well-drafted technical milestone earnouts specify the criteria for achievement in engineering language sufficient to be objectively determinable, designate a neutral technical expert to resolve disputes, and address what happens if the buyer's post-closing product decisions affect the team's ability to achieve the milestone. Courts have recognized that buyers owe an implied covenant of good faith in administering earnout provisions, but relying on litigation to enforce that covenant is a poor substitute for clear drafting at the outset.
15. IP Transfer Mechanics
The transfer of intellectual property in an asset purchase requires executed assignment instruments for each category of IP, and those assignments must be recorded with the appropriate government authorities to be effective against third parties. Patent assignments must be recorded with the USPTO under 35 U.S.C. Section 261, and failure to record within three months of the assignment can subordinate the buyer's rights to a subsequent purchaser who records first and lacks notice of the prior assignment. Trademark assignments must be recorded with the USPTO and, for international registrations, with the applicable foreign trademark offices and the World Intellectual Property Organization. Copyright assignments are not required to be recorded but may be recorded with the U.S. Copyright Office, and recordation provides constructive notice to subsequent purchasers.
Nunc pro tunc assignments are retroactive assignment instruments used to correct historical chain-of-title defects. When a prior assignment was not executed at the time development occurred, or when an assignment was executed but was defective in form, a nunc pro tunc assignment executed by the assignor and the assignee can cure the defect by acknowledging that the transfer was effective as of the original intended date. The legal effectiveness of a nunc pro tunc assignment depends on the law of the jurisdiction, the nature of the defect being cured, and the cooperation of the prior author or inventor. In diligence, when chain-of-title defects are identified, counsel must assess whether nunc pro tunc assignments can cure the defects and whether the individuals whose cooperation is required are available and willing to sign before the closing date.
Security interests recorded against IP assets must be released before or at closing, because a security interest in a patent, trademark, or copyright remaining unreleased at closing will encumber the asset in the hands of the buyer. Lenders who have taken security interests in the target's IP as part of a credit facility will typically file UCC financing statements and may record specific IP security interest filings with the USPTO or Copyright Office. A thorough lien search, including a search of the USPTO assignment and security interest records, is required in any technology acquisition to confirm that all security interests will be released at closing as a condition to the buyer's payment of the purchase price.
17. AI and Machine Learning Specific Diligence
Artificial intelligence and machine learning assets require diligence that goes beyond the standard IP framework because the legal analysis applicable to software code does not map cleanly onto trained models, training datasets, and inference infrastructure. Training data provenance is the most foundational issue: the value of an ML model depends on the quality and legality of the data used to train it, and data that was scraped without permission, licensed under terms excluding commercial AI training, or collected in violation of applicable privacy law creates legal risk that is embedded in the model itself and cannot be separated from the model post-closing. Copyright claims relating to AI training data are an active area of litigation, and the legal landscape is evolving in ways that are directly relevant to buyers of companies with proprietary ML assets.
Model weights ownership must be confirmed as part of IP diligence. A company that fine-tunes a foundation model under terms that vest ownership of the fine-tuned weights in the platform provider does not own what it has built. Similarly, a company that trains models using cloud-based training infrastructure under terms that give the cloud provider rights to model outputs or training data may have encumbered its model assets without intending to. Diligence should obtain and review the terms of service for every AI platform, API provider, and cloud ML service the target uses, with specific attention to provisions addressing ownership of models, model weights, fine-tuned outputs, and training data submitted to the platform.
Clean-room development practices are relevant to AI diligence in a distinct way from general software development. Where a company has trained models using publicly available datasets or open source model weights that are subject to license restrictions on commercial use, the buyer must assess whether a clean-room retraining process is required to eliminate those encumbrances. Some foundation models released under non-commercial or research-only licenses cannot be used as the basis for a commercial product, and if the target's proprietary model was derived from such a foundation model, the derivation creates a license compliance issue that must be resolved before the model can be commercially deployed by the acquirer. The scope and cost of clean-room retraining should be factored into the purchase price if remediation is required post-closing.
18. Representations and Warranties Insurance for Tech Deals
Representations and warranties insurance has become a standard component of the deal structure in a significant proportion of technology and software M&A transactions, particularly in PE-sponsored deals where sellers expect a clean exit and buyers want protection beyond what the seller's indemnification capacity provides. R&W insurance shifts the financial risk of unknown misrepresentations in the purchase agreement from the seller to the insurer, allowing sellers to distribute proceeds to investors at closing without maintaining a large holdback escrow, and giving buyers a creditworthy counterparty from whom to recover losses resulting from breaches of the seller's representations. For technology acquisitions, R&W insurance is widely available and the market is competitive, with multiple insurers actively seeking technology deal flow.
Technology-specific underwriting focuses on the IP representations with particular intensity. Underwriters engage their own IP specialists to review the target's IP diligence materials, and they apply retention requirements or exclusions to IP representations where chain-of-title defects, open source compliance issues, or freedom-to-operate concerns have been identified in diligence. Data privacy representations receive equivalent scrutiny, and underwriters typically apply sublimits or enhanced retentions for GDPR and CCPA compliance representations when the target's privacy diligence reveals gaps in lawful basis documentation, processor agreements, or breach notification history. Cybersecurity incident representations are another area where technology underwriters conduct detailed review, assessing the quality of the target's security diligence and excluding coverage for known incidents or active investigations.
The quality of legal and technical diligence is the most important factor in obtaining broad R&W coverage at a competitive premium. Underwriters rely on the diligence record compiled by the buyer's counsel, and a comprehensive, well-documented diligence process that addresses IP, open source, data privacy, security, and customer contract assignability in detail produces a more complete insurable risk profile than diligence that is surface-level or poorly documented. Buyers who engage experienced technology M&A counsel early in the diligence process and document their findings systematically are better positioned to negotiate favorable coverage terms and to make a successful claim if a breach is discovered post-closing.
19. Integration Planning for Engineering Teams
Engineering team integration is the operational dimension of technology M&A that most directly determines whether the buyer realizes the product value it paid to acquire. Integration planning for engineering teams must address organizational structure, reporting lines, technical infrastructure harmonization, code review and deployment processes, and the retention of institutional knowledge that is embedded in the acquired team's working practices rather than in formal documentation. Integration planning should address the engineering team's workflows, product roadmap and decision rights before the buyer changes reporting or development processes. Record the decisions that need technical input alongside the contract and IP handoff.
Legal issues arise in engineering integration in several specific areas. Intellectual property created by acquired engineers post-closing must be properly assigned to the buyer through updated employment agreements and IP assignment provisions executed at or promptly after closing. Employee benefits harmonization may require ERISA filings, plan amendments, and communications to employees about changes to their benefit arrangements. Non-compete and non-solicitation agreements with engineers in states that enforce them must be documented and enforced consistently to preserve their validity, because selective enforcement can undermine enforceability. Classification of engineers as employees versus contractors must be reviewed and corrected where necessary before integration because misclassification liability follows the acquirer in a stock transaction.
Technical integration of source code repositories, development tools, continuous integration and deployment pipelines, and cloud infrastructure requires legal review in addition to engineering execution. Licenses for development tools, SaaS platforms used by the engineering team, and code repositories may be priced per seat or per organization, and the merger of two distinct engineering organizations under a single license may require renegotiation of license terms. Export control analysis of the combined engineering team must account for the deemed export implications of access by foreign national employees of either organization to the other's controlled technology. Integration counsel and IP counsel should be part of the integration planning team from day one, not called in after problems arise.
20. Role of Technology M&A Counsel
Technology M&A is a discipline that requires counsel who understand both the legal mechanics of M&A transactions and the substantive IP, data privacy, and regulatory frameworks that govern technology businesses. General corporate M&A counsel who lack specific technology experience may miss IP chain-of-title defects, fail to identify open source compliance risks, overlook data privacy transfer obligations, or draft customer contract representations missing the specific terms most likely to create post-closing disputes. The consequences of these gaps are not hypothetical: they manifest as indemnity claims, customer losses, regulatory enforcement actions, and integration failures that directly reduce the value the buyer realized from the acquisition.
Experienced technology M&A counsel serves as the integrating function between the various specialist diligence workstreams, ensuring that IP, data privacy, open source, export control, and customer contract findings are synthesized into a coherent risk picture that informs deal structure, purchase price negotiation, representation and warranty drafting, and indemnification mechanics. Counsel must be able to communicate technical findings in business terms to the client's decision-makers, and to translate business risk tolerance decisions back into specific contract provisions. This requires not only legal skill but familiarity with the technology industry and the specific deal patterns that are common in software, SaaS, and AI acquisitions.
Bring the transaction structure, product ownership questions, customer consent list and next decision to an engagement assessment. Acquisition Stars scopes M&A document and negotiation work against those facts. Alex Lubyansky leads every engagement, reviews every document, and leads negotiation and closing, with an associate supporting the work. Identify any separately scoped IP, privacy, export-control and technical review before relying on an unresolved diligence assumption in the purchase agreement.
Frequently Asked Questions
What are the differences between a stock sale and an asset sale for a technology company?
In a stock sale the buyer acquires the target entity and inherits all of its assets, contracts, liabilities, and regulatory history without needing to transfer or novate individual agreements. In an asset sale the buyer selects which assets and contracts to acquire and can generally exclude unknown or contingent liabilities, but customer contracts, IP licenses, and software agreements must each be reviewed for anti-assignment clauses and change of control provisions that could require third-party consent before transfer. For SaaS companies with large customer bases and complex license stacks, the consent burden of an asset sale can be operationally significant, which is one reason stock purchases are common in software acquisitions even though they carry forward unknown liabilities.
Why does IP chain of title matter so much in a software acquisition?
Copyright ownership depends on authorship, employment status, the work-made-for-hire rules and any effective transfer. For a work made for hire, section 201(b) generally treats the employer or commissioning party as author and owner unless a signed written agreement provides otherwise. Employee-created code within the scope of employment and contractor-created code therefore require distinct analyses. Review the actual role, development history and signed agreements before identifying a title gap. A gap in the chain of title means the target does not own what it purports to sell, and a buyer who discovers the defect post-closing may find that it acquired an entity whose core product is subject to third-party ownership claims. Use the ownership analysis to identify the assignments, confirmations or other remediation the actual transaction needs before closing.
What open source compliance risks are most significant in a software acquisition?
The most significant open source risk in an acquisition is the presence of copyleft-licensed code, particularly code governed by the GNU General Public License version 2 or 3 or the Affero GPL, embedded in or combined with proprietary software. Whether a combined work triggers corresponding-source and licensing obligations depends on the actual license and technical relationship between components. Permissive licenses such as MIT, Apache 2.0, and BSD present far lower risk because they permit broad use subject to the actual notice, attribution, patent and other license terms, but even permissive license obligations must be tracked and fulfilled to avoid technical license breach.
What is GPL copyleft and why does it concern acquirers?
Copyleft conditions depend on the exact GPL or AGPL version, covered work, modifications, combination and distribution or network use. Review the source, build and deployment model with engineers and counsel. GPL distribution obligations and the AGPL requirement for a corresponding-source offer to network users of a modified version have different triggers. Mere presence of a component alone supplies no complete answer about the proprietary application.
Are SaaS customer contracts automatically assignable in a deal?
SaaS customer agreements frequently contain anti-assignment clauses that prohibit either party from assigning the agreement without the other's prior written consent, and change of control provisions that treat a merger or acquisition of the vendor as an assignment requiring customer consent or triggering a right to terminate. Whether a particular clause covers a stock sale, an asset sale, or both depends on the specific contract language, and many agreements distinguish between the two. The practical consequence is that an acquirer may need to obtain affirmative consent from some or all enterprise customers before closing or accept the risk that certain customers will exercise termination rights post-closing, which can affect revenue assumptions underlying the purchase price.
What triggers a change of control clause in a software license or SaaS agreement?
Change of control clauses typically define a triggering event as the acquisition of more than a specified percentage of the voting interests of a party, a merger or consolidation where the party's existing shareholders do not retain majority voting control, or the sale of all or substantially all of the party's assets. Some clauses in enterprise software agreements are deliberately broad and cover any transaction through which a third party acquires the ability to direct the management or operations of the contracting party. The triggering threshold and the remedy available to the counterparty (consent required, termination right, price adjustment, or notification only) vary by contract, and systematic contract review is required in any deal where third-party agreements are material to the valuation.
What data privacy issues arise in a technology M&A transaction?
Technology acquisitions involving personal data implicate GDPR if the target processes data of individuals in the European Economic Area, CCPA and CPRA if it processes California residents' personal information, and HIPAA if it handles protected health information in a healthcare technology context. During diligence, the buyer must assess the target's data mapping and processing inventory, lawful basis for processing under GDPR, privacy notice adequacy, vendor data processing agreements, breach history, and any regulatory investigations or enforcement actions. Post-closing, the buyer must ensure that personal data transferred from the target is covered by its own privacy notices and legal bases for processing, which may require notification to or consent from data subjects in some jurisdictions.
When is a source code escrow arrangement appropriate?
Source code escrow arrangements are appropriate in any transaction where the acquirer or a licensee needs assurance of continued access to source code if the software vendor becomes insolvent, ceases operations, or materially breaches its maintenance obligations. In an acquisition context, source code escrow is most relevant for software licensed from third parties whose continued business is essential to the target's operations, because a vendor failure post-closing could disable a critical component of the acquired product. Escrow arrangements specify release conditions (insolvency, material breach, cessation of business), verification procedures to confirm the deposited code is current and complete, and the scope of the license granted to the beneficiary upon release.
What retention structures are typical for founders and key engineers in a software acquisition?
Founder retention in technology acquisitions commonly involves a combination of equity rollover into the acquirer, new time-vested equity grants in the acquirer under an agreed vesting schedule, and cash retention bonuses payable over an agreed service period conditioned on continued employment. Key engineers and product managers are typically offered retention packages that include new equity grants and performance bonuses structured to align their incentives with integration milestones. Non-compete agreements for founders and senior technical personnel, where enforceable under applicable state law, are also standard in software acquisitions because the risk that a founder departs and recreates a competing product is a real concern to strategic and PE buyers alike.
What AI and machine learning specific diligence issues arise in a software deal?
AI and machine learning diligence requires analysis of training data provenance to assess whether the datasets used to train the company's models were lawfully obtained, properly licensed, and free from third-party IP claims. Model weights and trained model assets should be confirmed to be owned by the company rather than by a third-party platform or service provider whose terms may restrict commercial transfer. Buyers must also assess the company's use of foundation models and API-based AI services because some commercial AI provider agreements prohibit fine-tuning, redistribution, or commercial resale of outputs in ways that could affect the acquired product's functionality post-closing.
Is representations and warranties insurance available for technology transactions?
R&W insurance is broadly available for technology and software M&A transactions, and the product has become a common deal tool for allocating IP, data privacy, and contractual representation risk between sellers and buyers. Technology-specific underwriting focuses on IP chain of title, open source compliance, data privacy regulatory exposure, cybersecurity incident history, and the adequacy of customer contract representations. Underwriters generally exclude known IP disputes identified in diligence and apply specific sublimits or enhanced retentions for data privacy regulatory risk, but a thorough diligence process supported by specialist technology counsel tends to produce broader coverage and lower retentions than diligence that is incomplete or insufficiently documented.
What is a typical timeline for a technology or software M&A transaction?
Build the closing schedule from the actual IP remediation, customer consent, financing and regulatory workstreams after the initial diligence review. The timeline extends when IP chain of title remediation is required, when regulatory approvals such as HSR Act filings or export control reviews are triggered, or when customer consent obligations are material. Assign an owner and a dependency for each unresolved item, then negotiate an outside date and any extension rights against that plan.
Legal counsel for this topic
Acquisition Stars handles M&A transactions nationwide and works with securities counsel on securities matters. Alex Lubyansky leads the M&A engagements.
Closest fit for this topic Technology and SaaS M&A counsel Legal counsel for SaaS and technology company acquisitions.