Skip to main content

Post-Acquisition Data Integration Without Migrating Systems

· 10 min read
Dan Peacock
Dan Peacock
Chief Hustler

You have acquired a business. It has been trading successfully for years on its own systems, with its own processes and its own way of describing what it does.

Within weeks, someone will propose moving it onto yours.

That instinct is understandable and it is usually expensive. There is another way to get what the board actually wants, and it starts by separating two problems that are almost always treated as one.

Two problems wearing the same name​

"Integration" after an acquisition means two entirely different things depending on who is saying it.

The board means can we see the combined business? Consolidated revenue, shared customers, group margin, one set of numbers.

The IT programme means can we get them onto our stack? One CRM, one ERP, one set of processes.

The second is one way to achieve the first. It is not the only way, and it is by far the slower and riskier one — yet it is the default, because "integration" gets used for both and nobody notices the substitution.

What the default actually costs​

Migrating an acquired business onto your systems has a specific set of costs that rarely appear in the business case.

You disrupt the thing you just bought. Those systems are how that business currently earns the revenue that justified the price. Replacing them during the first year means changing how the business operates precisely when its performance is under the closest scrutiny.

The acquired team spends its first year on a systems project. The people who understand the customers and the market — the people you paid for — are in migration workshops instead of running the business.

Combined reporting arrives last. It is the final deliverable of a twelve to eighteen month programme, so for the whole of that period the group is managed on spreadsheets and manual consolidation.

And the deadline is external. Boards, lenders and auditors want combined numbers within a reporting cycle, not within two years.

Follow the data, not the systems​

The alternative starts from a different question. Instead of asking which system should everyone use, ask what activities actually matter to each business, and what data do they produce?

Both businesses raise invoices. Both hold customers. Both record quantities, values and dates against transactions. The activities are the same. What differs is the software recording them, and the vocabulary that software uses.

That difference is a naming problem, not a business one.

An invoice is an invoice​

Take the common case. You run HubSpot for CRM and Pronto for ERP. The business you acquired runs Salesforce and Xero.

An invoice raised in Xero and an invoice raised in Pronto are the same financial instrument. Both carry a customer, an invoice number, a date, an amount, quantities, a currency. The field names differ. The meaning does not.

What happens next is the part that makes convergence possible, and it is not what most people expect. CryspIQ® does not store the invoice as an invoice. It decomposes it, and each element is placed in the part of the model that matches what that element is:

Element on the invoiceWhere it landsBecause it is
Invoice numberReferenceFacta reference to something, not a measure
Invoice amountMonetaryFactmoney
Line quantityQuantitativeFacta count or measure
CustomerEntityone of the master data objects
Product or service soldProduct / Servicelikewise
Date of the transactioncarried on each factwhen it happened

Two things then hold this together, and both matter more than the decomposition itself.

Every fact points at a fact type — also known as its mapping type — and that carries the definition of what the data means for the entire business. Not what Xero calls it, and not what this particular report assumes. The definition lives with the data type, alongside its security classification and the dates it is valid between. So when the acquired company's invoice amounts arrive, they are not merely "amounts from Xero" — they are an amount of a defined kind, meaning the same thing as the amounts arriving from Pronto, because both point at the same definition.

This is the enterprise-level context we described in How Do You Know If Your Data Is AI-Ready? — the half most organisations never build. It is also why the sensitivity of a field cannot be lost in transit: the classification is attached to the type, not to the system it came from or the tool being used to read it.

A link key does two jobs. It ties the decomposed pieces from one source record back together, so the invoice can be reassembled whenever it is needed. And it remains the link back to the source record itself — so any figure in a group report can be traced to the row in Xero or Pronto that produced it. That is lineage as a property of the model rather than a separate capability someone has to build.

This is why the two systems converge rather than merely sitting alongside each other. Neither one's invoice structure survives the front door. Both are broken into the same typed elements against the same dimensions, so the question "what did we invoice this customer" does not need to know which system the answer came from. There is no reconciliation step, because there is nothing to reconcile — the amounts are all MonetaryFacts against the same Entity.

It also means the two businesses do not need to agree on an invoice format, a numbering scheme, or a chart of accounts before you can report across them. Those are Xero's and Pronto's concerns, and they stay Xero's and Pronto's concerns.

Same for the CRM side. A customer in Salesforce and a customer in HubSpot are both Entities. Once mapped, they are the same kind of thing, and where they turn out to be the same customer — which after an acquisition is more common than anyone expects — that becomes visible rather than remaining hidden in two systems nobody queries together.

What you get, and when​

Combined reporting across both businesses, without either changing the systems it runs on.

The acquired business keeps trading exactly as it did the day before completion. Its people stay on the business rather than on a migration. And group reporting becomes available in the time it takes to map two sets of sources — weeks, not quarters.

You also get something the migration route does not give you until the very end: an early, evidence-based view of what you actually bought. Customer overlap, margin by segment across the combined book, which products sell into which accounts. Those answers are most valuable in the first ninety days, which is exactly when the migration approach has nothing to show.

This is not an argument against ever consolidating​

Worth being clear, because the opposite claim would be dishonest.

There are good reasons to consolidate systems eventually: licence cost, process standardisation, reducing the number of platforms your team supports. Those reasons are real and they do not disappear.

What changes is that consolidation stops being a prerequisite for visibility. It becomes a business decision, made on its own merits and its own timeline, by people who can already see the combined numbers while they decide. That is a considerably better position to decide from than one where the migration must happen before anyone can tell whether it was worth it.

CryspIQ® is designed to sit alongside what you already run rather than replace it — see co-existence — so mapping the acquired business in does not commit you to anything about its future.

It compounds across deals​

For an organisation that acquires regularly, this changes the shape of the problem.

Under the migration model, every acquisition is another integration programme, and they queue. Under the convergence model, each new business is another set of source mappings into a model that already exists — and because the master data elements are already defined, there is no negotiation about what a customer or an invoice is each time round.

The second acquisition is easier than the first, rather than the same programme again with different logos.

Where to start​

Before commissioning a systems migration, ask three questions:

  1. What does the board actually need to see, and by when? If the answer is combined numbers this quarter, a migration cannot deliver it.
  2. Which activities do both businesses genuinely share? Invoicing, customers, products — usually more than expected, once you look at activities rather than applications.
  3. What would it cost to be wrong? Migrating a business you have just bought is difficult to reverse. Mapping its data is not.

The systems question is worth answering properly. It is just rarely worth answering first.

Further reading