那些年,我們一起遷移過的資料

發布日期: 01/06/2022
feature image

AvePoint的老牌地端遷移軟體,DocAve Migrator已於2021年12月30日下線,作為SharePoint資料移轉全球最知名的軟體之一,從2002年正式投入使用,她已經服役了整整19個春秋。

2002年,那是一個怎樣的年代?台劇《流星花園》走紅、韓日世界盃,中國隊參賽、周傑倫稱霸歌壇、非典疫情肆虐,上海贏得2010年世博會主辦權。

那年的手機還是黑白屏為主,貪吃蛇是最火的,後來出來了諾基亞7650的廣告,首款拍照手機,還是滑蓋的,在一系列鋪天蓋地的廣告中傳達了很多前瞻性的概念——他們如今已經成為現實,比如,旅遊中用手機拍照記錄沿途的風景;多人自拍,將照片導到電腦中修圖等等。

而那時的微軟,剛剛在2001年買下NCompass Labs,這是一家專門做企業門戶網站、知識管理的軟體公司,微軟將其的核心功能同SharePoint整合,推出”SharePoint Portal Server 2001″。microsoft teams2002年是SharePoint的概念開始傳播的一年,越來越多的大型組織、企業開始使用這一平臺。2003年,微軟順勢推出SharePoint 2003,結果在平臺升級之時,惹了麻煩。

在SharePoint年代,平臺級別的升級都是大問題。從SharePoint 2003、2007、2010、2013、2016、2019,每次都得扒一層皮。

為什麼呢?

一、微軟的預設升級方式中,平臺升級時是不可用的。用戶無法訪問。

二、升級之後,全部客制化元件、工作流等,都必須重寫。

三、一旦升級失敗,只能回滾到原始狀態。

既然升級這麼麻煩,那我們不升級行不行呢?

當然不行。後續會有更多的麻煩。

比如,我們有過金融行業的客戶,如今還在使用SharePoint 2010,環境已經老舊不堪,存取速度也相當遲緩。因為政策原因,無法上雲,遂琢磨能不能遷移資料到SharePoint 2019,可是被微軟的合作夥伴告知:如採用微軟默認的升級方法,要先從SharePoint 2010升級到2013,再從2013到2016,2016再升2019,一共三次升級,期間不能出絲毫差錯。客戶當場要瘋,管理層後悔不已:早知今日,何必當初!當年要是每兩年升級一次,也就不會有這麻煩事了。

2002年那會兒,微軟找到AvePoint,說是有一家客戶不接受升級時平臺不可用,他們不允許有宕機時間。於是,AvePoint將之前主打的備份產品進行調整,做出了DocAve Migrator,這是地端遷移軟體的雛形。沒想到它幾乎每年都是AvePoint賣得最好的軟體。甚至微軟的技術中心(Microsoft Technology Centre)也使用AvePoint的遷移軟體,原因很簡單,也是不接受升級宕機。

他們往往都是AvePoint遷移工具的目標客戶。因為遷移並不是升級,你得先行準備好一個空的環境,然後把老環境裡的資料搬過去。這個概念就像搬家一樣,而升級更多是原地址裝修的感覺,地兒不變。所以,前文提到的跨多版本SharePoint升級就有解了,你只要創建一個SharePoint 2019的環境,直接從SharePoint 2010把資料搬過去就可以了。

AvePoint的遷移是始於微軟家的SharePoint,之後慢慢延伸至非微軟的平臺,比如:File Share、Documentum、Lotus Notes、Livelink、eRoom等。這些平臺的名字如今看來就像看《春秋》中的將領,透露著一股歷史感和滄桑勁兒。但是不管怎麼說,這些老古董的平臺如今做一家少一家,行至2021年,還在用著的客戶鳳毛鱗角了。這些死撐著不搬的客戶,多數源於平臺過於重要,資料和客制化過於沉重,這時候就不是軟體能解決的了。你需要考慮遷移服務。只說亞洲,大中華區(包括港、澳、臺地區)、韓國、日本、新加坡每年遷移服務帶來的收入,占AvePoint整體營收的40%以上。通常,要遷移服務,而不是遷移軟體的客戶,他們都有著極其明確的需求。

舉個例子:日本的Y公司,使用Notes幾乎要30年,遷移的前提是將Notes平臺完全遷至M365和SharePoint2019的混編平臺。這就需要大量的諮詢服務,來瞭解、分析客戶源端環境,繼而在微軟的雲端、地端平臺找到相應的解法,之後才是遷移。遷移之後,要培訓用戶有更換平臺的意識,企業傳統的管理模式亦要發生相應的變化等等。所以,這種場景之下,服務是大頭,而遷移僅僅是產生結論後,扮演將其落地的角色。

再比如:新加坡的A公司被來自美國的C公司收購,收購完成日期是在三個月之後,但是A公司的File Share、SharePoint地端和M365俱含有大量的資料需要遷移至C公司的文檔管理平臺內(DMS),總數據量達到270TB。那麼AvePoint的做法是,將遷移軟體佈署在Azure的虛擬機器上,虛擬機器越多,遷移軟體跑得執行緒也就越多,也就是說,只要客戶能保證提供足夠多的Azure服務,在極短的時間內完成如此重量級的遷移並不難。當然,這對實施團隊的業務素質、排錯能力、支援能力都要求較高。

還有,如今進入M365的雲時代,雲端的平臺就在那裡。所以遷移的做法逐漸成為主流是不可避免的趨勢。而疫情之下,加速了更重遷移專案的發生,而人員無法到場,遷移服務成為這些企業快速上雲的首選。

我們曾經在韓國和某汽車企業有過接觸,他們之前僅僅是專案部門要求將資料從SharePoint 2016遷移至M365,因為他們有強烈地使用Teams的需求,但是企業人員大都在家辦公,IT人員無法到場實施遷移,後經總部批准後,採用AvePoint線上遷移服務,一周將TB級別資料搬完。其他部門爭相效仿,從2020年疫情爆發開始到現在,該車企已有70%的用戶上雲。

所以,用遷移軟體,還是遷移服務,一切全看客戶源端的複雜程度,以及他們自己的需求。如果沒有那麼著急,資料結構相對單純的,用軟體就好;而源端相對複雜,需求又相對特殊,還是用服務比較合適。

這就讓DocAve Migrator的地位略顯尷尬了。

因為吧,大多數人都往雲上跑,既然上雲了,就不喜歡在硬體上投入了,遷移軟體都想要SaaS的,你整個DocAve Migrator還要裝備硬體、再上去安裝,實在不怎麼討人喜歡——故而,越來越多的客戶選擇了FLY,這是AvePoint另一款主打M365遷移的軟體,當下已經支援SaaS版本,無需任何安裝,即連即用。

如果客戶是陳舊的版本進行資料移轉,無論是不是SharePoint相關,大都是火燒眉毛,必須立即就開做的項目,這時候賣的都是服務,而非軟體。

再有,DocAve Migrator畢竟研發的年代久遠,還是建立在Silverlight架構之上,而Silverlight更是在上個月,微軟方面宣佈停止支援,這就註定了DocAve Migrator慢慢走下神壇,日漸沒落。然而,它的歷史使命已經完成。

如今,遇到遷移的需求,AvePoint首推的軟體是FLY,因為簡單、易用,對用戶更為友好;而涉及老舊版本的地端遷移,我們願意坐下來和客戶談談。本該在五到十年前解決的事情,放到現在才做,這已經不是軟體的事了,這裡肯定有複雜的狀況導致事情停滯不前,我們說說哪裡有坑,如何進行。

軟體,在這個時代,還是無法替代人的。

懷念那些年,我們用DocAve Migrator遷移過的資料。

記得2009年《阿凡達》大火,結尾處,男主角傑克最終放棄地球人身份,成為阿凡達星的一員,當時負責DocAve Migrator的售後支援同事笑著說:”男主角作為單一檔,搬移成功,但是原始檔案屬性徹底變了。”

2011年那會兒,《變形金剛》上映,遷移軟體的開發同事在Yahoo Messager上的簽名是:”《變3》講得就是個塞伯坦星球往地球做資料移轉,但是Job沒成功的故事!”

看《鋼鐵俠》,托尼·斯坦克通過和賈維斯的對話來實現家庭智慧管理,當時在JIRA上曾有同事提出:”對話機器人,也應該放在我們的軟體中。”數年後,DocAve Migrator沒有實現,但是Cloud Backup實現了。

那時的人們,一手拿著小屏智慧機,一手iPod,脖子上掛著有線耳機,背著沉重的Window 7電腦——它們沒有結束,日子在不停地延續,慢慢進化成一個我們預料不及的樣子。

這些時光一晃都已經過了10年了。悄然間,一個新的時代在我們還沒有意識到什麼時候開始的時候,悄然開始,雖然算不上措手不及,但還是很遺憾的回頭,向曾經賣過的、支援過的、開發過的、演示過的、喜愛過的、大罵過的,DocAve Migrator說再見了。其實,這些年我們送別的軟體不只是DocAve Migrator,它僅僅是最有代表性的一個。它曾經很能打,但是現在逐漸沒了用武之地。

那些年,我們一起遷移過的資料,如今還要繼續遷著。眼瞅著,昔日的新家,成為了舊家;那些資料被移到一個個新的平臺上,繼續存在著。資料和軟體都是有生命的,生如夏花之絢爛,死如秋葉之靜美。他們終究會離去,只是他們相伴過的日子,已成為你我永不磨滅的記憶,是光陰故事的一部分。


追蹤AvePoint最新資訊?訂閱我們的部落格

Share this blog

訂閱我們的博客