TSA Exit Acceleration
Off the seller’s GitLab tenant. Building from Day One.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
GitLab TSA separation is the work of standing up a dedicated Newco instance or top level group, moving the projects and their history, rebuilding the CI pipelines and runners, reconnecting the registry and integrations, and exiting the seller tenant before Newco source code and its delivery pipeline keep living under the seller administration. The work sits inside the broader carve-out advisory program because the GitLab instance is both the code and the factory that ships it. Treated casually, it leaves Newco development inside the seller environment and the seller bill.
GitLab separation starts with an inventory of the seller tenant. The buyer needs the group and project tree and which projects carry Newco work, the member directory and which developers move to Newco, the CI pipeline definitions and the runners that execute them, the container and package registries, the CI variables and secrets, and the integrations wired into the instance. GitLab carries code, pipelines, and artifacts in one platform, so the inventory maps the whole delivery chain rather than a repository list alone.
The seller often runs Newco projects inside a shared top level group on GitLab SaaS, or on a self managed instance that serves the entire seller business. The clean end state is a dedicated Newco top level group on GitLab SaaS, or a Newco owned self managed instance, contracted and administered by Newco. A shared seller group or instance is acceptable only as a bridge during the TSA, because the seller controls administration, runners, and access to Newco code.
Target instance strategy turns on whether Newco runs GitLab SaaS or self managed. SaaS removes the burden of operating the platform but requires a project migration into a Newco group. A self managed instance gives Newco full control and suits regulated workloads but means standing up and operating the application. The decision is settled early because it drives the migration mechanism, the runner architecture, and the identity model.
A clean inventory drives the downstream sequence: the contract, the instance or group build, the project and history move, the CI and runner rebuild, and the cutover. A project or a registry missed in the inventory is work that stays stranded in the seller tenant after exit.
GitLab is licensed per seat on a tier, whether Premium or Ultimate, often inside a broader seller agreement. That agreement does not transfer in a carve-out. Newco signs a direct subscription sized to its real engineering headcount and the tier features it needs. The risk is that Newco inherits an Ultimate tier scaled for the seller, paying for security and compliance capability the smaller standalone business does not yet require.
GitLab reads a carve-out as a buyer with a delivery pipeline that has to keep running. Negotiating leverage comes from a credible alternative and from the seat commitment Newco brings. The buyer scopes the Newco subscription from the member inventory before negotiating, and writes migration support and a clear export path into the contract so the instance or group can be validated before cutover rather than configured against a deadline.
Where the seller continues to host Newco projects through a TSA period, the pricing is cost-plus or fixed-fee with a defined exit ramp. The seller cannot mark up a subscription it already holds, and the TSA defines who administers Newco projects and runners, audit access, and how code and registries are returned at exit. The same consolidation discipline applies so Newco retires duplicate developer tooling at exit.
Implementation, where a partner is engaged, is fixed fee for defined deliverables under disciplined change control. An instance stand up or a group migration has a finite scope, so it is contracted against named projects, runners, and pipelines rather than open ended consulting time. The engagement model is Fixed Fee plus Portfolio Retainer.
The Newco group or instance is built and the projects are moved into it. GitLab supports project and group export and import, which carries the repository, the issues, the merge requests, and the project history, and a mirror clone covers the git history where an export is constrained. The buyer confirms that branches, tags, and the merge request record move so the engineering history is preserved rather than truncated.
History matters as much in GitLab as the code itself. The merge request record, the issue history, the pipeline history, and the release evidence are the audit trail of how the product was built. The buyer decides which projects Newco needs in full and confirms the migration carries the complete record, because a shallow import that drops history strips the engineering memory the team depends on.
The container and package registries are a distinct workstream. GitLab projects build images and packages into the integrated registry, and pipelines pull those artifacts on every run. The buyer rehosts the registries Newco depends on into the Newco instance so the build does not reach back into the seller registry after cutover, and confirms that image references in pipeline definitions are repointed.
The intellectual property boundary is settled in the purchase agreement. Projects can intermingle Newco and seller code, and shared internal libraries need explicit ownership treatment so the migration moves what belongs to Newco and leaves what belongs to the seller.
Identity is the foundation. SAML single sign on and SCIM provisioning are reconfigured against the Newco identity provider so developers authenticate into the Newco instance from the first day and deprovision cleanly when they leave. Where the seller managed GitLab identity, the buyer rebuilds the connection so Newco controls access, and access tokens and deploy keys are rotated as part of the move.
CI runners are the part that breaks. Pipelines depend on registered runners, whether shared SaaS runners or self managed runners on Newco infrastructure, and on CI variables that hold credentials. A pipeline that built and deployed cleanly in the seller tenant is dead until its runners are registered to the Newco instance and its variables are recreated. The buyer stands up runners and rebuilds the variable set so continuous integration keeps working after the move.
Integrations compound the work. GitLab connects to issue trackers, chat, security scanners, and deployment targets through integrations and webhooks. Each is reconfigured against the Newco instance and the webhooks repointed. The discipline parallels the broader GitHub separation work where the same engineering toolchain is rebuilt around Newco identity and infrastructure.
Protected branches, approval rules, and instance policies are recreated so the Newco instance enforces the same engineering controls from Day One. A project that arrives without its protection rules invites unreviewed merges into the default branch on the first day.
Cutover moves the engineering organization from the seller tenant to the Newco instance. Because developers depend on GitLab continuously, the cutover is sequenced to avoid a window where code and pipelines live in two places. The runbook covers the project move, the identity provisioning, the runner registration, the registry rehosting, the integration reconnection, and a communication plan that tells every developer when to repoint their remotes.
Validation confirms the instance works for real engineering. Developers can clone and push, merge requests open and merge, pipelines build and deploy, runners pick up jobs, and the registry serves images. The buyer runs a real pipeline end to end, from commit to deployment, before declaring the move complete, because a separation that leaves a broken pipeline has not moved the delivery capability.
Stabilization runs two to four weeks while the team settles. Failed pipelines, missing variables, and unregistered runners are triaged within agreed service-level commitments, and the buyer monitors commit and pipeline activity to confirm work has moved and the seller instance 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 instance is live and the TSA tail closes, the seller removes Newco members, revokes residual tokens, and confirms Newco projects and registries are deleted from the seller tenant so the code no longer persists in the seller environment.
GitLab separation cost is driven by the per seat tier, the choice between SaaS and self managed, and the effort of rebuilding runners and registries. The discipline is to size the tier to Newco real needs rather than inheriting the seller configuration, choose the operating model deliberately, and treat the move as a chance to consolidate sprawling groups rather than copy every archived project.
The common failure mode is treating GitLab as a repository move and ignoring the CI and registry estate. The instance cannot be cleanly exited until runners, variables, and registries are reconnected against Newco infrastructure. Buyers that inventory every pipeline and runner first avoid the discovery that the code moved but nothing builds or deploys.
The common operating mistake is underestimating self managed. A self managed instance gives control but is an application Newco must run, patch, and back up. The fix is to decide the operating model with eyes open and resource it. A PMO maintains the dependency map across source control, identity, and the deployment targets, escalating blocks inside forty eight hours.
A clean GitLab separation produces a Newco that owns its own instance, its own code, and its own delivery pipeline, building from Day One. The discipline runs through the TSA exit acceleration program under a Fixed Fee plus Portfolio Retainer engagement model.
Both are valid end states. SaaS removes the burden of operating the platform and suits most standalone businesses, while a self managed instance gives Newco full control and suits regulated workloads. The decision is settled early because it drives the migration mechanism, the runner architecture, and the identity model.
Yes. GitLab project and group export and import carries the repository, issues, merge requests, and history, and a mirror clone covers the git history where an export is constrained. The buyer confirms branches, tags, and the merge request record move so the engineering history is preserved.
The CI runners and pipeline variables. Pipelines depend on registered runners and on variables that hold credentials, neither of which moves automatically, so when projects change instances the runners must be re registered and the variables recreated. An unmapped pipeline leaves a build that no longer runs.
GitLab itself can stand up quickly, but identity, the runner and registry estate, and the choice of operating model 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.
Organization strategy, the repository and history move, and the Actions rebuild.
Read the article →Project and space strategy, the issue move, and the toolchain cutover.
Read the article →Account strategy, the workload move, and the landing zone build for Newco.
Read the article →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 →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
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.
Stand up standalone IT before the TSA meter and the seller's dependencies compound against you.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →