業務系統遷移規劃

㈠ 系統遷移如何進行

由於各種原因，越來越多的企業面臨著ERP系統替換問題，而在系統更換前，現有ERP系統中有效數據的倒入，對ERP系統切換以及新系統正常運行有著重要影響。數據遷移稍有不慎，便會造成新系統不能正常啟動，而遷移過多垃圾數據，將有可能使新ERP系統運行緩慢、甚至癱瘓。 因此，在進行新舊ERP系統替換過程中，企業CIO們除了要對新ERP系統進行項目需求、規劃、實施，解決用戶應用習慣以及開發相關介面外，還要認真考慮歷史數據的導入問題。尤其是在現有ERP系統運行數年，積累了上百GB數據的情形下，CIO們更需要仔細衡量歷史數據的有效性和對新系統的影響以及數據遷移的方式和方法。而這決不僅僅是異構資料庫、不同存儲設備之間數據遷移那麼簡單，它更像是對以前ERP數據以及ERP業務流程的重新審視和考核。 解決好ERP替換過程中的數據遷移問題不僅是新ERP系統成功上線的重要前提和保障，同時也是對已有ERP系統的一次全面總結和反思。 數據遷移切忌完整 對於傳統數據遷移或資料庫更替問題，企業CIO或資料庫開發維護人員考慮得更多的是數據遷移的完整性和可靠性，但是對於ERP替換過程中的數據遷移而言，保持數據的完整性卻是大忌。因為新舊ERP系統替換過程中，歷史數據的遷移絕對不是孤立存在的。它雖然看似一個簡單的資料庫更替問題，但是，它涉及到從一個ERP系統到另一個ERP系統，從一個應用模式轉向另一個應用模式的轉變，這更多的是ERP本身的問題。 業內人士指出，對於同一廠商不同ERP產品替換，由於系統是在同一資料庫基礎上開發，而且存儲邏輯或方法基本相同，所以舊系統中的數據利用率會很高，可以達到70%;而對於不同廠商的ERP產品替換，其舊數據利用率不超過10%，而且舊系統中數據利用得越多，新系統的負擔就越大、性能越差、信息越不準確，這與簡單的資料庫遷移強調完整性有著本質區別。 而且，雖然用戶選擇的ERP廠商所提供ERP產品的模塊可能相同，但是在相應實現方法、資料庫記錄的表結構以及ERP工作流程方面卻是大相徑庭，因此，ERP替換過程中的數據遷移不僅僅是數據的導入、導出問題，更是系統的更換、工作方式的改變。 所以，在進行ERP數據遷移時，企業CIO們不應簡簡單單地把ERP數據遷移看作是單一的資料庫問題。企業CIO們首先應根據新ERP系統的需求設立項目目標，針對新的模塊確定所要遷移的有效數據，其次才是ERP數據遷移過程中的技術實現問題。 雖然，數據遷移問題往往是在對新ERP系統進行項目需求、項目規劃、項目實施、相應介面開發和人員培訓之後，但是用戶在與新ERP廠商簽訂合同、進行項目需求調研、規劃時，就應該與相應ERP軟體廠商共同探討如何選擇有效的歷史數據以及如何對舊ERP系統中的歷史數據進行導入等問題。 神州數碼管理系統有限公司易飛服務部經理梁景茹建議，用戶最好能請曾長期應用舊系統的人員參與到數據遷移小組中，以了解新舊系統的資料庫和有關欄位，避免數據欄位對應錯誤。SAP咨詢部中國區技術咨詢經理趙旭民甚至建議，用戶最好能請到原ERP系統的開發、設計人員來幫助自身共同做好數據的遷移工作。 對於ERP替換過程中的歷史數據，並不是所有的數據都可以平滑過渡到新的ERP系統之中，尤其是對不同廠商的ERP系統替換，原有數據的利用率非常低。因此用戶和實施顧問更應該關注數據的有效性，即搞清到底哪些數據對於新系統功能模塊來說是有用的。 其次，新系統自動生成，是指在ERP系統切換後，通過新ERP系統的相關功能，或為此專門開發的配套程序生成所需要的數據。這種方法通常需要根據已經遷移到新系統中的數據來生成所需的信息。其實施的前提是，這些數據能夠通過其它數據產生。 工具遷移與手工錄入相結合 對於工具遷移而言，首先，各家ERP廠商多提供部分自主開發的遷移工具。北京時空公司相關負責人介紹，該公司就自主開發了專門解決數據遷移的「升級工具」。其可以從SQL Server 平台的數據源中抽取數據，完成轉換和清洗，裝載到各種系統裡面，更復雜轉換可以通過編寫腳本或結合SQL語言的擴展來實現，並且該「升級工具」提供調試環境，可以極大地提高開發和調試抽取、轉換程序的效率。 SAP針對SAP和非SAP系統之間替換的數據遷移工具分為兩類：一類是專門針對少量數據遷移的SAP專有系統遷移工具(LSMW)，其可以非常方便將少量文本文件導入、導出;還有一類是針對大批量數據導入、導出的批導入工具，該軟體類似於WORD里定義的宏概念。 另外，微軟、ORACLE、IBM等資料庫廠商也提供相應數據遷移工具，還有很多第三方公司開發的工具，如Ascential Software公司的DataStage。這些工具也可以從多個不同的業務系統，多個平台的數據源中抽取數據，完成轉換和清洗，裝載到各種系統里。 目前，通過工具遷移是最普遍的方式，但是用戶在使用的時候經常遇到的情況是，原來系統中遇到的數字，並不是客戶想要的准確數字。所以在通過工具遷移過程當中，派一至兩個人檢查，對新系統導入的准確性和有效性是有很大幫助的。 而在實際ERP數據遷移過程中，同時採用通過工具遷移和手工錄入方式可能更為合理，即少量數據通過手工導入，大量數據通過工具遷移。比如對於倉庫中上千種物料，通過工具遷移更為合適;而對於少量數據導入，如果還通過工具遷移，遷移的准確性肯定需要手工盤點來判斷，如果之間出現誤差，相關工作人員會再重新進行盤點或重新手工導入數據，其帶來的繁瑣程度大大超過直接錄入。 數據檢驗也要靠人判斷 在對舊ERP系統數據遷移完成後，用戶還需要對遷移後的數據進行校驗。而檢驗的指標應包括數據的准確性、有效性、一致性3部分。神州數碼管理系統有限公司易飛服務部經理梁景茹指出，對於檢驗用戶可以自己編制一些小軟體，按業務流程和一些數據進行模擬，看最後的數據結果和報表是否正確。 但SAP咨詢部中國區技術咨詢經理趙旭民認為，除程序檢測外，最好還要通過系統外的方法，即非計算機程序或軟體程序來判斷數據遷移的有效性和准確性。他說，「計算機程序沒有智能行為，要判斷數據的有效和准確一定要靠廠商中的實施顧問和客戶中的關鍵用戶。」 趙旭民認為，對於單一的數據，並沒有辦法判斷數據的有效性或准確性，最後判斷的根本還要回到原系統本身的運行狀態和運行結果，如果原系統的業務流程或數據模式不合理的話，數據根本就不需要再進行遷移也就無需檢驗了。

㈡ 基金行業的IT 基礎架構建設需要考慮哪些因素才能滿足「雲化要求」

雲時代，基金行業雲化除了靈活、高效、低成本之外，還必須滿足穩定、高性能、高安全性等要素。Nutanix 超融合基礎架構和企業雲操作系統軟體解決方案可以滿足基金行業的「雲化要求」。

基金行業可以在新的數據中心部署Nutanix 超融合基礎架構和企業雲操作系統軟體解決方案，並將資料庫管理、自動化辦公和容災等主要業務系統遷移至Nutanix平台上。

這能有效提高企業新數據中心的效率和生產力，同時減少了企業管理開銷和存儲空間。通過減少用於基礎設施「維護」上的時間，提高IT系統整體性能和靈活性，基金行業才能夠將更多的資源投入到新的業務模式開發之中，以適應新的挑戰。

另外，Nutanix內置的容災保護功能，可以通過顯著提升容災的恢復時間目標 （RTO） 和恢復點目標 （RPO），有效降低基金容災的技術復雜程度，使得基金企業能夠更加迅速地應對所有系統中斷或故障，快速恢復系統正常

㈢ 超融合注意事項有哪些

選型？還是轉型？抑或運營？姑且認為你是在問傳統架構轉型超融合的准備與注意事項吧。

超融合架構相對傳統架構具有高性能、部署維護簡單、易擴展等一系列優點，在使用模式、部署模式和維護模式都有較大區別，是傳統 IT 架構向新型 IT 架構的升級。所以在決定轉向超融合的時候，需要全面考慮以下幾點：

1. 現狀和需求分析

如上所述，超融合架構對 IT 基礎架構的改進是全面的，但用戶應該首先梳理當前的主要痛點有哪些，從而在產品選擇時，進行更有針對性的評估。

2. 超融合產品的選型

通過深入了解各廠商產品的優劣勢，然後進行 POC 測試驗證，結合預算等方面進行超融合產品的選定。

3. 虛擬化平台的選擇

因為超融合可以支持多種虛擬化平台，所以需要結合醫院現使用的虛擬化平台進行考慮，是否繼續選用現使用的虛擬化，還是採用其他虛擬化平台，因為關繫到未來業務系統遷移的復雜程度。

4. 資源規劃

如果是傳統架構淘汰，更換為新的超融合基礎架構，需要統計現有資源的使用情況，來規劃能夠承載現有業務系統的資源，另外再加一部分預留資源，給予故障後承載。

如果是新建數據中心或者是新上業務系統採用超融合，那麼可以計算和存儲資源均衡的方式進行構建，未來資源不足的情況下，可以直接擴充。

5. 業務系統的遷移規劃

比如一些要求的停機時間窗口較小的場景（如醫院），需要提前進行各業務系統分析，選擇最佳的遷移方式，進行測試模擬，規劃出准確的停機時間，以及回退方案。

6. 整體方案規劃

不論是先試點還是一次性全部替代，最好能夠有一個整體規劃，包括備份、雙活、網路、安全等等方面，能夠採用超融合基礎架構逐步地去完成。

整體來說，由於超融合架構比較簡單，而且使用標準的 x86 伺服器和乙太網交換機，所以切換是比較容易的，對團隊的要求也比較低，不需要太多的准備條件。

㈣ 企業上雲服務過程中，應該注意哪些方面

當下是中小企業上雲的最佳時機，藉助雲服務優化企業管理，縮小與大企業間的信息化鴻溝，市中小企業實現轉折的一次契機！但是企業上雲並非易事，要不得盲目。這里借用容商天下副總裁徐延政的一段話來給廣大中小企業業主提個醒：企業上雲之前，要做的第一步並不是選擇雲服務廠商，而是了解「企業上雲」、企業自身結構及生產特點，並制定一份完整的上雲規劃。

1、信息收集

「企業上雲」需要進行嚴謹細致的調研工作，需要收集硬體及網路環境信息、現有及將來可能增加的業務各類需求、系統配置信息、應用系統信息、數據風險等。

2、需求評估

從業務需求的角度分析各業務的目前現狀、存在的問題、是否可以雲化、業務未來的發展需求，定製對各個業務系統遷移的目標。

從系統的角度分析各系統的目前現狀，包括了主機、存儲、網路及安全，分析系統存在的問題，根據評估結果進行規劃。

3、應用分析

應用分析是成功上雲，降低業務停滯時間的關鍵。根據業務的負載、特性、復雜性、關聯性分析確定並量化業務上雲風險可能對業務造成的影響及損失，以確定業務上雲的優先分批范圍及上雲策略。

4、風險分析

根據收集到的相關信息對目前系統進行業務上雲的風險分析，分析各種潛在危險並針對可能發生的危險事件，採取相應措施。

5、上雲策略

「企業上雲」策略可遵循：統籌規劃、分步實施、由易而難、由簡單到復雜。一般順序：（1）獨立應用的系統，如郵件系統、合同系統；（2）應用堆疊的應用系統，如辦公OA；（3）存在業務依賴的系統，如CRM、ERP、MES系統；

㈤ 機房搬遷詳細方案

機房搬遷不僅僅是把機房的設備遷移到新機房那麼簡單，而是要求網路系統的遷移和集中存儲系統的遷移必須安全平穩，不能過長時間影響生產應用。表面上就是幾個IT 民工的搬運，但實際是一項目高度集中的體力與腦力的綜合項目。現將一般機房搬遷步驟介紹如下：

1、新機房的准備

2、搬遷規劃

3、系統的備份

4、設備文檔的准備

5、搬遷設備標簽

6、設備拆除、打包和運輸

7、設備重新安裝

8、測試及驗收，

具體每個步驟的的工作應該怎樣開展，都有詳細的介紹。遠瞻分享丨全面介紹機房搬遷需要做哪些步驟及實施方法？網頁鏈接。希望能幫助到您。

㈥ 企業IT應用系統向雲遷移如何估算成本

然而，向雲遷移卻牽扯著許多的問題，企業需要評估遷移需要的成本，以最合理的方式和成本進行遷移。 企業需要以下兩個步驟： 1、評估需求 人們很容易低估將應用程序遷移到雲環境的成本。例如，你可能會估計所需要的特定大小的伺服器數量，你需要使用這些伺服器多久以及你將使用的存儲數量。這會幫助你粗略估算出雲成本，對吧?但這並不能讓你估算出你的應用程序在雲環境的運營成本，這種計算並沒有包含讓應用程序在雲中部署和運行的成本。為此，我們需要考慮雲遷移的評估、設計和執行的成本。 本文中我們只考慮一種情況，即將現有應用程序從企業內部基礎設施遷移到公共雲供應商提供的基礎設施即服務(IaaS)中。遷移應用程序到新平台(例如Google Engine或者Heroku平台)不屬於本文討論的范圍。 這種系統可能使用相對較少的腳本，並且復制數據的方式並不需要與其他應用程序的協作，同時以相對簡單的方式將生成的數據傳遞給用戶，例如基本報告或者警報。而另外一方面則是跨越多個伺服器，具有復雜工作負載，大量依賴網路，並在業務運作中發揮關鍵作用的應用程序。這些應用程序也可以遷移到雲環境，到那時需要進行大量的規劃和設計工作。一旦確定了需要遷移的應用程序，你就可以開始仔細研究功能要求和運作依賴性。 雲遷移的部分成本來自於向你的應用程序提供配套服務的需要。很多應用程序需要身份驗證，並依賴於企業內的LDAP或Active Directory服務。這些目錄能夠全部或者部分復制到雲環境中嗎?如果可以的話，你還需要考慮維護費用。如果不可以，你需要確定如何確保能從雲端伺服器訪問這些目錄。這可以像改變防火牆設置一樣簡單，或者還需要添加雲端伺服器到你的VPN，這會產生額外的運營成本。 你還需要評估初始數據載入的需要。你可能有相當多的數據要復制到雲存儲。除了直接成本外，還應該考慮復制數據到雲端所需的時間。 幾乎沒有應用程序是完全孤立的孤島。大多數應用程序依賴於其他系統的數據或者應用程序服務。你應該確定在雲端運營的遷移應用程序是否能夠訪問這些服務(例如有沒有防火牆限制)?另外，還要考慮到雲端應用程序的網路流量是否有更長的延遲，這是否會對應用程序性能造成不利影響?最好盡可能早地確定這些依賴性，以避免需要重新修改設計和部署。 確定遷移到雲端的應用程序是否具有故障恢復功能。應用程序伺服器和資料庫可以在故障轉移集群中配置，可以用於執行階段來簡化遷移的最後步驟。 2、設計和執行雲遷移 這可能需要一個了解應用程序、網路配置和存儲架構的設計團隊，因為他們將需要考慮訪問控制、網路安全、數據傳輸和軟體授權等問題。例如，如果配套服務將部署在主應用程序中，軟體架構師將需要確定這些服務在哪裡運行以及如何配置組件。設計團隊將需要考慮數據該如何被復制到雲端。小量數據可以通過網路復制到雲環境，但是大量的數據應該通過磁碟復制到雲端。 當在雲環境伺服器中運行商業應用程序時，請一定要確定是否需要獲得軟體許可。這對於在公共雲廣泛應用之前創建的舊應用程序而言，尤為重要。 執行應用程序雲遷移 遷移應用程序到雲環境的最後一個元素是實際執行。如果早期評估和設計階段很全面的話，這個過程應該會有一些驚喜。在執行階段，你需要與雲服務供應商討論管理要求，建立和部署機器映像，配置網路基礎設施，並確保對企業內部應用程序中數據的最後修改都完整地復制到雲應用程序數據存儲中。 對應用程序新部署的測試需要確保應用程序進行了正確的配置，並且企業內部和雲端資料庫中的數據相同。 最後一步就是從企業內部系統切換到雲端應用程序。這個步驟非常簡單，只要關閉這一個，開啟另一個即可，當然，還可能涉及更多操作，這取決於應用程序的類型。 將應用程序從企業環境遷移到雲環境富有挑戰性，因為應用程序可能存在復雜的依存關系和互操作性問題。評估當前的配置，制定一個遷移計劃，並有條不紊地執行這個計劃，可以幫助你減輕風險，並減少昂貴的遷移錯誤。