The technology stack belongs in the purchase agreement

The asset is a connected set of rights

An IP register is a useful starting point, but it rarely describes what a software or digital-services target can actually transfer and operate. Value may depend on cloud capacity, SaaS subscriptions, reseller terms, integration agreements, code repositories, data rights and the continuing cooperation of customers or providers. The diligence exercise should therefore start with the services that generate revenue or support delivery, then identify the rights and dependencies required for each one.

A share transaction ordinarily leaves the target as party to its contracts, but change-of-control clauses may permit a counterparty to terminate, renegotiate or require consent. In an asset transaction, contractual transfer generally requires the cooperation of the counterparty under art. 6:159 DCC, because contractsovername requires an agreement among the transferring party, the transferee and the counterparty. The conditions precedent list should distinguish actual assignment consents from change-of-control consents, since the consequence of a missing consent and the available alternatives may differ.

The review should also identify agreements made through resellers, group purchasing arrangements or platform marketplaces. A licence held by a seller group entity, rather than the target, may not move with a share sale. A clear contract map identifies the contracting party, term, termination rights, assignment or control restriction, consent status, criticality and available substitute.

Exit rights are part of the acquired business

Cloud and SaaS arrangements need to be read beyond the headline subscription. The relevant questions are whether the target can obtain its data in usable formats, receive transition assistance, maintain access during migration, and recover operational configurations, interfaces and credentials. A provider's generic export right may be inadequate where the target depends on proprietary tooling or cannot recreate its environment within the period customers will tolerate.

Source code escrow can be material where bespoke software is essential to operations or a key provider is financially exposed. The diligence record should establish what has been deposited, the release triggers, update frequency, verification process and whether the materials can be built and deployed. A contractual right to an untested archive provides less protection than a tested recovery process.

The EU Data Act places a statutory floor beneath those contractual rights. Providers of cloud and other data processing services must enable customers to switch to another provider and must include the terms for doing so in the contract, such as a notice period, a transitional period, a specification of the data that can be ported and a period for retrieving data before it is erased. The regulation also limits the charges a provider may impose for switching and phases them out.

The extent of the obligation varies with the type of service, and not every service falls fully within the regime. The diligence exercise should therefore classify each material service, confirm that the contract carries the required terms and test the export route against the architecture, since a statutory entitlement does not by itself make a migration workable within the period customers will tolerate. The SPA should record the material service arrangements, the applicable switching terms and any known constraint on extraction.

Code, data and model rights require separate analysis

Software may be protected by copyright, and the Auteurswet contains specific rules for computer programs that are relevant to ownership, permitted acts and contractual allocation. The legal review should establish whether employees, contractors and group entities created the code, what agreements assign or license rights, and whether development tools or generated materials are subject to third-party terms. The Databankenwet may separately protect a database where its requirements are met, but it does not establish rights in every collection of data.

A code scan can identify open-source components and licence notices, but its result needs legal and technical interpretation. Open-source licence terms may require attribution, provision of source code, preservation of notices or licensing of derivative work on specified terms. The warranty package should therefore address compliance with applicable licence terms, disclosure of identified components and the absence of obligations inconsistent with the target's licensing model.

Data used to train or fine-tune a model needs its own provenance analysis. Customer contracts, privacy notices, permissions and internal governance should show whether the target was entitled to use the data for training, evaluation or improvement, rather than merely to provide the contracted service. Model and tooling licences should also be read for rights in outputs, derivative models, restrictions on commercial use, attribution, indemnities, provider access and the continued availability of the model after completion.

Roles, data protection and post-completion cost

The AI Act allocates obligations by role, including provider and deployer. The agreement should identify which entity performs each role for every material system and whether the buyer will change that position after completion through rebranding, modification, distribution or deployment. The classification and allocation cannot be settled by a generic warranty that the target complies with all law, because the ongoing compliance cost and operational work depend on the system and the role.

The timetable also matters. The AI Act obligations take effect in phases; which of them already apply at the time of a transaction and which are still to come varies by system. That phasing should inform the warranty survival period, the remediation covenant and any adjustment for identified compliance work.

Personal data arrangements transfer operationally with the target but may require re-papering after completion. The GDPR sets requirements for arrangements with processors and for arrangements between parties that jointly determine the purposes and means of processing. The diligence report should identify controller, processor and joint-controller positions, the relevant customer and vendor arrangements, international transfers, and the changes that the buyer's integration plan will create.

A schedule makes the warranty package usable

A technology-stack schedule should state, for each material component, the product or service, owner or provider, contract reference, renewal and termination dates, change-of-control or assignment position, data location and extraction route, key dependencies, source-code status, open-source position, AI role and personal-data role. The schedule is not a technical inventory for its own sake. It supplies the factual baseline against which warranties, disclosures and covenants can be tested.

The SPA warranties can then cover ownership or sufficient rights to use the technology, compliance with material open-source licence terms, enforceability of material technology contracts, disclosed consent requirements, lawful use of training data, accuracy of the AI role allocation and the existence of the arrangements required under the GDPR. Known gaps are better converted into specific disclosures, conditions, price treatment or post-completion obligations than left within a general IP warranty. That approach keeps the allocation clear and preserves a workable route to completion.