限时活动:如果您在 2022 年 5 月 15 日之前申请云迁移试用版,则可以免费试用 12 个月。申请试用
Cloud 迁移指南
欢迎使用 Cloud 迁移指南!
我们通过将迁移过程分解为易于理解的多个阶段,并着重描述每一步所需的工具、资源和支持,从而帮助您自信地完成迁移之旅。
需要更多的实践建议?
除了本指南,我们的免费迁移演示还提供每个阶段的建议、提示和最佳实践,以及在整个演示过程中与我们迁移支持团队进行的实时聊天问答。
正在迁移 1,000 多个用户?
虽然大多数团队可以自行管理迁移,但迁移超过 1,001 个用户的客户应直接与我们联系,以获取更多支持,并与我们的团队安排迁移窗口(尤其是那些计划在下班后或周末进行迁移的客户)。请在既定迁移日期前 2 个月内与我们联系,以确保我们有足够的资源为您提供支持。
让我们砥砺前行!
简介
迁移至 Cloud 是一项团队行动,涉及 Atlassian、解决方案合作伙伴和我们的 Marketplace 合作伙伴,而其中最重要的因素是:您。在迁移中心内,我们提供免费的工具、资源和支持,以确保您踏上正轨并成功迁移 — 从本指南开始吧。
认识团队
我们提供多个不同的支持渠道,以帮助您完成迁移过程。您需要的支持级别将取决于您在迁移过程中所处的阶段和迁移的复杂性,而迁移的复杂性可能受到用户数量、要迁移的应用和产品等因素的影响(下文会详细介绍)。
- Atlassian 社区 — 提出迁移问题、寻求答案和支持,并与其他 Atlassian 用户建立联系
- 推广人员 — 讨论与定价、功能、Cloud 和自行管理产品之间的差异等相关的主题
- Cloud 迁移经理和迁移支持工程师 — 解决技术问题,在某些情况下还可提供其他迁移指导
- 解决方案合作伙伴 — 值得信赖的第三方合作伙伴网络,可以支持端到端迁移或执行特定迁移任务
了解更多有关我们的支持范围、联系方式以及何时需要考虑解决方案合作伙伴。
我们的免费迁移工具
您可以使用的最重要的工具是免费 Cloud 迁移试用版,以及我们适用于 Jira 和 Confluence 的 Cloud Migration Assistant。
了解每个方面,以及如何利用它们作为迈向 Cloud 的第一步:
云迁移试用版
我们为考虑迁移到 Cloud 的 Server 和 Data Center 客户提供免费的 Cloud 迁移试用版。试用将维持 Server 维护或 Data Center 订阅的持续时间(最长 12 个月),并与您当前自行管理的用户等级(最多 20,000 个用户)相匹配。如果您的维护接近尾声,或者您的维护已经过期,您仍然有资格享受 2 个月的 Cloud 迁移试用。您可以使用试用版:
- 探索 Standard 和 Premium Cloud 的功能,并评估其在 Cloud 中的差别
- 构建概念验证以了解 Cloud 中的体验,并与利益相关者一起进行试用
- 您可以根据自己的需要对迁移进行多次测试,一旦准备就绪,就可运行真正的迁移,并将试用版用作生产许可证
强烈建议在迁移完成后,注册填写一个您计划作为新生产站点而保留的 URL。
Cloud Migration Assistant
适用于 Jira 和 Confluence 的 Cloud Migration Assistant 均为免费应用,可从我们的 Marketplace 获取。而根据您使用的版本,它们也可能已经安装在您的自行管理实例上。这些助手可帮助您评估和审计应用,并在迁移之前清理您的数据。根据您选择的迁移方法,用于实际迁移数据的工具可能有所不同。
- 对于 Confluence 客户,Cloud Migration Assistant 可以轻松地将您的空间、用户和群组迁移至 Cloud。了解有关“使用 Confluence Cloud Migration Assistant 可迁移哪些数据”的更多信息
- 对于 Jira Software、Jira Service Management 和 Jira Core,您可以使用 Jira Cloud Migration Assistant 来迁移数据。了解有关“使用 Jira Cloud Migration Assistant 可迁移哪些数据”的更多信息
- For Bitbucket, you can use the Bitbucket Cloud Migration Assistant to migrate your code, users, and pull requests. Learn more about what data gets migrated with Bitbucket Cloud Migration Assistant
成本比较工具
为了帮助您最好地评估 Server 和 Cloud 之间的成本,我们构建了定价工具,可提供全面的定价视图和估算。
- 通过估算与 Server 或 Data Center 相比的 Cloud 总体拥有成本,全面了解成本的实际组成。计算您的 Cloud 节省金额
- 获取 Cloud 或 Server 中产品和 Marketplace 应用的预估成本。您还可以添加其他产品或应用,并更改 Cloud 计划或用户数量,以便观察成本的变化情况。查看您的估算
了解您的要求
在您开始您的 Cloud 旅程之前,有几个问题需要考虑,以便大致了解您的迁移需求:
- 此次迁移的目标是什么,您希望在长期时段内实现哪些目标?
- 您的时间表是怎样的?数据迁移是否准备就绪,还是要再等等?
- 预算是多少?
- 您和您的团队可以在迁移方面投入多少时间?哪些人会参与其中?
- 您希望迁移哪些产品,贵公司的规模有多大?
- 您对安全、法律、合规和隐私的要求是什么?
- 哪些 Marketplace 应用是您的团队所必需的?
为了帮助确定您的时间线和预算,最好对迁移可能需要的时长有一个大致的了解。迁移时间线可能会有很大差异,具体取决于迁移的复杂性、选择的策略以及分配给项目的预算和资源。
为向您提供粗略的估计,我们通常会遇到的迁移时间范围如下:
- 最多 1,000 个用户:大约 3 个月
- 1,000 到 5,000 个用户:大约 6 个月
- 5,000 多个用户:大约 9 个月以上
在下一阶段,要把这些问题牢记在心,以帮助您做出有关规划和策略方面的决定。

评估阶段
旅程的第一阶段是评估阶段。在此阶段,您可以评估当前的状况,并了解 Cloud 和自行管理部署(例如:功能、维护和成本)之间的区别。
比较 Cloud 与自行管理产品
在此部分,我们将重点介绍在比较部署时需要考虑的几个关键事项,以确保您做出正确的决策。您还可以利用我们的迁移评估来获得个性化建议和量身定制的资源,以支持您的迁移。
是什么让云与众不同
部署和管理
与我们的自行管理产品不同,它们需要您花费时间和精力进行维护、升级、托管等,我们的 Cloud 产品由 Atlassian 托管、安装、保护、维护和更新,从而可为您的团队免除管理负担。您将始终能够访问最新的特性、改进和安全更新,不需要手动进行版本升级。下载我们的“成为 Atlassian Cloud 管理员”指南,了解有关过渡的更多信息。
云安全性与合规性
Atlassian 非常重视数据安全、隐私和合规。我们负责掌握全球不断变化的法规和合规性需求,管理员不用理会,因此无论您位于何处,您的数据都是安全的。想要更深入了解我们的认证以及我们如何保护您的数据安全,请访问 Atlassian Trust Center。
用户管理和 Atlassian Access
在管理 Cloud 中的用户时,创建组织并验证网域可为您提供企业跨多个 Cloud 站点和 Atlassian Cloud 产品的所有用户的集中视图。这也将给予管理员更多的控制权,使其能够为申领的用户帐户实施安全策略。
为了获得更多企业级安全性和集中式管理,我们构建了 Atlassian Access,只需一次订阅,就可以在您的全体 Atlassian 云产品上运行。在判断是否需要 Atlassian Access 时,可以评估的一些考虑因素包括:
- 您公司有云应用方面的安全需求吗?
- 您需要 SAML SSO 来简化访问和身份验证吗?
- 您是否需要连接到内部目录的自动化用户生命周期管理?
Access 支持可伸缩的治理,具有诸如用户配置、SAML SSO、Active Directory 同步、强制 2FA、API 令牌控制等特性。我们建议迁移者尽早评估他们是否需要 Access,以充分了解他们的 Cloud 情况。如果您仍希望使用本地 Active Directory,则还需要云身份提供商来连接您的 Cloud 产品。
云计划和定价
Cloud 既可以提供每名用户每月的价格,也可以提供年度订阅。月度订阅是根据每个月产品的授权用户的确切数来收费的。年度订阅则是根据您所属的用户级别收费的,并以较低的价格提供。
Atlassian 还提供了一系列的价格计划,旨在满足所有类型的团队的需求:要深入了解每个产品的定价计划所包含的功能,请访问以下定价页面:
如果您不确定需要哪种计划,可申请免费 Cloud 迁移试用版,以免费测试 Standard 和 Premium 功能,且无需任何承诺。
乍一看,云似乎更昂贵。但是,考虑到隐性服务器维护成本,以及 Atlassian 负责管理您的软件的事实,随着您的团队减少 IT 开销、维护、硬件成本等,您的长期成本就会转化为节省。除去这些项目,您的云账单便只剩下订阅费用和管理费用。

详细了解更多有关如何估算您的 Cloud 成本的信息,其中包括如何了解总体拥有成本,以及获取将 Server 产品迁移到 Cloud 的个性化成本估算。
查看即将推出的产品
我们正在不断创新和改进我们的 Cloud 解决方案。查阅我们的 Cloud 路线图,以了解即将推出的功能,以便为将来可以帮助您轻松迁移的功能做好计划。
评估当前的情况
在审核您当前的整套技术时,请记下您拥有哪些产品(包括 Atlassian 产品,以及您可能想要集成的其他工具)。
- 它们都是自行管理的,还是您已经有了一些云产品?
- 每种产品分别有多少员工在使用以及用于什么目的?
- 它们的使用频率有多高?
- 有没有您之前不知道的实例?如果有,您打算将它们与云站点放在一起,还是将它们归档?
- 您在运行的是哪个版本的 Atlassian 产品?
- 您为 Atlassian 的产品做过定制吗?您或您的团队多久维护一次实例中的工作流和自定义字段?
通过了解您当前的环境和您的团队现在需要什么(而不是随时间的推移自然扩展或采用了什么工具),可帮助您更好地确定您的前进道路。在迁移之前做好清理并实现您工作流程的标准化将使迁移过程更为顺畅,并在您的团队过渡到 Cloud 时成为一大优势。
评估应用和集成
与前面的步骤类似,对您自己安装或构建的当前应用(也称为插件)进行评估。在审核过程中,可能需要问自己这样一些问题:
- 如何使用每个应用?它们都被用于既定的目的了吗?
- 有多少人在使用这些应用?
- 是否有多个应用服务于同一个目的?
- 云产品中是否有相同的应用功能?
- 服务器和云应用之间的成本差异是什么?
- 是否有任何应用许可证已经过期?
审计应用时,主要关注的是它们是否在 Cloud 中可用,以及数据是否可以迁移。
使用 Cloud Migration Assistant 评估您的应用
如果还没有,请下载适用于 Jira 和 Confluence 的 Cloud Migration Assistant,并导航到“评估应用”。应用评估功能会显示当前在实例上安装的所有应用,Cloud 是否有该应用的版本,功能是否相同,以及是否存在迁移路径。
使用关于如何通过 Cloud Migration Assistant 进行应用评估的分步指导,或观看此处的视频教程。
如果您无法下载 Cloud Migration Assistant,请使用我们的应用评估手册指南。
云应用可用性和迁移能力
有了当前应用的列表和它们的使用情况后,请利用此机会来彻底清理。与内部团队交流,了解哪些应用对日常工作至关重要,哪些应用是 Cloud 中必备的,哪些应用不再对任务十分关键甚至不再使用。某些情况下,您在 Server 中使用的应用是 Cloud 中的原生功能。
对于那些重要的应用,请确保有对等的 Cloud 应用可用。此操作可通过 Cloud Migration Assistant 完成,或者您也可以在 Atlassian Marketplace 中进行搜索。
如果没有类似的应用,应直接联系供应商,看看是否有类似的应用正在开发中,了解 Marketplace 上是否存在类似的选择,或者重新评估这个应用是否对您的团队至关重要。请注意,服务器中的应用在云中的功能可能不同。我们建议直接联系供应商,检查云应用是否功能相同。
要了解您的 Server 应用是否有可用的 Cloud 迁移路径,请查阅 Server 到 Cloud 应用迁移文档,了解符合迁移条件的应用列表和说明。
与 Atlassian 的产品一样,Cloud 应用在功能和特点上可能与 Server 版本有所不同。所有的 Cloud 应用都有一个 30 天的免费试用期,所以您可以确保它仍然满足团队在 Cloud 中的需求。申请免费 Cloud 迁移试用版并安装您选择的 Cloud 应用,以便进行测试。
应用安全性
与使用自行管理许可证的应用不同,Cloud 应用并不是安装在您的防火墙后。相反,大多数 Cloud 应用是由 Marketplace 或开发该应用的 SaaS 合作伙伴托管的。虽然我们的供应商对其应用的安全性负责,但我们仍针对 Atlassian Marketplace 中的每款产品实施了严格的要求。第三方应用须遵守:
- 业界一致的安全自评估
- GDPR 和欧洲关于数据和隐私的法规
某些应用合作伙伴也会选择参与我们的公共缺陷赏金计划,在此活动中,将有一组安全研究人员对应用进行测试。您会在他们的应用列表上看到一个“云安全参与者”徽章。
我们还启动了我们的 Cloud Fortified 应用计划。通过该计划,您可以更轻松地查找具有高级安全性、可靠性和支持的 Atlassian Marketplace Cloud 应用。要获得 Cloud Fortified 徽章,Marketplace 应用必须满足 Atlassian 的云安全性要求,并参与其他选择加入的云安全性计划,接受定期性能检查和监控,以最大限度地提高可靠性,并保持严格的支持 SLA。
为了支持 Cloud 产品的可扩展性和定制性,Marketplace 合作伙伴和客户可使用我们的应用开发平台 Forge 构建符合核心 Atlassian 平台且附带内置安全防护的应用。
评估数据的规模和复杂性
在整个评估阶段,您收集了有关您当前情况的信息。接下来,需要通过查看要迁移到 Cloud 的数据量和用户数来了解迁移的潜在复杂性。您的复杂程度可能会影响您的时间线、选择的迁移策略以及可能需要的支持级别。可能对复杂程度造成影响的因素包括:
- 规模:您的数据规模以及用户数
- 应用:您拥有的关键应用的数量,它们是否在云中可用(或具有替代方案),以及它们是否有迁移途径
- 自定义:自定义字段、非 Atlassian 集成、自定义应用和非常见数据形态
- 产品数量:您要迁移的产品越多,您的迁移就越复杂。例如,仅迁移 Jira Software 要比迁移 Jira Software 加 Jira Service Management 更简单。
- 合并和联合:如果要合并多个站点,而不只是简单地迁移到一个新站点,则由于需要协调数据、应用和用户,而会增加复杂性。同样,联合或拆分站点,或者选择同时在 Cloud 和 Data Center 实例中托管数据则可能会增加迁移过程中的复杂性。了解有关 Cloud 中单实例和多实例模型的部分使用案例的更多信息。
- 用户管理:对 Atlassian Access 的需求、匿名用户的数量、非活动用户的数量以及使用多个身份提供商
组建团队
正如我们此前所言,迁移是一项团队行动,所以您应立即组建强大团队,来帮助组织进行迁移。在大多数迁移中,以下列出的这些角色关乎到整个迁移过程的成败,不过,如果团队规模较小,同一个人可能会扮演多个角色。请记住,您随时都可以从 Atlassian 获取支持。
- 项目经理:专门负责凝聚团队的人员,负责展示业务案例,管理迁移,跟踪状态和各个任务,并担任主要联系人。
- 系统管理员:在 Server 上配置系统,了解需要迁移的权限和工作流。他们还可以执行迁移。如果他们没有 Cloud 方面的经验,也可以依赖解决方案合作伙伴来执行实际的迁移工作。
- 执行发起人:负责预算审批,业务案例审批,并可能成为公司的 Atlassian 拥护者。
- 技术团队和测试人员:执行迁移的专门团队。在迁移之前,您将希望运行一系列测试,以确保团队能够完成重要的任务。测试人员应该来自不同的团队,他们将以不同的方式使用您的系统,并应测试他们最重要的任务。
- 安全、法务和合规:来自安全和法务部门的人员应该尽早参与进来,以确保迁移计划满足所有的安全和合规标准(并防止这些要求在此过程的后期成为障碍因素)。
- 产品代表:迁移将改变团队的工作方式,这意味着团队将需要培训、解决疑难,还可能需要通过就工作流程集思广议来获取帮助。此角色可以指定一个人员来承担,也可以由一个团队共同承担。
对于任何团队来说,务必要在迁移过程中为具体的运作制定指导方针,以确保清晰和一致的沟通路线。以下是确保团队顺利运作的一些建议:
- 及早设置清晰的角色和职责
- 经常沟通
- 尽早制定计划,尽快组建团队
- 在必要的时机和场合引入解决方案合作伙伴。我们看到,在超过 1,000 个用户的迁移中有 60%、在超过 5,000 个用户的迁移中 100% 都有解决方案合作伙伴的参与。了解更多有关何时需要考虑解决方案合作伙伴的信息
下载 Cloud 迁移工具包以获取清单、通信模板等。

规划阶段
既然您已经花时间对 Cloud 进行了研究、评估了自行管理的设置并组建了团队,那么现在是时候开始规划实际的迁移了。
准备好在云端工作
使用 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 小时,因此最好尽早开始。
选择迁移策略和方法
具体选择哪种方法将取决于您团队的独特迁移需求。查看以下部分,了解并选择适合您团队的最佳策略和方法。
从服务器到云的迁移策略
优化和迁移推荐
评估要迁移到 Cloud 的数据,以及哪些数据和/或非活跃用户需要留在 Server 实例上。在单个停机时间窗口中仅迁移必要的数据和用户。
直接迁移
整合您所有的数据(产品数据、用户和应用),并在一个停机时间窗口内将它们迁移到 Cloud。
分阶段
分 2-4 个阶段迁移数据,而不是一次迁移所有数据。我们建议根据特定于价值的群组选择阶段(例如,单独的服务器、产品、活动与已存档/非活动)。当您完成每次迁移后,就可以解决相关问题,并以小规模的形式对用户进行迁入和培训。
某些客户选择在较长的时段内连续地逐个项目、逐个空间或逐个团队进行多次迁移。我们不建议采用此方法,因为它可能会导致额外的复杂性,包括:
- 用户在两个平台上被拆分
- 管理员在转换期间需同时维护 Cloud 和自行管理产品
- 资源、变更管理和潜在合作伙伴服务的成本上升
- 业务中断
- 自行管理产品和 Cloud 产品之间很有可能存在配置偏差
从头开始
如果您有确定最近不会使用大多数现有服务器项目数据,或者想立即在云中工作,则可以选择从头开始方案来建立云站点。
| |
---|---|
优点 |
|
缺点 |
|
何时推荐 |
|
| |
---|---|
优点 |
|
缺点 |
|
何时推荐 |
|
| |
---|---|
优点 |
|
缺点 |
|
何时推荐 |
|
| |
---|---|
优点 |
|
缺点 |
|
何时推荐 |
|
选择您的迁移方法
至于实际的迁移方法,有一些选项可供选择。考虑上面您选择的迁移策略,然后查看此处概述的迁移方法,以确定最佳方案。影响您方法的因素包括:
- 想要迁移哪些产品
- 您使用的 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 迁移文档。
记录您的迁移项目计划,包括规划的活动、估计的时间、每个任务的负责人和依赖关系。

准备阶段
您已经制定好了计划,现在是时候让团队、环境和数据为这一重大转变做好准备。此阶段可能需要几天到几周的时间,因此请确保您有足够的时间完成此阶段的工作。如果您人手有限,或者需要更多实际操作方面的支持,可以与解决方案合作伙伴联系,让他们为您分担繁重的工作。
准备您的团队和站点
有了计划和估计的时间线,就可以开始与将受影响的利益相关者和团队讨论迁移的细节,这样您的用户就可以在不影响工作的情况下顺利开始。对于某些公司而言,根据要迁移的产品的关键程度,此步骤可能需要在更早阶段开始。最好建立沟通层级,规定沟通时间和频率,以便团队可以收到通知并为变更做好准备。
下载 Cloud 迁移工具包以获取通讯模板、运行手册模板等资源。
确保您使用了受支持的服务器版本
根据您已经选择的迁移方法,您可能需要在特定版本的 Server 或 Data Center 实例上执行迁移。请查看以下受支持的版本:
清理您的 Server 实例
迁移的数据越多,迁移的时间就可能越长、越复杂,并且可能会影响 Cloud 性能。在运行测试迁移之前,请将迁移作为清理 Server 实例的一次机会。
其中需要注意的部分事项可能包括:非活动的应用或用户、旧产品数据(例如:项目、自定义项或可以简化或遗留的工作流程)以及所有重复数据。有关清理的最佳实践,请参阅我们的文档。
安装云应用
作为测试的一部分,您可能需要安装和测试打算在 Cloud 中使用的所有应用的全部功能和迁移。确保您和您的利益相关者都已经测试了 Cloud 功能,并且适合您团队的需求。了解有关迁移应用的更多信息。
制定运行手册和时间表
汇编一本运行手册或逐步清单,说明在什么时候需要执行哪些操作、支持性说明、每个任务的负责人以及每个步骤需要多长时间。记录哪些步骤是相互依赖的,且如果没有完成便会阻碍您推进。在运行手册的最后,为负责人提供一个缓解计划,以防需要回滚某些内容。
要开始使用,请下载我们的运行手册模板,并根据需要修改任务。您可以观看我们关于如何使用模板的短视频。
在下一阶段,您将使用运行手册运行测试迁移,并根据需要进行调整。

测试阶段
在此阶段,您将进行测试性运行,确保一切正常,计算迁移花费的时间,并在生产迁移之前发现所有问题。
测试性迁移
无论公司规模或迁移复杂性如何,我们都建议所有客户在执行生产迁移之前先运行测试性迁移。在使用我们的测试指南完成测试性迁移之前,请确保您已完成准备阶段的预迁移清单中的所有内容。
如果您使用的是 Cloud Migration Assistant,则请查看我们的文档以获取分步指导:
使用免费的 Cloud 迁移试用版来测试您的迁移、应用以及您可能需要的所有配置。您可以根据需要运行任意次数的测试性迁移。请参阅我们的文档,了解如何重置站点以运行多个测试。
备份您的数据
无论您选择了哪种迁移策略和方法,我们都建议在迁移之前备份您自行管理的实例。如果在您的 Cloud 站点中已经有数据,请务必同时备份这些数据。请参阅我们的文档以获取指导:
准备培训材料
迁移至 Cloud 可为您的最终用户带来一些变化和好处。请确保您已经了解它们,并为给用户带来的所有重大变化做好准备,例如,用户将会如何登录、新的 URL、应用的变化,以及用户界面的差异。上述 UAT 应该会让您了解用户将会遇到哪些问题,以及可能对他们有益的培训。除了搜集资料,下面还有一些额外的资源可能会有帮助:
- Atlassian University — 提供免费课程和付费课程,帮助管理员和最终用户学习如何充分利用我们的产品。在此处查看我们的迁移教程。
- Jira 产品指南 — 提供有关使用和定制 Jira、入门和最佳实践所需的一切知识
- Confluence 产品指南 — 提供关于如何启动和运行 Confluence 的教程和演示
- Bitbucket 产品指南 — 为您提供关于购买、使用以及与 Bitbucket Cloud 共同成长所需的一切知识
- 迁移后开始在 Cloud 中工作 — 在给用户的电子邮件中包含此页面或作为他们可以访问的附加资源会对其大有裨益
要让团队成功过渡,可以考虑创建一个清晰的流程,来收集反馈意见并回答最终用户关于迁移至 Cloud 的问题,比如办公时间或聊天室。
传达您的计划
安排好最终时间线和负责人后,就可以将正式计划传达给您的组织。沟通中需要包含以下内容:
- 何时进行迁移?
- 预计用户会遇到多长的停机时间?
- 让最终用户避免在过渡期间进行任何更改。
- 迁移后,旧站点会怎样?是否仍然可以访问或读取?
- 新的 URL 是什么?
- 用户将如何登入?
- 如果遇到任何问题或无法登录,应该与谁联系?
- 他们可以查看哪些培训材料以适应云环境?
切记,在迁移过程中可能会发生一些问题,您可能需要进行故障排除,因此请为最终用户安排一个调整期,以清理您的站点并按计划开展工作。
在 Jira 或 Confluence 中全站点使用横幅来提醒用户即将进行迁移。
将您的服务器设置为只读
根据您选择的迁移策略,您的用户可能不再需要访问您的自行管理实例。为了避免造成任何混乱,以及有助于切换,请在迁移之前将您的站点置于只读模式。对于 Confluence Server,请处理每个空间并删除除了读取之外的其他所有权限。Jira Server 中没有直接的“只读”模式,但您可以通过手动设置实现,方法是创建一个权限方案,仅允许“浏览”并将其应用于所有项目。对 Jira 和 Confluence 的站点端公告栏进行更新,阐明您的站点正在迁移,且现在处于只读模式。
如果迁移后您有用户继续在 Server 产品中工作,请确保在迁移完成后删除此设置。
运行生产迁移
现在请取出您创建的运行手册,并按照您汇总的步骤和时间安排将数据迁移到 Cloud 中。如果您正在使用此方法,请参阅我们的文档,了解如何使用 Cloud Migration Assistant 来运行迁移。
如果您是 Bitbucket 客户,请参阅我们的 Bitbucket 迁移文档来执行迁移。
迁移所有应用
利用已确定的应用迁移途径,安装并迁移您认为对于在 Cloud 中使用至关重要的应用。
对已迁移的数据进行 QA 检查
检查以确保您的数据已按预期迁移,并且一切工作正常且井然有序。请参阅我们的测试指南中的第 6 步,以获取有关在审查数据时的注意事项。
如果遇到障碍或者需要在整个迁移阶段获得指导,请联系我们的迁移支持团队以寻求帮助。

启动阶段
您成功了,可以松一口气了!通过仔细的规划、准备和全明星团队,您已经成功地迁移至 Cloud。在您庆祝(或休长假)之前,请确保您的团队受到热烈欢迎,确保他们已经为 Cloud 做好了准备,并且确保您的管理员相信自己已经做好了承担 Cloud 责任的准备。
欢迎您的团队
告知有关人员迁移已取得成功,并说明为什么公司决定进行此迁移,并重新分享目前的新现状。查阅我们的 Cloud 入门文档,并与您的团队共享,让您的用户顺利开展工作。我们建议您发送电子邮件以邀请用户访问您的 Cloud 站点,并在邮件中包含以下关键信息:
- 新书签链接,例如新的云站点链接
- 关于最终用户将如何登录的说明
- 重置内容(例如:头像,或者如果未使用 SSO,用户则需重置密码)
- 应用或功能的更改
- 将提供哪些培训
- 可向谁求助
第二个选项是在 Cloud 站点内邀请用户。
适应云环境
为了帮助您的团队进行调整,请留出一些时间来对任何迁移后的问题、反馈或问题进行优先排序。在迁移到组织日历后的第一周为办公时间添加一些时段,并创建 Slack 聊天室,最终用户可以在其中提问或提供反馈。
如果您不再打算使用自行管理的实例,请备份您的数据以便进行审计(如果尚未执行),那么可以让维护到期。
过渡到支持和维护
大多数(即便不是全部)问题都已解决,现在应该让团队过渡到对 SaaS 应用的标准支持和维护流程了。如果您仍然需要帮助,请与我们的团队联系,我们将协助您让站点正常运行。在 Cloud 环境中,管理员不需要像在自行管理的环境中那样承担手动维护的任务。接下来,您的团队可扮演更具战略性和前瞻性的角色,以时刻掌握公司的需求,并在团队规模扩大时专注于为团队提供支持。
遵循云安全最佳实践
云治理看起来也与典型的自行管理安全设置稍有不同。利用我们的最佳实践,包括身份提供商、安全协议,并熟悉 Atlassian 在保护您的数据安全方面的角色,为保护企业的成果而奠定坚实的基础。
关注云更新
作为 Cloud 管理员,您会希望随时掌握 Cloud 平台和产品的最新动态。请查阅我们的 Cloud 路线图以了解我们当前的工作内容。
探索我们的免费工具
使用我们的 Cloud Migration Assistant,评估您的应用并探索迁移选项等等。