{"meta":{"title":"关于从 GitHub Enterprise Server 到 GHE.com 的实时迁移","intro":"实时迁移如何最大程度地减少开发人员的停机时间？","product":"迁移","breadcrumbs":[{"href":"/zh/enterprise-cloud@latest/migrations","title":"迁移"},{"href":"/zh/enterprise-cloud@latest/migrations/elm","title":"实时迁移（GHES 到 GHE.com）"},{"href":"/zh/enterprise-cloud@latest/migrations/elm/about-live-migrations","title":"关于实时迁移"}],"documentType":"article"},"body":"# 关于从 GitHub Enterprise Server 到 GHE.com 的实时迁移\n\n实时迁移如何最大程度地减少开发人员的停机时间？\n\n> \\[!NOTE]\n> Enterprise Live Migrations 位于 公开预览，可能会有变动。\n\n## 什么是 Enterprise Live Migrations?\n\nEnterprise Live Migrations （ELM） 是用于从 GitHub Enterprise Server带有数据驻留权的 GitHub Enterprise Cloud （GHE.com） 迁移存储库的服务。 使用命令行工具在GitHub Enterprise Server上进行操作。\n\n迁移是“实时”，因为用户在大多数迁移过程中都可以继续使用源存储库。 最初收集存储库数据后，Webhook 会检查存储库的更改，例如对设置的新提交或更新。 这些更改已报告给 ELM 并纳入迁移中。\n\n迁移ELM涉及单个存储库。 组织级数据（如组织设置、团队和项目） **不包括** 在迁移中，必须在目标企业上手动重新配置。\n\n## 与 GitHub Enterprise Importer 的差异\n\nELM 和 GitHub Enterprise Importer（GEI）是两个独立的工具，都支持将存储库从 GitHub Enterprise Server 迁移到 GHE.com。\n\n主要优点 ELM 是：\n\n* **缩短开发人员停机时间**：使用 GEI 进行迁移期间，开发人员在迁移期间无法访问存储库。 此停机时间会导致阻止部署或停止功能工作等风险。\n* **Monorepo 支持**： ELM 能够迁移具有深度历史记录的大型复杂单一存储库。 这些通常会超过 GEI 的容量。\n* **更好的可见性**： ELM 提供有关迁移进度的详细存储库级别可见性、显示精细故障，以便可以确信迁移的存储库是准确的副本。\n\n但是，由于与实时更新关联的流量负载较高， ELM 因此支持的并发迁移比 GEI 少： 每个目标企业最多可以有 20 个并发迁移，从单个实例最多可以进行 10 个并发存储库迁移。\n\n在平台迁移过程中，你可能希望使用这两种工具，并优先处理受益最多的存储库 ELM。\n\n## 迁移概述\n\n通常，站点管理员使用 `elm` CLI 工具通过 SSH 在终端会话中运行迁移。 操作员必须同时提供 personal access tokens 对目标 GitHub Enterprise Server 企业的访问权限。\n\n迁移的高级阶段包括：\n\n1. **创建**：站点管理员运行 CLI 命令来创建和启动迁移，并指定源存储库和目标。\n2. **预检检查**：迁移服务验证参数、令牌、网络连接和存储库配置。\n3. **回填**：该工具 ELM 执行初始爬网以捕获所有存储库数据并将其发送到目标平台上的迁移服务。 在回填阶段，Webhook 会在迁移过程中监控存储库的实时更新。\n4. **切换**：源代码仓库被存档（设为只读），并且任何最后的实时更新都会发送到 ELM。 这是开发人员的停机时间。\n5. **完成**：迁移已完成。 站点管理员可以检查数据是否已成功迁移。\n6. **跟进**：组织所有者对目标企业执行后续任务，例如重新配置组织设置并向用户重新分配活动。\n\n## 后续步骤\n\n若要准备好运行迁移，请参阅 [准备从 GitHub Enterprise Server 到 GHE.com 的实时迁移](/zh/enterprise-cloud@latest/migrations/elm/prepare-for-your-migration)。"}