展開您的雲端旅程

雲端轉型過程只要涉及應用程式，都會倍加複雜。然而，在這種複雜性中，雲端旅程還是有幾個定義明確的目的地。其中一個目的地在於打造目標應用程式的「雲端就緒」程度。為了在所需時間範圍內遷移到雲端，您希望/需要應用程式的雲端就緒程度如何？在本文中，我們將概述其中一些目的地，並重點介紹以我方歷程為基礎的最佳實踐和經驗教訓。成功關鍵在於提前明確定義您的遷移目標，以便就實現目標的方式做出最佳決策。您還會發現自己面臨著許多潛在的路徑。在遷移過程中，開發人員、交付團隊和高階主管將需要對繼續方式進行評估，並做出許多選擇。

我們建議重點關注以下技術和業務驅動因素，以制訂實現業務目標所需的決策。

延展性

雲端服務能提供大規模的運算能力，遠遠超出託管基礎設施的可行範圍，有助您的業務增長，以迎接市場機遇。雲端為本的基礎設施即服務 (IaaS) 和平台即服務 (PaaS) 有助 ISV 專注於利用現代組件，構建可延展的架構。轉型的另一個好處是，透過從管理和延展 IT 規模的過程中騰出內部開發團隊人手，即可將重點放在調整和優化性能上。

現代化

工具集、服務和架構的現代化程序，簡化了組件之間的集成，有助應用程式發揮雲端可用工具和技術的全部價值。上述工具的種類從基礎設施升級項目、自動化部署管道、到提高應用程式性能的集成機器學習模型不等。在市場快速且持續變化的情況下，應用程式必須保持動態，才能跟上發展步伐—故此，現代化流程最為重要。在某些情況下，服務可以完全重寫和重新命名，利用最新的技術堆疊來降低成本，或簡化服務選項。這種變化可以更新老化的產品並擾亂以授權產品為常態的成熟市場。在其他情況下可能會採用新方法對產品進行徹底檢修、改善服務，同時保持品牌知名度和客戶忠誠度。這不一定要對產品套件進行完全變更。

遷移到雲端，已成為廣泛推動現代化的觸發因素。正因為雲端能為您和團隊提供組織往常無法採用的服務、技術和專門技術，因此更有機會助您實現新目標，並帶來新功能。團隊可以在堆疊上「向上移動」，專注於全新而普遍適用的產品功能，而非與不同客戶的特定部署相關聯的自定義代碼。隨著服務佈建、產品更新和客戶支援的速度比以往任何時候都快，資源可以重新集中在開發新功能之上。這樣一來，雲端遷移正好為現代化活動的廣泛浪潮奠定基礎，革新產品升級的執行、以至客戶服務質量的各方各面。

---

「遷移到 Gen2 Cloud 使 Oracle 得以透過強大的 DevSecOps 模型來確保服務成功交付，以便支援客戶的業務轉型。我們現在每天都發佈軟體，並將佈建時間減少了 98% 以上。」—Oracle Global 業務單位高級首席產品策略經理 Karthic Murali

---

標準化

橫跨 IaaS 和 PaaS 的標準化流程，可為您節省開銷，並使團隊更加靈活，可互相替代。隨著組織發展規模，團隊將會採用成熟度水平各有不同的工具。只要將這些工具集整合到雲端服務中，即可大幅度消除 IT 管理此一層面的相關複雜性，讓工作任務標準運營實踐的開發和使用能投射到整個產品組合上。標準化還能令常規活動更簡單、更可預測，從而減少對基本任務的人手需求。以往因在各個應用程式之間導覽各有不同、且可能各不相容的程序而被綁定的資源，現能騰出，以專注於更重要的問題，包括為客戶開發新世代產品和服務。

值得注意的是，標準化令安全、風險、合規性和其他運營活動領域實施通用政策和實踐的過程變得更加簡單，團隊可輕鬆地將上述政策和實踐應用到現有產品和新產品上。事實上，應用程式均可繼承 IaaS 平台的許多內在功能，例如認可合規性認證等。

收入優化

收入優化可透過兩種主要形式體現。首先，最明顯的效果是成本有所降低。採用 IaaS 消除資料中心，不僅可將財務模式從資本支出轉變為運營支出，且通常更能顯著節省 TCO。另一種較不明顯的差別在於，透過對已遷移到雲端之應用程式組合中使用的技術堆疊進行合理化程序，也可節約成本。通用工具集有助創造機構知識，並消除與非標準化工具臨時培訓相關的費用。按照這些思路，將基礎設施視為代碼的通用工具集可實現自動化目標，最終節省時間和勞動力成本。最後，整體產品組合基礎領域 (例如安全性) 的專責團隊再也毋須為每個獨立的產品團隊培育專家。

其次，遷移到雲端後，您即可更快進入市場，最終得以優化收益，原因在於應用程式為雲端就緒或屬雲端原生，產品開發時間線通常都會縮短。只要能更快進入市場，即能更快實現收益。應用程式一旦為雲端就緒，便能在短短幾分鐘內部署到全球任何一處。

綜合而言，上文討論的原則應能令產品與服務架構得以標準化，同時提升部署速度和質量。規模源於重複模式的設計，有助於優化收入、更快實現價值，且能因而衍生重新集中資源、以提高客戶服務質量和完整性的能力。

---

WorkForce Software 將勞動力管理解決方案遷移到 Oracle Cloud Infrastructure，性能提升了 30%。

深入瞭解

---

在雲端實現價值的途徑

雲端運算可包括一系列 IaaS 和 PaaS 資源，以及多種軟體部署模型，範圍從存取裸機實例、集成容器化環境到功能齊全的服務堆疊不等。在最基本的層面上，雲端運算是指以核心 IaaS 資源替換物理基礎設施組件。

大多數企業應用程式最初都不是為雲端而構建。對於許多應用程式而言，要轉換成或迎合雲端模式，既耗時又困難。從時間和勞動力角度看來，重訂平台可能最為昂貴。因此，從頭開始為雲端原生主體設計有時更容易，也就不足為奇了。想及這一點，公司在考慮雲端遷移時，通常處於以下三種主要場景之一。

• 棄用傳統資料中心：運營資料中心耗價不菲—建築、人員、電力、冷卻、維護和升級，均只是日常職責中的一小部分。許多企業正在積極致力評估應用程式組合，從而減少或消除公司對資料中心的依賴，以便候選產品搬離實體物業。他們的首要任務是將應用程式移出託管或本地資料中心，以減少或消除資本支出。一般來說，企業會採用直接遷移策略，將應用程式按原樣遷移到雲端裸機伺服器或虛擬機器。
• 革新技術堆疊：在這種情況下，公司開始逐步對需要額外投資—但也有望帶來更高價值—的應用程式進行增量更改，例如以雲端為本的 Oracle Autonomous Database 取代 Oracle Database 的本地版本，而不對應用程式本身進行重大更改。此舉有時稱為「遷移改進」策略。
• 全力投入雲端原生：自下而上重新構建應用程式以實現雲端就緒，好處可能足以抵銷採用上述任一場景、而保留不甚成熟的應用程式所衍生的成本。雲端原生應用程式本質上屬於高度分佈式，通常使用「12 因素」原則構建，因而被設計為獨立於底層架構，即使其下層的基礎設施發生故障，應用程式也能繼續運行。簡而言之，企業值得評估這條路徑是否適用於目標應用程式，因為全方位遷移到雲端，肯定比遷移與底層基礎設施緊密耦合的應用程式更容易。

要瞭解 Oracle 如何定義雲端原生、雲端原生應用程式的起源、以及構建它們時應遵循的最佳實踐，歡迎閱讀此電子書。

---

要構想這些場景，另一種方法就是查看您可以採取的一系列行動，將企業應用程式遷移至更接近雲端原生架構，同時移入 Oracle Cloud Infrastructure。請參見下文的圖 1。

圖 1：雲端遷移變化與投資水平

圖 1 左側代表最少量變化、最短實現價值時間和最低初始投資額。隨著您向右移動，變化、投資額和時間水平通常會增加，但實現的價值也更大。此模型有助您制訂適用方法，預測在遷移階段要考慮進行的投資類型。請注意：因應用程式乃以多種方式構建，所以各場景不一定互相獨立，並會稍為重疊。

上述場景可成為評估現有成熟度水平和雲端轉型目標的關鍵參考點。當前狀態與目標狀態之間的差距，正好讓您粗略估計雲端轉型所需的技術及流程變更規模。在最完美的狀況下，雲端轉型應可令所有應用程式變遷為雲端原生交付模型。然而，面對資源與時間限制，很少有組織能在單一流程中將整體產品組合轉換為雲端原生模型。即使只是簡單的重訂平台工作，也會耗用大量資源—單是複製舊有功能，便已需要龐大投資。

因此，雲端轉型的問題癥結是在雲端最佳成熟度水平 (應用程式上圖所示雲端託管至雲端原生圖譜中的位置) 與重新建構產品及相關業務流程所需之工程投資之間做出權衡。在此階段，關鍵步驟是識別每個應用程式的當前和目標成熟度水平，從而粗略估計彌合差距所需的開發投資。

應用程式成熟度水平如在遷移過程中有所改變，其運作模式和期望也要因而改變。成熟度水平變化，會影響支援服務所涉的團隊、流程和策略。

 

評估雲端技術就緒程度

對於目標應用程式—又或提供多個 SaaS 為本應用程式的公司整體應用程式組合—的技術性理解，正是瞭解轉型要求和從屬因素的關鍵。在此階段，重點關注範疇應為識別應用程式所需功能，以及其與這些從屬因素的關係，以便推動遷移活動的相對時間安排，並確定重點關注領域。相關評估應涉及三個關鍵方面。

1. 基礎設施要求：雲端會將軟體與其底層硬體或操作環境解耦。成熟度高的應用程式在本質上獨立於所處環境，僅依賴通用基礎設施資源，例如 CPU 或 Kubernetes 集群，並可在雲端輕鬆擴展規模。成熟度低的應用程式依賴系統所提供的特定設備、組件或環境，例如託管基礎設施或其他專用系統。您必須先記錄應用程式對雲端基礎設施組件和配置的硬性依賴程度，並最終予以消除。與底層基礎設施相關聯/耦合的自定義項目 (由您或客戶建立) 並不罕見。
2. 服務組件：雲端會以獨立於應用程式運行和交付的獨立服務形式，提供支援功能。成熟度高的應用程式環繞離散組件構建，在整個堆疊中依賴性最低，可讓您進行針對性更改和升級，並最大限度延長正常運行時間。成熟度低的應用程式以緊密耦合的大型組件構建而成，各組件之間的相互依賴性高，必須以單一實體形式進行管理。您必須妥為記錄各應用程式的上述服務關係。
3. 運作就緒度：雲端改變了技術架構，以及工作流程、技能組合、可用工具和運營模式。成熟度高的應用程式已能像雲端應用程式一樣運行，並使用在雲端運作良好的流程、標準和工具集。成熟度低的應用程式會認為雲端缺少關鍵的支援服務，而支援團隊具備的技能組合不適用於雲端工作，又或使用程序會因遷移到雲端而中斷。

展開遷移程序時，透過根據上述因素來評估應用程式成熟度，即可進行適當規劃，避免因下游意外而造成延遲、增加成本並錯失目標。正因為當前生產環境、支援服務套件和目標雲端環境都會在整個過程中持續蛻變，遷移過程的複雜性不容低估。只要探索服務與應用程式之間的聯繫，不僅有助提前進行智慧規劃，更可令規劃項目靈活應對遷移過程中不可避免的變化。這項評估如能有效記錄，應會為遷移過程訂出清晰的待辦事項列表，確保預計遷移時間表與不斷變化的路線圖始終保持一致。

---

Zoom 在 Oracle Cloud Infrastructure 上快速擴展並激活數百萬個並發會議。

深入瞭解

---

財務目標

一如任何 IT 計劃，雲端轉型也需要一系列投資，才能全面實現價值—尤以目標應用程式乃為本地託管模型構建更甚。如應用程式獲視為值得遷移到雲端，將逐漸變為雲端原生，又或最終退役。然而，初始目標通常都會是讓應用程式進入雲端發佈狀態。

要將應用程式從當前狀態變為雲端發佈狀態，所需要素正是一系列決策與初始投資的結晶品。您是否打算簡單地將應用程式提升並轉移到裸機伺服器 (在這種情況下，大部分投資會在雲端基礎設施上)？又或者，您是否計劃在遷移之前令應用程式變得雲端就緒 (在這種情況下，部分投資就要將應用程式堆疊的部件遷移到雲端為本模型，例如將資料庫從本地遷移到 DBaaS 或 Oracle Autonomous Database)？如果您已創建硬編碼的自定義項目，以啟用客戶特定功能，則這些項目必須針對平台組件封裝、並透過 API 以產品化功能交付的模型歷經重構。硬體或平台從屬因素須予以移除，方可在雲端擴展高度分佈式應用程式的規模。瞭解這些投資項目，正是規劃和實現雲端遷移相關財務目標的關鍵因素。

初始投資涉及進行我們剛探討之雲端遷移階段相關產品變革所需的開發時間與人力。然而，額外費用也必須考慮在內。在轉型期間，您的組織可能要面對的各類支出包括：

• 開發投資：重新構建產品或為遷移工作創建加速器所需的開發勞動力，包括支援資料庫遷移和應用程式佈建等活動的自動化流程
• 遷移執行：佈建新資產、遷移現有環境和資料，以及淘汰舊有清單所需的人力資源
• 基礎設施採用：IaaS 升級衍生的訂閱費用—此程序會漸趨穩定，惟在遷移期間也會帶來新的增長項目
• 廢棄的基礎設施：在遷移過程中暫時未能棄用的資料中心及當中衍生的資本支出折舊成本，須一直承擔至其能被消除或抵銷為止
• 勞動力轉型：培訓、教育或重組現有團隊，又或搜羅具備所需雲端技能組合之新資源的相關費用
• 客戶轉型：與新模型無法支援的環境特點或服務條款變更相關的成本，包括新開發項目、激勵措施、合同項目的重新談洽或客戶流失

上述各項成本或多或少都是 IaaS 轉型過程的必要組成部分，各以不同形式對您的成本概況帶來影響。舉例來說，開發投資和遷移執行費用可能屬於一次性費用—即使與這項工作相關的資源或為固定資源亦然。新基礎設施的採用將導致個別時期的支出錄得淨增長，直至棄用基礎設施所涉的支出已消除為止。部分勞動力和客戶過渡支出 (例如培訓或遷移獎勵) 都是一次性費用。勞動力擴張或客戶合同變化等其他因素則可能衍止新的恆常支出。

只要瞭解上述動態因素如何隨著時間推移而發揮作用，即有助您的組織為雲端轉型做好準備，並設定合理期望。如果您的組織熱衷於雲端的龐大優勢，但對轉型風險缺乏清晰瞭解，就可能會為前期初始支出增加而驚訝不已，尤以遷移、基礎設施重疊和預付轉型成本最難令人接受。設定合理期望，並保持遞進過程清晰可見，就是組織轉型期間維持一致性和紀律性的基本要素。

雲端遷移清單

雲端遷移清單是您遷移到雲端時必不可少的要素。什麼是雲端遷移清單？簡而言之，這是您組織全部資產的清單，另加說明各項資產的相關關鍵資料。清單列出要遷移的目標應用程式及其一切從屬因素。您用哪種媒介來擷取資料都無關緊要；而正因為資料一般是由公司內多個部門分別蒐集，所以用上多種工具的情況也不少見。所需資料通常分散在一系列生產、銷售和運營資料庫中。例如，配置管理資料庫或會詳盡追蹤技術從屬因素及資產位置，甚至細緻到實體伺服器及機架位置。可是，此資料庫不包含業務與客戶考慮因素，而這些因素對於決定通知客戶轉型事宜的時機與方式至關重要。相關資料一般包含在專為運營與支援利益相關者設計的存儲庫中。此外，收購、特殊用例和產品倉庫或意味著資訊進一步分散於多個存儲庫中。

遷移清單的主要目的是讓您集中一覽管理雲端遷移所需的因素。例如：資產是什麼？資產在哪裡？資產支援什麼產品？資產有什麼作用？資產支援哪些客戶？

我們從一開始就應意識到，藍圖是一份「活文件」，會隨時日而蛻變，所以必須靈活—尤對擁有多個應用程式或應用程式版本的公司更甚。清單將隨著新問題和新需求浮現而發展；就連底層雲端基礎設施也可能在遷移過程中發生變化，進而令清單再次演變。遷移清單應盡量多加擷取可用資料，以便您開始初始規劃，並隨著轉型過程揭示新需求而添加細節層。

管理遷移清單本身就是一項跨職能專案，必須平衡詳細資料需求與資料蒐集工作，當中也包含識別從屬因素、約束和資源的元素，而這些元素將影響時間表和速度，例如精細技術規格、架構方針、客戶要求和資料傳輸路徑。如資訊太少，清單將無甚作用；如資訊太多，維護工作即成負擔，而相關資料也會很快過期失效。

我們推薦以下遷移清單框架，作為雲端遷移的起點。

由遷移清單到運營清單

雖然我們專注於遷移清單，但雲端遷移最終還是會帶來兩個挑戰，最直接的是因而衍生規劃、確定優先次序和追蹤遷移活動的需求。然而，遷移本身會強行令日常運營追蹤所需的資料發生變化。舉例來說，有關物理伺服器和機架的遷移後配置詳情將變得無關緊要—以至於關乎個別實例的資訊重要性也會減低。與此同時，總體使用情況和資料出口等指標可能變得至關重要，尤其是在組織採用自助服務模式時更甚。

要建立遷移清單，應由轉用這些以雲端為中心的全新資料模式和流程開始。雖然創建清單和遷移應用程式這兩項挑戰並駕齊驅，卻不應獨立處理，應以遷移工作為主導，而這也可能是組織第一次為資產創建詳細統一的視圖。在這個變革性時刻，適用於遷移後全新清單視圖的範本將會形成。如上所述，遷移清單須具有靈活性和適應性。如果管理得當，遷移清單將在遷移後演變成有價值的 Inventory Management 工具。

試行通往雲端的道路

設計託管 SaaS 應用程式的基礎設施

作為提供 SaaS 為本應用程式的 ISV，您需要安全、可擴展的企業級基礎設施，用以託管服務，並以隔離方式管理客戶。下文圖 3 的參考架構提供歷經驗證的框架，當中包含最佳實踐，可讓您在 Oracle Cloud Infrastructure 上託管 SaaS 應用程式。

在此參考架構中，您會部署和管理多個隔離應用程式實例。每項部署都針對特定租戶，而這些個別租戶應用程式實例則透過共用管理層進行管理。

您可以選擇從單一代碼庫構建所有租戶應用程式實例，又或者為每個租戶提供應用程式的自定義版本。這種模式非常適合需要完全隔離應用程式環境的 SaaS 客戶。

圖 3：OCI 上 SaaS 應用程式的最佳實踐參考架構

有關上述參考架構的更多詳情，請瀏覽 Oracle Architecture Center。此外，我們創建了 Terraform 為本工具，協助您為四個租戶部署架構，另有步驟指南供您參閱。最後，我們一致建議遵循 Oracle Cloud Infrastructure 最佳實踐指南，其為以下四個常見的業務目標提供指引：安全性和合規性、可靠性和彈性、性能和成本優化，以及運營效率。

除了架構變化之外，您還須考慮服務堆疊在雲端中將如何變化。用於監控的 Core Tool 集、網路管理、又或部署在專為本地架構開發之舊有環境的安全性項目，最終都會針對雲端而蛻變。遷移到雲端，讓您有機會擴充這些工具的適用範圍。雲端為本工具會在整個堆疊中提供監控功能，而非主要監控端點。有時，雲端服務供應商會在核心功能之上提供雲端為本或混合型監控工具。在採用 Oracle Cloud Infrastructure 的情況下，本機監控、標記和審計功能組合就可提供監控全面服務堆疊的能力，並能時常自動修復指定規範之外的異常現象。如果您現時在本地使用第三方監控工具，這些供應商也可能會提供混合型或雲端為本工具。

---

Cisco Tetration 將核心應用程式遷移到 Oracle Cloud Infrastructure，性能提升了 60 倍。

提供驗證 (或挑戰) 技術可攜性假設的背景環境—尤以技術向來於相同環境下運行的情況更甚，有助團隊瞭解自己是否準備好遷移，並識別遷移所需實施的變動。

讓團隊有機會確認應用程式/資料庫與目標環境服務集成的就緒程度，瞭解現時須實施的變動，以及應用程式與目標服務環境兩者均準備好進行遷移的時機。

讓團隊有能力為目標環境進行構建，並創造立足點，日後將成為產品組合其他部分遷移至新服務與新環境的跳板。這樣一來，團隊即可認清產品組合的策略性目標。

---

Manhattan Associates 將供應鏈解決方案遷移到 Oracle Cloud Infrastructure，比之前的雲端解決方案節省了 50% 成本。

訓練：試點計劃會測試現有技能，揭示組織對技術遷移工作的就緒程度。管理層應使用試點計劃來評估技術熟練程度，瞭解哪些工具和能力最需要學習，並規劃如何在這些關鍵領域快速為現有人員發展技能 (或聘用具備相關技能的人才)。

協同合作：試點計劃會揭示開發、運營和支援團隊可如何以不同方式協同合作。管理層應確保這些團隊在試點計劃期間切實合作，提出新要求，並瞭解如何在這種新環境中運營。

改變的慾望：試點計劃讓公司有機會尋找影響更廣泛遷移進程的文化障礙。如果單一組別在試點計劃中遇到問題，即表示公司大範圍也會出現同樣的反應。試點計劃正是管理層識別問題、部署培訓和調整計劃的好機會，將組織面臨的實際情況納入考慮。

順利遷移的關鍵，在於奠定堅實的基礎。遷移過程的第一階段將推動開發核心服務和平台，並隨繼續遷移而逐步擴展。最終，這些核心功能須擴充規模，以支援整體遷移組合。因此，我們不僅要確保初始雲端版本發佈成功，還要為所有後續版本和升級項目開闢跑道。

適應組織變革

設計託管 SaaS 應用程式的基礎設施

在組織交付模式和客戶關係變化下，您可能需要嶄新技能、知識、業務流程和思維方式。這些變化可對組織整體帶來廣泛影響—正因如此，文化變革常被視為雲端轉型中最困難的範疇。

單是這些變化規模之大，已足以構成「雲端轉型須大範圍重組結構，替換具備雲端經驗與專門技術的人手」此一印象。雖然「內部職能專業化變動」及「聘請專注雲端技能組合的人才」均為雲端轉型的主要組成部分，但您的確無法承擔既定程序、動向和貢獻者流失所帶來的後果，尤以上述因素都是您迄今成功的關鍵為甚。您必須在組織變革速度、以及其對持續業務和客戶體驗的潛在干擾之間取得平衡，這一點至關重要。要保持這種平衡，就須重新調整職涯發展能力的結構變化，讓現有員工順利過渡到新的運營模式。

要將經營已久的軟體業務轉型至雲端交付模式，在假設、技術知識和標準操作流程方面都會發生巨大轉變。儘管所需變更規模可能令人生畏，但我們的經驗表明：保留和投資現有團隊，一般比嘗試全面換聘雲端專家更理想。如組織要規劃同類轉型，不妨一覽我們的 GBU 組織如何開始對變革需求進行自下而上的分散式評估，也就是允許每個團隊創建各自的遷移清單和服務堆疊路線圖，從而確定各自控制範圍內所需的步驟。此方針可讓團隊保持計劃與有形變革驅動因素一致，同時避免對潛在需求進行高層次假設。

---

8x8 透過遷移到 Oracle Cloud Infrastructure，得以與世界保持聯繫，將成本降低 80%，並改進服務。

觀賞影片

---

商業影響

成功的雲端轉型與組織變化相輔相成。要從原先主要屬託管或內部部署的產品組合轉型為雲端為本業務，您的組織與客戶互動的方式須落實根本性的轉變。然而，既定業務實踐和假設的變化程度，大多取決於雲端轉型期間施行的產品變革範疇。

即使在變化度低的場景中，轉用 IaaS 也會推動業務流程轉變。在這種情況下，我們的 GBU 確認了兩個關鍵變革機會。

1. 運用將短期波動和長遠預期均納入考慮的運營支出導向預測模型，取代資本支出密集型物理基礎設施管理機制
2. 為現已毋須承擔傳統職責的安全和合規團隊轉型，專注於提供服務組件

只要組織能應對上述變遷—以及應用程式內的技術變化—就能更充分發揮雲端遷移的全部潛力。

客戶聯盟

要從採用塑料薄膜熱縮包裝的實體產品、以至託管產品轉型為真正雲端服務，將會是您與客戶共同經歷的旅程。事實上，正是這種服務模式的改變，才將雲端與之前所有託管模式區分開來。從可擴展性、正常運行時間到彈性雲端服務，每項變化都會影響客戶體驗。在某些情況下，客戶可能會要求—甚至促使—您轉用全新交付模式。在另一些情況下，客戶對產品特質、功能和成本的期望可能正在變遷，只能透過雲端為本交付方式予以滿足。

隨著您開始讓客戶參與雲端策略，就必須為以下兩種觀點做好準備：對發展路線的興奮，以及不願棄用熟悉事物的抗拒感。要應對上述觀點，您應與客戶清晰有度地溝通，指明工作方向，以免對方迷失於技術細節之中，或因而引發危險信號。這正是讓組織內部的客戶專責團隊參與進程的關鍵時刻，以確保隊員瞭解現正進行的工作、業務所做的投資，以及產品與交付的預期結果。為此，您的客戶專責團隊也須出一分力，將這種變遷轉化為強而有力的服務條款，增強客戶對服務的信心。

對於即將使用雲端服務的客戶而言，場景可能稍顯複雜。有一部分客戶會要求使用雲端服務，因為他們深明 SaaS 在效率和敏捷度方面可帶來的好處。然而，隨著雲端或 SaaS 選項已成為「賭注」，客戶須瞭解令供應商服務各有不同的功能和服務級別協議，而不僅限於雲端本身的價值。

事實上，並非所有客戶都渴望轉用雲端服務。具體而言，託管或管理式服務模型的現有客戶可能對現狀心滿意足；如果他們擁有與雲端交付不一致的定制服務組件或非標準環境與存取模型，就更是如此。即使客戶明知轉用雲端服務裨益不淺，也可能會對交付條款或遷移雲端環境對服務所衍生的干擾感到不安。

要讓客戶放心，需要營銷、銷售、支援和客戶成功團隊互相協調，一致溝通。在最理想的情況下，客戶根本不會意識到工作負載已遷移，在喜見性能改進的同時，對已實施的變化毫不察覺。現實是，要將服務遷移到雲端，通常須進行升級和停機，並有機會要更改服務條款或可用功能。引導客戶度過上述階段—同時符合整體轉型時間表—是一項複雜壯舉，不僅講求瞭解變革優點，更須認同現正實施的變化，並在有機會影響客戶業務的遷移步驟上保持一致。

---

CMIC 將建築企業軟體遷移到 Oracle Cloud Infrastructure，部署速度提升了 10 倍。

觀賞影片

---

只要客戶對雲端轉型帶來的好處和變化表達支持，組織所需採取的最後一個步驟就是將客戶的工作負載實際轉移到新環境中，挑戰在於決定最佳遷移時間，並對新環境進行驗證測試。即使客戶接受一段時間的停機，也還是會對實際停機時間抱持強烈意見。

雖然客戶偏好對您很重要，但您也必須平衡許多其他問題。規劃遷移的過程，涉及多種因素的權衡，當中包括產品或服務的技術屬性、所有客戶偏好的協調、內部資源限制，以及整合/消除現存舊有資料中心或終止已淘汰產品線等業務目標。為了平衡這些相互衝突的優先事項，您應將客戶專責團隊納入遷移規劃活動中，讓他們代表市場期望表達關鍵想法。

您的組織除了須為長時間投資和遷移、以及雲端交付模型的持續技術和業務流程變化就緒，也要為吸引客戶參與遷移的方式、以及產品和客戶關係的新現狀做好準備。

我們 GBU 回應上述需求的方法，是首先審視轉型事宜在技術、運營和交付承諾方面對客戶帶來的影響，隔離須對商業關係特別關注、進行互動或作出潛在變動的範疇。客戶專責團隊的準備工夫也以類似觀點為基礎，涉及產品、運營、策略和其他團隊之間的協作，以達致一致雲端素養，同時應對特定產品和客戶的變化。

這項工作不僅在於為客戶專責團隊做好與客戶互動的準備。只要跨職能核心領導層聚首一堂，在客戶互動上保持一致，就能創造寶貴機會，將以往主要由技術主導的計劃擴展為更廣泛的舉措，重新審視我們解決方案的核心價值，重新闡明產品與別不同之處，並規劃在市場中保存和增長價值的最佳途徑。

提前準備

設計託管 SaaS 應用程式的基礎設施

在本手冊中，我們根據自己於遷移託管在數千個實例中的 60 多個 GBU 應用程式期間所汲取的經驗教訓，提供最佳實踐指引。以下，我們總結了整個旅程中面臨的五大挑戰，相信適用於要將應用程式遷移到雲端的任何組織。

1. 確定遷移前的開發工作
   要為雲端發佈準備已確立的應用程式，可能涉及大量投資，尤以將產品帶入雲端原生狀態為甚。投資雲端原生應用程式原則，固然可讓您從雲端獲享最大益處，惟也消耗大量時間和開發資源，才能達致最終狀態。產品的雲端就緒需時越長，您就越遲才能獲享雲端遷移的固有遞增優勢，並可能延長面臨舊有環境常見風險的時間。與此同時，並非所有產品都能同等獲益，一切取決於其生命週期階段和客戶狀況。充分瞭解並記錄遷移前要進行的開發工作量，正是成功遷移的關鍵。
   
   GBU 應用程式群多種多樣，當中包括處於各個雲端成熟度水平和生命週期階段的產品。雖然所有應用程式都須遷移到雲端，但雲端發佈前應進行多大程度的產品變更，卻始終令人苦惱。要達致完美平衡，組織須評估各項產品的生命週期階段、增長潛力及「上雲」工作量。根據上述綜合評估結果，GBU 得以確定每項產品的優先次序和可行支出水平。
2. 確定開發組合
   公司要為雲端投資就緒度投入多少工程頻寬？為應對市場需求開發新特質與功能，又要投入多少工程頻寬？這正是 GBU 難以達致平衡的一點。
   
   GBU 在雲端轉型優先次序方面不乏一致性，惟產品團隊確實難以理解應投入多少心力，開發有力提升客戶體驗與性能、而又不取代客戶所需特質的雲端功能。雲端開發講求對底層運營能力進行投資，而這些運營能力有機會分散組織迎合客戶對新功能之需求的能力。權衡各方，實在難以釐清如何於雲端就緒度與產品強化計劃之間分配時間。
   
   為應對此項挑戰，GBU 仰賴第 1 章探討過的雲端成熟度框架，深入瞭解每條路徑所需的相關開發投資。然後，團隊審視了每個潛在雲端轉型階段的投資回報率，並在該結果與新功能開發預期的潛在收益貢獻之間權衡輕重，從而訂出通用評估框架，可用於確定正確的工作組合，保持目標業務成果清晰可見。

   ---

   Altair 選用 Oracle Cloud Infrastructure 的高效運算功能，將性價比提高了 20%。

   "透過遷移到 OCI，Oracle GBU 團隊成功將資本支出降低了 80%，並將基礎設施成本降低了 64%。"—GBU 雲端架構副總裁 Mike Prindle
   

   ---

3. 優先考慮和組織遷移工作
   實際上，您可透過多種途徑遷移工作負載，從複製現有 VM 影像、安裝新實例到複製資料皆可，惟上述各項均講求一定程度的技術投資或人力資源，才能完成。各項工作在組織產品群的每個產品環境中倍增加乘，很容易令遷移所涉的人手量和種類大幅增加，變得難以承擔。現時可用以完成任務的資源有限，而且通常還須用於管理日常運營。

   ---

   OceanX 將商業智慧系統從 Amazon Web Services (AWS) 遷移到 Oracle Cloud Infrastructure，性能提升了 3 倍。

   

   第 6 章：成果及開展進程

   慶賀成果

   本手冊根據 Oracle GBU 團隊於遷移 60 多個 SaaS 為本應用程式到 Oracle Cloud Infrastructure 期間所汲取的經驗教訓為基礎。上述應用程式支援全球八個產業和超過 199,000 名客戶的核心企業職能。設計細緻、計劃完善、執行良好的遷移計劃，可帶來可觀的收益。

   • 將 80 個資料中心合併為 11 個
   • 將資本支出降低 80%
   • 將基礎設施成本降低 64%
   • 軟體供應商從 28 家減少到 10 家
   • 將軟體支出減少 42%
   • 轉為每日發佈軟體
   • 將佈建需時減少 98% 以上
   • 將計劃停機時間減少 98% 以上

   雖然此 ISV 手冊乃以我們 GBU 團隊的經驗為基礎，但團隊的工作只是 Oracle Cloud Infrastructure 數次大型遷移之一。如將所有 SaaS 應用程式的收益和客戶數量納入考慮，Oracle 可被視為全球最大型 ISV 之一，對遷移過程深有瞭解。實際上，我們已經將整體產品組合 (包括 Oracle Fusion Cloud ERP、Oracle Fusion Cloud EPM、Oracle Fusion Cloud HCM、Oracle Advertising and CX 以及 Oracle Fusion Cloud SCM) 遷移到 Oracle Cloud Infrastructure。上述遷移行動是名為 Oracle@Oracle 的轉型計劃的一部分，此計劃橫跨多年，涉及分佈在數十個資料中心的數萬個應用程式。

   以下是我們從上述工作中觀察到的一些好處。

   • 基礎設施–我們各個應用程式組合均達致 99.99% 可用率，同時節省了 30% 成本，性能提升 2 倍至 10 倍
   • 財務–10 天內喜獲結帳和報告收益的能力
   • 人力資源–人才審核週期縮短了 70%
   • 供應鏈–供應鏈規劃週期從 1 週縮短至 48 小時，改進率達 71%
   • CX–活動前導時間從 4 週縮短至 5 天，改進率達 82%
   • 永續性–Oracle 在 2019 財年重用或回收了 99.4% 的退役設備

   與 Oracle 合作

   我們主力協助 ISV 擴大目標市場，同時增加收入增長潛力。歡迎發送電子郵件至：oraclecloud-isv_ww@oracle.com，瞭解更多。

   如欲詳細瞭解 ISV 選擇 Oracle Cloud 的原因，請參閱以下資源：

   • isv.oracle.com
   • ISV 專用 Oracle@Oracle 專案
   • 探索 Cloud Hosting Considerations and Patterns 的微型網站

   ---

   Körber 將倉庫管理系統整合到 Oracle Cloud Infrastructure 上，執行速度提高了 40%。

   觀賞影片

   ---