Rebuilding sales, administrative, and transaction workflows at a regional M&A firm meant clarifying roles and handoffs between departments. That experience shapes how I look at add-on integration: a shared system doesn't, by itself, establish a shared way of working.
For a private equity owner, the decision isn't simply whether an acquired business should move onto the platform company's software. It's which operating rules need to become common, which differences should remain, and what must stay intact while those decisions take effect. I would settle those questions before treating a system migration as an integration plan.
Start where responsibility changes hands
I begin with the points where work passes from one person or department to another. A task may be complete for the person sending it and still be unusable for the person receiving it. Integration planning needs to account for both sides.
I want to know what the receiving person needs, what establishes that the work is ready, and who resolves a disagreement. Those are operating decisions. Moving information between applications doesn't settle them.
For an add-on, I would trace work across the boundary between the acquired business and the platform company. I would look for places where responsibility changes but the information, authority, or acceptance criteria don't follow. That's a more useful starting point than comparing software features.
Agree on meaning before moving records
A shared field name isn't evidence of a shared definition. Before combining records, I would establish what each important status means, who can change it, and what action that change permits.
The same scrutiny belongs on completion rules. I wouldn't assume that work described as finished in one business meets the receiving team's requirements in another. Without agreement, a consolidated view may conceal unresolved work rather than make it easier to manage.
My priority would be the definitions that affect customer commitments, delivery, billing, and accountability. The objective isn't to document every local habit. It's to make the information used for consequential decisions understandable across the combined operation.
Standardize the boundary before the whole business
I wouldn't treat every difference as a defect. A local process may reflect a genuine customer requirement, contractual obligation, or operating constraint. It may also be a workaround that no longer serves a purpose. The integration plan needs to distinguish between them.
I would first define what must be consistent wherever work crosses the organizational boundary: required information, approval authority, acceptance rules, and responsibility for exceptions. Local methods can then be evaluated against those requirements rather than against a preference for uniformity.
Where legal, contractual, or regulatory obligations affect the design, I would bring the proposed changes to qualified counsel for review. A cleaner workflow isn't sufficient reason to remove a required control.
Give the transition its own operating rules
The intended end state isn't enough to run the transition. I would specify where active work belongs while systems and responsibilities are changing, which record governs when information conflicts, and who can authorize a correction.
I would also make unfinished work part of the cutover decision. Moving records and transferring responsibility are separate tasks. Each open item needs an accountable owner who understands what remains to be done.
Before retiring an old process, I would verify that the receiving team can carry the work, including exceptions. A successful data transfer wouldn't be my sole evidence that the operating handoff is ready.
Put AI behind the operating decision
I would consider AI assistance only after defining the work and its controls. I can compare process documentation and examine inconsistencies with AI assisting that work. I remain responsible for interpreting the differences and deciding which ones matter.
AI may change the economics of parts of the combined operation. But I wouldn't use that possibility to skip decisions about authority, definitions, or customer obligations. Faster movement through an unresolved process isn't the integration objective.
The test is whether work can cross the boundary
For an add-on integration review, I would ask management to demonstrate that work can move between the businesses with clear ownership, usable information, and an understood path for exceptions.
That demonstration matters more to me than a list of connected applications. My integration plan would make the handoffs explicit, verify them during the transition, and use the findings to decide when broader consolidation is justified. Shared systems should support the operating model — not substitute for deciding what it is.