I would rather defer a software integration saving than recognise it before we understand the operating knowledge that makes the acquired product dependable. That knowledge is not always located in a formal process or a current design document. It may sit with an engineer who knows why a release sequence differs for one customer, or a support colleague who can identify a recurring configuration problem from an apparently unrelated symptom. Removing the practice that carries it can be easy. Reconstructing it after failure can be expensive.
This is not a defence of permanent separation after an acquisition. Duplicate tools, inconsistent controls and avoidable complexity have costs of their own. My argument concerns the order of decisions. A buyer should distinguish what it can standardise safely now from what it has not yet understood. That distinction should appear in the integration plan with owners, evidence and a point of reconsideration. Without it, a timetable can create the appearance of decisive management while transferring unresolved risk into product operations.
Find the knowledge that has no obvious owner
During our acquisition of Ostren Workflow, we found useful history in a small support tool that the integration proposal regarded as redundant. The tool contained configuration notes and incident relationships that were not fully represented in the current documentation. Its continued use was inconvenient for the combined organisation. Its immediate removal would have made some experienced colleagues the only remaining route to knowledge others needed. We kept it for a defined period while transferring and testing the material that mattered.
The discovery changed how we asked diligence and integration questions. We wanted to know which operating outcomes depended on an experienced person noticing something unusual. Where did the written process stop? Which release steps were performed in a particular order for reasons no longer obvious? Which customer commitments had produced configurations that looked accidental to an outsider? These questions did not imply that the acquired team had managed badly. Small software companies often preserve speed through informal knowledge. The buyer needs to understand what that informality is carrying before changing it.
An organisation chart is an incomplete map of this dependency. The person whose title appears central may not hold the practical knowledge required for a difficult support decision. Conversely, a colleague with deep historical understanding may be spending much of their time on work that could be transferred more easily. I ask leaders to observe actual releases and incidents rather than infer importance entirely from reporting lines. This produces a more useful discussion about retention, role design and the sequence in which responsibilities can move.
The acquired team's account also needs challenge. A practice may be described as essential because nobody has tried another way, or because its owner reasonably fears losing influence. We should neither dismiss nor automatically accept that description. A testable explanation helps: what outcome does the practice protect, under which conditions, and how could another person demonstrate the same capability? That approach respects experience while creating a route beyond permanent dependency on particular individuals. The purpose of transfer is to make important knowledge usable more widely, not to celebrate its secrecy.
Make the pause a decision with conditions
We deferred US$1.4 million of anticipated first-year savings in the Ostren integration. That was a decision with a cost, and the board needed a reason more specific than caution. I explained which release and support dependencies we had not yet understood, what observation period we needed and which changes could still proceed. The pause did not cover every integration task. Financial reporting and agreed control improvements continued, while selected product-operating changes waited for evidence that the receiving team could perform the work reliably.
The distinction mattered to colleagues. If management says only that integration is paused, people may infer that the acquisition thesis is in doubt or that the acquired company will remain untouched. Neither described our position. We wanted a combined business, and we expected certain practices to change. We also recognised that announcing a new process did not create the competence needed to use it. I would communicate that reasoning earlier in a future transaction, because uncertainty about intent can itself make knowledgeable people consider leaving.
Conditions for moving forward should concern capability, not activity. A hundred completed documents do not establish that a team can handle a difficult customer configuration. Attendance at a training session does not show that someone can identify the exception that makes a standard procedure unsafe. We used paired work on real incidents and release preparation, with a receiving colleague carrying increasing responsibility. The original expert remained available, but the review examined whether the work could proceed without their private intervention at every critical step.
There is a temptation to turn the pause into an indefinite protection for familiar arrangements. I resist that too. Each retained practice needs a decision date and an owner for the evidence required to change it. If a transfer cannot be completed, management should explain whether the obstacle is capability, product design or an obligation that the acquisition model understated. That explanation may change the integration economics. Discovering it is better than preserving a saving in a spreadsheet while the operational cost reappears elsewhere under a different label.
Test transfer through somebody else's action
Our most useful reviews asked a colleague from the acquiring team to work through a situation using the transferred record. Could they identify the relevant configuration, explain the release dependency and reach the appropriate escalation point? Where they could not, we returned to the material or the process. This was a more demanding test than asking the original author whether the documentation was complete. Familiarity makes omissions hard to see; a receiving colleague reveals them by trying to act without the history the author carries implicitly.
We also watched customer outcomes during the transition. Consolidation that appears complete internally but produces more severe incidents has not delivered its intended value. Over eighteen months, we completed the main release-process consolidation without increasing the acquired product's severity-one incident count. Thirty-five of the original thirty-eight engineers remained. Those measures are relevant but not a complete causal explanation. Retention depends on several factors, and incident counts can conceal changes in severity or exposure. We kept the supporting case reviews rather than asking two headline numbers to prove the whole integration approach.
The broader lesson is that operating memory deserves an explicit place in the acquisition plan. It affects which people need support, which tools can be retired and which savings can responsibly be recognised when. A chief executive does not need to understand every technical dependency personally. They need to ensure that the people making integration decisions have examined those dependencies and can demonstrate the capability that is supposed to replace them. That is how a buyer turns an acquired product into a durable part of the company, rather than discovering after completion that it purchased knowledge it had not arranged to keep.