关于企业迁移到 GitHub Actions
若要将企业从现有系统迁移到GitHub Actions，可以规划迁移、完成迁移并停用过时的系统。
本指南介绍了迁移的具体注意事项。 要了解有关将 GitHub Actions 引入您的企业的更多信息，请参阅 向企业介绍GitHub Actions。
规划迁移
在开始将企业 GitHub Actions迁移到之前，应确定将迁移哪些工作流以及这些迁移如何影响团队，然后规划迁移的方式以及何时完成迁移。
利用迁移专家
GitHub 可以帮助您进行迁移，您还可以通过购买 GitHub Professional Services 获得益处。 有关详细信息，请联系你的专属代表或 [GitHub 的销售团队](https://github.com/enterprise/contact)。
确定和清点迁移目标
在迁移到 GitHub Actions之前，需要完全了解企业在现有系统中使用的工作流。
首先，创建企业内现有构建和发布工作流的清单，收集哪些工作流正在使用且需要迁移的信息，以及哪些可以不进行迁移。
接下来，了解您当前提供商和 GitHub Actions 之间的区别。 这将帮助您评估迁移每个工作流程时遇到的任何困难，以及您的企业在哪些方面可能会遇到功能差异。 有关详细信息，请参阅“迁移到 GitHub Actions”。
利用此信息，你将能够确定哪些工作流你可以并且想要迁移到 GitHub Actions。
确定迁移对团队的影响
当您更改企业中使用的工具时，会影响团队的工作方式。 需要考虑如何将工作流从现有系统迁移到GitHub Actions，这会如何影响开发人员的日常工作。
确定将受迁移影响的任何流程、集成和第三方工具，并为需要进行的任何更新制定计划。
请考虑迁移可能会如何影响您的合规性问题。 例如，你的现有凭据扫描和安全分析工具是否会使用 GitHub Actions，或者是否需要使用新工具？
识别现有系统中的关口和检查，并验证是否可以使用 GitHub Actions 来实现它们。
识别和验证迁移工具
自动化迁移工具可将企业工作流从现有系统的语法转换为所需的 GitHub Actions语法。 识别第三方工具，或联系您的专用代表，或 GitHub 的销售团队，以咨询 GitHub 可以提供的工具。 例如，可以使用 GitHub Actions Importer 来规划、限定范围和迁移 CI 管道，从各种受支持的服务迁移到 GitHub Actions。 有关详细信息，请参阅“使用 GitHub Actions Importer 自动迁移”。
确定用于自动执行迁移的工具后，请通过在某些测试工作流程上运行该工具并验证结果是否符合预期来验证该工具。
自动化工具应该能够迁移大部分工作流程，但您可能需要手动重写至少一小部分。 估计您需要完成的手动工作量。
确定迁移方法
确定最适合您的企业的迁移方法。 较小的团队可以使用“替换并重建”方法一次性迁移所有工作流程。 对于大型企业，迭代方法可能更现实。 您可以选择让中央机构管理整个迁移过程，也可以要求各个团队通过迁移自己的工作流程进行自助服务。
我们建议采用将主动管理与自助服务相结合的迭代方法。 从一小群早期采用者开始，他们可以充当您的内部拥护者。 确定一些足够全面的工作流程，以代表您的业务广度。 请与早期采用者协作，将这些工作流迁移到 GitHub Actions其中，根据需要进行迭代。 这将让其他团队相信他们的工作流程也可以迁移。
然后，将 GitHub Actions 提供给更大的组织使用。 提供资源来帮助这些团队将他们自己的工作流迁移到GitHub Actions，并告知团队现有系统将何时停用。
最后，通知仍在使用旧系统的任何团队，以便在特定时间范围内完成迁移。 您可以指出其他团队的成功案例，以向他们保证迁移是可能的，也是可取的。
定义迁移计划
确定迁移方法后，构建一个计划，概述每个团队何时将工作流 GitHub Actions迁移到其中。
首先，确定您希望迁移完成的日期。 例如，您可以计划在与当前提供商的合同结束时完成迁移。
然后，与您的团队合作，创建一个符合最后期限又不会牺牲团队目标的时间表。 查看业务的节奏以及你要求迁移的每个团队的工作负荷。 与每个团队协调，了解他们的交付时间表，并制定一个计划，允许团队在不影响其交付能力的时间迁移其工作流程。
迁移到 GitHub Actions
当您准备好开始迁移时，请使用之前规划的自动化工具和手动重写策略，将现有工作流转换为 GitHub Actions。
您可能还希望维护现有系统中的旧构件，也许是通过编写脚本化进程来存档构件。
停用现有系统
迁移完成后，可以考虑停用现有系统。
你可能想要在一段时间内并行运行这两个系统，同时验证 GitHub Actions 配置是否稳定，并且不会降低开发人员的体验。
最终，停用并关闭旧系统，并确保企业内没有人可以重新打开旧系统。