Inventory what each business actually runs.
Before deciding what to connect, write down what exists: the applications each business uses, who owns each one, what it costs, when the contract renews, and which integrations already move data between them. Include the spreadsheets, shared inboxes, and personal databases that hold real operating information, because the acquired business often depends on them every day.
For each system, note how data gets out. An export, a supported API, a reporting database, or nothing at all changes what an integration can reasonably do. Vendor terms sometimes restrict access to the records themselves, so find that out before it blocks the project.
The inventory should also record who understands each system. An acquisition often depends on one or two people who know why the process works the way it does. Their knowledge needs to be captured while they are still available and willing.
Decide which system owns each record.
Integration failures usually trace back to an unanswered question: which system is the source of truth for a customer, a product or service definition, a price, an employee, or a financial transaction? The answer can differ by record. The acquired CRM may remain the owner of customer records for that business while the group finance platform owns invoices.
Write the ownership down and give each record a stable identifier that survives the move between systems. Mapping tables, not manual lookups, should connect a customer in one system with the same customer in another.
Resist the reflex to put everything on one platform in the first year. A consolidated platform may be the right destination, but deciding ownership and connecting the important flows first lets the business keep operating while that larger decision is made properly.
Connect the flows that change how the business runs.
Rank candidate integrations by their effect on operations, not by how easy they look. Order-to-cash across the combined businesses, a single way to submit and route work requests, and consolidated operational reporting usually matter more than synchronizing every field in every system.
For each flow, specify the trigger, the direction of updates, the validation on receipt, and what happens on failure. Duplicate events, incomplete records, and an offline endpoint are normal conditions, not edge cases. Someone must be able to see which records did not move and fix them.
Sequence the work around the business calendar. A finance close, a seasonal peak, or a system renewal date can make a technically sound cutover operationally reckless. Choose cutover dates with the people who will live with the result.
Handle local differences deliberately.
Acquired businesses do things differently for reasons that range from essential to accidental. Sort each difference into keep, standardize, or retire, and decide who has the authority to make that call. An integration that silently forces one business’s rules onto another creates resentment and workarounds.
Where differences remain, make them explicit in the data model: a location-specific approval step, a product code that only one business uses, a customer segment with its own terms. Explicit exceptions can be reported on; hidden ones cannot.
Validate with representative records from each business before cutover, including the awkward ones. A test that only uses clean examples from the acquirer proves very little about the acquired company’s data.
Run the integration like a product, not a project.
Once records are moving, the integration becomes part of how the business operates. It needs monitoring, a queue for failed records with an owner, documentation someone other than the builder can follow, and a plan for when a connected vendor changes its interface.
Agree on what will be measured: records reconciled between systems, exceptions resolved and how quickly, manual re-entry eliminated, and the reports that are now produced without a spreadsheet. These are operating measures the team can check, not promises made in advance.
Expect the next acquisition. If the ownership rules, identifiers, and integration patterns are documented, connecting the next business is a repeat of a known sequence rather than a new project every time.
Put it into practice
Talk through the project you are considering.
Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.
Discuss your project