Light-touch or full integration after a software acquisition: what to standardize

What should a software acquirer standardize?#

A software acquirer should standardize the few controls where a mistake at one company becomes a problem for the whole group: security, data retention, AI and data-use policy, and core legal templates. Almost everything that touches customers day to day, from roadmap to help desk configuration, can stay with the acquired team.

Buy-and-hold software groups often describe themselves as decentralized, and for product and customers that is usually the right call. Decentralized does not mean uncontrolled. The group's reputation, insurance, lender covenants and future exits all depend on a minimum standard that every business meets, whatever its size or market.

Standardize versus leave local: the two-column view#

The standardize column is short on purpose. Each item is a policy, a template or an approval right with a named owner at group level, not a shared system. A company can keep its own help desk and still follow the group retention schedule and the approval rule for deleting tickets.

Some items sit on the border. A shared billing platform, a common identity provider or a single cloud account can save money, but each moves the company toward full integration and should be justified on its own merits rather than bundled into the minimum standard.

Why AI and data-use policy belongs in the standard set#

AI and data-use policy belongs in the standard set because product teams are adding AI features quickly, and each feature raises the same question: what may we do with customer data? Left to each company, the answers drift, and customer terms change in ways the group cannot see until a customer complains.

Vendor episodes show the cost of vague terms. On August 7, 2023, following criticism of terms changes it had made that March, Zoom wrote into its terms that it would not train its AI models on customers' audio, video or chat content without their consent. In June 2024, Adobe published a clarification after users objected to updated terms shown in a mandatory re-acceptance prompt, then said it would write a no-training statement into its terms as a legal obligation.

A group policy sets the defaults: which customer data may feed product features, which uses need customer consent, how internal records such as support tickets and engineering history may be used, and who approves exceptions.

Retention schedules protect records you cannot replace#

A group retention schedule protects records that cannot be recreated, such as support history, issue trackers, code review threads and sales notes, from deletion settings buried in each company's tools. Many SaaS tools let admins configure automatic deletion that cannot be undone, and an acquired company may have switched it on long before the deal.

The standard does not dictate tools. It sets minimum and maximum retention by record type, requires group approval before bulk deletion or tool retirement, and asks each company to keep a current list of the systems holding its records.

• 1List every system holding customer, support, engineering or sales records, with an admin owner.
• 2Review deletion schedules, archiving rules and plan-level export limits in each system.
• 3Apply group minimums by record type while honoring contractual deletion commitments.
• 4Require approval before retiring a tool or cancelling a subscription.
• 5Export and index records from any tool being retired.

Legal templates: harmonize at renewal, not by force#

Legal templates should converge on a group standard over time, mostly at renewal, rather than forcing every acquired customer onto new paper at once. The group template sets the floor for data use, confidentiality, liability and data return, and acquired companies adopt it for new customers right away.

For existing customers, keep inherited terms until renewal unless a specific clause creates unacceptable risk. Track which customers sit on which paper, because inherited contracts decide what each company can do with its records long after close, including whether internal records can be used outside normal operations.

Keep a simple register per company: template version, customers still on inherited paper, renewal dates and any clauses that restrict data use. That register is what a buyer's counsel will ask for, and it answers most questions about records before anyone opens a contract.

When to move from light-touch to full integration#

Move from light-touch to full integration when a concrete trigger makes separate operation more expensive or riskier than combining. Without a trigger, integration tends to absorb management attention and unsettle customers for little gain.

Treat each trigger as a separate decision with its own business case. Fully integrating one company does not oblige the group to integrate the others, and a company can move part of the way, for example sharing infrastructure and identity while keeping its own roadmap, pricing and support team.

Illustrative: a vertical software group sets its minimum standard#

Illustrative: a fictional software holding group owns products for veterinary clinics, self-storage operators and specialty contractors. Each company keeps its own roadmap, pricing and help desk, from Zendesk at one company to Intercom at another.

Soon after each close, the group issues a short standard: a security baseline, a retention schedule by record type, an AI and data-use policy and group templates for MSAs and DPAs. The retention review finds that the self-storage company had a ticket deletion schedule that would have removed its oldest support history; the records are exported and indexed instead.

Later, two of the companies begin selling to the same customers, which triggers a separate decision on whether to merge products. The others stay light-touch.

How SourceX fits a light-touch model#

SourceX fits a light-touch model because each operating company remains the supplier and approves its own license. The group's AI and data-use policy and retention schedule decide which internal records are eligible; SourceX then runs the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, company by company.

For each package, the SourceX Evidence Packet documents five things: provenance, licensing rights, permitted use, the privacy record and release authorization. That gives the group consistent documentation without centralizing the companies' systems.