乐趣区

关于云计算:Server版支持即将到期Jira和Confluence如何迁移2

到 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 解决方案合作伙伴,比方龙智,来提供帮忙。迁徙的复杂性将基于以下几个次要因素:

  1. 规模:包含数据的大小,用户的数量。一个只有几个千兆字节数据和不到 1000 个用户的小型站点比一个领有数百千兆字节数据和数千个用户的站点更容易迁徙,无论是从数据迁徙和停机工夫的角度,还是整体策动的角度来看;
  2. 应用程序:包含要害应用程序的数量,它们是否又对应的云版产品(或有其余代替计划),以及它们是否有迁徙路径;
  3. 自定义:包含自定义字段、非 Atlassian 集成、自定义应用程序和不寻常的数据结构;
  4. 产品数量:要迁徙的产品越多,迁徙就越简单。例如,只迁徙 Jira Software 比同时迁徙 Jira Software 和 Jira Service Management 更简略;
  5. 合并:如果要合并多个站点,而不仅仅是迁徙到一个新站点,这将减少复杂性,因为须要协调数据、应用程序和用户。一般来说,须要合并的数量越多就越简单;
  6. 用户治理:有几个因素会减少复杂性,包含须要应用 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 应用程序,理解云版应用程序可用性。除了激活收费的云迁徙试用版以外,建议您第一步先下载云迁徙助手。

有任何问题?
没有什么云迁徙之旅是放之四海而皆准的,然而不要放心,您并不孤独。依附 Atlassian 寰球白金合作伙伴、云业余搭档——龙智的专业知识来帮忙评估、打算和执行您的迁徙,为您的团队腾出工夫专一于真正重要的事件。

云迁徙之旅

云迁徙有六个阶段,在浏览本篇文章之时,您可能曾经启动了其中一些阶段。向云的迁徙不会始终是线性的,与相干人员的交换也可能不按程序进行,这些阶段能够为您提供一个灵便的框架参考,让您朝着正确的方向后退。

上图提供了一个简要概述,帮忙您在迁徙过程中放弃在正规之上,并放弃前瞻性。每个阶段都蕴含几个要害的工作和指标,在持续下一步之前必须实现。请记住,每个企业的云迁徙都是举世无双的——没有通用模板。

何时须要解决方案合作伙伴

如果您面临简单的迁徙工作,或者您的团队以前从未进行过云迁徙,那么引入一个解决方案合作伙伴能够使所有变得不同。一些大型和中型公司的客户通过与业余的合作伙伴单干,从布局和执行云迁徙的细节中获益。以下是一个查看清单,可帮忙您思考何时寻求解决方案合作伙伴的帮忙:

  • 无限的外部资源来帮助这个我的项目
  • 您须要帮忙解决 Atlassian 反对范畴之外的事件,包含用户验收测试、服务器降级或用户培训
  • 您须要迁徙项目管理、打算和执行方面的帮忙
  • 您面临简单的合并场景
  • 您须要迁徙五个或更多的要害业务应用程序
  • 您有特定的安全性和合规性需要
  • 您须要迁徙超过 1,000 个用户

Atlassian 寰球白金合作伙伴、云业余搭档——龙智为您提供端到端的迁徙服务,能够依据您企业的需要,量身定制一个适宜的套餐。

治理新的云产品

设想一下云迁徙实现的那一天。你和你的团队一起庆贺了一天,好好劳动了一天,带着一种满足感回到了工作中。那么下一步是什么呢?请持续浏览无关迁徙后如何治理新的云产品的最佳实际和技巧。

构建云版治理团队

迁徙上云为某些传统职位发明了机会。一些已经小众的工作当初变得重要起来,因为他们能够解决新呈现的挑战。其余职位根本放弃不变,但职责范畴会有所扩充。例如:

  • 大多数职位必须更多地依附他们治理和集成的能力。如果他们在云转型前不足这些能力,则须要倒退晋升;
  • 关注的重点从硬件转移到软技能,并转移到治理端到端的能力,而不是设计过程中的各个步骤;
  • 平安需要不同,与供应商的关系也在变动,受到最器重的技能类型也会发生变化;
  • 解决方案架构师和企业架构师等职业的重要性大大提高,他们次要整合内部云服务;
  • 基础架构角色,如网络管理员、数据库管理员和存储管理员,必须从新调整其云技能,并解决更多层次的自动化。

有了云工具,安全更新和性能改良会更频繁地主动进行。因而,放弃最新的状态在很大水平上就是及时理解变动的状况,理解正在进行中的性能和更新,并理解它们对最终用户的影响,而不是进行基础设施和软件的物理保护。尽管这的确须要一些工夫和技巧,但比本地堆栈治理节约了更多工夫。

退出移动版