那些年，我們一起遷移過的資料
AvePoint的老牌地端遷移軟體，DocAve Migrator已於2021年12月30日下線，作為SharePoint資料移轉全球最知名的軟體之一，從2002年正式投入使用，她已經服役了整整19個春秋。
2002年，那是一個怎樣的年代？台劇《流星花園》走紅、韓日世界盃，中國隊參賽、周傑倫稱霸歌壇、非典疫情肆虐，上海贏得2010年世博會主辦權。
那年的手機還是黑白屏為主，貪吃蛇是最火的，後來出來了諾基亞7650的廣告，首款拍照手機，還是滑蓋的，在一系列鋪天蓋地的廣告中傳達了很多前瞻性的概念——他們如今已經成為現實，比如，旅遊中用手機拍照記錄沿途的風景；多人自拍，將照片導到電腦中修圖等等。
而那時的微軟，剛剛在2001年買下NCompass Labs，這是一家專門做企業門戶網站、知識管理的軟體公司，微軟將其的核心功能同SharePoint整合，推出”SharePoint Portal Server 2001″。
2002年是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，它僅僅是最有代表性的一個。它曾經很能打，但是現在逐漸沒了用武之地。
那些年，我們一起遷移過的資料，如今還要繼續遷著。眼瞅著，昔日的新家，成為了舊家；那些資料被移到一個個新的平臺上，繼續存在著。資料和軟體都是有生命的，生如夏花之絢爛，死如秋葉之靜美。他們終究會離去，只是他們相伴過的日子，已成為你我永不磨滅的記憶，是光陰故事的一部分。
