The financials are restructured. The legal opinions are in order. The resolution plan is approved. Then someone asks: who actually owns this code? And the answer is… nobody knows for certain.
The Question That Unravels Everything
In a conventional M&A transaction, codebase ownership is verified during due diligence. IP assignments are confirmed. Licence agreements are reviewed. Repository access is catalogued. The buyer walks away with a clear picture of what they’re acquiring.
Distressed M&A is nothing like this.
When a company is in financial distress, whether under IBC proceedings, receivership, or a fire-sale acquisition, the orderly processes that maintain technology governance are usually the first things to collapse. Developer contracts go unsigned or expire. Freelancers who built critical modules never executed IP assignment agreements. The source code sits in a repository that’s tied to a personal GitHub account. The cloud infrastructure runs on a vendor contract with a change-of-control clause that nobody reviewed. The ERP is so deeply customised by a third-party integrator that the company doesn’t actually control its own operational backbone.
These aren’t edge cases. According to Kearney’s Distressed M&A Study 2025, distressed transactions are becoming increasingly complex and selling insolvent assets is more challenging than ever due to reduced investor interest and limited performance upside. In this environment, the acquirer who doesn’t untangle codebase ownership before closing is buying a legal and operational liability disguised as a technology asset.
This is where proper technology due diligence separates the informed buyer from the one who discovers, three months post-close, that they don’t actually own what they paid for.
5 Ways Codebase Ownership Collapses in Distressed Companies
In a healthy company, technology governance maintains clean ownership records. In a distressed company, that governance has usually been degraded for months or years before the acquisition. Here are the five ownership fractures we encounter most frequently:
1. Developer Contracts Without IP Assignment Clauses
This is the most common and most dangerous gap. Startups and SMEs routinely engage freelancers, contract developers and offshore teams to build core software. Under most jurisdictions, unless there’s an explicit written assignment, the developer, not the company, retains copyright over the code they wrote.
Best practice requires that all agreements with developers, contractors and consultants contain presently effective assignment language that makes IP transfer immediate, rather than requiring future execution. In distressed companies, these agreements are often missing entirely, unsigned, or poorly drafted. The result: the company’s most valuable technology asset may not legally belong to the company.
2. Repository Access Tied to Individuals
The source code repository is the single most critical technology asset in any software-dependent acquisition. Yet in distressed companies, it’s common to find that repo access is tied to the personal accounts of former CTOs, lead developers, or founding engineers who left months ago.
If the acquirer can’t access the repo, they can’t verify what they’re buying, they can’t assess code quality and they can’t ensure continuity. In extreme cases, the code may reside on infrastructure the company doesn’t control at all.
3. Vendor Lock-In With Change-of-Control Triggers
Enterprise software, cloud services and SaaS platforms almost always have licence agreements. Many of these agreements include change-of-control clauses that allow the vendor to terminate, renegotiate, or refuse transfer upon acquisition. In a standard M&A, legal teams review every vendor contract for these provisions. In distressed deals, where time pressure is acute and documentation is sparse, these clauses are routinely missed.
The consequence: the acquirer closes the deal and within weeks, discovers that a critical vendor has exercised its termination right, or is demanding a renegotiation that doubles the licensing cost.
4. Open-Source Licence Violations Buried in the Codebase
Open-source software is present in virtually every modern codebase. The risk isn’t the open-source code itself, it’s the licence compliance. GPL and other copyleft licences require that derivative works be released under the same open-source terms. If a distressed company has incorporated GPL-licensed code into a proprietary product without compliance, the acquirer inherits that violation.
Unresolved open-source licence violations can expose the acquiring company to lawsuits, forced code disclosure and regulatory fines. In distressed acquisitions, where no one was monitoring compliance, these violations are almost always present.
5. Third-Party Code With No Source Access
Distressed companies frequently rely on third-party integrators and development agencies for critical system components. The company has a working application, but the source code for key modules was never handed over. The agency retains it. And the contract, if one exists, may not include provisions for source code transfer upon termination.
The acquirer inherits a dependency on a third party that may not be willing to cooperate, especially when the original payment obligations of the distressed company went unmet.
Why Distressed M&A Makes All of This Worse?
Every ownership problem listed above exists in conventional M&A too. But distressed transactions amplify each one, for specific structural reasons:
| Factor | Conventional M&A | Distressed M&A |
| Time for diligence | 60–90 days of structured review | Days to weeks; compressed timelines under insolvency rules |
| Documentation quality | Organised data rooms with complete records | Incomplete, outdated, or missing; management may be unable to provide standard materials |
| Contractual protections | Extensive warranties, reps and indemnities | Minimal or none; transactions typically operate on an “as is, where is” basis |
| Management cooperation | Active participation and disclosure | Management teams may be disengaged, adversarial, or unavailable |
| Vendor relationships | Stable; contracts transfer smoothly | Strained; vendors may have unpaid invoices or threatened termination |
| Employee retention | Targeted retention plans pre-close | Key technical staff often already departed or disengaged |
Zunic Law’s analysis of distressed M&A notes that these deals operate on a “buyer beware” basis with fewer contractual protections, emphasising the critical importance of pricing in risks and conducting targeted due diligence. When it comes to technology assets, this means the buyer must independently verify ownership, access and transferability, because no one else is going to guarantee it.
The Codebase Ownership Audit: What It Covers and Why It Matters?
A codebase ownership audit is a specific, deal-focused assessment that goes beyond a standard code review. It answers one question: Does this company actually own and control the technology it claims to?
At Dextra Labs, our tech audit for distressed acquisitions covers seven critical dimensions:
- IP Assignment Verification: Review every developer, contractor and vendor agreement for IP assignment clauses. Identify gaps where code was written without a valid transfer of ownership. Flag any founder-created IP that was never formally assigned to the company.
- Repository and Source Code Access: Map every code repository, verify access credentials, confirm the company has administrative control and ensure no critical code resides on personal accounts or uncontrolled infrastructure.
- Licence Compliance Scan: Scan the codebase for open-source components. Identify every licence type (GPL, MIT, Apache, LGPL, etc.). Flag copyleft violations where proprietary code incorporates GPL-licensed components without compliance.
- Vendor Contract Analysis: Review every technology vendor contract for change-of-control provisions, termination triggers, non-transferability clauses and unpaid obligations that could jeopardise continuity post-acquisition.
- Third-Party Dependency Mapping: Identify every component built by external agencies or freelancers. Verify whether source code has been delivered and whether the company has the right to modify, redistribute and build upon it.
- Cloud and Infrastructure Ownership: Confirm ownership and administrative access to all cloud accounts (AWS, Azure, GCP), domain registrations, SSL certificates, API keys and deployment pipelines. These assets are frequently tied to individuals rather than the corporate entity in distressed companies.
- Data Ownership and Privacy Compliance: Verify that customer data, training data and operational data were collected and stored in compliance with applicable privacy laws (DPDPA, GDPR). Confirm that data rights transfer with the acquisition and that no third-party restrictions prevent the buyer from using acquired data assets.
The output is a structured ownership risk register that maps every gap to a deal-level consequence: legal exposure, remediation cost, or walk-away recommendation.
From Audit to Action: The Tech Transfer Roadmap for Distressed Deals
Identifying ownership gaps is only useful if you know what to do about them. Here’s how we translate audit findings into an executable transition plan:
Phase 1: Secure (Days 1–14)
- Lock down access: Transfer all repo, cloud and infrastructure credentials to the acquiring entity. Revoke access for departed employees and contractors.
- Preserve evidence: Capture the current state of all code repositories, deployment configurations and documentation before any changes are made.
- Notify vendors: Formally notify all technology vendors of the change of control. Identify contracts requiring consent and begin the consent process immediately.
Phase 2: Remediate (Days 15–60)
- Close IP gaps: Execute retroactive IP assignment agreements where possible. For cases where original developers are unreachable or uncooperative, assess whether the code can be replaced, rewritten, or licensed.
- Resolve licence violations: For open-source compliance issues, implement remediation: either comply with the licence terms, replace the violating components, or isolate them from proprietary code.
- Renegotiate vendor contracts: For contracts with change-of-control issues, negotiate new terms. Where vendor cooperation is not forthcoming, begin planning for alternative solutions.
Phase 3: Transition (Days 61–90)
- Implement governance: Establish code ownership policies, IP assignment standards for all new development and ongoing open-source compliance monitoring.
- Complete knowledge transfer: Ensure that institutional knowledge about system architecture, undocumented processes and vendor relationships is extracted from remaining staff and documented. Follow structured knowledge transfer processes to prevent knowledge loss.
- Deliver the tech estate map: A complete inventory of every technology asset, its ownership status, its health and its role in the business, the foundation for all future technology decisions.
What Dextra Labs Brings to Distressed Tech Transfer?
Dextra Labs operates at the intersection of technology due diligence and deal advisory. We’re built for the complexity that distressed transactions demand.
Our RCOI framework, Risks, Costs, Opportunities, Impact, is designed to translate technical findings into deal language. In the context of codebase ownership:
- Risks: IP gaps that create legal exposure, vendor contracts that may terminate, open-source violations that could force code disclosure.
- Costs: Remediation budgets for IP gap closure, code rewriting, vendor renegotiation and compliance remediation.
- Opportunities: Proprietary technology that, once properly secured, becomes a genuine competitive asset. Data assets that can power AI and automation initiatives.
- Impact: Projected value creation from resolving ownership issues and unlocking technology potential that was trapped behind governance failures.
For distressed acquisitions specifically, we layer in Dipstick assessments for rapid pre-bid intelligence and full Comprehensive reviews for deep technical evaluation during the diligence window, however compressed that window may be.
The Bottom Line: If You Don’t Own the Code, You Don’t Own the Company
In distressed M&A, everything is moving fast. Timelines are compressed. Information is incomplete. Contractual protections are minimal. The pressure to close is enormous.
But closing a deal without confirming codebase ownership is not speed, it’s recklessness. Every unresolved IP assignment, every unreviewed vendor contract, every unscanned open-source dependency is a liability that the acquirer inherits in full, with no warranties, no indemnities and no recourse.
The companies that succeed in distressed acquisitions are the ones who conduct targeted, focused technology due diligence that answers the one question that matters before the cheque clears: Do we actually own what we’re buying?
If you can’t answer that question with documented certainty, you’re not acquiring a technology asset. You’re acquiring a dispute.
FAQs:
Who owns the codebase in a distressed M&A deal?
Ownership is rarely clear-cut. Freelancers and contractors retain copyright unless explicit IP assignment agreements exist. In distressed companies, these agreements are often missing, unsigned, or poorly drafted, meaning the codebase may legally belong to individual developers, not the company being acquired.
What happens to vendor contracts when a distressed company is acquired?
Many vendor contracts contain change-of-control clauses that allow termination or forced renegotiation upon acquisition. In distressed deals, these clauses are frequently overlooked due to time pressure. The acquirer can face sudden contract terminations or significantly higher licensing costs within weeks of closing.
How do you verify IP ownership before acquiring a distressed tech company?
Conduct a codebase ownership audit covering all developer and contractor agreements, repository access, third-party dependencies and founder IP assignments. Every piece of code must be traced to a valid, written IP transfer. Gaps should be flagged as legal liabilities before the deal closes.
What are the risks of open-source licence violations in M&A?
Incorporating GPL-licensed code into proprietary software without compliance forces the acquirer to either release their code publicly or face lawsuits. In distressed companies where compliance was never monitored, these violations are common and can result in forced code disclosure, regulatory fines and litigation.
What is a codebase ownership audit and why is it needed in distressed deals?
A codebase ownership audit verifies whether a company truly owns and controls its technology assets. It covers IP assignments, repository access, open-source compliance, vendor contracts and data rights. In distressed deals with minimal legal protections, it’s the only reliable way to confirm what’s actually being acquired.
How does change-of-control affect technology vendor contracts?
Change-of-control clauses give vendors the right to terminate, suspend, or renegotiate contracts when company ownership changes. For critical SaaS platforms, cloud providers, or ERP systems, this can disrupt operations immediately post-acquisition, making pre-close vendor contract review an essential part of distressed tech due diligence.
