# Planifier votre migration de GitLab vers GitHub

Planifiez votre migration en comprenant votre chronologie, les données qui seront migrées et votre structure organisationnelle.

## Déterminez combien de données vous devez migrer

Déterminez d’abord votre chronologie, car elle forme en grande partie votre approche. La première étape pour déterminer votre planning consiste à obtenir un inventaire de ce que vous devez migrer.

* Nombre de référentiels (projets)
* Nombre de demandes de fusion

> \[!NOTE] Le minutage de la migration est largement basé sur le nombre de demandes de fusion dans un référentiel. Si vous souhaitez migrer 1 000 référentiels et que chaque référentiel a 100 demandes de fusion en moyenne, votre migration sera probablement très rapide. Si vous souhaitez migrer uniquement 100 référentiels, mais que les référentiels ont chacun 75 000 demandes de fusion en moyenne, la migration prend beaucoup plus de temps et nécessite plus de planification et de test.

Nous vous recommandons la commande `inventory-report` dans le GL2GH extension of the GitHub CLI. Cette commande se connecte à l’API GitLab et crée deux fichiers CSV.
`groups.csv` répertorie vos groupes GitLab et `projects.csv` répertorie vos projets, y compris le nombre de demandes de fusion.

Pour produire les fichiers CSV, utilisez la commande suivante, en remplaçant `GITLAB_SERVER_URL` par l’URL de votre serveur GitLab (par exemple `https://gitlab.com`) et `YOUR_GITLAB_GROUP` par le groupe sur lequel vous souhaitez créer un rapport. Pour signaler tous les projets auquel vous pouvez accéder, omettez `--gitlab-group`. Pour toutes les options disponibles, exécutez `gh gl2gh inventory-report --help`.

```shell copy
gh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP
```

Après avoir effectué l’inventaire des référentiels que vous devez migrer, pesez vos données d’inventaire par rapport à votre chronologie souhaitée.

* Si votre organisation peut résister à un plus haut degré de changement, vous pouvez probablement migrer tous vos dépôts à la fois, en concentrant vos efforts de migration sur quelques jours.
* Si vous avez des équipes qui ne sont pas en mesure de migrer en même temps, vous souhaiterez peut-être effectuer un traitement par lots et décaler vos migrations pour s’adapter aux chronologies des équipes, ce qui étend votre effort de migration.

## Déterminer la GitHub structure organisationnelle

Ensuite, planifiez la structure organisationnelle que vous allez créer dans GitHub. GitLab et GitHub avoir différentes façons d’organiser le travail d’une entreprise.

* GitLab : groupes > instances > sous-groupes (qui peuvent être imbriqués jusqu’à 20 niveaux de profondeur) > projets (référentiels)
* GitHub: référentiels de > d’organisation d’entreprise >

Après la migration vers GitHub, vous ne devez avoir qu’un seul compte d’entreprise et un certain nombre d’organisations appartenant à cette entreprise. Chaque groupe de niveau supérieur de GitLab correspond généralement à une seule organisation sur GitHub. Pour obtenir des conseils sur le nombre d’organisations à créer, consultez [Meilleures pratiques pour organiser le travail dans votre entreprise](/fr/enterprise-cloud@latest/admin/concepts/enterprise-best-practices/organize-work).

> \[!NOTE]
> GitHub n’a pas d’équivalent des sous-groupes imbriqués de GitLab. Nous vous déconseillons de créer une organisation sur GitHub chaque sous-groupe, car cela peut entraîner une grande liste de dépôts non groupés au sein de chaque organisation. Au lieu de cela, vous pouvez gérer l’accès aux groupes de référentiels en créant des équipes.

Si vous souhaitez interrompre votre effort de migration en lots, la nouvelle structure peut vous aider à les déterminer. Si vous avez plusieurs groupes dans GitLab et que les dépôts de chaque groupe sont raisonnablement dimensionnés, envisagez le traitement par lot par groupe.

1. Déterminez la structure de votre nouvelle organisation.
2. Déterminez si vous devez diviser votre migration en plus petites parties.
3. Si c’est le cas, décidez de la façon dont vous souhaitez diviser vos migrations.

## Configuration des autorisations de référentiel

Étant donné que les autorisations fonctionnent différemment dans GitHub GitLab, GitHub Enterprise Importer ne migre pas les autorisations de référentiel, les paramètres de groupe ou l’appartenance au groupe à partir de GitLab.

Dans GitLab, les membres reçoivent des rôles (tels que Invité, Reporter, Développeur, Maintenance ou Propriétaire) au niveau du groupe, du sous-groupe ou du projet, et ces rôles sont hérités dans la hiérarchie. Ces rôles ne sont pas mappés directement à GitHub. Vous devez donc recréer l’accès après la migration.

Pour donner aux utilisateurs l’accès aux dépôts migrés sur GitHub, nous vous recommandons de créer des équipes et d’accorder à chaque équipe le niveau d’accès approprié aux organisations et référentiels appropriés. Vous pouvez ensuite ajouter des personnes à ces équipes. Consultez « [Équipes dans une entreprise](/fr/enterprise-cloud@latest/admin/concepts/enterprise-fundamentals/teams-in-an-enterprise) ».