What needs rebuilding when a repository moves to a different hosting service?
Quick answer
Treat the move as two jobs: transfer the repository’s code and revision history, then inventory and verify the hosting service’s settings and integrations. Check issue links, review and branch rules, permissions, webhooks, apps, automation, and team access. Consult documentation for your exact migration route; do not assume a setting moved just because the repository did. Rebuild missing items, test them, and record an owner for each.
The question, the details, the next step.
What should we assume will need rebuilding when we move a repository to a different hosting service?
Assume you need to inspect and verify every setting that lives in or depends on the hosting service. Code and revision history are a separate migration concern from collaboration history and service settings; whether those settings transfer depends on the route and available tools. [S1]
Use these categories to make an inventory:
- Collaboration links: issue trackers, project boards, and notification routes.
- Review and merge controls: required approvals, reviewer assignments, branch rules, and bypass permissions.
- Access: teams, groups, repository roles, and app permissions.
- Automation and integrations: workflows, webhooks, installed apps, and external services.
- Repository conventions: default branch, labels, and templates.
These are prompts, not claims that every item is missing after every move. Check documentation for the exact source, destination, and migration method. The cited GitHub references cover specific GitHub migration routes, not arbitrary service moves. [S2][S3]
How do we find everything before the move, especially if configuration is spread across teams?
Create one inventory row for each setting or integration, and ask the responsible person to confirm it. Inspect repository and organization settings, workflow files, and team setup notes. A configuration file may depend on a separately configured app, secret, webhook, or permission, so record dependencies too. Do not copy secrets into the inventory.
For each item, capture its area, current behavior, owner, affected repositories, evidence checked, destination equivalent if confirmed, required action, and verification step. Mark unknown owners or destination behavior as open questions rather than guessing.
For the documented GitHub-product routes, follow-up examples include configuring Actions, enabling webhooks, reinstalling GitHub Apps, and recreating teams. Treat these as prompts for those routes, not a universal checklist. [S3]
Can you show a small example of turning that inventory into a rebuild plan?
Suppose a team has confirmed that one repository uses a required review rule, a webhook to a build service, and a link to an issue tracker. These are illustrative assumptions; check the actual settings and destination behavior.
| Item | Destination action and check |
|---|---|
| Review rule | Confirm the equivalent rule and eligible reviewers; recreate if needed, then check that a test change follows the intended approval requirement. |
| Build webhook | Confirm the endpoint, permissions, and expected event with the service owner; recreate if needed and confirm a safe test event is received. |
| Issue link | Confirm the destination supports the intended link; update it if needed and open it to check that it reaches the right project. |
Assign an owner and target date to each row. A successful code transfer does not prove these checks passed. For the GitHub-product routes in its guidance, GitHub says successful migrations can still have warnings about data not migrated or migrated with caveats; review the route’s status and logs. [S3]
What should we do on cutover day, and how do we know the rebuilt setup is ready?
Follow your team’s change plan. Confirm the repository and history are present, verify access and review controls, reconnect integrations and automation, and run the checks recorded in your inventory. Ask each owner to confirm results, and keep unresolved items visible rather than marking them complete by default.
Save the final inventory with statuses such as verified, recreated, intentionally retired, or unresolved. Record where configuration now lives and who maintains it. For a migration between GitHub products, review the route’s status and logs for warnings; its guidance also lists follow-up tasks such as configuring Actions and enabling webhooks. Those details do not establish what another provider transfers or guarantee a particular setup will work. [S3]
The practical rule is to verify behavior at the destination, not just the presence of a repository. If an important permission, rule, or integration cannot be confirmed, ask its service or security owner before relying on it.
A practical checklist
Confirm the source, destination, and migration method; find documentation for that route.
Inventory review rules, permissions, teams, issue links, webhooks, apps, and automation.
Record an owner, destination check, action, and verification step for each item; exclude secrets.
After cutover, mark each item verified, recreated, retired, or unresolved.
Test important controls and integrations at the destination with their owners.
A few more useful answers
Does Git history include review rules and webhooks?
Do not assume so. GitHub’s migration guidance separates code and revision history from collaboration history and settings, and says support depends on the migration route. Check that route’s documentation. [S1]
Can a successful migration still need follow-up?
Yes. For the GitHub-product routes in its guidance, GitHub notes that successful migrations can have warnings and lists possible follow-up tasks. Review the status and logs for your route. [S3]
Sources
References used for this guide.
- [S1] Planning your migration to GitHub docs.github.com · Checked
- [S2] Migrated data for live migrations from GitHub Enterprise Server to GHE.com docs.github.com · Checked
- [S3] Overview of a migration between GitHub products docs.github.com · Checked