Migrando seu repositório com Enterprise Live Migrations

Pré-requisitos

Verifique se você está pronto para a migração. Consulte Preparando sua migração ao vivo do GitHub Enterprise Server para o GHE.com.

1. Criar tokens de acesso

Você deve autenticar com um personal access token (classic) tanto para a origem quanto para o destino da migração. Para obter instruções detalhadas, confira Gerenciar seus tokens de acesso pessoal.

          **Anote ambos os tokens**, pois você precisará deles na próxima etapa.

1. Crie um personal access token (classic) em GitHub Enterprise Server com os escopos a seguir.

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

2. Crie um personal access token (classic) no GHE.com com os escopos a seguir.

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

3. Se o logon único for imposto na organização de destino GHE.com, autorize o token GHE.com.

2. Configurar GitHub Enterprise Server

Você deve definir alguma configuração na GitHub Enterprise Server instância antes de executar uma migração. Esses valores de configuração se aplicam a todas as ELM migrações. Os desenvolvedores que utilizam GitHub Enterprise Server podem passar por um breve tempo de inatividade ao aplicar a nova configuração.

1. Acesse o GitHub Enterprise Server shell administrativo por SSH. Consulte Acessar o shell administrativo (SSH).

2. Defina as variáveis de configuração a seguir com ghe-config.

   Por exemplo: ghe-config app.elm-exporter.enabled true

   Variable	Defina isso como...
   app.elm-exporter.enabled	true
   app.elm.internal-webhooks-enabled	true
   app.elm-exporter.webhooks-loopback-address-enabled	true
   secrets.elm-exporter.migration-target-url	A URL da API para sua empresa de destino (por exemplo: https://api.octocorp.ghe.com).

          **Não** inclua uma barra no final da URL. |
   

   | secrets.elm-exporter.migration-target-token | O token de acesso que você criou para GHE.com. | | secrets.elm-exporter.source-token | O token de acesso que você criou para GitHub Enterprise Server. | | secrets.elm-exporter.source-user | O nome de usuário associado ao GitHub Enterprise Server token (por exemplo: ghe-admin). |

3. Se você ainda não tiver migrações habilitadas e o armazenamento de blobs configurado na instância, você poderá configurá-las agora. Você pode verificar suas configurações existentes na seção "Migrações" do Console de Gerenciamento (HOSTNAME/setup/settings).

   Você pode usar os seguintes valores padrão, que não introduzirão nenhuma funcionalidade inesperada.

   Shell

   ghe-config app.migrations.enabled true
   

   Shell

   ghe-config secrets.migrations.blob-storage-type local-storage
   

4. Aplicar a configuração.

   Shell

   ghe-config-apply
   

3. Definir variáveis de ambiente necessárias

Quando a configuração tiver sido aplicada e antes de iniciar uma migração, defina as variáveis de ambiente necessárias. Por exemplo:

export API_URL='http://localhost:1738'

          **Não** inclua uma barra no final da URL. |

| MIGRATION_TARGET_TOKEN | O personal access token (classic) para GHE.com |

Qualquer um desses valores também pode ser fornecido como sinalizadores da CLI em qualquer elm comando, o que terá prioridade sobre as variáveis. Por exemplo: --api-url http://localhost:1738.

4. Criar uma migração

Crie uma nova migração especificando os detalhes do repositório de origem e de destino. --pat-name deve ser definido system-pat como um valor estático. Os outros valores são espaços reservados específicos para seu ambiente.

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

Por exemplo:

elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo \
  --target-api $MIGRATION_TARGET_URL \
  --pat-name system-pat

Sinalizadores opcionais:

• --start: se você estiver pronto para iniciar a migração imediatamente.
• --target-visibility: repositórios migrados são criados com visibilidade interna por padrão, mas você pode especificar private.

Salvar o ID da migração

Você deverá ver uma resposta semelhante à seguinte:

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

Exporte como migrationId uma variável, pois você precisará dela para os próximos comandos. Por exemplo:

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

5. Iniciar a migração

Se você ainda não iniciou a migração, inicie-a agora usando a ID de migração que você acabou de salvar.

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

Isso inicia os processos de backfill e atualização em tempo real. ELM agora está coletando dados do repositório de origem e monitorando eventos de webhook com suporte.

6. Monitorar a migração

Quando a migração for iniciada, você deverá ver um novo repositório.GHE.com Durante a migração, você verá o preenchimento do repositório com uma carga inicial de dados e receberá atualizações à medida que os desenvolvedores continuarem a trabalhar no repositório de origem.

Execute o comando a seguir regularmente para monitorar o status da migração. Você verá um detalhamento dos status da origem e do destino e informações sobre dados dinâmicos sendo migrados.

elm migration status --migration-id $MIGRATION_ID

elm migration status --migration-id $MIGRATION_ID

O indicador mais importante na resposta é o status no objeto combinedState . Quando o status chegar COMBINED_STATUS_READY_FOR_CUTOVER, você deverá estar pronto para prosseguir para a próxima etapa. No entanto, você será alertado no displayMessage se algum recurso individual não tiver migrado, o que talvez seja necessário investigar.

Por exemplo:

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

Dicas:

• Se você estiver executando várias migrações, poderá verificar o status de todas elas com elm migration list. Esse comando mostra migrações em andamento por padrão, mas você também pode filtrar por --status.
• Se você encontrar status de falha que exijam atenção, consulte Solução de problemas de migrações dinâmicas do GitHub Enterprise Server para o GHE.com.

7. Concluir a migração

Quando uma migração estiver pronta para entrada em operação, você pode concluir a migração. O processo de substituição bloqueará o repositório de origem, tornando-o permanentemente indisponível para desenvolvedores, a menos que um administrador o desbloqueie.

elm migration cutover-to-destination --migration-id $MIGRATION_ID

elm migration cutover-to-destination --migration-id $MIGRATION_ID

Continue monitorando a migração. Quando você vê o MIGRATION_STATUS_COMPLETED status na parte superior da resposta, a migração é concluída, embora haja algumas tarefas de acompanhamento para dar acesso aos usuários de GitHub Enterprise Server.

Próximas Etapas 

Dê aos usuários acesso ao novo repositório e reconcilie a atividade com contas de usuário. Consulte Concluindo sua migração ao vivo do GitHub Enterprise Server para o GHE.com.