到2024年2月，Atlassian将终止对Server产品及插件的所有支持。是时候制定您的迁移计划了——Atlassian为您提供两种迁移选择，一是本地部署的数据中心版本，中国用户25人以上即可使用，二是云版。作为Atlassian全球白金合作伙伴，龙智也为您准备了系列文章——《数据中心是否适合您的企业》、《迁移到数据中心版前，您需要做这些准备》，以及《如何将Jira和Confluence迁移上云》等，方便您选择适合自己的版本，并顺利实施迁，确保业务不受影响。

本文是《如何将Jira和Confluence迁移上云》系列文章的第三篇。当您比对完版本差异、了解了如何制定计划后，您就可以根据自己企业的实际情况定义属于自己的迁移策略了。

定义您的迁移策略

根据您所使用的Server版本和选择使用的工具，实际的迁移方法和策略会有所不同。

迁移核心数据的注意事项

Atlassian的Confluence和Jira云迁移助手将帮助您将项目、内容、用户和组从自托管的许可证迁移上云，而不会对团队造成任何中断。通过这些助手，您可以选择要迁移上云的内容，在方便的时间开始迁移，并在整个迁移过程中监控进展。

当您想要评估Server应用程序在云版产品中的可用性，查找应用程序是否有可用的迁移路径，以及在真正迁移前运行测试迁移时，云迁移助手也会派上用场。

如果您有兴趣进行云到云的迁移来整合站点，或者需要将数据从Jira Service Management Server(以前称为Jira Service Desk)或Advanced Roadmaps(以前称为Jira Portfolio)迁移到新的云站点，请联系Atlassian全球白金合作伙伴、云专业伙伴——龙智，我们的专家团队将帮助您迁移上云，这样您就可以继续专注于创造价值。

关于用户管理的注意事项

根据您在本地产品中进行用户管理的方式以及未来的需求，有几种方法可以迁移用户。

虽然一些企业选择手动管理用户，但也有一些企业选择将Atlassian Access添加到他们的云产品集合中，以便更紧密（且更容易）地控制密码策略、管理日志、统一用户管理和双因素身份验证、API控制以及SAML单点登录。

根据TechValidate对311名Atlassian用户进行的调查，85%的IT组织表示云端的用户管理更好或与本地部署持平。

Atlassian Access的用户可以使用SCIM供应功能进行迁移。对于没有使用Access的客户，Atlassian建议使用上述提到的云迁移助手。这些工具将承担用户迁移的重要任务，并执行预迁移检查，识别无效的电子邮件、重复的用户，以及其他要在迁移前进行的“清理”工作，以便将云产品推向最终用户。

在继续之前，还有几个问题需要您的回答：

您所有的Server产品目前是否使用相同的用户目录?
如果你使用第三方来管理用户，那么现在哪个身份提供商保存了这些数据?
在当前系统中最初设置用户管理的是谁？(如果不是您，务必让负责人或Server管理员参与进来，他们需要确认用户和组是如何配置的，以及考虑这些配置如何进行迁移。)

应用程序（插件）如何处理？

一个优秀的应用迁移计划始于对当前Server应用程序和集成环境的了解。Audits工具能帮助您做到这一点，还能帮助您确定在迁移过程中应该采取的行动。你需要回答的一些基本问题：

你们目前有哪些应用？
它们被用来做什么，由谁使用？
它们是必须的吗？
云上是否有类似的功能或应用程序的替代方案？
Server版和云版的成本比较如何？

您可能有很多应用程序。也许您从之前的管理员那里继承了一个包含30多个应用程序的实例（听起来有点多，但这种情况确实存在），所以，请把迁移看作是一次大扫除的机会。

应用程序是任何迁移讨论的重要组成部分，对于那些没有时间审查和迁移应用数据的人来说，这可能会令人望而却步。而这正是龙智的用处所在。作为Atlassian全球白金合作伙伴、云专业伙伴，我们拥有专业的知识，可以评估您当前的应用程序套件、执行审核，确定最佳的迁移方式，或者探索如何迁移到类似的云应用程序。

评估迁移的复杂性

您的迁移越复杂，策划和执行的时间就越长。根据预算和资源的情况，您可能会倾向于引入专业的Atlassian解决方案合作伙伴，比如龙智，来提供帮助。迁移的复杂性将基于以下几个主要因素:

规模：包括数据的大小，用户的数量。一个只有几个千兆字节数据和不到1000个用户的小型站点比一个拥有数百千兆字节数据和数千个用户的站点更容易迁移，无论是从数据迁移和停机时间的角度，还是整体策划的角度来看；
应用程序：包括关键应用程序的数量，它们是否又对应的云版产品（或有其他替代方案），以及它们是否有迁移途径；
自定义：包括自定义字段、非Atlassian集成、自定义应用程序和不寻常的数据结构；
产品数量：要迁移的产品越多，迁移就越复杂。例如，只迁移Jira Software比同时迁移Jira Software和Jira Service Management更简单；
合并：如果要合并多个站点，而不仅仅是迁移到一个新站点，这将增加复杂性，因为需要协调数据、应用程序和用户。一般来说，需要合并的数量越多就越复杂；
用户管理：有几个因素会增加复杂性，包括需要使用Atlassian Access、匿名用户的数量、非活跃用户的数量以及使用多个身份提供者。

优化并迁移（推荐做法）

这是一种“一次性”的迁移方法，您可以评估哪些数据要迁移到云端，哪些数据会留在Server实例上，设置为只读状态，用于将来作参考。

适用于

中等复杂性的客户和/或拥有2,000-10,000个用户的客户

优点

一次性迁移
只迁移所需的数据
整体迁移时间更短，迁移停机时间更少
团队更容易适应云环境
可能改善云性能
由于时间线延长，可能降低迁移成本（例如资源投入、合作伙伴成本）

缺点

所有用户需要同时登录
根据数据量多少，可能会增加停机时间
需要额外的规划和工作来确定如何优化

提取并迁移

将所有数据（产品数据、用户和应用程序）一次性迁移到云端。

适用于

拥有少于2,000个用户的低复杂度客户

优点

一次性迁移
整体迁移时间较短
由于时间线延长，可能降低迁移成本（例如资源投入、合作伙伴成本）

缺点

所有用户需要同时登录
根据数据量多少，可能会增加停机时间
可能会将不必要的数据和用户迁移上云，增加成本

分阶段迁移

分阶段迁移数据，而不是一次全部迁移。在每个迁移完成后，您可以解决问题，并以模块的方式进行用户上线和培训。

适用于

高复杂性客户和/或超过10,000个用户的客户

优点

分阶段用户登录
减少单次停机时间
允许随时间推移逐步清理和优化
给用户适应新方式的时间

缺点

如果需要迁移Jira Service Desk或Advanced Roadmaps（以前称为Portfolio），则无法支持
较长的总迁移时间，可能导致成本增加
在过渡期间管理多个部署可能会更复杂
需要仔细规划，因为必须映射依赖关系

从头开始迁移

如果您确信不会继续使用现有服务器项目的大部分数据，或者希望立即在云上开始工作，那么您可以选择全新开始，来设置云站点。

适用于

低复杂性的客户，用户较少的客户或新客户

优点

没有或有限的迁移停机时间
如果您有Server许可证，可以保留数据存档

缺点

用户将无法访问旧的项目/空间数据

最重要的是，您要了解每种方法的所有优缺点，同时选择出适合您企业特定需求的方法。事实上，真正复杂的迁移可能会混合使用提取、优化和分阶段迁移的方法。但正确的平衡取决于你的预算、时间安排和风险阈值。

规划和准备迁移

一旦了解自己的需求，就到了熟悉迁移的各个阶段并制定项目计划的时候。您需要了解具体步骤、预估时间、依赖关系以及每个任务的负责人。

迁移工具

如果您还没有注册免费的云迁移试用版，请联系Atlassian全球白金合作伙伴、云专业伙伴——龙智，我们的专家团队将帮助您立即开始！迁移至 Atlassian Cloud 版后的试用期长短是由您当前的自托管许可证的用户数梯度等级以及剩余的运维天数决定的（最长为 12 个月），这样您就可以在Jira和Confluence Cloud中进行探索，并计划迁移的详细内容。

Atlassian还为Confluence和Jira创建了云迁移助手，这是由Atlassian构建和维护的免费Marketplace应用程序。它可以帮助您将项目、内容、用户和组从Server版或数据中心版迁移上云，不会对团队造成任何干扰，并帮助您评估当前Server应用程序，了解云版应用程序可用性。除了激活免费的云迁移试用版以外，建议您第一步先下载云迁移助手。