Blog · Platform Separation

GitHub separates by organization, and by every pipeline wired into it.

GitHub TSA separation is the work of standing up a dedicated Newco organization or enterprise account, moving the repositories and their full history, rebuilding the Actions pipelines and self hosted runners, reconnecting the security and integration apps, and exiting the seller tenant before Newco source code keeps living under the seller administration. The work sits inside the broader carve-out advisory program because source code is the operating asset of a software business. Treated casually, it leaves Newco intellectual property inside the seller account and the seller bill.

5
Workstreams
2 to 4 Mo.
Typical Timeline
7 min
Read Time
2026
Last Updated
Section 01

Repository inventory and target tenant strategy.

GitHub separation starts with an inventory of the seller tenant. The buyer needs the repository list and which repositories carry Newco code, the organization and team structure, the member directory and which developers move to Newco, the installed GitHub Apps and OAuth integrations, the Actions workflows and self hosted runners, the packages and container images, and the secrets stored at organization and repository level. Source code is where the product actually lives, so the inventory is a map of how the engineering organization builds and ships rather than a simple file count.

The seller typically hosts Newco repositories inside a shared organization or a GitHub Enterprise account alongside the rest of the seller business. The clean end state is a dedicated Newco organization, or a Newco enterprise account on GitHub Enterprise Cloud, contracted directly with GitHub. A shared seller organization is acceptable only as a bridge during the TSA, never as a steady state, because the seller controls administration, audit logging, and who can read Newco source code.

Target tenant strategy depends on Newco scale and compliance posture. A single organization suits a smaller standalone business, while a larger Newco may stand up an enterprise account with multiple organizations, or run GitHub Enterprise Server where regulatory constraints require self hosting. The decision is settled early because it drives the migration mechanism, the identity model, and how repositories and teams are mapped out of the seller environment.

A clean inventory drives the downstream sequence: the contract, the organization build, the repository and history move, the Actions and runner rebuild, and the cutover. A repository missed in the inventory is code that stays stranded in the seller tenant after exit, which is exactly the outcome the separation exists to prevent.

Section 02

Contracting and the GitHub commercial.

GitHub is licensed per seat on a plan tier, often bundled into a broader enterprise agreement on the seller side. That seller agreement does not transfer in a carve-out. Newco signs a direct contract sized to its real engineering headcount and the plan features it needs, whether GitHub Team or an Enterprise plan with Advanced Security. The risk is that Newco inherits a plan scaled for the seller, paying for Enterprise capability or security add ons the smaller business does not yet require.

GitHub reads a carve-out as a buyer with an engineering team that needs to keep shipping. Negotiating leverage comes from a credible alternative, whether a competing platform or a lower plan tier, and from the seat commitment. The buyer scopes the Newco plan from the member inventory before negotiating, and writes migration support and a clear export path into the contract so the organization can be stood up and validated before cutover rather than configured under deadline pressure.

Where the seller continues to host Newco repositories through a TSA period, the pricing is cost-plus or fixed-fee with a defined exit ramp. The seller cannot mark up a per seat subscription it already holds, and the TSA defines audit access, who administers Newco repositories, and how code and history are returned at exit. The same discipline that governs license consolidation applies so Newco eliminates duplicate developer tooling spend at exit.

Implementation, where a partner is engaged, is fixed fee for defined deliverables under disciplined change control. An organization stand up has a finite scope, so it is contracted against named repositories, teams, and pipelines rather than open ended consulting time. The engagement model across the program is Fixed Fee plus Portfolio Retainer, never a billing arrangement tied to hours.

Section 03

Repositories, history, and the IP boundary.

The Newco organization is built and the repositories are moved into it. GitHub supports transferring a repository between organizations, which preserves the full git history, issues, pull requests, and stars, and a mirror clone covers cases where a transfer is not possible. The buyer confirms that branches, tags, releases, and Git LFS objects move with the repository rather than leaving large binaries behind in the seller tenant.

History is the part buyers underestimate. The value of a repository is its full commit history, its issue and pull request record, and its release artifacts, not just the latest branch. The buyer decides which repositories Newco needs in full and confirms that the migration carries the complete record, because a shallow copy that drops history strips the audit trail and the institutional memory the engineering team depends on.

The intellectual property boundary is the legal heart of the work. Repositories in the seller tenant can contain Newco code and seller code intermingled, and the reverse is also true, so the migration is scoped to move what belongs to Newco and leave what belongs to the seller. Shared libraries and internal packages owned jointly need explicit treatment in the purchase agreement so ownership is settled rather than assumed.

Packages and container images are part of the same boundary. The buyer inventories the GitHub Packages registry and the container images Newco builds depend on, and rehosts them in the Newco organization so the build pipeline does not reach back into the seller registry after cutover.

Section 04

Identity, Actions, and the integration estate.

Identity is the foundation. SAML single sign on and SCIM provisioning are reconfigured against the Newco identity provider so developers authenticate into the Newco organization from the first day and deprovision cleanly when they leave. Where the seller managed GitHub identity through its directory, the buyer rebuilds the connection so Newco controls access rather than depending on the seller, and personal access tokens and deploy keys are rotated as part of the move.

The Actions and integration estate is the part that breaks. Workflows reference secrets, environments, and self hosted runners, and an Actions pipeline that built and deployed cleanly in the seller organization is dead until its secrets are recreated and its runners are reconnected against Newco infrastructure. The buyer inventories every workflow, recreates organization and repository secrets in the Newco tenant, and stands up runners so continuous integration keeps working after the move.

Third-party apps compound the work. Security scanning, code quality, deployment, and project tracking tools connect to GitHub through apps and webhooks. Each app is reinstalled and reauthorized against the Newco organization, and the webhooks that drive ticketing and chat alerts are repointed. The work parallels the broader Jira and Confluence separation where the same engineering toolchain is rebuilt around Newco identity.

Branch protections, required checks, and organization policies are recreated so the Newco organization enforces the same engineering controls from Day One. A repository that arrives without its protection rules invites unreviewed merges into the main branch on the very first day.

Section 05

Cutover, validation, and developer adoption.

Cutover moves the engineering organization from the seller tenant to the Newco organization. Because developers work in GitHub continuously, the cutover is sequenced to avoid a window where code lives in two places. The runbook covers the repository move, the identity provisioning, the Actions and runner rebuild, the app reconnection, and a communication plan that tells every developer when to switch their remotes and where the new organization lives.

Validation confirms the organization works for real engineering. Developers can clone and push, pull requests open and merge, required checks run, Actions pipelines build and deploy, and packages publish and resolve. The buyer runs a real build and a real deployment end to end before declaring the move complete, because a separation that leaves a broken pipeline has not actually moved the engineering capability.

Stabilization runs two to four weeks while the team settles. Broken workflows, missing secrets, and unconnected apps are triaged within agreed service-level commitments, and the buyer monitors commit and build activity to confirm work has moved and the seller organization has gone quiet. Only after the pipeline is stable does the buyer certify source control for TSA exit.

Decommissioning the seller access is explicit. Once the Newco organization is live and the TSA tail closes, the seller removes Newco members, revokes residual tokens, and confirms that Newco repositories are deleted from the seller tenant so the code no longer persists in the seller environment.

Section 06

Cost discipline and where carve-outs go wrong.

GitHub separation cost is driven by the per seat plan and by the effort of rebuilding Actions, runners, and the app estate. The discipline is to size the plan tier and the security add ons to Newco real needs rather than inheriting the seller configuration, retire the repositories and apps that no longer serve the standalone business, and treat the move as a chance to consolidate sprawling organizations rather than copy every archived repository.

The common failure mode is treating GitHub as a simple repository copy and underestimating the build and integration estate. The organization cannot be cleanly exited until the pipelines, runners, secrets, and apps are reconnected against Newco infrastructure. Buyers that inventory every workflow and integration first avoid the discovery that the code moved but nothing builds.

The common legal mistake is leaving the intellectual property boundary vague. The fix is to settle code ownership, shared libraries, and package registries in the purchase agreement, and to document exactly what moved and what the seller retains. A PMO maintains the dependency map across source control, identity, and the systems the pipelines deploy to, escalating blocks inside forty eight hours.

A clean GitHub separation produces a Newco that owns its own organization, its own code, and its own pipelines, with engineering that ships from Day One. The discipline runs through the TSA exit acceleration program under a Fixed Fee plus Portfolio Retainer engagement model.

FAQ

Questions buyers ask about GitHub separation.

Does Newco need its own GitHub organization?

Yes. The clean end state is a dedicated Newco organization or enterprise account contracted directly with GitHub, with its own repositories, teams, and pipelines. A shared seller organization is acceptable only as a bridge during the TSA, because the seller controls administration, audit logging, and who can read Newco source code.

Can full git history be migrated to a new organization?

Yes. GitHub repository transfers preserve the complete commit history, issues, and pull requests, and a mirror clone covers cases where a transfer is not possible. The buyer confirms that branches, tags, releases, and Git LFS objects move with the repository so no history or large binaries are left behind in the seller tenant.

What breaks first in a GitHub exit?

The Actions pipelines and self hosted runners. Workflows depend on secrets, environments, and runners that do not move automatically, so when repositories change organizations the secrets must be recreated and the runners reconnected against Newco infrastructure. An unmapped pipeline leaves a build that no longer runs and a deployment that no longer fires.

How long does a GitHub separation take?

GitHub itself can stand up quickly, but identity, the Actions estate, and the integration apps drive the timeline. Most buyers plan two to four months so the source control cutover aligns with identity separation and the infrastructure the pipelines deploy to.

Related Reading

More on platform separation.

Free Download

Get the buyer-side TSA Exit Playbook.

The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.

No spam. Unsubscribe in one click. · Read the overview first →

GitHub separates by organization, and by every pipeline wired into it.
TSA Exit Acceleration

Off the seller’s GitHub tenant. Shipping from Day One.

Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.

White paper

The TSA Exit Playbook

Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.

Read the playbook →
White paper

The IT Separation Playbook

Stand up standalone IT before the TSA meter and the seller's dependencies compound against you.

Read the playbook →
The Day One Letter

Get buyer-side TSA intelligence every two weeks

One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.

Subscribe to The Day One Letter →