Preparing to migrate data to your enterprise

移行アーカイブを作成すると、ターゲットの GitHub Enterprise Server インスタンスにデータをインポートできます。変更を恒久的にターゲットのインスタンスに適用する前に、潜在的なコンフリクトがないか変更をレビューできます。

ここには以下の内容があります:

移行したデータを GitHub Enterprise Server にインポートするための準備
移行のコンフリクトのリストの生成
移行コンフリクトのレビュー
移行コンフリクトの解決もしくはカスタムマッピングのセットアップ

移行したデータを GitHub Enterprise Server にインポートするための準備

scp コマンドを使って、ソースインスタンスまたは Organization から生成された移行アーカイブを GitHub Enterprise Server ターゲットにコピーします:
```
$ scp -P 122 /path/to/archive/MIGRATION_GUID.tar.gz admin@hostname:/home/admin/
```
サイトアドミンとしてターゲットのGitHub Enterprise ServerインスタンスにSSHでアクセスしてください。
```
$ ssh -p 122 admin@HOSTNAME
```
ghe-migrator prepare コマンドを使ってターゲットインスタンスにインポートするためのアーカイブを準備し、次のステップで使用する新たな移行 GUID を生成します。
```
ghe-migrator prepare /home/admin/MIGRATION_GUID.tar.gz
```
- 新たにインポートを試みるには、再び ghe-migrator prepare を実行して、新しい Migration GUID を取得します。
- マイグレーションファイルをステージングする場所を指定するには、コマンドの末尾に--staging-path=/full/staging/pathを追加してください。デフォルトは/data/user/tmpです。

移行のコンフリクトのリストの生成

ghe-migrator conflicts コマンドに移行 GUID を付けて実行し、conflicts.csv ファイルを生成します。
```
$ ghe-migrator conflicts -g MIGRATION_GUID > conflicts.csv
```
- If no conflicts are reported, you can safely import the data by following the steps in "Migrating data to your enterprise".
コンフリクトがある場合は、scp コマンドを使って conflicts.csv をローカルコンピュータにコピーします。
```
$ scp -P 122 admin@hostname:conflicts.csv ~/Desktop
```
「移行コンフリクトの解決もしくはカスタムマッピングのセットアップ」に進みます。

移行コンフリクトのレビュー

テキストエディタもしくはCSV互換のスプレッドシートソフトウェアを使ってconflicts.csvをオープンしてください。
以下の例とリファレンスのガイダンスと共にconflicts.csvファイルをレビューし、インポートの際に適切なアクションが取られることを確認してください。

conflicts.csvファイルには、コンフリクトの移行マップと推奨アクションが含まれています。移行マップは、ソースから移行されるデータと、そのデータがどのようにターゲットに適用されるかのリストです。

`model_name`	`source_url`	`target_url`	`recommended_action`
`ユーザ`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`map`
`Organization`	`https://example-gh.source/octo-org`	`https://example-gh.target/octo-org`	`map`
`リポジトリ`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/widgets`	`rename`
`Team`	`https://example-gh.source/orgs/octo-org/teams/admins`	`https://example-gh.target/orgs/octo-org/teams/admins`	`マージ`

conflicts.csvの各行には以下の情報があります。

名前	説明
`model_name`	変更されるデータの種類。
`source_url`	データのソースURL。
`target_url`	期待されるデータのターゲットURL。
`recommended_action`	データをインポートする際に`ghe-migrator`が行う推奨のアクション。

各レコードタイプで可能なマッピング

データの転送時にghe-migratorが行えるマッピングアクションは複数あります。

`action`	説明	適用可能なモデル
`import`	（デフォルト）ソースからのデータがターゲットにインポートされます。	すべてのレコードタイプ
`map`	ソースからのデータがターゲット上の既存のデータで置き換えられます。	Users、organizations、repositories
`rename`	ソースからのデータは名前が変更されてターゲットにコピーされます。	Users、organizations、repositories
`map_or_rename`	ターゲットが存在する場合、そのターゲットにマップします。そうでない場合はインポートされたモデルの名前を変更します。	ユーザ
`マージ`	ソースからのデータはターゲット上の既存のデータと組み合わされます。	Team

We strongly suggest you review the conflicts.csv file and use ghe-migrator audit to ensure that the proper actions are being taken. If everything looks good, you can continue to "Migrating data to your enterprise".

移行コンフリクトの解決もしくはカスタムマッピングのセットアップ

ghe-migratorが正しくない変更を行うと考えられるときは、conflicts.csv内でデータを変更することによって修正をかけられます。 conflicts.csv内の任意の行を変更できます。

たとえばソースのoctocatユーザがターゲットのoctocatにマップされていることに気づいたとしましょう。

`model_name`	`source_url`	`target_url`	`recommended_action`
`ユーザ`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`map`

このユーザをターゲット上の他のユーザにマップさせることができます。 octocatが実際にはターゲットのmonalisaだということを知っているとしましょう。 conflicts.csvの target_urlをmonalisaを指すように変更できます。

`model_name`	`source_url`	`target_url`	`recommended_action`
`ユーザ`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`map`

もう1つの例として、もしもocto-org/widgetsリポジトリをターゲットインスタンス上ではocto-org/amazing-widgetsに名前を変えたいとすれば、target_urlをocto-org/amazing-widgetsに、recommend_actionをrenameに変更してください。

`model_name`	`source_url`	`target_url`	`recommended_action`
`リポジトリ`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/amazing-widgets`	`rename`

カスタムマッピングの追加

移行における一般的なシナリオは、移行されたユーザがターゲット上ではソース上とは異なるユーザ名を持つことです。

ソースのユーザ名のリストとターゲットのユーザー名のリストがあれば、カスタムマッピングのCSVファイルを構築し、各ユーザのユーザ名とコンテンツが移行の終了時点で正しく割り当てられているようにそのファイルを適用できます。

ghe-migrator auditを使えば、カスタムマッピングを適用するのに必要なCSV形式で、移行されるユーザのCSVを素早く生成できます。

$ ghe-migrator audit -m user -g MIGRATION_GUID > users.csv

これで、このCSVを編集してマップあるいは名前を変更したい各ユーザに新しいURLを入力し、4番目の列をmapあるいはrenameを適切に更新できます。

たとえばユーザoctocatの名前をターゲットhttps://example-gh.target上でmonalisaに変更したいのであれば、以下の内容の行を作成します。

`model_name`	`source_url`	`target_url`	`state`
`ユーザ`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`rename`

同じプロセスは、カスタムマッピングをサポートする各レコードのマッピングを作成するために使うことができます。詳しい情報についてはレコードに可能なマッピング上のテーブルを参照してください。

修正された移行データの適用

変更を加えた後、修正された conflicts.csv (または適切な形式のその他のマッピング CSV) を scp コマンドを使ってターゲットインスタンスに適用します。
```
$ scp -P 122 ~/Desktop/conflicts.csv admin@hostname:/home/admin/
```
修正された CSV ファイルへのパスと移行 GUID を渡して、ghe-migrator map を使い、移行データを再マップします。
```
$ ghe-migrator map -i conflicts.csv  -g MIGRATION_GUID
```
ghe-migrator map -i conflicts.csv -g MIGRATION_GUID がまだコンフリクトがあると報告してきた場合、移行のコンフリクト解決のプロセスをもう一度行ってください。

Preparing to migrate data to your enterprise

Still need help?