A GitLab group can hold years of development work while depending on one person for administrative decisions. If that person dies or becomes unavailable, developers may still be able to push code without anyone knowing who can maintain group access, approve subscription spending, or replace deployment credentials. Families and colleagues then face different parts of the same unfinished handover.
GitLab group owner succession starts with a named coordinator, a tested backup owner, and an inventory of operational dependencies. This checklist covers preparation and the first review after an owner's death. Identify whether you use GitLab.com or a self-managed instance before following any administrative procedure. Technical permissions are one part of continuity; document separately who can make decisions for the organization and who represents the estate.
1. Map the group and its responsibilities
Record the instance URL, top-level group path, important subgroups, project locations, and current human owners. Include personal namespaces that contain work the organization relies on, but flag them for separate review. Do not assume that every repository created by a founder belongs to the same business or should be shared with the same successor.
Assign people to four responsibilities: group administration, code stewardship, infrastructure operations, and payment decisions. One person may cover several roles, but every role needs a backup and a contact method. Record who approves sensitive changes and where the decision log lives. Ask project leads to identify missing repositories, private documentation, or release instructions that a central inventory might overlook.
2. Verify a surviving owner's access
GitLab documents changing a group's Owner through its membership controls. The group must retain at least one human Owner; a bot or service account cannot be its only Owner. When planning ahead, arrange a second trusted human owner and verify their access while the current owner is available.
Have the successor sign in with their own account and locate the correct group. Check the administrative controls needed for the handover, not just whether a project page opens. Record how their access is granted and whether identity-provider membership or another organization-controlled setting could affect it. Use an approved secure location for recovery material, with instructions that an authorized successor can actually follow.
Treat a successful invitation as the start of verification. Rehearse locating member settings, finding a critical repository, and contacting the person responsible for infrastructure. Record the date and any gaps. Avoid changing production settings merely to prove access: a review of the relevant controls and a harmless permitted task can establish readiness without disrupting the team.
3. Escalate an access gap with a focused request
If no surviving person has the required controls, collect the instance address, group path, relevant project URLs, known account identifiers, and a reachable organizational contact. For GitLab.com, contact GitLab Support to ask what process applies. For a self-managed instance, involve its authorized administrator and the people responsible for hosting and identity services.
Explain which access is missing and which work is blocked. Ask the receiving team to confirm its evidence requirements and available options. This checklist does not establish a special bereavement transfer policy, a guaranteed recovery outcome, or a processing deadline. Keep requests and responses in the handover log, and assign a person to follow up rather than leaving the matter in an unmonitored inbox.
4. Preserve more than the Git repository
Inventory repositories alongside issues, merge requests, wikis, release assets, packages, container images, and important project documentation. Decide what the organization is authorized to retain and who needs access. A developer's local clone may preserve code while leaving out the project discussions and operational records that explain how to maintain it.
GitLab's file export documentation describes included and excluded items. CI/CD variables are among the items excluded from project file exports. Review the documentation for your version and chosen method instead of treating an export as a complete operational backup.
Give every preservation task an owner, secure destination, and verification step. Confirm that saved material opens, record its capture date, and note omissions. Keep copies of sensitive business data within approved storage. Where a restore or import is part of the plan, test it in an appropriate isolated environment before relying on it during a real handover.
5. Review pipelines and credential dependencies
Create a dependency list for critical build and deployment workflows. Include runners, scheduled jobs, webhooks, external registries, cloud services, package publishing, and signing arrangements actually used by the team. Identify which connections depend on the unavailable person's account and which are maintained by the organization. Record credential locations and custodians without copying secret values into the continuity note.
GitLab's CI/CD variable guidance recommends storing sensitive values in settings rather than in the pipeline configuration file. During the handover, have authorized operators inspect how required secrets are supplied. Keep access limited to people who need it and avoid exposing values in screenshots, tickets, or job output.
Plan replacement credentials with the responsible operators. Test a representative build and, where appropriate, a controlled deployment before routine revocation of old dependencies. If there is evidence of compromise, urgent containment may take priority; document what remains untested. The aim is a deliberate sequence with accountable owners, rather than an unexplained collection of working tokens.
6. Keep billing and identity services reachable
Record subscription details, renewal dates, invoice locations, payment approvers, and billing contacts. Verify that communications reach a monitored address controlled by the organization. Assign someone to decide which services must continue during the transition and to keep confirmation of approved payment changes. Group administration and responsibility for expenditure need separate checks.
For self-managed GitLab, also inventory hosting, backups, storage, certificates, domains, and the people who operate the instance. For either deployment model, review any external identity provider involved in sign-in. A working GitLab login does not demonstrate that someone can maintain the domain renewal, hosting contract, or identity configuration next month. Give each dependency its own successor and review date.
7. Complete the handover before routine account removal
Review outstanding work assignments, approval responsibilities, integrations, and authorized preservation tasks before routine removal of the deceased person's access. Coordinate changes with security and identity administrators. Preserve attribution and useful project history according to the organization's retention decisions; do not improvise broad account deletion as an administrative cleanup step.
Avoid moving groups or changing namespace paths merely to establish a new administrator. If a move is required for a separate business reason, review its effects first and give it its own change plan. Connect the GitLab continuity note to the wider online business continuity plan, and review both after staffing or infrastructure changes.
Next steps
Name a coordinator, inventory the groups, and test a surviving owner's access. Escalate missing permissions through the appropriate support or instance administration channel. Preserve authorized records, check pipeline dependencies, and assign billing and infrastructure responsibilities. Finish with a dated list of completed tasks and open issues. A rehearsed plan gives colleagues a practical route forward and leaves the family fewer technical decisions to untangle.