Cette version de GitHub Enterprise Server ne sera plus disponible le 2026-03-17. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Vue d’ensemble d’une migration de Bitbucket Server vers GitHub Enterprise Cloud

Découvrez le processus de migration de Bitbucket Server vers GitHub avec GitHub Enterprise Importer, de la planification à l’implémentation jusqu’à l’exécution des tâches de suivi.

Dans cet article

Vue d’ensemble

Avec GitHub Enterprise Importer, vous pouvez migrer vers GitHub Enterprise Cloud dépôt par dépôt. Pour plus d’informations, consultez « À propos de GitHub Enterprise Importer ».

Si vous effectuez une migration à partir de Bitbucket Server, vous pouvez utiliser ce guide pour planifier et implémenter votre migration, puis effectuer des tâches de suivi.

Planification de votre migration

Pour planifier votre migration, posez-vous les questions suivantes.

Quand devons-nous effectuer la migration ?

Déterminez votre planning qui dictera 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
  • Nombre de demandes de tirage

Le timing de la migration dépend beaucoup du nombre de demandes de tirage dans un dépôt. Si vous souhaitez migrer 1 000 dépôts, que chaque dépôt a 100 demandes de tirage en moyenne et que seuls 50 utilisateurs ont contribué aux dépôts, votre migration sera probablement très rapide. Si vous souhaitez migrer seulement 100 dépôts, mais que les dépôts ont chacun 75 000 demandes de tirage en moyenne et 5 000 utilisateurs, la migration prendra beaucoup plus de temps et demandera beaucoup plus de planification et de test.

Une fois que vous avez effectué l’inventaire des dépôts que vous devez migrer, vous pouvez adapter vos données d’inventaire par rapport au planning souhaité. 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. Toutefois, vous pouvez avoir plusieurs équipes qui ne peuvent pas migrer en même temps. Dans ce cas, vous souhaiterez probablement séquencer et échelonner vos migrations pour rentrer dans le planning des équipes, ce qui prolongera vos efforts de migration.

  1. Déterminez le nombre de dépôts et de demandes de tirage que vous devez migrer.
  2. Pour savoir quand les équipes peuvent être prêtes à migrer, interrogez les parties prenantes.
  3. Passez en revue le reste de ce guide, puis décidez d’un planning de migration.

Savons-nous ce qui va être migré ?

Assurez-vous que vous et vos parties prenantes savez quelles données peuvent être migrées par GitHub Enterprise Importer.

Pour les migrations à partir de Bitbucket Server, GitHub Enterprise Importer migre uniquement les dépôts Git et les demandes de tirage. Toutes les autres ressources, telles que les pipelines CI, restent dans Bitbucket Server.

Étant donné que les autorisations fonctionnent différemment dans GitHub que dans Bitbucket Server, GitHub Enterprise Importer ne tente pas de migrer les autorisations de dépôt à partir de Bitbucket Server. Pour plus d’informations, consultez Configuration des autorisations.

  1. Passez en revue les données migrées à partir de Bitbucket Server. Pour plus d’informations, consultez « Informations sur les migrations de Bitbucket Server vers GitHub Enterprise Cloud ».
  2. Dressez la liste des données que vous devez migrer ou recréer manuellement.

Qui va exécuter la migration ?

Pour migrer un dépôt, vous devez être propriétaire de l’organisation de destination dans GitHub, ou un propriétaire d’organisation doit vous accorder le rôle de migrateur.

Vous devez également disposer des autorisations requises et de l’accès à votre instance Bitbucket Server :

  • Autorisations d’administrateur ou de super administrateur
  • Si votre instance Bitbucket Server exécute Linux, utilisez l’accès SFTP à l’instance, en utilisant une clé privée SSH prise en charge (consultez Gestion de l’accès pour une migration à partir de Bitbucket Server)
  • Si votre instance Bitbucket Server exécute Windows, le partage de fichiers (SMB) accède à l’instance
  1. Déterminez si vous souhaitez qu’un propriétaire de l’organisation de destination effectue vos migrations, ou si vous devez accorder le rôle de migrateur à quelqu’un d’autre.
  2. Si vous avez choisi d’accorder le rôle de migrateur, choisissez la personne ou l’équipe à laquelle vous allez accorder le rôle.
  3. Accordez le rôle de migrateur à la personne ou à l’équipe. Pour plus d’informations, consultez Gestion de l’accès pour une migration à partir de Bitbucket Server.
  4. Vérifiez que la personne a correctement configuré les personal access token pour répondre à tous les besoins d’accès. Pour plus d'informations, consultez Gestion de l’accès pour une migration à partir de Bitbucket Server.
  5. Confirmez que le migrateur dispose d’autorisations d’administrateur ou de super administrateur et d’un accès SFTP pour votre instance Bitbucket Server.

Quelle structure organisationnelle voulons-nous dans GitHub ?

Ensuite, planifiez la structure organisationnelle que vous allez créer dans GitHub.

Dans Bitbucket Server, les dépôts sont regroupés dans des projets. Dans GitHub, les dépôts appartiennent aux organisations. Toutefois, vous ne devez pas supposer que la meilleure approche consiste à créer une organisation dans GitHub par projet dans Bitbucket Server.

Après la migration vers GitHub, vous ne devez avoir qu’un seul compte d’entreprise et un petit nombre d’organisations appartenant à cette entreprise.

Chaque dépôt migré appartient à l’une de ces organisations, ce qui peut donner une grande liste de dépôts non groupés au sein de chaque organisation. Toutefois, vous pouvez gérer l’accès aux groupes de dépôts en créant des équipes sur GitHub. Pour plus d’informations, consultez « À propos des équipes d'organisation ».

Si vous souhaitez répartir votre effort de migration, envisagez de procéder par organisation.

  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.

Exécution de vos migrations

Pour vous aider à identifier les problèmes qui peuvent être propres à votre entreprise, nous vous recommandons vivement d’effectuer un essai de votre migration. Avec un essai, vous apprendrez :

  • Indique si la migration d’un référentiel donné peut se terminer correctement.
  • Indique si vous pouvez récupérer le référentiel migré vers un état utilisable.
  • Combien de temps une migration prendra-t-elle pour s'exécuter.

Les exécutions d’essai peuvent se produire à tout moment et le travail n’a pas besoin d’arrêter pendant la migration. Pour réduire le temps nécessaire à l’exécution de vos migrations d’essai, vous pouvez planifier les lots de vos exécutions d’essai les unes à la suite des autres. Les utilisateurs de ces dépôts peuvent ensuite valider les résultats quand ils veulent.

Nous vous recommandons de créer une organisation de test à utiliser comme destination pour vos migrations d’essai. Vous pouvez utiliser une seule organisation pour toutes les exécutions d’essai, ou vous pouvez créer une organisation de test pour chaque organisation de destination prévue. Pensez à inclure -sandbox à la fin des noms d’organisation pour clarifier que les organisations sont destinées uniquement à la validation de la migration et non à la production. Vous pouvez supprimer les organisations de test une fois que vous avez terminé.

  1. Créez une organisation de test pour vos migrations d’essai.
  2. Exécutez les migrations d’essai.
  3. Effectuez les tâches de suivi décrites ci-dessous pour les migrations d’essai.
  4. Demandez aux utilisateurs de valider les résultats des migrations.
  5. Résolvez les problèmes découverts par vos migrations d’essai.
  6. Si votre destination utilise des listes d’adresses IP autorisées, configurez la liste pour autoriser l’accès par GitHub Enterprise Importer. Pour plus d'informations, consultez Gestion de l’accès pour une migration à partir de Bitbucket Server.
  7. Exécutez vos migrations de production. Pour plus d’informations, consultez « Migration de dépôts de Bitbucket Server vers GitHub Enterprise Cloud ».
  8. Si vous le souhaitez, supprimez l’organisation de test.

Exécution des tâches de suivi

À la fin de chaque migration, vous devez effectuer des tâches supplémentaires avant que le dépôt soit prêt pour le travail.

Vérification de l'état de la migration

Tout d'abord, vérifiez si votre migration a réussi ou échoué.

La façon dont vous vérifiez le statut de votre migration dépend de la manière dont vous avez exécuté la migration.

  • Si vous avez exécuté la migration à l'aide de GitHub CLI, le processus affichera par défaut l'échec ou la réussite de la migration une fois qu'elle sera terminée. Si la migration a échoué, vous verrez la raison de l'échec.

    Migration completed (ID: RM_123)! State: SUCCEEDED

  • Si vous avez exécuté la migration à l'aide des données GitHub CLI avec l'argument facultatif --queue-only, le processus s'arrête immédiatement après la mise en file d'attente de la migration et ne vous indique pas si la migration a réussi ou échoué. Vous pouvez vérifier le statut d'une migration à l'aide de la commande wait-for-migration ou en consultant le journal de migration.

  • Si vous avez exécuté la migration à l'aide de l'API GraphQL, vous pouvez interroger les champs state et failureReason sur l'objet RepositoryMigration.

Si la migration a échoué, le journal de migration peut contenir des informations supplémentaires sur la cause de l'échec. Pour plus d'informations, consultez Examen du journal de migration.

Examen du journal de migration

Examinez le journal de migration pour chaque référentiel migré. Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Si la migration a échoué, le journal peut contenir des informations supplémentaires sur la cause de l'échec.

Si la migration a réussi, il peut y avoir des avertissements dans le journal de migration représentant des éléments de données spécifiques (par exemple des demandes de tirage (pull requests), des problèmes ou des commentaires) qui n'ont pas été migrés ou qui ont été migrés avec des avertissements.

Pour plus d'informations sur la compréhension des avertissements de migration, consultez Résolution des problèmes de votre migration avec GitHub Enterprise Importer. Après avoir examiné les avertissements de migration, vous devrez décider si vous pouvez les accepter et poursuivre votre action.

Définition de la visibilité du dépôt

Tous les dépôts sont migrés en tant que dépôts privés par défaut, et seul l’utilisateur qui a exécuté la migration et les propriétaires de l’organisation y ont accès. Si vous ne souhaitez pas que le dépôt soit privé, changez la visibilité.

  • Vous pouvez changer la visibilité d’un dépôt dans le navigateur. Pour plus d’informations, consultez « Définition de la visibilité du dépôt ».
  • Vous pouvez également utiliser GitHub CLI pour changer la visibilité d’un dépôt à partir de la ligne de commande. Pour plus d’informations, consultez gh repo edit dans la documentation GitHub CLI.

Configuration des autorisations

Étant donné que les autorisations fonctionnent différemment dans GitHub que dans Bitbucket Server, GitHub Enterprise Importer ne tente pas de migrer les autorisations de dépôt à partir de Bitbucket Server.

Pour accorder l’accès aux dépôts migrés, vous pouvez créer des équipes et accorder à chaque équipe l’accès au dépôt.

  1. Créez des équipes. Pour plus d’informations, consultez « Créer une équipe d’organisation ».
  2. Ajoutez des membres d’organisation aux équipes. Pour plus d’informations, consultez « Ajout de membres d’une organisation à une équipe ».
  3. Donnez à chaque équipe l’accès au dépôt. Pour plus d’informations, consultez « Gestion de l’accès de l’équipe à un dépôt de l’organisation ».

Récupération de mannequins

Après avoir exécuté une migration avec GitHub Enterprise Importer, toutes les activités utilisateur dans le dépôt migré (à l’exception des commits Git) sont attribuées à des identités d’espace réservé appelées mannequins.

Remarque

Seuls les propriétaires d’organisation peuvent récupérer des mannequins. Si le rôle de migrateur vous a été accordé, contactez un propriétaire d’organisation pour effectuer cette étape.

  1. Décidez si vous voulez récupérer des mannequins.
  2. Planifiez quand vous effectuerez les récupérations.
  3. Récupérez les mannequins. Vous pouvez réattribuer l’historique de chaque mannequin à un membre de l’organisation avec l’interface CLI GitHub ou dans votre navigateur. Si vous utilisez l’interface CLI GitHub, vous pouvez récupérer des mannequins en bloc. Pour plus d’informations, consultez Récupération de mannequins pour GitHub Enterprise Importer.
  4. Si l’un des membres ne dispose pas déjà d’un accès approprié au dépôt via son appartenance à l’équipe, donnez-lui l’accès au dépôt. Pour plus d’informations, consultez « Gestion de l’accès d’une personne à un dépôt d’organisation ».

Configuration des listes d’adresses IP autorisées

Si vous avez ajouté les plages d’adresses IP pour GitHub Enterprise Importer à la liste d’adresses IP autorisées de votre organisation de destination, vous pouvez supprimer ces entrées. Si vous avez désactivé les restrictions de la liste d’adresses IP autorisées de votre fournisseur d’identité pour votre entreprise de destination, vous pouvez les réactiver maintenant.

Pour plus d’informations, consultez « Gestion de l’accès pour une migration à partir de Bitbucket Server ».