Are you sure you want to delete this access key?
title | intro | redirect_from | versions |
---|---|---|---|
Migrating data to your enterprise | After generating a migration archive, you can import the data to your target {% data variables.product.prodname_ghe_server %} instance. You'll be able to review changes for potential conflicts before permanently applying the changes to your target instance. | [/enterprise/admin/guides/migrations/importing-migration-data-to-github-enterprise/ /enterprise/admin/migrations/applying-the-imported-data-on-github-enterprise-server /enterprise/admin/migrations/reviewing-migration-data /enterprise/admin/migrations/completing-the-import-on-github-enterprise-server /enterprise/admin/guides/migrations/applying-the-imported-data-on-github-enterprise/ /enterprise/admin/guides/migrations/reviewing-the-imported-data/ /enterprise/admin/guides/migrations/completing-the-import-on-github-enterprise/ /enterprise/admin/guides/migrations/importing-migration-data-to-github-enterprise-server/ /enterprise/admin/user-management/migrating-data-to-your-enterprise] | [{enterprise-server *}] |
{% data reusables.enterprise_installation.ssh-into-target-instance %}
Using the ghe-migrator import
command, start the import process. You'll need:
$ ghe-migrator import /home/admin/<em>MIGRATION_GUID</em>.tar.gz -g <em>MIGRATION_GUID</em> -u <em>username</em> -p <em>TOKEN</em>
> Starting GitHub::Migrator
> Import 100% complete /
By default, ghe-migrator audit
returns every record. It also allows you to filter records by:
The record types match those found in the migrated data.
Record type | Filter name |
---|---|
Users | user |
Organizations | organization |
Repositories | repository |
Teams | team |
Milestones | milestone |
Project boards | project |
Issues | issue |
Issue comments | issue_comment |
Pull requests | pull_request |
Pull request reviews | pull_request_review |
Commit comments | commit_comment |
Pull request review comments | pull_request_review_comment |
Releases | release |
Actions taken on pull requests or issues | issue_event |
Protected branches | protected_branch |
Record state | Description |
---|---|
export |
The record will be exported. |
import |
The record will be imported. |
map |
The record will be mapped. |
rename |
The record will be renamed. |
merge |
The record will be merged. |
exported |
The record was successfully exported. |
imported |
The record was successfully imported. |
mapped |
The record was successfully mapped. |
renamed |
The record was successfully renamed. |
merged |
The record was successfully merged. |
failed_export |
The record failed to export. |
failed_import |
The record failed to be imported. |
failed_map |
The record failed to be mapped. |
failed_rename |
The record failed to be renamed. |
failed_merge |
The record failed to be merged. |
With the ghe-migrator audit
command, you can filter based on the record type using the -m
flag. Similarly, you can filter on the import state using the -s
flag. The command looks like this:
$ ghe-migrator audit -m <em>RECORD_TYPE</em> -s <em>STATE</em> -g <em>MIGRATION_GUID</em>
For example, to view every successfully imported organization and team, you would enter:
$ ghe-migrator audit -m organization,team -s mapped,renamed -g <em>MIGRATION_GUID</em>
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
We strongly recommend auditing every import that failed. To do that, you will enter:
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g <em>MIGRATION_GUID</em>
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
If you have any concerns about failed imports, contact {% data variables.contact.contact_ent_support %}.
After your migration is applied to your target instance and you have reviewed the migration, you''ll unlock the repositories and delete them off the source. Before deleting your source data we recommend waiting around two weeks to ensure that everything is functioning as expected.
{% data reusables.enterprise_installation.ssh-into-instance %} {% data reusables.enterprise_migrations.unlocking-on-instances %}
To unlock the repositories on a {% data variables.product.prodname_dotcom_the_website %} organization, you'll send a DELETE
request to the migration unlock endpoint. You'll need:
id
of the migrationcurl -H "Authorization: token <em>GITHUB_ACCESS_TOKEN</em>" -X DELETE \
-H "Accept: application/vnd.github.wyandotte-preview+json" \
https://api.github.com/orgs/<em>orgname</em>/migrations/<em>id</em>/repos/<em>repo_name</em>/lock
After unlocking the {% data variables.product.prodname_dotcom_the_website %} organization's repositories, you should delete every repository you previously migrated using the repository delete endpoint. You'll need your access token for authentication:
curl -H "Authorization: token <em>GITHUB_ACCESS_TOKEN</em>" -X DELETE \
https://api.github.com/repos/<em>orgname</em>/<em>repo_name</em>
{% data reusables.enterprise_installation.ssh-into-instance %} {% data reusables.enterprise_migrations.unlocking-on-instances %}
Press p or to see the previous file or, n or to see the next file
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?