Consolidating self-managed GitLab instances with direct transfer: what the move involves
Direct transfer can move groups and projects from one self-managed GitLab instance to another, or between groups on the same instance, but only after an administrator enables it. On Self-Managed, the feature is off by default, so the first decision is who owns that setting and when it is switched on. Once enabled, only the group and project items you select come across. Anything outside that list, and any link from a migrated item to a group or project that stayed behind, does not follow. Links to other source groups or projects are not rewritten, so issue references, merge request links and wiki pages that point at content left on the old instance will break unless you correct them by hand or migrate the referenced content as well. Effort depends far more on planning than on the copy itself. The GitLab direct transfer documentation gives observed examples of 100 projects migrated in about 8 hours and 1,926 projects in about 34 hours, so ask your partner or your own team to estimate against your actual project count, group depth and largest export size, since migrations fail when a group's export exceeds the maximum relation size. Plan the sequence of groups, the inventory of links, the user mapping and the verification steps before anyone runs a transfer. The work that carries the risk sits around the transfer. Confirm which source and destination instances are on compatible versions, which edition and license tier each instance runs, and how runners, CI/CD variables, protected branches and integrations will be re-created on the target. Agree a cutover window in which writes to the source groups stop, record the group and project counts on both sides, and check a sample of merge requests, pipelines and permissions after each batch. Confirm the current behavior and limits with the GitLab Docs guide to direct transfer before you commit to a schedule.
How to enable direct transfer on a self-managed instance
This sequence turns on direct transfer on both Self-Managed instances, confirms who can act on each side, and starts a group import from the destination. It ends with a status review that shows what moved and what still needs follow-up.
Confirm instance access and versions
Confirm that you have administrator access to both the source and destination Self-Managed instances, and that each instance runs a release where direct transfer is documented. Record the version of each instance, the administrator account you will use on each side, and the group paths you plan to move. Check the requirements in the GitLab direct transfer documentation for your version before you change any setting. Output: a short written record of both versions, the accounts, and the source and destination group paths.
Enable direct transfer on the source instance
An instance administrator opens the Admin area, goes to the general settings for visibility and access controls, and turns on the direct transfer option. Direct transfer is off by default on Self-Managed, so this change is required before any group can be exported. Menu labels change between releases, so confirm the exact path in the documentation for your version. Done when the setting shows as enabled after you save and reload the page.
Enable direct transfer on the destination instance
Repeat the same setting on the destination instance, using an administrator account there. The check is needed on both sides because the source must allow exports and the destination must accept imports. Record who made the change and when, since the setting is an instance-wide control. Done when the destination administrator confirms the setting is saved and a test user can see the group-level import option in a sandbox group.
Confirm group-level roles on both sides
Verify that the person who will run the transfer holds the roles the documentation requires on the source group and on the destination group or parent namespace. Roles decide who can start an import and who can monitor it, so confirm them before the day of the cutover. If many groups move, ask whether separate operator accounts or tokens are needed for the source side. Output: a named operator for each side, with roles recorded and an agreed approach to tokens.
Start the import from the destination group
On the destination instance, open the group that will receive the content and choose the option to import a group by direct transfer. Provide the source instance URL, a personal access token with the scopes the documentation requires, and the source group path. Select the items to bring across and confirm the selection. For the exact fields and scopes, follow the GitLab direct transfer documentation. Output: a queued import that appears in the destination import list.
Review the import status and results
Watch the import status until it completes or fails, then review each migrated group and project. Compare item counts and key metadata against the source, and record any group that reports an error. Large groups can fail when their export exceeds the maximum relation size, so note the size of each group before the run. Output: a reconciliation list that shows what moved, what failed, and what needs manual follow-up, such as links to other groups or projects that are not rewritten.
What direct transfer moves, what it leaves behind and what needs rework
This table compares each item in a GitLab group or project with what direct transfer carries, what needs manual rework, and what you must confirm for your version. Read each row before scoping a consolidation, and treat any row marked for confirmation as a test item in your pilot transfer.
| Item | Direct transfer behavior | Migration note |
|---|---|---|
| Groups and subgroups | Copied as listed in the transfer selection | Confirm subgroup nesting and group settings on your target version before scheduling cutover |
| Projects and listed items | Carries only the group and project items the docs list | Check the documented item list for your version and inventory anything outside it |
| Links to other source groups or projects | Not rewritten by direct transfer | Manual rework: update references in descriptions, comments and wikis that point to the source instance |
| Users and memberships | Mapping of users after transfer is handled through the import workflow, and direct transfer is the importer GitLab marks for post-migration user mapping | Confirm how placeholder users and reassignment behave for your version and plan user review time |
| CI/CD variables | Not described as migrated in the topic facts | Confirm with GitLab docs for your version; plan to re-create variables and protected settings manually |
| Runners | Runners are separate from projects and are not part of the transferred item list | Manual rework: re-register or reassign runners to the target instance and align Runner and GitLab versions |
| Container and package registries | Not described as migrated in the topic facts | Confirm behavior for your version; plan to copy images and packages with a separate process and update pipeline references |
| Migration failures from export size | Migrations fail if a group's export exceeds the maximum relation size | Split very large groups into smaller transfers and test the largest group in a pilot first |
Documented import paths for moving between GitLab instances
GitLab documents more than one way to move content from one self-managed instance to another, but they do not offer the same coverage. The cards below compare the paths you can plan around, separate the one that should carry a consolidation from the fallbacks, and point to the checks that decide which path fits your groups and projects.
Direct transfer as the primary path
Direct transfer is the only documented importer that supports groups, projects, a migration tool and post-migration user mapping together. For a consolidation that moves whole groups between instances, it is the path to plan around. It is off by default on Self-Managed, so an administrator must enable it before any team can start a transfer. Confirm that the source and target instances can reach each other over the network you intend to use, and confirm which group and project items the transfer carries before you schedule a cutover.
Group file export is deprecated
Group migration by file export still appears in older guides and internal runbooks, but GitLab marks it as deprecated and does not list it as a supported importer for groups with a migration tool and user mapping. Do not make it the planned path for a consolidation, even if an earlier test succeeded. If your team has existing export files, treat them as archives for reference, and plan the move itself with direct transfer. Ask the team that wrote older runbooks which steps they relied on, so nothing is lost in translation.
Project file export as a fallback
For a single project that direct transfer cannot move, GitLab offers project-level file export and import. This is a fallback for individual projects, not a method for restructuring a group. Each project moves on its own, so you must recreate group membership, group settings and links between projects by hand. Use it for a small number of exceptions and record each one in the cutover plan, with its owner and the reason it did not use the primary path.
Export size limits and failure modes
Direct transfer can fail when a group's export exceeds the maximum relation size. Large groups with many issues, merge requests or CI records are the most exposed. Before you start, ask the instance administrator for the configured limit, and review the largest groups by item count. Split oversized groups into subgroups or projects that can be moved independently, and rehearse those splits on a copy of the source data before the cutover window.
Reading the import documentation
The GitLab import documentation lists each importer's supported objects, and it is the reference your team should check against your own inventory. Compare every object type in your groups, including issues, merge requests, wikis, runners, CI/CD variables and group settings, with the importer support table. Anything listed as unsupported needs a manual step, a fallback or an accepted gap. Record that comparison in writing, because it becomes the scope your implementation partner or internal team signs off.
How long a consolidation takes and where transfers fail
Plan a direct transfer around two observed data points from GitLab's documentation: 100 projects migrated in about 8 hours and 1,926 projects migrated in about 34 hours. These are examples from other migrations, not estimates for your instances. Your duration depends on repository size, the number of issues, merge requests and attachments per project, the network path between the source and target instances, and how busy both instances are during the run. Treat the figures as a sense of scale for a rehearsal, and measure your own throughput on a representative group before you commit a cutover window.
The most important failure condition is a group whose export exceeds the maximum relation size. When that limit is hit, the migration of that group fails, and the failure is tied to the amount of data in the group's export rather than to the number of projects you requested. Large groups with heavy issue or merge request history are the usual candidates. Inventory the largest groups on the source instance, then split consolidation into batches so that no single group carries a disproportionate share of the data. Run each large group as a rehearsal on a non-production target, confirm it completes, and record which groups needed to be split or reorganized.
Confirm the current maximum relation size and any other export limits in the GitLab Docs: Migrate groups and projects by using direct transfer page before you size batches, since these values can change between releases. Ask your GitLab administrator to verify the target and source versions are compatible with direct transfer, and to schedule the batches so that each one has a clear success check, such as comparing project counts, group structure and a sample of issues. Keep the source groups intact until every batch has been verified on the target.
Sequencing a consolidation: inventory, pilot, parallel run and cutover
This sequence moves groups from source instances into one destination in controlled batches, so each cutover has a tested path, a verified owner and a clear point at which the source can be retired.
Inventory every group, project and dependency
List every source group, subgroup and project, along with its members, owners, visibility, CI/CD variables, runner tags, protected branches, container and package registry use, and any links from other groups or projects that point back to the source. Direct transfer migrates only the listed group and project items and does not rewrite links to other source groups or projects, so each cross-reference needs an owner and a fix. Confirm the license tier and feature set of the destination against what the sources use. Done when every item has a named owner, a target group path and a note on how its references will be updated.
Enable direct transfer on both instances
On a self-managed instance, direct transfer is off by default, so an administrator must enable it in the admin settings on the source and the destination before any migration can start. Record who holds that administrator role, confirm network paths between the two instances, and check that the instances run versions that support the direct transfer feature you plan to use. Done when a test connection succeeds and the enablement is recorded in your change log.
Pilot one representative group end to end
Choose a group that has subgroups, a meaningful number of projects, CI/CD variables and at least one runner dependency, then run a full direct transfer into a non-production target path. Check repository history, merge requests, issues, wiki content, pipelines and artifacts against the source, then map users to the destination and confirm that contributions appear under the correct accounts. Record the elapsed time and any failed items. Done when the pilot group matches the source on your agreed checklist and the team that owns it signs off.
Verify runners and CI/CD references in the pilot
Confirm that jobs in the migrated projects can reach the runners they need on the destination, that runner registration tokens and tags resolve correctly, and that CI/CD variables are present and scoped as intended. Run a pipeline on each default branch and on one protected branch. Fix any reference in
.gitlab-ci.ymlthat points at a source group or project, since those links are not rewritten automatically. Done when pilot pipelines pass and you have a written list of every reference that needed manual change.Run a parallel period with team verification
Keep the source readable while teams work against the destination for an agreed period. Ask each owning team to clone from the new paths, open a test merge request, run a pipeline and check that their access matches their role. Track defects in a shared list and resolve them before the next batch. You set the length of this period and the cutover window with your own teams, and you should document the freeze rules for commits, merges and deployments before this phase starts. Done when no open defects block the next batch and each team confirms its access.
Cut over group by group
Migrate the remaining groups in batches sized to the team and runner capacity you verified during the pilot. For each batch, freeze writes on the source group, run the direct transfer, update CI/CD references and external links such as bookmarks, webhooks and deployment targets, then announce the new path. Observed examples in the vendor documentation show 100 projects taking about 8 hours and 1,926 projects about 34 hours, so use those figures only as a rough reference and measure your own batches. Migrations fail if a group's export exceeds the maximum relation size, so check large groups early. Done when each batch passes its checklist and its owners confirm the new location.
Decommission the source after verification
Once every group has been verified on the destination and no team depends on the source, archive the source groups, revoke runner registrations and tokens that point at the old instance, and remove scheduled jobs and integrations. Retain a final backup of the source according to your records policy before shutting anything down, and keep the decision and the backup location in your change record. Done when the source is read-only or retired, its runners are deregistered and the closing report lists every group, its destination and its verifier.
Questions buyers ask before consolidating GitLab instances
How much does consolidating GitLab instances cost?
No fixed price applies, because cost follows the written scope. Direct transfer itself is a built-in GitLab feature, so the cost sits in the work around it: inventory, admin enablement, transfer runs, checking results, rebuilding CI/CD references, user mapping decisions and cutover support. Some costs are one-time, such as the migration itself. Others recur if you keep two instances running during a transition or add licensed seats. Ask for a quote that lists the number of groups, projects and users in scope, which source and target tiers are involved, and whether runner, variable and integration reconfiguration is included. A fixed-scope quote should name deliverables and timelines in writing before work starts.
How long does a direct transfer consolidation take?
Duration depends mostly on how many projects move and how large their exports are. GitLab's direct transfer documentation gives two observed examples: 100 projects migrated in about 8 hours, and 1,926 projects in about 34 hours. Those figures are context, not a plan for your instance, because repository size, group structure and network path between instances also matter. Migrations also fail when a group's export exceeds the maximum relation size, so large groups may need splitting and retrying. Plan separate time for inventory, a trial run on a representative group, cutover freeze, and post-transfer verification of memberships and pipelines.
What does our internal team need to provide for the move?
Your team needs to provide administrator access on both instances, a list of groups and projects with owners, and a decision on which instance will be the system of record after cutover. Someone must enable direct transfer on the self-managed instance, since it is off by default until an administrator turns it on. You also need network routing between the two instances, a maintenance window agreed with development teams, and a named owner for runners, CI/CD variables and external integrations. Confirm your upgrade status with GitLab's upgrade paths documentation before moving data between versions.
Can our own engineers run a consolidation without a partner?
Yes, a capable internal team can run direct transfer, because the feature is built into self-managed GitLab and administrators control it. The harder parts are rarely the transfer command. They include deciding how to handle group hierarchies, checking that memberships and permissions arrived correctly, updating pipelines that reference other groups, and sequencing the cutover so no one writes to the old location during the move. If your team has not run a multi-group migration before, a partner can plan the sequence and run verification. Ask any partner to show the written scope, the verification checklist and who performs each step.
How are users, memberships and contributions mapped during direct transfer?
Direct transfer is the only GitLab importer that documents post-migration user mapping, so plan that step before the first run. Confirm which users exist on the target instance, how usernames and email addresses will match, and who approves any reassignment of contributions. Group and project memberships should be reviewed after each batch, because access that does not match the source can expose code or block teams from working. Check whether your identity provider and SCIM provisioning already create accounts on the target, since duplicate accounts complicate mapping.
What happens to links and CI/CD references after the move?
Direct transfer copies only the listed group and project items. Links to other source groups or projects are not rewritten, so issue references, merge request links, wiki pages and include paths that point at the old instance will break until someone updates them. Pipelines that reference other projects, container registry paths, package sources and CI/CD variables also need review. Runners are separate from the transfer and must be re-registered or reconfigured on the target. Build an inventory of cross-project references before cutover and decide whether to rewrite them, redirect them, or accept the break and communicate it to teams.
Does direct transfer support compliance evidence and audit trails?
Direct transfer moves repository, issue and group data, but it does not produce an audit report or certify that the move met a control. Your compliance function or an independent auditor decides what evidence counts. Record the inventory, transfer logs, verification results and approvals so that the change record survives the move. Keep the old instance in a read-only or archived state for a defined period, and confirm retention rules with your compliance team before decommissioning.
Should we consolidate onto a new instance or keep both running?
Consolidating onto one instance reduces the number of upgrades, backups, runner fleets and license administration you carry. Keeping two instances may be justified when data residency, network isolation or different tiers serve different business units. Decide this before scoping the work, because it changes whether you need a cutover or a long coexistence period. Sequence upgrades on both instances against GitLab's required upgrade stops, which fall at versions such as 18.2, 18.5 and 19.2, so that the instances are on compatible versions when transfer runs.
What drives the cost and duration of a GitLab consolidation
This table lists the factors that change how much work a consolidation takes and whether each cost is paid once or repeats. Read each row as a question to put to a partner or your own team before agreeing on a written scope. The main takeaway is that the observed durations in GitLab's direct transfer documentation depend heavily on how many groups and projects move, so ask for the count and the cutover plan before comparing quotes.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Number of groups and projects | Each item is listed and transferred, and GitLab's docs give observed examples of 100 projects in about 8 hours and 1,926 projects in about 34 hours, so volume drives both runtime and checking effort. | One-time | Exact group and project counts per source instance, and the expected transfer window for each batch. |
| Total repository size | Large groups can exceed the maximum relation size in the export, which causes failed migrations that need splitting or rerunning. | One-time | A size inventory per group and a plan for splitting any group that is likely to hit the limit. |
| Users needing mapping | Contributions from imported users are tied to placeholder accounts that someone must reassign, so more users mean more review time. | One-time | Number of distinct authors and owners, and who approves reassignment on each side. |
| CI/CD variables and runners | Direct transfer does not carry the runner fleet, and variables and protected settings must be recreated on the target, which is manual work per group. | One-time, with runner upkeep recurring | An inventory of variables, runners and environments, and whether runner rebuilds are in scope. |
| Cross-group links | Links to projects or groups outside the transferred set are not rewritten, so each one needs a search, a decision and an edit. | One-time | A count of known cross-references and whether link rewriting is included or left to your team. |
| Tier and version alignment | Source and target must be on compatible GitLab versions and license tiers, and upgrading to meet them adds upgrade-stop work. | One-time | Current versions and tiers of both instances, and the upgrade path each would need to follow. |
| Parallel run length | Running both instances during cutover means keeping two sets of users, runners and access rules in step, which costs staff time for every week it lasts. | Recurring until cutover | The planned length of the parallel run, who maintains each instance during it, and the rollback plan. |
| Enabling the admin setting and access checks | Direct transfer is off by default on Self-Managed, so an administrator must enable it and confirm permissions before any batch starts. | One-time | Confirmation of who enables the setting, who holds admin rights and how access is verified after each batch. |
What usually goes wrong in a direct transfer and how to prevent it
Direct transfer moves groups and projects, but it does not carry everything that surrounds them. The risks below cluster around references that stay behind, data that is too large or too mismatched to move cleanly, and work that continues on the source while the copy is in progress. Each one has a check you can run before the cutover window opens.
Links that point back to the source
Direct transfer does not rewrite links to other source groups or projects, so issue cross-references, merge request links, and wiki or README links can keep pointing at the old instance. Inventory the links that matter most before the first transfer, list which ones cross group boundaries, and decide whether to rewrite them after the move or accept them as historical references. Confirm the exact behavior for your GitLab version in the direct transfer documentation.
Exports above the relation size limit
A migration fails when a group's export exceeds the maximum relation size. Large groups with many issues, merge requests, or notes are the usual cause, so a failed transfer may look like a platform problem when it is a sizing problem. Identify the largest groups by project count and history before scheduling, split very large hierarchies into smaller transfers where the structure allows, and ask the administrator of the source instance to confirm the configured limit.
Users who do not map cleanly
Contributions made by accounts that do not exist on the destination arrive as unassigned activity until someone maps them. Mismatched usernames, emails that differ between instances, and accounts that were deactivated on the source all create gaps in attribution. Export the user list from both instances, agree on the matching rule, and assign an owner to resolve unmatched accounts before the cutover rather than after developers notice missing history.
CI/CD variables and runners left behind
Pipelines depend on CI/CD variables, protected environments, and the runners that execute their jobs, and those do not move with the group. A transferred pipeline can fail on the first run because a secret or runner tag is missing on the destination. Record every variable, environment, and runner tag used by the transferred projects, recreate the secrets through your approved secrets process, and register runners on the destination before the first pipeline runs.
Version and tier mismatches
Moving work between instances on different GitLab versions or license tiers can leave features unavailable or data unsupported on the destination. A destination running an older release may not accept everything a newer source produces, and features tied to a higher tier may silently stop working. Align the versions and tiers of both instances before enabling the transfer, follow the upgrade stops that apply to your path, and confirm that the destination license covers the features your projects use.
Pushes to the source during cutover
Developers who keep pushing to the source group while a transfer runs create a copy that is already out of date, and the work done after the snapshot does not appear on the destination. Freeze pushes and merges on the source for the affected groups, announce the window, and block CI job requests on the source so new pipelines do not start there. Agree on who lifts the freeze and how any late changes are reconciled before developers return to work.
When consolidation is the right move and when to keep instances separate
Consolidate instances when the main cost is administering several GitLab installations, not when the instances exist for a real reason. One instance means one set of administrators, one authentication configuration, one runner fleet to govern and one place where users and groups are managed. Direct transfer makes that merge practical for groups and projects, but it does not decide whether the merge is wise. Before choosing it, the team should confirm who owns each instance and each group, which business units depend on separate administration, and whether any group must stay in a particular jurisdiction or network zone. If a regulator, a data residency rule or a segregated network requires a separate system of record, keeping the instances apart is the correct outcome and direct transfer should not be used to work around it.
Several conditions must be settled internally before any transfer is scheduled. Confirm the GitLab tier on each source and target, since the features a group relies on must exist on the destination, and check whether the target's license covers the users being moved. Confirm that the source and target run versions that can exchange data, and plan any required upgrade stops on each instance first, using the GitLab upgrade paths documentation as the reference. Agree who approves the scope, which groups move in which order, and what happens to runners, CI/CD variables and external integrations that point at the source. The written scope should name every group and project in the transfer, so that the cutover is measured against an agreed list rather than against whatever the source happens to contain on the day.
Treat consolidation as a scoped migration with a defined end state, not as an open-ended merge. Decide in advance whether the source instance will be archived, kept read-only or decommissioned, because direct transfer copies the listed items and leaves the source in place. Some references will not be rewritten, so the team should plan how links, bookmarks and CI includes that point at the old instance are found and updated. If a large number of projects is involved, the timing observed in GitLab's documentation suggests a cutover window measured in hours or days rather than minutes, so it should be planned with the business owners who accept the outage. A consolidation that cannot be stated in one sentence, with a named owner for each group and a stated fallback, is not ready to start.
What your team provides and what DeployOpen delivers
This sequence sets out what your team supplies before any transfer runs and what DeployOpen delivers under a written scope, so that each group moves once, is verified against an agreed checklist, and ends with a signed record of the cutover.
Confirm admin access on both instances
Your team provides administrator accounts on the source and target GitLab instances, along with the named contacts who can approve changes on each side. Because direct transfer is off by default on Self-Managed, an administrator on the target must confirm that the setting is enabled, and the source must allow the export. DeployOpen checks access with a read-only review before any transfer is scheduled. The step is complete when both administrators have confirmed the setting and the access has been tested.
Provide the group and project inventory
Your team supplies a list of every top-level group, subgroup and project in scope, with its size, visibility, owner and any links to projects outside the group. DeployOpen turns this into a written inventory that marks which items transfer, which need restructuring, and which links will need manual rewriting, since links to other source groups or projects are not rewritten. The inventory is complete when your team has signed off on the item list and the open questions are closed.
Name an owner for each group
For every group in scope, your team names one accountable owner who can answer questions about membership, settings, CI/CD variables and runners, and who can confirm the result. Owners also decide whether their group moves as-is or with changes. DeployOpen records these names in the runbook so that verification and sign-off are assigned to a person, not a team alias. The step is complete when each group in the inventory has a named owner who has accepted the role in writing.
Agree cutover windows and sign-off rules
Your team sets the cutover windows, the freeze rules for source groups during transfer, and who signs off each group. DeployOpen proposes a sequence of pilot and production waves and documents the freeze and rollback conditions in the runbook. Timelines depend on the agreed scope and the observed data volume, so no duration is promised here. The step is complete when the windows, freeze rules and approvers are written into the agreed scope.
Run and record the pilot transfer
DeployOpen runs a pilot transfer of a small, representative set of groups and projects into the target instance, with your owners checking membership, repositories, issues, merge requests and pipeline history. Results are written into a pilot report that lists what migrated, what did not, and any failures, including exports that exceed the maximum relation size. The pilot is complete when your team has reviewed the report and agreed the fixes for the production waves.
Deliver the transfer runbook and verification checklist
DeployOpen delivers a written transfer runbook with the step order, commands, roles and rollback path, together with a verification checklist covering groups, projects, members, access levels, CI/CD variables, runners and post-migration user mapping. Your owners use the checklist to confirm each transferred item against its source. The deliverable is accepted when your team confirms it matches the agreed scope and the checklist has been tested against the pilot.
Execute waves and verify each group
During the agreed windows, your team freezes each source group as the runbook specifies, DeployOpen runs the transfer, and the group owner completes the verification checklist. Any mismatch is logged with its cause and either fixed or accepted by the owner before the group is considered moved. The wave is complete when every group in it has a checked result and the open items are either closed or recorded.
Issue the cutover record
DeployOpen issues a cutover record listing each group, its source and target locations, the verification results, the accepted exceptions and the sign-off names and dates. Your team retains the record as evidence of the consolidation and as the reference for links that still need manual rewriting. The engagement closes when your approver has signed the record and the remaining gaps have an owner.
How DeployOpen scopes, delivers and supports a GitLab consolidation
DeployOpen plans and runs consolidation work inside your own cloud accounts, data centers or air-gapped networks, under a written scope agreed before work starts. The cards below follow the path from scoping to verification and the ongoing support that can follow the cutover.
Written scope before any transfer
The scope fixes which source instances and groups move, which target instance receives them, and which edition and license tier the target runs. It also records who owns runners, CI/CD variables and user accounts on each side. Ask for the scope to list every group and project that is out of bounds, because direct transfer does not rewrite links to projects or groups that stay behind. Agree the list of groups before anyone enables the transfer setting.
Inventory and dependency mapping
Before transfer, we review each source group for nested subgroups, shared CI/CD configuration, external integrations and references between projects. Those references are the main source of broken links after a move, so they are recorded and assigned an owner. The output is a dependency register that the cutover plan uses to decide what moves first and what waits.
Pilot group before bulk transfer
We run a pilot on a small, representative group that includes a large project, protected branches and active pipelines. The pilot checks permissions, user mapping, package and registry content, and the time each step takes on your hardware. Results from the pilot decide the batch size and the cutover window for the full set, and they are documented before the bulk run starts.
Staged transfer and verification
Bulk transfers run in batches, with each batch checked against a list of repository counts, issue counts, merge request counts and group membership. Failed exports are investigated before the next batch begins, since a group whose export exceeds the maximum relation size fails outright. We capture the verification evidence for each batch so that your team can sign it off in writing.
Runners, identity and post-move access
Consolidation changes who can reach what, so we review runner registration, CI/CD variables, deploy keys and SSO group mapping on the target instance. Users who authenticate through SAML, LDAP or SCIM need their group memberships confirmed before the source instance is closed. Confirm with your identity team how user mapping and reassignment are handled in your edition.
Retainers for upgrades and support
After the cutover, the consolidated instance needs upgrades through required stops, backups, and monitoring. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can be scoped separately from the consolidation project. Ask what response times and upgrade windows the retainer includes, and confirm them in writing before signing.
