Migrating an acquired team's GitHub organization: what to preserve

What history does a GitHub organization hold, and how far back does it go?

An organization holds two layers of history. The git layer, meaning commits, branches and tags, travels with any clone. The platform layer, meaning pull requests, review comments, issues, discussions, wikis, Actions runs and releases, lives in GitHub itself and does not move with a plain git push. Code-only integration plans keep the first layer and lose the second.

Git history reaches back to the first commit, which can predate GitHub if the team once used Subversion or another host. Platform history usually starts when the team adopted GitHub, so an acquired team that has worked there for years holds every pull request, review thread and issue since then, including those in archived repositories.

Feature names and plan limits change, so confirm each row against GitHub's current documentation before the move.

Why do pull requests and issue threads matter to AI buyers?

A pull request is a complete record of one unit of engineering work: the problem (a linked issue), the attempt (the diff), critique (review comments and requested changes), revision, tool feedback (CI results) and a verdict (merged or closed). AI developers building agents that write, test and review code need records of exactly that loop, and private commercial codebases rarely appear on the public web.

The history is worth more when it is connected and consistent:

• Merges to the main branch go through reviewed pull requests rather than direct pushes.
• Pull request descriptions explain why the change was made and link the issue or ticket.
• CI runs on each pull request and the results are kept.
• Decisions are written down, for example architecture decision records and incident postmortems stored in the repository.
• Engineering work connects to other systems: a support ticket leads to an issue, a pull request and a release note.

GitHub is rarely the only system worth protecting: chat and support tools often merge in the same quarter; see merging Slack workspaces after an acquisition and keeping ticket history when helpdesk instances merge.

Which migration path keeps the most history?

Transferring repositories, or leaving the acquired organization intact under the parent's enterprise account, keeps the most. Re-creating repositories by pushing git history into new ones keeps the least.

Two rules cover most of the risk. Archive, do not delete: archived repositories are read-only and keep their history. And preserve before you harmonize: when the parent rolls its retention schedule over the acquired company, old repositories can fall inside a deletion sweep, which the guide to harmonizing data retention policies after an acquisition helps you plan around.

What rights checks come before anyone licenses the code?

Ownership comes first. Code employees wrote in their jobs generally belongs to the company; contractor, open-source, forked and client code each need their own check.

Under US copyright law, a work prepared by an employee within the scope of employment is a work made for hire, and the employer is treated as its author (17 U.S.C. § 101). Commissioned work from outside contractors qualifies as made for hire only in listed categories and with a signed written agreement, as the Copyright Office's Circular 30 on works made for hire explains, so ownership of contractor-written code usually turns on a written assignment. The ownership section of the Copyright Act (17 U.S.C. § 201) also lets any exclusive right be transferred and owned separately, which is how a company can grant a narrow license while keeping ownership.

Two companion guides help here: an open-source license audit before licensing a private codebase, and which legal entity can license which records once the acquired entity is merged or kept.

Repositories also carry personal data and secrets: author names and emails in commit metadata, credentials committed by mistake, customer records in test fixtures. Redaction and de-identification rules are settled with the company before work starts, and nothing is delivered until an agreement is executed and the company authorizes it.

This is general information, not legal, tax or financial advice. Confirm ownership questions with the company's IP counsel before acting.

How can an operating partner spot a strong GitHub history without seeing code?

Ask the portfolio CTO or VP of engineering six questions; you never need repository access.

• Has the organization kept several years of continuous history, including archived repositories?
• Do merges to the main branch require a reviewed pull request?
• Do pull requests link an issue or ticket that explains the change?
• Was most of the code written by employees, or do contractor agreements assign IP?
• Is client-owned code kept out of the organization, or clearly separated?
• Can someone run exports and own an inventory?

On size and history, the portfolio company needs 50+ full-time employees at peak (contractors excluded) and several years of documented US operations, plus the right to license what it holds and an executive with authority to sign. The company fit checker gives a preliminary, non-binding read with no contact details required.

A short note to the integration lead before repositories move does most of the work:

Which mistakes erase history during an integration?

• Deleting the acquired organization when its plan lapses, which removes every repository still inside it.
• Rewriting or squashing history as a cleanup step; rotate exposed credentials instead where you can, and agree any purge with security and counsel.
• Moving issues to another tracker without links back to the pull requests that resolved them.
• Switching off CI services or third-party integrations without exporting their logs.

How do introductions and rewards work for operating partners?

You make the introduction; SourceX qualifies the company on size, history, data breadth and rights, and the company completes a data inventory that can describe repositories, years of history and pull request volume without sharing code. Partners never export, upload or describe confidential records. The page for private equity operating partners covers the role across a whole portfolio.

Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company. Rewards become payable only after the buyer pays and SourceX receives its fee, and no reward is guaranteed. The reward comes from SourceX's fee and is never deducted from what the portfolio company receives; check your firm's policy on fees connected to portfolio companies before you join.

Next step

Before the next integration milestone, put the six questions to the CTO and keep the old organization archived until the answers are in. If the company looks like a fit, register as a partner and make the introduction, or share your referral link so the CEO can apply at sourcex.si/apply.