SaaS 遷移

許多採用 SaaS 的提供商都從傳統安裝的軟件模型遷移到 SaaS（前面描述）。對於這些提供商而言，對 SaaS 的核心原則保持良好的一致性尤為重要。

在這裡，再次，可能會對遷移到 SaaS 模型的含義存在一些混亂。例如，有些人視圖遷移到雲中作為遷移到 SaaS。其他人認為將自動化添加到其安裝和佈建過程中，以實現遷移。

可以公平地說，每個組織都可能從不同的位置開始，有不同的遺留考慮因素，並且可能面臨不同的市場和競爭壓力。這意味著每次遷移都會有所不同。

儘管每個路徑都不同，但在某些區域中，圍繞塑造遷移策略的核心原則存在斷開連接。圍繞概念和原則進行良好的一致性可能會對 SaaS 遷移的整體成功產生重大影響。

根據先前概述的概念，應該清楚的是，轉向 SaaS 始於業務策略和目標。這一點可能會迷失在遷移設置中，其中存在盡快進入 SaaS 的壓力。

在此模式下，組織通常主要是將移轉視為技術練習。現實情況是，每個 SaaS 遷移都應該從清晰的目標客戶、服務體驗、營運目標等方面開始。更清楚地關注 SaaS 業務需要的外觀，將對將解決方案遷移到 SaaS 所採取的形狀、優先順序和路徑產生深遠影響。

從遷移一開始就擁有這個清晰的願景，為您遷移到 SaaS 的過程中如何遷移技術和業務奠定了基礎。當您在這條道路上展開時，請專注於那些可以告訴您最有關您要去哪裡的問題。

下表提供技術與業務移轉心態的對比性質檢視。

表 1 — 技術優先與企業優先移轉

科技第一的心態	企業第一的心態
我們如何隔離租戶數據？	SaaS 如何幫助我們發展業務？
我們如何將用戶連接到租戶？	我們的目標是哪些區段？
我們如何避免嘈雜的鄰居條件？	這些區段的大小和輪廓是多少？
我們如何做 A/B 測試？	我們需要支援哪些層級？
我們如何根據租戶負載進行擴展？	我們的目標是什麼服務體驗？
我們應該使用哪個帳單提供商？	我們的定價和包裝策略是什麼？

在左邊是可能的外觀範例。工程團隊非常專注於追求對任何 SaaS 架構都很重要的經典多租戶主題。

問題在於，左側許多問題的答案通常直接受右側問題的答案的影響。對於任何正在尋求遷移的人來說，這一點不太可能是新的。然而，現實情況是，許多組織開始追逐運營和成本效率作為他們的第一步，假設業務位將自己工作出來。

在此遷移策略中，您的舊環境如何演變為適合 SaaS 模型，也可能會產生混淆。這也是一個有許多遷移到 SaaS 選項的領域。但是，我們通常會主張任何遷移的共同價值體系。

在我們之前對 SaaS 原則的討論中，我們概述了用於描述 SaaS 環境的不同模式和術語。跨越所有這些解決方案的一個共同主題是擁有圍繞您的應用程序的共享服務的想法。身分識別、入職、指標、帳單 — 這些都稱為任何 SaaS 環境的核心元素。

現在，當我們看到遷移時，您會發現這些相同的共用服務在任何遷移故事中都扮演著關鍵角色。下圖提供移轉環境的概念檢視。

遷移至 SaaS

此圖表代表任何移轉路徑的目標體驗。它包括之前描述的所有相同共用服務。中間是應用程式的預留位置。

關鍵的想法是，您可以在此環境的中間著陸任意數量的應用程序模型。您在遷移的第一步可能會讓每個租用戶在自己的筒倉中執行。或者，您可能有一些混合架構，其中元素是孤立的，而其他位元的功能則透過現代化的微服務集合來解決。

您一開始將應用程式現代化的程度會根據舊有環境的性質、市場需求、成本考量等而有所不同。沒有改變的是這些共享服務的引入。

任何 SaaS 遷移都需要支援這些基礎共用服務，讓您的企業能夠以 SaaS 模式運作。例如，應用程序體系結構的所有變化都需要 SaaS 身份。您需要承租人感知作業，才能管理和監控 SaaS 解決方案。

將這些共用服務放在移轉的前端，可讓您向客戶呈現 SaaS 體驗，即使基礎應用程式仍在每個租用戶的完整堆疊中執行也是如此。

一般目標是讓您的應用程式在 SaaS 模型中執行。然後，您可以將注意力轉向應用程序的進一步現代化和改進。這種方法還允許您以更快的速度移動業務的其他部分（營銷，銷售，支持等）。更重要的是，這可讓您開始參與並收集客戶意見反應，這些意見反應可用於塑造持續的環境現代化。

重要的是要注意，您所設置的共享服務可能不包括您最終需要的每個功能或機制。主要目標是建立移轉一開始所需的共用機制。這可讓您專注於系統元素，這些元素對於應用程式架構的演進和營運演進至關重要。