为您的云之旅保驾护航

任何包含应用迁移的云转型过程都会十分复杂。尽管存在这种复杂性，但云之旅有几个明确定义的目标。其中一个目标涉及如何使目标应用达到“云就绪”。为了在所需的时间范围内迁移到云，您希望/需要应用达到何种程度的云就绪？在本文中，我们将概述其中的一些目标，并重点说明来自于我们旅程的优秀实践和经验教训。成功的关键是提前明确定义您的迁移目标，以便就如何实现这些目标制定优质决策。您会发现，面前有很多可能的路径。在迁移过程中，开发人员、交付团队和高管需要对推进方法进行评估并做出众多抉择。

我们建议您重点关注以下技术和业务驱动因素，以在制定实现业务目标所需的决策。

可扩展性

云服务可提供大规模计算能力，远远超出托管基础设施可能达到的范围，使您的企业能够不断发展，以抓住市场机遇。利用基于云的基础设施即服务 (Infrastructure as a Service, IaaS) 和平台即服务 (Platform as-a-Service, PaaS)，ISV 可以专注于利用现代组件构建可扩展的架构。迁移的另一个好处是，内部开发团队不必再管理和扩展 IT 运营，可以专心调整和优化性能。

现代化

实现工具集、服务和架构的现代化可简化组件之间的集成，促进应用充分发挥云中可用工具和技术的价值。此类工具包括基础设施升级、自动化部署管道，以及可提高应用性能的集成机器学习模型。在市场持续不断快速变化的领域，现代化尤为重要，因为应用必须保持动态才能与时俱进。在某些情况下，可能要完全重写和重塑服务，以利用最新的技术堆栈降低成本或提供更精简的服务选项。这种更改可以更新老化的产品，并颠覆以许可授权产品为主的成熟市场。在其他情况下，可能会通过新方法对产品进行更新改造，以改善服务，同时保持品牌知名度和客户忠诚度。这并不一定需要对产品套件进行全面更改。

迁移到云将成为您广泛推进现代化的一个契机。由于云为您和您的团队提供了以前在组织中无法获得的服务、技术和专业知识，实现新目标和提供新功能便成为可能。您的团队可将注意力从堆栈转移到普遍适用的新产品功能上来，不必操心为不同客户的特定部署编写定制代码。随着服务预配、产品更新和客户支持的速度比以往更快，您可以将资源重新集中在开发新功能上。这样一来，云迁移就为广泛开展现代化活动创造了条件，改变了从产品升级到客户服务质量的方方面面。

---

“迁移到第二代云使 Oracle 能够通过强大的开发、安全和运营 (DevSecOps) 模式确保成功交付我们的服务，并使我们能够支持客户的业务转型。我们现在每天都发布软件，且预配时间缩短了 98% 以上。”— Oracle 全球业务部门高级首席产品战略经理 Karthic Murali

---

标准化

实现 IaaS 和 PaaS 标准化能够减少开销，并提高团队的灵活性和可互换性。随着组织的发展，您的团队会采用不同成熟度的工具。将这些工具集整合到云服务中可大大降低这一 IT 管理层的复杂程度。这允许为任务开发和使用标准操作实践，这些实践可对应到整个产品组合。标准化还将简化日常活动，提高可预测性，从而减少基本任务的人工需求。以前资源疲于应对各种应用中导航方式各异且可能互不兼容的流程，而现在他们可以集中精力解决更重要的问题，包括为客户开发新一代产品和服务。

值得注意的是，标准化使您围绕安全、风险、合规性和其他运营活动实施全球政策和实践变得更加简单，您的团队可以轻松地将这些政策和实践应用于现有产品和新产品中。事实上，应用可以继承 IaaS 平台的许多内在功能，例如经认可的合规性认证。

收入优化

收入优化可以通过两种主要方式实现。首先，最明显的是成本降低。利用 IaaS 消除数据中心不仅将财务模式从资本支出转变为运营支出，通常还会显著节省总拥有成本。此外，通过合理调整已迁移到云的应用组合所采用的技术堆栈也会节省成本，只是这种节省可能不那么明显。通用工具集可建立起长期性的知识体系，省去为非标准化工具提供临时培训所产生的相关费用。除了这些方面，将基础设施视为代码的通用工具集还提供了自动化功能，最终节省了时间和人工成本。最后，有了专门负责整个产品组合的基础领域（例如安全性）的团队，便无需在每个产品团队中培养相关专家。

其次，迁移到云可以帮助您更快地进入市场，从而实现收入优化，因为一旦应用成为云就绪或云原生应用，产品开发时间通常便会缩短。更快地进入市场意味着更快地实现收入。一旦应用成为云就绪应用，便可以在几分钟内部署到全球任何位置。

综合起来，上述原则应能实现产品和服务架构标准化，并提高部署速度和质量。利用基于重复模式的设计进行扩展，从而促进收入优化，加快价值实现速度，并实现将资源重新聚焦于提高客户服务的质量和完整性。

---

WorkForce Software 将其员工管理解决方案迁移到 Oracle 云基础设施，实现了 30% 的性能提升。

“出色的财务绩效使我们从一开始就节省了 30% 到 35% 的资本支出，再加上来自 OCI 的卓越性能，我们的套件提供的投资回报率越来越高。”— WorkForce Software 首席执行官 Mike Morini

了解更多信息

---

在云中实现价值的途径

云计算可以包含一系列 IaaS 和 PaaS 资源以及多种软件部署模型，支持访问裸金属实例、集成的容器化环境，以及功能齐全的服务堆栈。在最基本的层面上，云计算是指用核心 IaaS 资源替代物理基础设施组件。

大多数企业应用最初并非针对云构建。对于许多应用来说，转换为云模式或符合云模式既耗时又困难。从时间和人工角度而言，平台重构成本高昂，因此有时从头设计云原生主体反而更加容易，也就不足为奇了。鉴于这一点，公司在考虑云迁移时通常有三种主要方案可选。

• 退出旧数据中心：运行数据中心成本高昂。建筑、人员、电力、制冷、维护和升级只是日常工作中的一小部分。许多企业通过评估应用组合，选出要从内部部署移除的候选应用，以主动减少或消除他们对数据中心的依赖。当务之急是将应用从托管、代管或内部部署数据中心移出，以减少或消除资本支出。这通常采用直接迁移战略，即将应用按原样迁移到云中的裸金属服务器或虚拟机。
• 转变技术堆栈：在这种情况下，公司对应用进行增量更改，这虽然需要额外投资，但预计会随着时间的推移产生更多价值。例如，将内部部署版本的 Oracle 数据库替换为基于云的 Oracle 自治数据库，而不对应用本身进行重大更改。这有时被称为“迁移并改进”战略。
• 完全采用云原生：重新构建从上到下都是云就绪的应用可能更有利，比在实施上述某种方案时保留不太成熟的应用更节省成本。云原生应用本质上是高度分布式的应用（通常采用 12 要素原则构建），并因此设计为独立于底层架构，这意味着即使底层的基础设施出现故障，应用仍会继续运行。简而言之，评估此途径是否适合目标应用是合理的，因为迁移到云肯定比迁移与底层基础设施紧密耦合的应用更容易。

要了解 Oracle 如何定义云原生、云原生应用的起源以及构建云原生应用时要遵循的优秀实践，请阅读此电子书。

---

设想这些方案的另一种方式是评估在将企业应用迁移到 Oracle 云基础设施时，可以采取哪些行动将其移至更接近云原生架构的位置。见下文图 1。

图 1：云迁移变更和投资级别

图 1 的左侧表示变更最少、价值实现时间最短和初始投资最低。随着您向右移动，变更、投资和时间通常会增加，但实现的价值也会更大。此模型可帮助您制定一种方法来预测在迁移阶段要考虑进行的投资类型。请注意，由于应用以多种方式构建，各个方案不一定是孤立的，可能会有一些重叠。

上述方案是您在评估现有成熟度和云转型目标时的重要参考点。您可根据当前状态与目标状态之间的差距对云转型所需的技术和流程变更范围进行粗略估计。在理想情况下，云转型应使所有应用都转型到云原生交付模式。然而，由于资源和时间限制，很少有组织能够在单个流程中将其整个产品组合转型到云原生模式。即使是简单的平台重构工作也可能需要大量资源，并且需要大量投资来复制旧功能。

因此，云转型是一个权衡理想的云成熟度（应用在上述云托管到云原生连续体中的位置）与重新设计产品及其相关业务流程所需的工程投资的问题。在此阶段，关键步骤是确定每个应用的当前和目标成熟度，并粗略估计弥合差距所需的开发投资。

对于在迁移过程中成熟度发生变化的应用，其运营模式和预期效果也必须更改。成熟度的变化会影响支持服务的团队、流程和策略。

 

评估云的技术就绪程度

对目标应用的技术理解，或者对整个应用组合的技术理解（公司提供多种基于 SaaS 的应用），对于理解迁移的要求和依赖项至关重要。在此阶段，关注的重点应该是确定应用所需的功能以及这些功能与依赖项的关系。这有助于推定迁移活动的相对时间安排，并明确关注的重点。评估应涉及三个关键方面。

1. 基础设施要求：云将软件与其底层硬件或操作环境分离。成熟度高的应用基本上独立于它们的环境，仅依赖于通用的基础设施资源（如 CPU 或 Kubernetes 集群），此类资源可在云中轻松扩展。成熟度低的应用依赖于所提供的特定设备、组件或环境，例如托管基础设施或其他专用系统。应用对云中基础设施组件和配置的硬性依赖关系必须首先记录并最终消除。与底层基础设施相关联/耦合的定制项（您或您的客户定制）并不少见。
2. 服务组件：云将支持功能作为独立的服务提供，这些服务独立于应用运行和交付。成熟度高的应用基于分离的组件构建，在整个堆栈中的依赖项极少，允许有针对性的更改和升级，并尽可能延长正常运行时间。成熟度低的应用由紧密耦合的大型组件构建而成，高度相互依赖，且必须作为单个实体进行管理。必须针对每个应用记录这些服务关系。
3. 运营就绪程度：云可以更改技术架构以及工作流程、技能集、可用工具和运营模式。成熟度高的应用已经可以像云应用一样运行，并使用在云中运行良好的流程、标准和工具集。成熟度低的应用会出现以下问题：云中缺少关键的支持服务，支持团队采用的技能集不适合云工作，或者使用的流程会因迁移到云而中断。

开始迁移时，首先根据这些因素评估应用的成熟度，这样您可以制定适当的计划，避免下游出现意外，造成延迟、增加成本并导致未实现目标。由于当前的生产环境、整套支持服务和目标云环境将在整个迁移过程中持续发生变化，迁移的复杂性不容小觑。揭示服务和应用之间的联系不仅可以提前进行明智的规划，而且可以使规划灵活应对迁移过程中不可避免地发生的更改。将这些内容有效地记录下来后，该评估将为迁移过程提供一个明确的待办事项清单。这将有助于确保预计的迁移时间表仍与不断变化的路线图步调一致。

---

Zoom 在 Oracle 云基础设施上快速扩大规模并激活数百万个并发会议。

“我们最近经历了有史以来最显著的业务增长，需要大幅提高我们的服务能力。我们了解了多个平台，Oracle 云基础设施在帮助我们快速扩展容量和满足新用户需求方面可发挥重要作用。”— Zoom 首席执行官 Eric S.Yuan

了解更多信息

---

财务目标

与任何 IT 计划一样，云转型需要一系列投资才能实现其全部价值，尤其是在目标应用采用内部部署托管模式构建时。随着时间的推移，被认为值得迁移到云的应用最终将成为云原生应用或停用。然而，最初的目标通常是使应用达到云发行版状态。

将应用从其当前状态转变为云发行版状态需要做出一系列决策和初始投资。您是计划只将应用直接迁移到裸金属服务器（在这种情况下，大部分投资将用于云基础设施），还是计划在迁移之前使应用达到云就绪（在这种情况下，需要用一些投资将部分应用堆栈迁移到基于云的模型，例如将数据库从内部部署迁移到 DBaaS 或 Oracle 自治数据库）？如果您创建了硬编码的定制项来支持特定于客户的功能，则必须按照以下模式对其进行重构：封装平台组件，并通过 API 将这些组件作为产品化功能交付。为了在云中扩展高度分布式的应用，需要消除硬件或平台依赖性。了解这些投资是规划和实现与云迁移相关的财务目标的关键因素。

最初的投资涉及的开发时间和人工用于进行与上述云迁移阶段相关的必要产品更改。然而，额外的费用也必须考虑在内。在转型期间，贵组织可能会发生的各种费用包括：

• 开发投资：重新构建产品或为迁移工作（包括支持数据库迁移和应用预配等活动的自动化功能）创建加速器所需的开发人工
• 迁移执行：预配新资产、迁移现有环境和数据以及停用旧清单所需的人工资源
• 基础设施采用：向 IaaS 转型期间产生的订阅费用，该费用以后会转到稳定状态，但在迁移期间会表现出新的增长
• 搁置的基础设施：迁移过程中产生的数据中心和资本支出折旧成本，在可以被消除或冲销之前一直存在
• 劳动力转型：与培训、教育或重组现有团队或获取具有所需云技能集的新资源相关的费用
• 客户转型：与新模式中无法支持的环境功能或服务条款变更相关的成本，包括新开发、激励、重新协商合同项或客户流失

这些成本中的每一项或多或少都是向 IaaS 转型所必需的。每一项都以不同的方式影响成本结构。例如，开发投资和迁移执行费用可能属于一次性费用，即使与这项工作相关的资源可能是固定的。采用新基础设施将导致一段时间内费用净增长，直到搁置的基础设施费用完全消除。一些劳动力和客户转型费用（如培训或迁移激励）为一次性费用。劳动力规模扩大或客户合同变更等其他因素可能会导致出现新的持续费用。

应了解这些动态因素随着时间的推移而发生的变化，这对于组织为云转型做好准备和设定预期至关重要。如果贵组织热衷于云的巨大优势，但对转型风险缺乏清晰的认识，那么在最初的早期阶段费用增加会令您感到惊讶，尤其是前期要承担迁移成本、重叠的基础设施成本和转型成本。设定正确的期望并了解进展是在组织转型期间保持一致性和原则性的基础。

云迁移清单

云迁移清单对于迁移到云至关重要。什么是云迁移清单？简单来说，它是包含组中所有资产以及描述每项资产的相关关键数据元素的列表。它列出了要迁移的应用及其所有依赖项。用于获取这些数据的媒介无关紧要，并且由于数据通常会跨公司内的多个部门，使用多种工具获取数据十分常见。所需的信息通常分散在一系列生产、销售和运营数据库中。例如，配置管理数据库可以详细跟踪技术依赖项和资产位置，获取物理服务器和机架位置。但是，对确定何时以及如何通知客户转型至关重要的企业和客户注意事项不在该数据库中。这些信息通常包含在为运营和支持相关方设计的存储库中。此外，收购、特殊用例和产品孤岛可能意味着这些信息进一步分散在多个存储库中。

迁移清单的主要目的是提供管理云迁移所需的各种因素的集中视图。例如：什么是资产？资产在哪里？它支持什么产品？有何用途？它支持哪些客户？

从一开始就必须认识到，蓝图是一份动态的文件。它必须是灵活的，因为它会随着时间的推移而变化，对于拥有多个应用或多个应用版本的公司更是如此。清单将随着新问题的出现和新需求的发现而不断变化。甚至底层云基础设施也可能在迁移过程中发生变化，从而再次更改清单。迁移清单应获取尽可能多的可用数据，以便您能够制定初始计划，然后在转型揭示出新需求时增加细节。

管理迁移清单本身是一个跨职能的项目，必须平衡对详细数据的需求和收集数据的工作量。它还包括确定依赖项、限制和资源的要素，例如精细的技术规范、架构方法、客户需求和数据传输路径，这些要素将影响时间和速度。如果信息太少，清单就没什么用处。但若信息太多，又会带来维护负担，数据可能会很快过时，无法使用。

我们建议使用以下迁移清单框架作为云迁移的起点。

从迁移清单到运营清单

虽然我们将重点放在迁移清单上，但云转型最终会带来两个挑战。最直接的是，它产生了对迁移活动进行规划、确定优先级和跟踪的需求。但是，迁移本身将强行更改日常运营跟踪所需的数据。例如，有关物理服务器和机架的迁移后配置详细信息将变得无关紧要，甚至有关单个实例的信息也将变得没那么重要。与此同时，总体使用情况和传出数据等指标可能会变得至关重要，尤其是在组织采用自助模式时。

创建迁移清单会开启向这些以云为中心的新数据模式和流程的转型。虽然创建清单和迁移应用这两项挑战相互独立，但不应孤立地解决。迁移工作是主要工作，组织可能是第一次创建详细的综合资产视图。这是一个变革性的时刻，应在此期间形成新的迁移后清单视图的模板。如上所述，迁移清单需要具有灵活性和适应性。如果管理得当，迁移清单将发展为有价值的迁移后清单管理工具。

试行云转型

设计托管 SaaS 应用的基础设施

作为提供基于 SaaS 的应用的 ISV，您需要安全、可扩展的企业级基础设施来托管您的服务，并以隔离的方式管理您的客户。下图 3 中描绘的参考架构提供了一个经过验证的采用优秀实践的框架，使您能够在 Oracle 云基础设施上托管 SaaS 应用。

在此参考架构中，您可以部署和管理多个隔离的应用实例。每个部署都针对特定租户，这些单个租户应用实例通过共同的管理层进行管理。

您可以选择使用单个代码库构建所有租户应用实例，也可以为每个租户提供定制版本的应用。此模式非常适合需要完全隔离应用环境的 SaaS 客户。

图 3：OCI 上 SaaS 应用的优秀实践参考架构

有关上述参考架构的更多详细信息，请访问 Oracle 架构中心。此外，我们还创建了基于 Terraform 的工具，协助用户为四个租户部署架构，并提供了分步指南。最后，我们始终建议您遵循 Oracle 云基础设施优秀实践指南，该指南提供了有关以下四个常见业务目标的指导：安全性和合规性、可靠性和弹性、性能和成本优化以及运营效率。

除了架构更改之外，您还需要考虑云中的服务堆栈会如何变化。在旧环境中部署的为内部部署架构开发的用于监视、网络管理或安全防护的核心工具集将发生变化，以满足云需求。迁移到云为扩大这些工具的应用范围提供了机会。基于云的工具可监视整个堆栈，而不是主要监视端点。有时，云服务提供商将在核心功能的基础上提供基于云或混合环境的监视工具。在 Oracle 云基础设施中，原生的监视、标记和审计功能组合能够实现对整个服务堆栈的监视，且通常会自动补救在指定规范之外发现的异常。如果您当前在内部部署中使用第三方监视工具，这些供应商也可以提供基于混合环境或云的工具。

---

Cisco Tetration 将其核心应用迁移到 Oracle 云基础设施，性能提升了 60 倍。

“与 Oracle 的合作非常愉快。所以 Cisco Tetration 才实现了这样的奇迹。”— Cisco Tetration 创始人 Navindra Yadav

---

制定试点计划

与所有工程工作一样，从小型试点计划或原型入手，让试点团队和组织了解可以做什么以及如何推进，能够充分提高成功的几率。试点和概念验证计划可确定和解决各种挑战，而无需承受全方位的组织范围的变革带来的时间和财务压力。试点计划可以帮助您控制变革的速度，您可以慢速迁移并熟悉新的运营环境。

利用试点，核心开发人员和运营人员团队有机会探索目标云环境、了解架构、服务和运营模式。该团队可形成一套实践知识、有用的工具和优秀做法，并积累信心、专业知识和经验。团队在积累这些知识的同时，也在不断调整基于云的环境中团队间协作的路线方针。云迁移需要应用团队从直接的资源管理者转变为其他团队提供的服务的使用者。试点可让应用团队了解服务边界的变化，如何与提供其所用服务的运营团队建立关系，并学习如何向这些运营团队传达自己的需求。

试点具有以下益处：

• 提供一个环境来验证（或质疑）技术可移植性的假设，尤其是在技术始终在同一环境中运行的情况下。这有助于团队了解他们是否做好了迁移的准备，并确定为实施迁移需要进行哪些更改。
• 提供一个机会来确认应用/数据库是否准备好与目标环境中的服务集成。团队可从中了解需要进行哪些更改，以及应用和目标服务环境何时准备好进行迁移。
• 能够针对目标环境进行构建，创造立足点，并将其作为产品组合其余部分迁移到新服务和新环境的起点。这为团队的产品组合设定了战略目标。

---

Manhattan Associates 将其供应链解决方案迁移到 Oracle 云基础设施，这比以前的云解决方案节省了 50% 的成本。

“Oracle 云在应用层和数据库层都具有高度的灵活性和丰富的功能，与以前的云解决方案相比，我们在基础设施方面节省了约 50% 的成本。”— Manhattan Associates 副总裁 Jeff Demenkow

---

管理试点计划

对于技术和运营人员以及高管和管理团队而言，试点是一次学习体验。高管和管理团队应与试点团队持续沟通，帮助消除组织中的障碍，确保组织充分利用从试点项目获得的经验（即哪些有效、哪些无效、优秀实践、经验教训和发现的标准模式或反模式）。获取这些有价值的信息，然后与组织的其他成员共享，在理想情况下可以使后续的云项目效率更高，效果更显著。管理人员可借助试点测试制定计划时提出的假设，并理清不确定的地方。虽然这些假设因组织而异，但试点计划在任何迁移中都会面临一些关键挑战。

• 培训：试点测试现有技能，揭示组织对技术迁移工作的准备情况。管理人员应使用试点来评估技术熟练程度，了解最需要掌握哪些工具和能力，并计划如何快速培养（或通过招聘人员来获取）这些关键领域的技能。
• 协作：试点展示了开发、运营和支持团队将如何以不同的方式协同工作。管理人员应确保这些团队在试点期间切实合作，发现新需求并了解如何在这种新环境中运营。
• 接受变革：试点有机会发现影响更大规模迁移的文化障碍。在试点中出现问题的组在大规模推行时也同样会出现问题。试点让管理人员有机会发现问题、部署培训并根据特定组织的现实情况调整计划。

顺利迁移的关键是奠定坚实的基础。迁移的第一阶段将推动开发一组核心服务和平台，随着迁移的进行，这些服务和平台将逐步扩展。最终，这些核心功能需要扩展到支持整个迁移产品组合。因此，初始云发行版不仅要成功，还要为所有后续发行版和升级开辟道路，这一点至关重要。

适应组织变革

设计托管 SaaS 应用的基础设施

改变组织的交付模式和客户关系可能需要新的技能、知识、业务流程和思维方式。这些变化会对整个组织产生广泛影响，这就是为什么文化变革常常被认为是云转型中最困难的方面。

这些变革的范围很广，因而可能会给人留下这样的印象：云转型需要大规模重组并替换劳动力，引入具有云经验和专业知识的劳动力。虽然更改内部职能的专业领域和招聘具有云技能集的新人是云转型的重要环节，但失去迄今为止对企业成功至关重要的既定流程、动态因素和贡献者也是难以承受的。您必须平衡组织变革的速度与对当前业务和客户体验的潜在干扰。保持这种平衡需要重新调整对职业发展能力的结构性更改，使现有员工能够转型到新的运营模式。

要将存在已久的软件业务转型到云交付模式，众多关键业务领域的假设、技术知识和标准操作流程都要发生巨大转变。虽然所需的更改量可能令人生畏，但我们的经验表明，保留并投资于现有团队通常要比尝试彻底重建云专家团队更好。计划进行类似转型的组织应了解一下我们的 GBU 组织：该组织首先对变更需求进行自下而上的分散评估，允许每个团队制定各自的迁移清单和服务堆栈路线图，从而确定各自控制领域所需的步骤。通过此方法，团队可以将其计划与切实的更改驱动因素保持一致，同时避免对可能需要的资源作出概括性的假设。

---

8x8 通过迁移到 Oracle 云基础设施，实现了全球互联，不仅成本降低 80%，服务也得到了改善。

“随着视频会议快速成为当今新世界的沟通桥梁，我们的用户数量大幅增加。为了支持这种指数级增长，我们考察了多个平台，并最终选择了 Oracle 第二代云基础设施，因为它具有强大的安全性、出色的性价比和卓越的支持服务，可以满足激增的新用户需求。”— 8x8 首席执行官 Vik Verma

观看视频

---

业务影响

成功实现云转型不仅能促进整个组织发生变化，而且能通过组织的改变获得有力支持。从以托管或内部部署产品组合为主转变为基于云的业务模式，需要从根本上转变组织与客户的互动方式。但是，既定业务实践和假设的更改幅度将在很大程度上取决于在云转型中进行的产品更改的范围。

即使在更改很少的场景中，迁移到 IaaS 也会推动业务流程的转变。GBU 确定了此转型中的两个关键更改机会。

1. 使用以运营支出为导向的考虑短期波动和长远预期的预测模型取代资本支出密集型的物理基础设施管理
2. 培养安全和合规性团队，使其从传统职责中解放出来，专注于提供服务组件

妥善应对这些变革和应用技术变革的组织将能够更好地发挥云迁移的全部潜力。

客户协调

从"压缩打包的"产品或甚至是托管产品转型到实际云服务，是您和您的客户要携手完成的旅程。事实上，正是这种向即服务模式的转变，将云与之前所有的托管模式区分开来。向云服务的每一次转变都会影响客户的体验 — 从可扩展性到正常运行时间再到弹性。在某些情况下，客户可能会请求，甚至迫切要求更改为新的交付模式。在其他情况下，对特性、功能和成本的期望可能会推动组织向着只能通过云交付来实现的方向发展。

当您开始让客户参与云战略制定时，您必须为以下两种观点做好准备：对路线图兴奋不已和不愿走出舒适圈。回应这些观点需要清晰、慎重的沟通，应指明努力的方向，但不要陷入技术细节或引发危险信号。这是让组织中面向客户的团队介入的关键时刻，确保他们了解正在开展的工作、企业正在进行的投资以及产品和交付的预期成果。为此，您需要让面向客户的团队参与进来，将这种改变转化为能够增强客户对服务信心的措辞。

对于将要使用云服务的客户而言，情况可能会更复杂一些。有一些客户群体需要云服务，他们了解 SaaS 在效率和敏捷性方面会带来的好处。然而，随着云或 SaaS 选项成为基本配置，客户需要了解供应商服务特有的功能和服务级别协议，而不是云本身的价值。

不过，并非所有客户都渴望获得云服务。尤其是采用托管或受管服务模式的现有客户可能会满足于现状，如果他们拥有与云交付不一致的定制服务组件或非标准环境和访问模式，则更是如此。即使客户看到迁移到云服务的优势，也可能会对交付条款变更或迁移环境需要中断服务的情况感到不安。

让客户放心需要营销、销售、支持和客户成功团队进行协调并采取一致的沟通。在理想情况下，客户根本不会意识到他们的工作负载已迁移，不知道发生了什么变化，直到有一天发现性能得到了改善。可现实情况是，将服务迁移到云通常需要升级和一段时间的停机，并且服务条款或可用功能也可能发生更改。指导客户完成这些活动，同时与整个转型时间表保持一致是一项复杂的工作，仅仅了解变革的好处是不够的，还需要认同发生的变革，并与可能影响客户业务的迁移步骤协调一致。

---

CMIC 将建筑企业软件迁移到 Oracle 云基础设施，部署速度提高了 10 倍。

“除了 OCI 比其他云提供商更具成本优势之外，我们现在还提高了敏捷性。OCI 使我们的技术灵活性达到了新的水平。借助 Oracle 容器服务和 Oracle 自治数据库等技术，我们可以继续专注于提供卓越的建筑 ERP 软件，同时向未来迈进。”— CMIC IT 和云基础设施总监 Vince Di Piazza

观看视频

---

一旦客户接受了云转型所带来的好处和变革，组织面临的最后一步就是将客户的工作负载实际迁移到新环境中。于是，确定新环境的迁移和验证测试的理想时间便成了又一挑战。接受了将面临一段时间停机的客户通常仍会对具体的停机时间有强烈意见。

虽然客户偏好对您来说很重要，但您必须平衡许多其他问题。规划迁移涉及到权衡多种因素，包括产品或服务的技术属性、所有客户偏好的协调、内部资源限制和业务目标，例如整合/消除现有的旧数据中心或终止弃用的产品线。为了平衡这些相互冲突的优先事项，可以让面向客户的团队参与迁移计划活动，因为他们将在表达市场预期方面发表重要意见。

正如组织必须为一段时间的投资和迁移以及云交付模式带来的技术和业务流程持续更改做好准备一样，组织也必须为如何就迁移与客户沟通及产品与客户关系将进入的新常态做好准备。

GBU 审查了转型在技术、运营和交付承诺方面会对客户造成怎样的影响，将那些需要特别关注、沟通和可能需要改变商业关系的客户分离出来，首先满足这些需求。使面向客户的团队做好准备的工作也基于类似的逻辑，包括与产品、运营、战略和其他团队协作，以提供全面的云知识，同时解决具体的产品和客户变更需求。

这项工作不仅仅是让面向客户的团队做好与客户沟通的准备。将跨职能的核心领导层聚集在一起协调客户沟通也会创造宝贵的机会，可将主要由技术主导的计划扩展为更广泛的行动计划，以重新审视解决方案的核心价值，重新阐明产品的独特之处，并规划在市场中保持和发展这种价值的理想方法。

提前准备

设计托管 SaaS 应用的基础设施

在本手册中，我们根据数千个实例中托管的超过 60 个 GBU 应用的迁移经验，提供了优秀实践指导。下面是我们总结的整个旅程中面临的五大挑战，我们认为这些挑战适用于将应用迁移到云的任何组织。

1. 确定迁移前的开发工作
   使既定应用达到云发行版就绪状态可能需要大量投资，使产品达到云原生状态更是如此。投资落实云原生应用原则可从云中获得最大收益，但同时也会消耗大量时间和开发资源，才能达到最终状态。产品达到云就绪所用的时间越长，获得云迁移固有的增量收益的时间就越会推迟，并且还可能延长暴露在通常与旧环境相关的风险下的时间。同时，并非所有产品都能平等受益，具体取决于它们的生命周期阶段和客户状况。充分了解并记录迁移前的开发工作量是迁移成功的关键。
   
   GBU 应用组多种多样，包括处于各个云成熟度和生命周期阶段的产品。虽然所有应用都需要迁移到云，但问题在于应对产品进行多少更改才能达到云发行版状态。为了找到正确的平衡点，组织需要对每个产品的生命周期阶段、增长潜力和将产品迁移到云所需的工作进行评估。基于这些综合评估，GBU 确定了每个产品的优先级和费用。
2. 确定开发组合
   如何在云资产就绪与开发满足市场需求的新特性和功能之间恰当分配工程资源以达到平衡，对 GBU 来说十分不易。
   
   GBU 并非难以就云转型的优先事项达成一致，但产品团队确实难以知晓应为云功能付出多少努力才能既改善客户体验和性能，又不替换客户所需的功能。云开发需要投资开发基础的运营功能，这可能会分散组织满足客户需要的新功能的精力。这些权衡使得我们很难弄清楚如何在云就绪和产品增强计划之间分配时间。
   
   为了应对这一挑战，GBU 依靠第 1 章中所述的云成熟度框架来深入分析每条路径所需的相对开发投资。然后，他们研究了每个潜在云转型阶段的投资回报率，并将该结果与开发新功能预期贡献的潜在收入进行了比较。这提供了一种通用评估框架，可用于确定正确的工作组合，并保持充分了解目标业务成果。

   ---

   Altair 选择了 Oracle 云基础设施上的高性能计算，性价比提高了 20%。

   “我们考察了外面的所有云供应商，发现 Oracle 非常专注于 HPC。他们的裸金属产品，我认为是业内首创，具有高速、低延迟的网络，这对我们来说非常重要。"— Altair 战略关系高级副总裁 Piush Patel

   ---

3. 了解组
   无论您的公司是拥有单个应用还是大型产品组合，在云迁移过程中都有许多因素需要跟踪和清点。为了充分理解需要进行哪些更改，您必须充分了解现有应用资源库的当前清单以及计划在云中使用的项目。如果您有许多应用要迁移，当前可能并没有清单，也可能您依赖有关特定应用状态的口头描述。即使公司只拥有单个面向客户的应用，也仍然需要清点整个应用堆栈，以确定在迁移到云时需要更改哪些方面。了解哪些需求在云中会发生变化及需要什么样的设计是记录转型所需工作的关键方面。
   
   每个应用实例所需的工作类型和工作量有所不同，具体取决于根据每个实例的特点（版本、硬件/平台依赖项、定制、客户访问模式等）。此外，应用数据可能分散在多个记录系统中。
   
   Oracle GBU 整合了 30 多个收购企业，组涵盖了 80 个数据中心和 12,000 多个应用实例。与这些实例相关的关键数据高度分散，而且在组件产品团队中也并不是按一致的方式进行管理。如果没有这些信息，他们就无法有效地组织和规划迁移人工。为了清楚地了解需要迁移的项目，GBU 不得不开展专门的数据收集和整合工作。

   ---

   “通过迁移到 OCI，Oracle GBU 团队将资本支出降低了 80%，将基础设施成本降低了 64%。”— GBU 云架构副总裁 Mike Prindle
   

   ---

4. 确定迁移工作的优先级并组织相应工作
   实际上，迁移工作负载可以采用多种方式 — 从复制现有 VM 的映像到安装新实例和复制数据；但所有方法都需要一定程度的技术投资或人工投入才能完成。迁移涉及的人工量和人工类型在组织组的各个产品环境中不断叠加，很容易变得难以应对。可用于完成迁移的资源是有限的，而这些资源通常还需要负责管理日常运营。

   ---

   OceanX 将商务智能系统从 Amazon Web Services (AWS) 迁移到 Oracle 云基础设施，性能提升了 3 倍。

   “我们需要数据平台以较低的成本实现扩展和高性能。将数据平台从 AWS 迁移到 Oracle 是 OceanX 最成功的迁移之一，再加上性能的大幅提升和实实在在的成本节省，这意味着整个项目取得了巨大的成就。最终，这使我们能够为客户提供一个帮助他们更快做出更明智决策的平台。"— OceanX 数据和分析副总裁 Vijay Manickam

   ---

   GBU 云转型需要执行 3,000 多个独立的迁移项目。这些项目最初是根据客户偏好（即根据客户的综合反馈确定迁移时间框架的优先级）或特定环境的迁移就绪程度来确定优先级的。最终，这种方法未能在迁移过程中带来增量业务收益。由于没有共同的优先级顺序或协调框架，GBU 发现迁移活动数量也不一致。高资源争用期和资源浪费期交替出现，给负责完成迁移工作的团队带来了沉重的负担。
   
   为了解决这些难题，GBU 建立了一个专门负责迁移的中央计划管理办公室和一个执行监督委员会，负责根据目标业务成果确定迁移的优先级并确定关键机会。
5. 管理组织变革
   云转型涉及的更改需要有人来负责知识、技能和流程的新领域以及文化变革产生的其他领域。应对这些人力资源挑战可能比管理云转型的技术部分更困难。为了解决此问题，Oracle GBU 大力开展培训，帮助现有团队转变为云团队。要解决何时引入新人才以及何时寻找其他机制来转变组织的问题，需要 GBU 根据主要职能领域和产品组进行劳动力评估，然后针对每个用例制定适当的改进计划。如果您的公司有多个应用要迁移，请考虑可以在什么位置建立覆盖所有产品的基础云知识，如安全性和通用 IaaS。

庆祝取得的成果

本手册根据 Oracle GBU 团队将 60 多个基于 SaaS 的应用迁移到 Oracle 云基础设施所积累的实践经验编写而成。这些应用为八个垂直行业的核心企业职能提供支持，在全球拥有超过 199,000 家客户。考虑周全、计划充分且执行良好的迁移带来了巨大的收益。

• 将 80 个数据中心整合为 11 个
• 资本支出降低了 80%
• 基础设施成本降低了 64%
• 软件供应商从 28 家减少到 10 家
• 软件费用减少了 42%
• 改为每天发布软件
• 预配时间减少了 98% 以上
• 计划停机时间减少了 98% 以上

虽然此 ISV 手册是根据我们 GBU 团队的经验编写的，但他们的实践只是几个大型 Oracle 云基础设施迁移项目中的一个。鉴于我们全部 SaaS 应用的收入和客户数量，Oracle 可被视为世界上规模最大的 ISV 之一，我们充分了解迁移过程。实际上，我们已将整个产品组合（包括 Oracle Fusion 云 ERP、Oracle Fusion 云 EPM、Oracle Fusion 云 HCM、Oracle 广告和客户体验以及 Oracle Fusion 云 SCM）迁移到 Oracle 云基础设施。这些迁移是我们称为 Oracle@Oracle 的转型计划的一部分。这是一个多年项目，涉及分布在数十个数据中心的数万个应用。

以下是这些迁移带来的一些好处。

• 基础设施 — 在我们的应用组合中实现了 99.99% 的可用性，成本节省了 30%，性能提升了 2 倍至 10 倍
• 财务 — 能够在不到 10 天的时间内结账和报告收益
• 人力资源 — 人才盘点周期缩短了 70%
• 供应链 — 供应链计划周期从 1 周缩短到 48 小时，改进幅度高达 71%
• 客户体验 — 营销活动前期准备时间从 4 周缩短到 5 天，改进幅度高达 82%
• 可持续性 — 2019 财年，Oracle 收集的停用设备有 99.4% 得到了再利用或再循环

与 Oracle 合作

我们帮助 ISV 扩大他们的潜在市场，同时提高他们的顶线收入增长潜力。要了解更多信息，请给我们发送电子邮件：oraclecloud-isv_ww@oracle.com。

要详细了解 ISV 为何选择 Oracle 云，请参考以下资源：

• isv.oracle.com
• 面向 ISV 的 Oracle@Oracle 计划
• 探索“云托管注意事项和模式”微型网站

---

Körber 将仓库管理系统整合到 Oracle 云基础设施上，运行速度提高了 40%。

“在评估不同的决策点时，OCI 对我们在进入市场战略方面所做的尝试具有重要意义。”— Körberö 北美销售和联盟高级副总裁 Rick Schrader

观看视频

---