# Knowledge handover records before an acquisition | SourceX

Canonical: https://refer.sourcex.si/guides/workflow-knowledge-handover-gaps
Last updated: 2026-10-20

Before a practice acquisition, inventory the records that show where documented processes depended on undocumented exceptions: the handover checklists, the questions new owners raised that the documents could not answer, the page versions that changed afterward, and the deliverables accepted once the gap was closed. Note which system holds each, who owns it, and the date old spaces or projects may be archived or purged. A knowledge management advisor records metadata only and introduces the operations director with the owner who can authorize a licensing discussion.

A knowledge handover gap is the distance between what a process document says and what the people who ran it actually did. The gap stays invisible until the people change, which is exactly what a practice acquisition does. The records left when a gap surfaces, and gets fixed, are among the most honest a firm holds: they show which knowledge was tacit and how it was finally written down.

## What should be inventoried before a practice acquisition affects knowledge handover gaps history?

Inventory by deal stage, because the risk changes as the deal moves. The real deadline is usually not closing day but the integration step that archives, merges or purges the seller's spaces and projects.

| Deal stage | What to record | Typical risk |
|---|---|---|
| Before signing | Systems in use, years of page and ticket history, who administers each | Nobody knows which spaces hold exceptions |
| Signing to closing | Handover checklists in progress; the purchase agreement's limits on records | Cleanup before closing deletes old versions |
| Transition period | Unresolved questions raised by the new team, and the answers | Answers given by phone or chat, never written |
| Integration | Planned merges, archive dates, purge or tenant deletion dates | Version and issue history dropped in migration |
| After integration | Where the seller's history now lives, and who owns it | Old tenant retired with no export |

## How the history gets lost at each stage

Most losses are routine housekeeping, not decisions about records. That is why they happen without anyone noticing what went with them.

- **Cleanup before closing.** Sellers tidy their wiki before a buyer sees it. In Confluence Cloud, a deleted page sits in the space trash and can be restored until it is purged, but purging removes the item with all its versions and attachments, and deleting a single page version is permanent.
- **Version history that lives and dies with the space.** Confluence keeps a version history for each page, two versions can be compared, and restoring an older version saves it as the newest without deleting later ones. The history survives only if the space does.
- **Tracker history nobody reports on.** Jira has no built-in report of when a field value changed; the information sits in each issue's History tab. A migration that carries only current field values drops the record of when a question was raised and when it was resolved.
- **Answers given live.** New owners ask the seller's staff how an exception works, get the answer on a call and never write it down. The inventory should note whether transition questions were logged at all.

Metadata to collect, never content: record classes, rough counts (pages with more than a few versions, tickets with exception comments), years covered, system owners, and each dated deadline. Do not recommend keeping anything beyond what the company's retention policy, the purchase agreement and client terms allow.

The [IT handover checklist for a sale of business](/resources/it-handover-checklist-sale-of-business) covers credentials, tenants and archive locations, and the [CFO handover document](/resources/cfo-handover-document) covers the finance side. This page is narrower: whether the trail of a single gap can still be followed once systems move. For capturing knowledge before an owner leaves, see [knowledge transfer from a retiring owner](/guides/knowledge-transfer-retiring-owner) and [what institutional knowledge is](/questions/what-is-institutional-knowledge).

Some firms run a formal knowledge program. ISO 30401 sets requirements for a knowledge management system that apply to any organization regardless of type or size. A firm working to it may already keep handover and lessons-learned records in a consistent place, but the standard is not a condition of a SourceX introduction.

## Questions for the operations director and the owner

The operations director usually knows the systems; the owner, and after closing the buyer, decides what happens to them. Ask both:

1. Which systems hold process documents, handover checklists and transition questions, and since when?
2. Does the purchase agreement or any client contract limit which records can be kept or discussed?
3. Is any cleanup, archive or purge planned before closing or during integration, and on what dates?
4. Will page version history and issue history move to the buyer's systems, or only current content?
5. Who on each side can decide whether these records are discussed with an outside party?

## Does the firm qualify, and what stays unknown?

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. In an acquisition, check which entity will hold the records after closing; the seller's authority can end on that date.

What stays unknown until SourceX reviews it: which records the firm has rights to license, what client details must be removed, SourceX's current data needs, and any offer. The [internal knowledge bases page](/data-types/internal-knowledge-bases) describes the record type in general, and a firm without a formal wiki can still be introduced, as [this answer](/questions/can-i-introduce-a-company-that-has-no-formal-knowledge-base) explains.

## Go deeper on knowledge handover gaps

- [Knowledge handover gap exception examples](/guides/knowledge-handover-gaps-exception-examples): worked cases showing which records explain how a hidden exception was found and documented.
- [Reconstructing handover gaps across systems](/guides/knowledge-handover-gaps-records-across-systems): a system map of the links between checklists, page versions and tracker comments.
- [Who can license knowledge handover records](/questions/who-can-license-knowledge-handover-gaps-records): a short answer on which seller and buyer roles to introduce.
- [Knowledge handover gaps referral brief template](/resources/knowledge-handover-gaps-referral-brief-template): a fill-in template for the one-page introduction.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If the gap trail still runs from checklist to page version to ticket and the integration plan has a merge or purge date, [register as a partner](/register), check the firm against [who qualifies](/who-qualifies), and read the [program terms](/terms) and [reward rules](/rewards) before sending the note.

## Sources

- https://refer.sourcex.si/terms
- https://support.atlassian.com/confluence-cloud/docs/create-edit-and-publish-a-page/
- https://support.atlassian.com/confluence-cloud/docs/delete-restore-or-purge-a-page/
- https://support.atlassian.com/jira/kb/how-to-identify-and-list-when-a-field-value-was-changed-in-jira/
- https://www.iso.org/standard/68683.html