You Bought the Company. Did You Buy What It Knows?

An acquisition transfers the assets, the records and the people. It does not transfer the reasoning that made the acquired business work, because that reasoning was never written down anywhere the deal could reach it.

This is not a rare or exotic problem. The Office for National Statistics provisionally put mergers and acquisitions involving UK companies at 353 in Quarter 2 (Apr to June) 2026, and that figure covers only transactions worth £1 million or more that changed majority ownership, so the true number of businesses absorbing another one in any given quarter is higher than the published count. Most of those deals are not headline transactions. They are a mid-market company buying a smaller one for its customers, its region, its licence, or the particular thing it happens to be very good at.

And in a good number of them, six months later, somebody asks a question that the acquired team used to answer in ten seconds, and nobody can answer it at all.

Three things change hands, and only two of them move on their own

It helps to separate what an acquisition actually delivers, because the three parts behave completely differently and only one of them needs your attention.

What you acquired	How it transfers	Who owns it in the plan
Assets, contracts, intellectual property, systems	Automatically, on completion	Legal and finance
Records: files, CRM, drives, whatever wiki they kept	With the systems, more or less intact	IT
Reasoning: why the business works the way it does	Only if somebody moves it deliberately	Nobody

The first row is what the lawyers spend their time on and it looks after itself. The second row is what the integration plan spends its time on, and it is largely a migration exercise. The third row is the one you paid for and the only one with no owner.

You can see the shape of the problem in how the government thinks about its own data. The UK guidance on preparing government datasets for AI warns that providing raw data or basic APIs without information on data quality or provenance can lead to misunderstanding and misuse. That is a fair description of what lands on your side of an acquisition. You get the records without the provenance. Every file is technically yours and none of it tells you which version is still in force, who decided it, or what it was a response to.

The post-acquisition integration plan has a line for everything else

Look at the plan for the first 100 days after completion. Systems consolidation has an owner and a date. Payroll and contracts of employment have an owner and a date. The brand decision, the customer communication, the rebadging of the vans, the merging of two accounting periods, all of them have somebody's name against them.

The reasoning behind how the acquired business made money has nobody's name against it. It is assumed to transfer through proximity, which is to say through people sitting near each other and asking questions when something comes up.

There is nothing stupid about that assumption. Knowledge really does move that way inside a stable business, and it works well enough while everyone involved is still employed and still cheerful about it. What makes it dangerous in an acquisition is that it is the only mechanism in place, and it has a deadline nobody has written down.

IBM's study of 2,000 chief executives reports that CEOs cite lack of collaboration across organizational silos, aversion to risk and disruption, and lack of expertise and knowledge as top barriers to innovation in their organization. An acquisition creates all three at once, on a single Monday morning. You have just built a new silo, introduced a group of people with every reason to be wary, and taken on a body of expertise you cannot yet describe.

Two versions of everything, from the first week

The day after completion, your business has two answers to a long list of questions and no way of telling which is right.

There are two views on what a good customer looks like, and two pricing logics, one of which quietly discounts on volume and one of which quietly does not. There are two positions on how much discretion a project manager has before something needs signing off, and two lists of suppliers, with one company avoiding a supplier the other uses weekly for a reason nobody on your side of the deal can recall.

This is different from the ordinary drift a business accumulates as it grows. Drift is gradual, it happens to one company over years, and you can usually trace it. What an acquisition produces is a collision, fully formed, on day one, between two sets of practice that each made complete sense in their own context. Neither side is wrong. Both sides can defend their version, and neither can explain the other's.

The failure mode is not the argument. It is what happens when nobody has the argument at all, and the two versions carry on running in parallel until a customer notices they have been quoted differently by two parts of the same business.

The clock is the retention period, not the integration timetable

Retention arrangements and earn-outs commonly run 12 to 24 months. Integration plans are usually written against that horizon, which is how the knowledge work ends up scheduled for a phase two that never quite arrives.

The problem is that the useful part of the window is much shorter. In the first weeks the acquired team is engaged, proud of what they built, and pleased to be asked how it works. Being asked to explain your business to the people who bought it is flattering early and tiresome later. Somewhere around month six, the same question gets a shorter answer.

Then the founder's earn-out completes, the operations manager takes a job with a competitor, and the two people who could reconstruct the pricing logic from memory are both gone.

The same IBM study found that 69% of the chief executives surveyed say their organisation's success is directly tied to maintaining a broad group of leaders with a deep understanding of strategy and the authority to make critical decisions. An acquisition is one of the few events that can shrink that group overnight, because the people who held the acquired company's strategy in their heads are precisely the people with the money and the options to leave. We have written elsewhere about what walks out of the door when one key operator resigns. An acquisition is that risk applied to an entire team at once, with a known expiry date attached.

What the first 100 days should actually contain

None of this needs a large programme. It needs somebody to be responsible and a small number of things written down properly.

Give the question an owner. One named person whose job is the reasoning, not the systems. Without a name against it, this loses every scheduling conflict to something with a deadline.

Ask the questions the data room could not answer. Not the process, the judgement behind it. Why is that customer on a different rate? What made you stop bidding for that type of work? Which of your suppliers would you never use again, and what happened? Fifteen good questions will get you further than a process-mapping exercise, and they take an afternoon each.

Write the answers down where they can be cited. With a date, a named source, and the reasoning attached rather than just the conclusion. A decision that arrives with its reasoning survives a change of personnel. A decision recorded as a rule gets overturned by the first person who thinks it looks arbitrary. Our piece on what an intelligence system actually contains covers the shape this takes.

Do not let the migration stand in for the work. Moving the acquired team onto your stack is worth doing for licensing, security and reporting, and it moves precisely none of this. It also consumes the same months and the same people. If you have to sequence them, capture first. Our comparison of where company knowledge should actually live makes the wider case that the tool is the least important part of this question.

Decide which version wins, and record why. Both pricing logics, both definitions of a good customer, both approval thresholds. Choose deliberately, write down the reasoning, and the decision holds. Skip that step and the same argument gets reopened in eighteen months by people who were not in the room the first time.

What this looks like when it works

None of this is unique to acquisitions. Any business running the same commercial motion in several places has a version of it.

We built a content engine for Excellerate Services across three regions and two sectors. The work was already being done well. What varied was the standard, which differed from region to region and lived largely with whoever happened to be doing it that week. Putting that standard somewhere the whole business could reach it made brand control consistent across every market for the first time, and it took weekly production from roughly 12 hours down to about 2 hours of oversight.

For an acquirer, the consistency is the part worth noticing rather than the hours. You arrive at two ways of working, both defensible, and what you need is one shared account of what the business now believes, written down where anybody can check it.

If you are not sure how much of the acquired company's reasoning is actually recoverable, that question has a shape and a price, and we have written up what a knowledge and intelligence audit involves and what it costs. An acquisition is one of the clearest cases for buying one, because the deadline is real and it is not yours to move.

Practical takeaways

• An acquisition transfers assets and records automatically. The reasoning behind how the business worked transfers only if somebody is made responsible for moving it.
• The integration plan gives every other workstream an owner and a date. Give this one an owner and a date too, or it will lose to whatever has a deadline.
• The capture window is the first 100 days, not the retention period. Willingness to explain the business decays long before the earn-out completes.
• Systems consolidation is worth doing and it does not solve this. It moves files, and the files were never the hard part.
• Where two versions of a process collide, record the reasoning behind the decision and not just the decision itself, because the reasoning is what stops the argument being reopened.
• Ask fifteen judgement questions rather than mapping fifty processes. The judgement is the part you paid for and the part that leaves.

Frequently asked questions

What knowledge do you actually acquire when you buy a company?

You acquire the records and you acquire access to the people, and those are two different things from the knowledge itself. The records are the files, the CRM, the drives and whatever wiki the team kept, and they arrive intact because they travel with the systems. The people arrive too, for as long as they stay. What sits between the two is the reasoning, which is why the pricing works the way it does, which customers were quietly not worth having, why a supplier was dropped in 2023 and never reinstated. None of that is in the data room and none of it is in the folders. It is in the heads of eight or ten people, and you have bought their time rather than their thinking.

Why does knowledge get lost after an acquisition?

Because nobody is made responsible for moving it, and the loss is invisible until somebody needs an answer. Every other workstream in an integration has an owner with a date against it. Systems consolidation belongs to IT, payroll belongs to HR, contracts belong to legal, and the brand decision belongs to marketing. The reasoning behind how the acquired business worked belongs to nobody, so it is left to transfer through conversation and proximity. That works while the people who hold it are still in the building and answering questions willingly. It stops working the moment they leave, and by then there is no record of what they knew, only a gap where decisions used to be quick.

How long after a deal do you have to capture what the acquired team knows?

Less time than the integration timetable assumes, because the window closes when the people leave rather than when the plan says integration is complete. Retention arrangements and earn-outs usually run 12 to 24 months, and the honest position is that the useful part is shorter still. The first few months are when the acquired team is engaged, still identifies with what they built, and finds it flattering to be asked how it works. That willingness decays well before the retention period ends. Treat the first 100 days as the capture window, not the point at which you have made a start, and ask the questions while somebody still wants to answer them.

Should you move an acquired company onto your systems?

Often yes for licensing, security and reporting, but do not expect it to solve the knowledge problem, because it does not touch it. Consolidating two businesses onto one stack is a sensible piece of housekeeping and it is genuinely worth doing. What it moves is the files, and the files were never the difficult part. The reasoning behind them does not migrate with a folder, and a migration project can actively make things worse by consuming the same months and the same people you needed for the capture work. Do the consolidation because it saves money and effort on its own terms. Do the knowledge work separately, and do it first if you have to choose.

Should the acquired business adopt your way of working, or the other way round?

Neither, until you can say out loud why each business does what it does, because otherwise you are choosing between two processes you only half understand. The default is that the buyer's way wins, and it wins on authority rather than on merit. Sometimes the acquired business is better at the thing you bought it for, which is frequently why you bought it. Write down the reasoning behind both versions of the process first, then decide which one survives, then record why. That last step is the one everybody skips, and it is the reason the same argument gets reopened eighteen months later by people who were not in the room.