Cloud 迁移指南

评估当前的情况

在审核您当前的整套技术时，请记下您拥有哪些产品（包括 Atlassian 产品，以及您可能想要集成的其他工具）。

• 它们都是自行管理的，还是您已经有了一些云产品？
• 每种产品分别有多少员工在使用以及用于什么目的？
• 它们的使用频率有多高?
• 有没有您之前不知道的实例？如果有，您打算将它们与云站点放在一起，还是将它们归档?
• 您在运行的是哪个版本的 Atlassian 产品？
• 您为 Atlassian 的产品做过定制吗？您或您的团队多久维护一次实例中的工作流和自定义字段?

通过了解您当前的环境和您的团队现在需要什么（而不是随时间的推移自然扩展或采用了什么工具），可帮助您更好地确定您的前进道路。在迁移之前做好清理并实现您工作流程的标准化将使迁移过程更为顺畅，并在您的团队过渡到 Cloud 时成为一大优势。

评估应用和集成

与前面的步骤类似，对您自己安装或构建的当前应用（也称为插件）进行评估。按照我们的分步指南评估您需要在 Cloud 中使用哪些应用，并检查以下问题以帮助指导您的评估：

• 如何使用每个应用？它们都被用于既定的目的了吗?
• 有多少人在使用这些应用？
• 是否有多个应用服务于同一个目的？
• 云产品中是否有相同的应用功能？
• 服务器和云应用之间的成本差异是什么？
• 是否有任何应用许可证已经过期？

评估应用时要关注的主要问题是，假设您的组织需要的应用存在于云中并且可以迁移到云端，那么将应用保留在云端是否还有商业合理性。

使用 Cloud Migration Assistant 评估您的应用

下载适用于 Jira 和 Confluence 的 Cloud Migration Assistants，并导航到“评估您的应用”。应用评估功能可显示当前在实例上安装的所有应用，并显示 Cloud 中是否有该应用的版本、功能是否相同，以及是否存在迁移路径。

使用关于如何通过 Cloud Migration Assistant 进行应用评估的分步说明，或观看短视频教程。

云应用可用性和迁移能力

有了当前应用的列表和它们的使用情况后，请利用此机会来彻底清理。与内部团队交流，了解哪些应用对日常工作至关重要，哪些应用是 Cloud 中必备的，哪些应用不再对任务十分关键甚至不再使用。某些情况下，您在 Server 中使用的应用是 Cloud 中的原生功能。

对于那些重要的应用，请确保有对等的 Cloud 应用可用。此操作可通过 Cloud Migration Assistant 完成，或者您也可以在 Atlassian Marketplace 中进行搜索。

如果没有类似的应用，应直接联系供应商，看看是否有类似的应用正在开发中，了解 Marketplace 上是否存在类似的选择，或者重新评估这个应用是否对您的团队至关重要。请注意，服务器中的应用在云中的功能可能不同。我们建议直接联系供应商，检查云应用是否功能相同。

要了解您的 Server 应用是否有可用的 Cloud 迁移路径，请查阅 Server 到 Cloud 应用迁移文档，了解符合迁移条件的应用列表和说明。

应用安全性

与使用自行管理许可证的应用不同，Cloud 应用并不是安装在您的防火墙后。相反，大多数 Cloud 应用是由 Marketplace 或开发该应用的 SaaS 合作伙伴托管的。虽然我们的供应商对其应用的安全性负责，但我们仍针对 Atlassian Marketplace 中的每款产品实施了严格的要求。第三方应用须遵守：

• 业界一致的安全自评估
• GDPR 和欧洲关于数据和隐私的法规

某些应用合作伙伴也会选择参与我们的公共缺陷赏金计划，在此活动中，将有一组安全研究人员对应用进行测试。您会在他们的应用列表上看到一个“云安全参与者”徽章。

我们还启动了我们的 Cloud Fortified 应用计划。通过该计划，您可以更轻松地查找具有高级安全性、可靠性和支持的 Atlassian Marketplace Cloud 应用。要获得 Cloud Fortified 徽章，Marketplace 应用必须满足 Atlassian 的云安全性要求，并参与其他选择加入的云安全性计划，接受定期性能检查和监控，以最大限度地提高可靠性，并保持严格的支持 SLA。

为了支持 Cloud 产品的可扩展性和定制性，Marketplace 合作伙伴和客户可使用我们的应用开发平台 Forge 构建符合核心 Atlassian 平台且附带内置安全防护的应用。

组建团队

正如我们此前所言，迁移是一项团队行动，所以您应立即组建强大团队，来帮助组织进行迁移。在大多数迁移中，以下列出的这些角色关乎到整个迁移过程的成败，不过，如果团队规模较小，同一个人可能会扮演多个角色。请记住，您随时都可以从 Atlassian 获取支持。

• 项目经理：专门负责凝聚团队的人员，负责展示业务案例，管理迁移，跟踪状态和各个任务，并担任主要联系人。
• 系统管理员：在 Server 上配置系统，了解需要迁移的权限和工作流。他们还可以执行迁移。如果他们没有 Cloud 方面的经验，也可以依赖解决方案合作伙伴来执行实际的迁移工作。
• 执行发起人：负责预算审批，业务案例审批，并可能成为公司的 Atlassian 拥护者。
• 技术团队和测试人员：执行迁移的专门团队。在迁移之前，您将希望运行一系列测试，以确保团队能够完成重要的任务。测试人员应该来自不同的团队，他们将以不同的方式使用您的系统，并应测试他们最重要的任务。
• 安全、法务和合规：来自安全和法务部门的人员应该尽早参与进来，以确保迁移计划满足所有的安全和合规标准（并防止这些要求在此过程的后期成为障碍因素）。
• 产品代表：迁移将改变团队的工作方式，这意味着团队将需要培训、解决疑难，还可能需要通过就工作流程集思广议来获取帮助。此角色可以指定一个人员来承担，也可以由一个团队共同承担。

准备好在云端工作

使用 Cloud 迁移试用版，或者如果您没有资格购买新的 Cloud 站点，并正在考虑使用 Atlassian Access 来提高整个站点的安全性，则需要立即完成两个步骤：设置您的组织和验证您的网域。请注意，这些操作并非必需，而是实施 Atlassian Access 的先决条件。

决定您是否需要 Atlassian Access

如果您需要在 Atlassian Cloud 产品中实现集中化的企业级安全和管理，那么现在则是考虑是否需要 Atlassian Access 的好时机。如果您也需要云身份提供商，请直接在 Atlassian Access 中注册免费的 Okta 帐户。如果您还不确定是否需要使用 Atlassian Access，也可以稍后添加。

设置您的组织

回顾一下：通过设置一个组织，您可以在同一处查看公司的所有 Atlassian Cloud 用户（跨多个 Atlassian 站点和产品），管理您用户的帐户，并设置 SAML SSO 一类的安全特性。系统将自动为每个站点创建一个组织，或者您也可以将站点转移到一个现有的组织。若要访问您的组织，请转到 admin.atlassian.com 并遵循关于如何设置、重命名产品和站点并将其添加到您的组织的步骤。

验证您的域

通过验证您的网域，将确保对您公司网域的所有权，并可以申领处于相同网域的所有用户的帐户（也称为受管理帐户）。选择一种方法并遵循有关如何为您的组织验证网域的步骤。此过程最长可能需要 72 小时，因此最好尽早开始。

选择您的迁移方法

至于实际的迁移方法，有一些选项可供选择。考虑上面您选择的迁移策略，然后查看此处概述的迁移方法，以确定最佳方案。影响您方法的因素包括：

• 想要迁移哪些产品
• 您使用的 Server 或 Data Center 版本是什么
• 需要迁移多少数据

应用迁移途径

迁移规划的其中部分工作包括确定您的应用迁移途径或将 Server 应用和应用数据迁移至 Cloud 的方法。

如今，不能使用 Cloud Migration Assistant 将应用数据自动从 Server 迁移到 Cloud。但是，我们正努力在今年年底之前将此功能添加到适用于 Confluence 和 Jira 的 Cloud Migration Assistant 中。

同时，许多 Marketplace 应用已记录了可用的手动迁移路径，或承诺构建自动迁移路径。在评估了应用并确定在 Cloud 中需要哪些应用后，请参阅针对 Jira 和 Confluence 应用的这些页面，以确定当前可用的迁移路径。如果您对文档中未介绍的应用迁移存有疑问，我们建议您直接与应用供应商联系。

用户迁移策略

用户迁移策略取决于您使用的迁移工具以及您是否具有外部身份提供商。在决定迁移用户之前，请确保您已查看如何迁移每种产品的用户、群组和权限。

如果您在使用自行管理的 LDAP 或 Active Directory 以作为用户身份验证方法，则必须使用 Atlassian Access，它可充当身份提供商和 Atlassian Cloud 产品之间的桥梁。如果您没有受支持的云身份提供商，Atlassian 将与 Okta 合作提供免费帐户。

要了解如何根据当前的用户管理设置向前推进，请参阅我们的 Access 和 Cloud 迁移文档。

记录您的迁移项目计划，包括规划的活动、估计的时间、每个任务的负责人和依赖关系。

准备您的团队和站点

有了计划和估计的时间线，就可以开始与将受影响的利益相关者和团队讨论迁移的细节，这样您的用户就可以在不影响工作的情况下顺利开始。对于某些公司而言，根据要迁移的产品的关键程度，此步骤可能需要在更早阶段开始。最好建立沟通层级，规定沟通时间和频率，以便团队可以收到通知并为变更做好准备。

确保您使用了受支持的服务器版本

根据您已经选择的迁移方法，您可能需要在特定版本的 Server 或 Data Center 实例上执行迁移。请查看以下受支持的版本：

• Jira Cloud Migration Assistant 支持的版本
• Jira Site Import 支持的版本
• Confluence Cloud Migration Assistant 支持的版本

清理您的 Server 实例

迁移的数据越多，迁移的时间就可能越长、越复杂，并且可能会影响 Cloud 性能。在运行测试迁移之前，请将迁移作为清理 Server 实例的一次机会。

其中需要注意的部分事项可能包括：非活动的应用或用户、旧产品数据（例如：项目、自定义项或可以简化或遗留的工作流程）以及所有重复数据。有关清理的最佳实践，请参阅我们的文档。

完成迁移前清单

在运行测试性迁移之前，请查看我们详细的迁移前清单，以确保您的数据和环境已准备就绪。

• Jira 迁移前清单
• Confluence 迁移前清单

安装云应用

作为测试的一部分，您可能需要安装和测试打算在 Cloud 中使用的所有应用的全部功能和迁移。确保您和您的利益相关者都已经测试了 Cloud 功能，并且适合您团队的需求。了解有关迁移应用的更多信息。

制定运行手册和时间表

汇编一本运行手册或逐步清单，说明在什么时候需要执行哪些操作、支持性说明、每个任务的负责人以及每个步骤需要多长时间。记录哪些步骤是相互依赖的，且如果没有完成便会阻碍您推进。在运行手册的最后，为负责人提供一个缓解计划，以防需要回滚某些内容。

要开始使用，请下载我们的运行手册模板，并根据需要修改任务。您可以观看我们关于如何使用模板的短视频。

在下一阶段，您将使用运行手册运行测试迁移，并根据需要进行调整。

测试性迁移

无论公司规模或迁移复杂性如何，我们都建议所有客户在执行生产迁移之前先运行测试性迁移。在使用我们的测试指南完成测试性迁移之前，请确保您已完成准备阶段的预迁移清单中的所有内容。

备份您的数据

无论您选择了哪种迁移策略和方法，我们都建议在迁移之前备份您自行管理的实例。如果在您的 Cloud 站点中已经有数据，请务必同时备份这些数据。请参阅我们的文档以获取指导：

• 备份 Jira 数据
• 备份 Confluence 数据

用户验收测试

测试性迁移的其中一部分是执行用户验收测试 (UAT)，以便您的最终用户能够复制常规日常任务，并确保它们按预期工作。通过此过程，您可以发现会影响您最终用户的所有问题，并帮助您的团队准备在 Cloud 中开展工作。查看测试指南的第 6 步，了解执行 UAT 的详情。

完成测试迁移并确定迁移将花费多少时间后，请选择进行生产迁移的日期。尽量将迁移安排在晚上、周末或者团队不太可能需要访问自行管理实例或 Cloud 站点的时间，以减少中断和数据差异的风险。不要忘记再花一些时间进行故障排除！

如果您要迁移 1,000 多个用户，请在既定迁移日期前 2 个月与我们联系。

准备培训材料

迁移至 Cloud 可为您的最终用户带来一些变化和好处。请确保您已经了解它们，并为给用户带来的所有重大变化做好准备，例如，用户将会如何登录、新的 URL、应用的变化，以及用户界面的差异。上述 UAT 应该会让您了解用户将会遇到哪些问题，以及可能对他们有益的培训。除了搜集资料，下面还有一些额外的资源可能会有帮助：

• Atlassian University — 提供免费课程和付费课程，帮助管理员和最终用户学习如何充分利用我们的产品。在此处查看我们的迁移教程。
• Jira 产品指南 — 提供有关使用和定制 Jira、入门和最佳实践所需的一切知识
• Confluence 产品指南 — 提供关于如何启动和运行 Confluence 的教程和演示
• Bitbucket 产品指南 — 为您提供关于购买、使用以及与 Bitbucket Cloud 共同成长所需的一切知识
• 迁移后开始在 Cloud 中工作 — 在给用户的电子邮件中包含此页面或作为他们可以访问的附加资源会对其大有裨益

要让团队成功过渡，可以考虑创建一个清晰的流程，来收集反馈意见并回答最终用户关于迁移至 Cloud 的问题，比如办公时间或聊天室。

传达您的计划

安排好最终时间线和负责人后，就可以将正式计划传达给您的组织。沟通中需要包含以下内容：

• 何时进行迁移？
• 预计用户会遇到多长的停机时间？
• 让最终用户避免在过渡期间进行任何更改。
• 迁移后，旧站点会怎样？是否仍然可以访问或读取？
• 新的 URL 是什么？
• 用户将如何登入？
• 如果遇到任何问题或无法登录，应该与谁联系？
• 他们可以查看哪些培训材料以适应云环境？

切记，在迁移过程中可能会发生一些问题，您可能需要进行故障排除，因此请为最终用户安排一个调整期，以清理您的站点并按计划开展工作。

将您的服务器设置为只读

根据您选择的迁移策略，您的用户可能不再需要访问您的自行管理实例。为了避免造成任何混乱，以及有助于切换，请在迁移之前将您的站点置于只读模式。对于 Confluence Server，请处理每个空间并删除除了读取之外的其他所有权限。Jira Server 中没有直接的“只读”模式，但您可以通过手动设置实现，方法是创建一个权限方案，仅允许“浏览”并将其应用于所有项目。对 Jira 和 Confluence 的站点端公告栏进行更新，阐明您的站点正在迁移，且现在处于只读模式。

如果迁移后您有用户继续在 Server 产品中工作，请确保在迁移完成后删除此设置。

运行生产迁移

现在请取出您创建的运行手册，并按照您汇总的步骤和时间安排将数据迁移到 Cloud 中。如果您正在使用此方法，请参阅我们的文档，了解如何使用 Cloud Migration Assistant 来运行迁移。

• 使用 Jira Cloud Migration Assistant 进行迁移
• 使用 Confluence Cloud Migration Assistant 进行迁移

如果您是 Bitbucket 客户，请参阅我们的 Bitbucket 迁移文档来执行迁移。

迁移所有应用

利用已确定的应用迁移途径，安装并迁移您认为对于在 Cloud 中使用至关重要的应用。

对已迁移的数据进行 QA 检查

检查以确保您的数据已按预期迁移，并且一切工作正常且井然有序。请参阅我们的测试指南中的第 6 步，以获取有关在审查数据时的注意事项。

如果遇到障碍或者需要在整个迁移阶段获得指导，请联系我们的迁移支持团队以寻求帮助。